CRA secure data removal should be treated as a product lifecycle function, not merely a user-interface delete button. Manufacturers should identify where user data and settings exist, define how permanent removal works across local storage and relevant remote systems, distinguish reset from deletion, account for credentials and security configuration, test removal behaviour and provide clear secure-decommissioning instructions.
Annex I Requires Permanent Removal of Data and Settings
Annex I Part I point 2(m) requires products with digital elements, on the basis of the cybersecurity risk assessment and where applicable, to provide users with the possibility to securely and easily remove all data and settings on a permanent basis. This requirement is broader than deleting one user-visible document or signing out of an account. Manufacturers should identify the data and settings stored across the product and determine how the user can remove them through a clear lifecycle function. The design should consider both security and usability because a removal mechanism that technically exists but is difficult to locate or understand can undermine the requirement's practical purpose.
- Inventory user data.
- Inventory product settings.
- Define the permanent-removal mechanism.
- Make removal reasonably accessible to the user.
- Verify the actual removal result.
Factory Reset and Secure Data Removal Are Not Automatically the Same
The CRA separately addresses resetting a product to its original state under the secure-by-default requirement and permanently removing data and settings under point 2(m). A factory reset can satisfy both functions only if its actual behaviour meets both requirements. Some resets restore configuration while leaving user files, cloud data, paired credentials or other information intact. Others remove data but preserve security-relevant enrolment. Manufacturers should therefore document reset and removal as separate product behaviours and verify whether one implementation legitimately performs both. User information should avoid implying complete data removal where residual data remain.
- Define what factory reset removes.
- Define what factory reset retains.
- Compare reset behaviour with point 2(m).
- Do not claim permanent deletion without verification.
- Document residual data where relevant.
Data Can Exist in More Places Than the Main Storage Area
Permanent removal requires understanding where information exists. Product data can appear in databases, files, caches, temporary storage, logs, diagnostic bundles, removable storage, browser storage, firmware configuration, synchronised devices and cloud services. Copies can also exist in backups or external systems outside the immediate product boundary. Manufacturers should map these locations and determine which are part of the product's removal capability and which require separate user instructions or operational processes. The analysis should be grounded in the actual product architecture rather than a simplified assumption that deleting the primary database removes everything.
- Identify primary storage.
- Identify caches and temporary data.
- Identify logs and diagnostics.
- Identify synchronised or remote data.
- Identify relevant backup behaviour.
Secure Removal Depends on the Storage Technology
The technical meaning of secure removal can vary by storage architecture. Traditional overwrite assumptions do not necessarily apply to flash storage, wear levelling, managed cloud storage or encrypted storage. In some designs, cryptographic erasure can make retained ciphertext inaccessible by securely destroying the relevant key. In others, the underlying platform provides deletion capabilities that the product must invoke correctly. The CRA does not prescribe one deletion algorithm in point 2(m). Manufacturers should choose a method appropriate to the product, storage technology, cybersecurity risks and available platform guarantees, then verify that the product behaviour matches the documented method.
- Identify storage technology.
- Understand platform deletion guarantees.
- Consider cryptographic erasure where appropriate.
- Protect deletion credentials and keys.
- Test the selected removal mechanism.
Credentials and Security Configuration Are Part of Decommissioning
A product can remain security-sensitive after ordinary user content has been deleted. Stored credentials, API tokens, certificates, pairing information, network configuration, trusted devices, administrator accounts and cryptographic keys can allow later access to user resources or connected systems. Secure removal and decommissioning should therefore consider the product's security state as well as visible content. Manufacturers should determine which credentials must be revoked, destroyed or unlinked when the product changes owner or leaves service. Where external accounts remain active after local removal, user instructions should explain any separate action needed.
- Remove or revoke stored credentials.
- Remove pairing relationships where appropriate.
- Remove security-sensitive configuration.
- Address external account links.
- Verify ownership-transfer behaviour.
Cloud-Connected Products Need a Clear Boundary
A cloud-connected product can store information both locally and on manufacturer-operated or third-party services. A local reset might leave remote information untouched, while cloud account deletion might leave local data on a device. Manufacturers should make the relationship clear and design removal flows appropriate to the product boundary. Where users need separate actions for local and remote removal, those actions should be understandable. The product team should also identify what data are retained for security, contractual or legal reasons outside the normal user-removal path and ensure that product claims accurately describe the behaviour.
- Separate local and remote data locations.
- Define which action removes each category.
- Avoid ambiguous delete-all claims.
- Document external-service dependencies.
- Test decommissioning with cloud connectivity unavailable where relevant.
Secure Transfer Is Part of Point 2(m)
Point 2(m) also provides that where data can be transferred to other products or systems, the transfer must be secure. This can be relevant during migration, replacement, device ownership changes or export-and-import workflows. Security should cover the transfer mechanism itself, including appropriate confidentiality, integrity and authentication controls based on the risks. Manufacturers should also consider temporary export files because a secure network channel does not protect a sensitive unencrypted archive left on local storage after transfer. The transfer workflow should therefore be considered from creation through delivery and cleanup.
- Protect data confidentiality during transfer.
- Protect integrity during transfer.
- Authenticate transfer destinations where appropriate.
- Protect temporary export files.
- Clean up transfer artefacts when no longer needed.
Annex II Requires Secure Decommissioning Instructions
Annex II requires detailed instructions, or an internet address referring to them, concerning secure decommissioning of the product, including information on how user data can be securely removed. This means the implementation and user documentation should agree. Instructions should identify the relevant removal or reset actions and any additional steps required for linked accounts, removable media, external services or credentials. Product documentation should be reviewed when removal behaviour changes because outdated instructions can leave users believing data have been removed when the architecture has changed.
- Provide secure decommissioning instructions.
- Explain how user data are securely removed.
- Explain separate cloud or account actions.
- Explain removable-media handling where relevant.
- Keep instructions aligned with product versions.
Removal Should Be Tested End to End
Testing should verify the actual result of removal rather than only confirm that a user-interface action completes successfully. Product teams can inspect storage, configuration, credentials, paired relationships and relevant remote state after removal. They should also test interrupted deletion, unavailable cloud services, partial failures and repeated operations. Where cryptographic erasure is used, verification should confirm that the relevant keys are no longer recoverable through the supported product path. Ownership-transfer scenarios can provide a practical test because the next user should not gain access to the previous user's information or security relationships.
- Inspect storage after removal.
- Inspect credentials and configuration.
- Test interrupted removal.
- Test remote-service failure.
- Test ownership transfer.
- Record version-specific results.
Evidence for CRA Secure Data Removal
Evidence can include the product data inventory, storage map, removal architecture, reset-versus-deletion specification, credential-cleanup design, cloud-removal flow, secure-transfer design, decommissioning instructions and verification results. The manufacturer should be able to show which data and settings are removed, by which mechanism and under which conditions. Where some information exists outside the product's direct control, the dependency and required user action should be explicit. Changes to storage technology, account architecture or cloud services should trigger review because they can invalidate earlier removal assumptions.
- Data and settings inventory.
- Storage-location map.
- Removal architecture.
- Reset and deletion distinction.
- Credential cleanup evidence.
- Secure-transfer design.
- Decommissioning instructions.
- Removal verification results.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.