CRA Annex I is the practical centre of product cybersecurity compliance. Part I covers the security properties expected of the product, including risk-appropriate security, secure configuration, access control, confidentiality, integrity, resilience, attack-surface reduction, logging and secure data removal. Part II covers vulnerability identification, remediation, testing, disclosure, coordinated vulnerability disclosure, update distribution and related processes. Manufacturers need to map these legal requirements to product-specific controls and evidence rather than treat Annex I as a generic corporate security checklist.
Annex I Is the CRA's Core Product-Security Requirement Set
Article 6 connects market availability directly to Annex I. A product with digital elements may be made available on the market only where the applicable requirements are met under the conditions set by the Regulation. Part I concerns the cybersecurity properties of the product itself. Part II concerns the vulnerability-handling processes put in place by the manufacturer. Article 13 then places these requirements into the manufacturer's lifecycle responsibilities. This structure matters because CRA compliance is not satisfied by maintaining a general information-security policy. The manufacturer needs product-level evidence showing how the relevant Annex I requirements have been interpreted and implemented for the specific product, its intended purpose, foreseeable use, architecture, components and cybersecurity risks.
- Part I addresses cybersecurity properties of products with digital elements.
- Part II addresses manufacturer vulnerability-handling processes.
- Article 6 makes Annex I central to placing covered products on the market.
- Article 13 connects Annex I to risk assessment and lifecycle implementation.
Part I Starts With Risk-Appropriate Product Security
The first requirement in Annex I Part I establishes the baseline: products with digital elements are to be designed, developed and produced so that they ensure an appropriate level of cybersecurity based on the risks. This is a risk-based requirement rather than a statement that every product must implement an identical control set. A low-complexity local tool and a remotely administered infrastructure product can present very different attack paths, privileges, data exposure and consequences. The manufacturer's cybersecurity risk assessment therefore becomes the bridge between the legal requirement and the technical control design. Teams need to be able to explain why selected controls are proportionate to the product's risks and why omitted or differently implemented controls remain appropriate for the product context.
- Start with the product's cybersecurity risks rather than a generic control catalogue.
- Connect security architecture decisions to the cybersecurity risk assessment.
- Document why controls are appropriate for the intended purpose and foreseeable use.
- Revisit the assessment when product changes alter relevant risks.
Part I Then Defines Specific Product Security Outcomes
Annex I Part I continues with a set of more specific outcomes that apply on the basis of the cybersecurity risk assessment and where applicable. These include making products available without known exploitable vulnerabilities, providing secure-by-default configuration, enabling vulnerabilities to be addressed through security updates, protecting against unauthorised access, protecting confidentiality and integrity, applying data minimisation, protecting essential and basic functions, limiting negative effects on other devices or networks, limiting attack surfaces, reducing incident impact, recording and monitoring relevant security activity and enabling secure removal of data and settings. The Regulation describes outcomes rather than prescribing one universal implementation technology. The manufacturer therefore needs to translate each applicable requirement into concrete product controls and verification evidence.
- Known exploitable vulnerability management.
- Secure-by-default configuration and reset capability.
- Security updates, including automatic updates where applicable.
- Authentication, identity and access controls.
- Confidentiality and integrity protections.
- Data minimisation.
- Availability and resilience.
- Attack-surface reduction and exploitation mitigation.
- Security logging and monitoring.
- Secure permanent removal of data and settings.
Part II Extends Annex I Into Vulnerability Handling
Part II addresses the processes manufacturers use to handle vulnerabilities in products with digital elements. The requirements include identifying and documenting vulnerabilities and components, addressing and remediating vulnerabilities without delay in relation to the risks posed, applying effective and regular security tests and reviews, publishing appropriate information about fixed vulnerabilities, maintaining a coordinated vulnerability disclosure policy, facilitating reporting of vulnerabilities, securely distributing security updates and ensuring that disclosed vulnerabilities are addressed through the manufacturer's processes. Article 13 also requires manufacturers to ensure that vulnerabilities, including vulnerabilities in components, are handled effectively during the support period. This means Annex I is not limited to the state of the product on release day.
- Maintain vulnerability and component information.
- Address and remediate vulnerabilities in relation to product risk.
- Perform regular security testing and review.
- Operate coordinated vulnerability disclosure processes.
- Distribute security updates securely.
- Maintain vulnerability handling during the support period.
The Cybersecurity Risk Assessment Determines How Annex I Is Applied
Article 13 requires the manufacturer to undertake an assessment of the cybersecurity risks associated with the product and to take the outcome into account during planning, design, development, production, delivery and maintenance. Annex I Part I point 2 expressly ties its listed outcomes to that assessment and uses the phrase where applicable. The result should not be a superficial table that marks every requirement yes or no without reasoning. A useful requirement map identifies the product feature or architecture area affected, the threat or risk being addressed, the control selected, the verification method, the evidence location and any rationale where a requirement is not applicable. Recital 55 also makes clear that where an essential cybersecurity requirement is considered not applicable, the manufacturer should include a clear justification in the cybersecurity risk assessment contained in the technical documentation.
- Identify the Annex I requirement.
- Identify the product risk or threat addressed.
- Map the requirement to a concrete product control.
- Define how the control is verified.
- Record the evidence location.
- Justify non-applicability where relevant.
Annex I Compliance Needs Product-Level Evidence
Conformity work needs evidence that the applicable requirements have been implemented in the actual product. Depending on the requirement, useful evidence can include architecture records, configuration baselines, threat models, access-control design, cryptographic design decisions, test results, dependency records, vulnerability tickets, update mechanisms, logging specifications, resilience tests and release approvals. The evidence should be traceable to the product version and risk assessment. A policy that says the organisation uses secure development practices may support the compliance system, but it does not by itself show that a particular product satisfies a confidentiality, integrity, attack-surface or vulnerability-handling requirement. Technical documentation under the CRA should therefore connect legal requirements, engineering decisions and verification records.
- Keep evidence tied to a specific product and version.
- Link risk decisions to architecture and implementation controls.
- Retain test and verification results.
- Keep vulnerability and update evidence connected to supported versions.
- Maintain traceability into the technical documentation.
Annex I Is Not the Same as the Conformity Assessment Procedure
Annex I states the essential cybersecurity requirements, while the conformity assessment provisions determine how conformity with applicable requirements is demonstrated. The assessment route can depend on product classification and other conditions in the Regulation. This distinction helps product teams avoid treating a certification or CE-marking task as a substitute for security engineering. The security controls and evidence need to exist before they can be assessed. Harmonised standards, common specifications or recognised certification mechanisms may help demonstrate conformity where the CRA provides for that effect, but the legal starting point remains the applicable Annex I requirement and the product-specific risk assessment. Engineering, security and conformity teams should therefore work from one shared requirement map rather than maintain separate interpretations.
- Annex I defines essential cybersecurity requirements.
- Conformity assessment determines how conformity is demonstrated.
- Classification can affect the available assessment route.
- Standards can support evidence but do not replace product-specific scope and risk analysis.
A Practical Annex I Requirement Map
A practical implementation model is to create one controlled Annex I matrix for each product or product family where the technical baseline is genuinely shared. The matrix should identify each relevant Part I and Part II requirement, applicability, the cybersecurity risks connected to it, implementing controls, responsible engineering owner, verification method, evidence repository and review trigger. This allows the same record to support design reviews, release gates, technical documentation and conformity preparation. It also makes product changes easier to assess because teams can see which legal requirements and evidence are affected when an interface, privilege model, dependency, update mechanism or intended purpose changes. The objective is not to turn Annex I into paperwork. It is to make the legal security outcomes traceable to the real product.
- Requirement and Annex I reference.
- Applicability and rationale.
- Related cybersecurity risk.
- Technical or process control.
- Control owner.
- Verification method.
- Evidence location.
- Review trigger and product version.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.