Under the Cyber Resilience Act (CRA), secure decommissioning is not just an end-of-life support topic. Annex I requires, on the basis of the manufacturer's cybersecurity risk assessment and where applicable, a product with digital elements to give users a secure and easy way to remove all data and settings permanently. Annex II separately requires manufacturers to provide detailed instructions for secure decommissioning, including how user data can be securely removed.
For product teams, the practical requirement is therefore two-sided: build a removal mechanism that works for the actual product architecture, and give users enough information to use it correctly. A generic factory-reset label is not sufficient evidence if credentials, cloud associations, removable storage, backups or other product state remain outside the reset path.
The CRA's main obligations apply from 11 December 2027. Manufacturers can use the preparation period to map where user and security-relevant state exists, define decommissioning behavior and add repeatable verification to product and release testing.
Start with the two CRA requirements
Annex I Part I point 2(m) requires products, based on the cybersecurity risk assessment and where applicable, to provide users with the possibility to securely and easily remove on a permanent basis all data and settings. Where data can be transferred to other products or systems, that transfer must be secure.
Annex II point 8(d) addresses the user-facing side. The information and instructions accompanying the product must explain secure decommissioning, including how user data can be securely removed.
These provisions should be treated together. The technical mechanism determines what can actually be removed; the instructions need to describe the real mechanism and its boundaries. If the implementation changes, the decommissioning guidance should be reviewed with the same product or release scope.
Define what “all data and settings” means for the product
A useful decommissioning design begins with an inventory of product state. The exact inventory depends on the architecture, but teams should consider at least:
- user-created content and uploaded files;
- account identifiers and locally cached profile data;
- authentication tokens, session material and stored credentials;
- cryptographic keys that belong to the user or device state;
- network credentials and paired-device relationships;
- configuration, preferences and security settings;
- logs or diagnostic records containing user or security-relevant data;
- application databases and caches;
- data on removable or auxiliary storage controlled by the product; and
- references to remote services, accounts or backups that remain associated with the product.
Do not assume that deleting the primary application database covers the full product state. The evidence should show which storage locations and associations were considered and which mechanism handles each one.
Separate reset, deletion and decommissioning semantics
Products often already expose actions called reset, restore, unlink, remove account or erase device. Those labels do not prove that the CRA decommissioning objective is met.
Define the semantics explicitly. A configuration reset may restore defaults while leaving user files intact. Removing an account from a user interface may leave a device token or remote association active. Reinstalling software may leave persistent partitions untouched. A secure-decommissioning path should have a documented end state that teams can test.
For each user-facing action, record what data and settings it removes, what state intentionally remains, whether credentials or tokens are invalidated, whether linked services need a separate action, what happens if the operation is interrupted, and how completion is shown.
Design removal around the cybersecurity risk assessment
Annex I point 2 applies its detailed product properties on the basis of the cybersecurity risk assessment and where applicable. The decommissioning design should therefore be connected to the product's identified assets, trust boundaries and risks rather than implemented as an isolated convenience feature.
Consider what could happen if a product is sold, returned, recycled, reassigned, discarded or transferred to another user without effective removal. Depending on the product, residual state may expose account access, network credentials, operational data, security configuration or other information that affects confidentiality or later control of the product.
The risk assessment should help determine which state needs removal, which associations need revocation, what assurance the removal mechanism needs and which failure modes matter. Preserve that reasoning so a later release does not silently weaken the decommissioning behavior when storage or identity architecture changes.
Make the user path secure and easy to operate
The CRA wording combines security with usability: the product should provide the possibility for users to remove data and settings securely and easily. Engineering and UX review should cover whether intended users can find the function, whether destructive actions are appropriately protected, whether permanent removal is distinguished from a temporary reset, whether deletion scope is explained, and whether completion and failure states are clear.
The correct design depends on product context. The useful evidence is the documented decision and verification for the actual product rather than a universal interface pattern.
Handle credentials, keys and external associations explicitly
Deleting ordinary files is only one part of decommissioning for connected products. A product may remain trusted by another system after local storage has been cleared.
Review device credentials, API tokens, certificates, pairing records and service registrations. Determine which can be destroyed locally, which need server-side revocation or de-registration, and which are not user-controlled state. Where another system must perform part of the process, make the dependency clear in both the design and user instructions.
ENISA's Secure by Design and Default Playbook recommends planning secure decommissioning and disposal, including data-erasure mechanisms and guidance such as factory reset, key revocation and account de-provisioning. It also recommends defining decommissioning actions as part of lifecycle and release controls. This is useful engineering guidance for turning the CRA requirement into a repeatable process; it does not replace the Regulation's legal text.
Treat secure transfer as part of the decommissioning path
Annex I point 2(m) also addresses data that can be transferred to other products or systems: the transfer must be secure. This matters when decommissioning includes migration to a replacement device, account export or another handover workflow.
Document what is transferred, how the destination is authenticated where relevant, how confidentiality and integrity are protected, and what happens to the source copy after a successful or failed transfer. A useful test should include both successful migration and interruption.
Write Annex II instructions from the tested behavior
Annex II requires detailed instructions, or an internet address referring to them, covering secure decommissioning and secure removal of user data. Write those instructions from verified product behavior rather than from a generic security template.
The guidance should explain where to start the process, prerequisites, what categories of data and settings are removed, separate handling for removable media or linked services, secure transfer where available, irreversible consequences, completion indication and failure recovery.
Keep product version and documentation version aligned. If a release changes storage, identity or reset behavior, the user guidance may need to change even if the feature name remains the same.
Test the real decommissioning end state
A useful test does not stop when the interface displays “reset complete.” Verify the resulting state. Evidence can include the seeded starting state, the exact procedure, checks of relevant storage, confirmation that credentials expected to be invalid are unusable, checks of paired systems, the intended post-decommissioning configuration, interruption behavior and the exact software or firmware version tested.
Automated tests can cover repeatable software behavior, while hardware, removable storage or service interactions may require additional integration tests. The CRA does not prescribe one test format; choose evidence that demonstrates the behavior of the product being assessed.
Include decommissioning in change and release review
Secure removal can regress when teams add a new database, credential store, telemetry cache, partition, cloud service or pairing mechanism. A decommissioning control should therefore be part of lifecycle change review rather than a test performed only before initial market placement.
Release review should ask whether a change introduced new persistent state, changed authentication or key storage, added external associations, altered reset coverage or made the Annex II instructions inaccurate. Tie the resulting test evidence to the release or to a justified unchanged baseline.
Preserve evidence without storing the user's erased data
Evidence of a successful decommissioning control does not require retaining the sensitive user data that the product is designed to remove. Preserve the test scope, expected state, procedure, result, product version and relevant assertions without copying unnecessary user content into compliance records.
Keep decommissioning evidence connected to the product lifecycle
Secure-decommissioning evidence can become stale when reset behavior, storage architecture and user instructions live in separate systems. Teams need a way to show which requirement, test result, documentation revision and product release belong together.
AA-sec is designed around traceability between requirements, security evidence, decisions and exact product or lifecycle context. That model can help teams organise decommissioning evidence alongside other CRA-readiness work while existing engineering, CI/CD and product systems continue to own implementation and testing.
Key takeaway
CRA secure decommissioning requires teams to connect product behavior with user guidance. Where Annex I point 2(m) applies, users need a secure and easy way to remove all data and settings permanently, and Annex II requires instructions explaining secure decommissioning and user-data removal.
Map the complete product state, define the intended post-decommissioning condition, handle credentials and external associations explicitly, test the real end state and keep the instructions aligned with each relevant release. The resulting evidence should show not merely that a reset control exists, but that the product's actual decommissioning path was understood and verified.