A CRA security instruction set should be operational, version-aware and written around user actions. It should explain what secure use requires at commissioning, what must remain true during operation, how security changes and updates affect the product, and how to remove the product and its data safely at the end of use.
Security Instructions Must Enable Secure Installation, Operation and Use
Article 13(18) requires Annex II information and instructions to allow for the secure installation, operation and use of products with digital elements. Annex II point 8 then specifies the detailed instruction topics manufacturers need to cover. A generic user manual can satisfy this only if it actually contains the security information users need for the relevant product.
- Write for secure product use.
- Use product-specific instructions.
- Keep instructions clear and accessible.
- Update them when security-relevant behaviour changes.
Explain Necessary Measures During Initial Commissioning
Annex II point 8(a) requires the necessary measures during initial commissioning and throughout the product lifetime to ensure secure use. Commissioning instructions can include changing credentials where relevant, enrolling devices, applying an initial security update, enabling required protections, establishing trusted connections or placing the product in the intended security environment.
- Initial security setup.
- Credential or identity configuration where relevant.
- Required security updates.
- Network or deployment conditions.
- Verification that secure defaults remain active.
Explain What Secure Use Requires Throughout the Product Lifetime
Secure commissioning is only the starting point. Annex II requires measures for secure use throughout the lifetime of the product. Instructions should explain recurring user responsibilities such as installing security updates, maintaining supported integrations, protecting administrative access, reviewing security-sensitive settings or following manufacturer guidance when the operating environment changes.
- Ongoing update practices.
- Administrative access protection.
- Supported configuration expectations.
- Security-relevant maintenance activities.
Explain How Product Changes Can Affect Data Security
Annex II point 8(b) requires information about how changes to the product can affect the security of data. Users should understand when configuration, extensions, integrations, firmware changes or other modifications can alter confidentiality, integrity or availability. The manufacturer does not need to predict every possible modification, but should explain the material security consequences users can reasonably encounter.
- Configuration changes.
- Extensions and integrations.
- Firmware or software changes.
- Security consequences for stored or transmitted data.
Explain How Security-Relevant Updates Can Be Installed
Annex II point 8(c) requires instructions explaining how security-relevant updates can be installed. The instructions should identify the normal update path, prerequisites, verification steps and any special process for manual or offline updates. Where several supported branches exist, users should be able to determine which package or version applies to their product.
- Normal update mechanism.
- Manual or offline procedure where relevant.
- Prerequisites and restart requirements.
- Version and package selection.
- Verification of successful installation.
Provide Secure Decommissioning and Data-Removal Instructions
Annex II point 8(d) requires secure decommissioning instructions, including information on how user data can be securely removed. Decommissioning can involve more than uninstalling software or powering off a device. Users may need to revoke credentials, remove cloud associations, wipe storage, reset cryptographic material, disconnect integrations or transfer ownership securely.
- Remove user data securely.
- Revoke credentials or tokens where relevant.
- Disconnect cloud or third-party integrations.
- Reset or retire security-sensitive configuration.
Explain How the Default Automatic Security-Update Setting Can Be Turned Off
Annex II point 8(e) requires information explaining how the default setting enabling automatic installation of security updates can be turned off. This instruction should be accurate for the actual product and should not hide the security consequences of disabling automatic updates. If the product provides postponement or alternative update controls, those options should be explained consistently with the product's update design.
- Identify the automatic-update control.
- Explain how the setting can be changed.
- Explain relevant security consequences.
- Keep instructions consistent with product behaviour.
Give Integrators the Information Needed for CRA-Compliant Integration
Annex II point 8(f) applies where the product is intended for integration into other products with digital elements. The manufacturer must provide information necessary for the integrator to comply with Annex I cybersecurity requirements and Annex VII documentation requirements. This can include security assumptions, interfaces, update dependencies, required configuration and limitations that affect the security of the combined product.
- Security assumptions for integration.
- Relevant interfaces and dependencies.
- Required secure configuration.
- Information needed for technical documentation.
Use Version-Aware Instructions
Security instructions can become inaccurate when software, firmware or hardware changes. Manufacturers should connect instruction maintenance to release management so supported versions receive the correct configuration, update and decommissioning guidance. Historical instructions should remain accessible where older supported products continue to operate differently from the current release.
- Tie instructions to supported versions.
- Update after security-relevant changes.
- Retain historical supported guidance.
- Avoid silently replacing old instructions with incompatible new ones.
Test the Instructions as Part of Product Readiness
Security instructions should be tested against the actual product before release. A technically correct control is not useful if the documented menu path, package name or decommissioning procedure is wrong. Product security, support and technical-writing teams can validate that a representative user can follow the documented steps and reach the intended secure state.
- Test commissioning instructions.
- Test update instructions.
- Test decommissioning steps.
- Verify version and interface references.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.