If you build industrial equipment for the EU market, Annex I is the part of the Cyber Resilience Act you will actually be measured against. It is shorter than its reputation — and structured in a way that decides how much of it lands on you.
Two parts, two different kinds of obligation
Part I — security properties of the product. Its first point is unconditional: the product must be designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks, and be delivered without known exploitable vulnerabilities and in a secure-by-default configuration.
The rest of Part I — access control, confidentiality and integrity protection, data minimisation, availability and resilience, attack surface limitation, exploit mitigation, security logging, and secure update capability — is risk-driven. Which of them apply follows from the Article 13(2) risk assessment.
Part II — vulnerability handling. Eight requirements, and unlike Part I’s conditional set, these are unconditional. They are process obligations, and they are where most industrial OEMs have the largest gap.
The risk assessment is the gate, not the paperwork
This is the structural point worth internalising. You cannot decide that a Part I property does not apply because it is inconvenient. A “not applicable” verdict needs a documented justification grounded in the risk assessment — and without one, it is not N/A. It is not met.
Which makes the risk assessment the highest-leverage document in the whole exercise. Done properly it narrows your obligations defensibly. Skipped, every requirement in Part I point 2 lands on you by default and you have no argument.
The eight Part II duties, in the order they bite
- Identify and document vulnerabilities and components, including an SBOM in a commonly used machine-readable format, covering at least the top-level dependencies.
- Remediate without delay, including through security updates — and where feasible, ship security updates separately from functional updates.
- Apply effective and regular tests and reviews of product security.
- Publicly disclose fixed vulnerabilities once a fix is available, with enough detail to act on.
- Have a coordinated vulnerability disclosure policy in force.
- Provide a contact address for reporting vulnerabilities.
- Provide secure distribution of updates.
- Ensure security updates are disseminated without delay and free of charge, with advisory information.
Point 2 is the one that collides hardest with industrial reality. Customers who cannot take a functional change mid-campaign can often take a security-only patch — but only if your release engineering can produce one. If today every fix ships as a full firmware release, that is a build-system problem, and it takes longer to solve than the regulation gives.
Where the support period lands
Part II runs across the support period, which you determine to reflect how long the product is expected to be in use. It must be at least five years, unless the product is genuinely expected to be in service for less. Security updates must remain available for at least ten years after they are issued, and the technical documentation and declaration of conformity are retained for at least ten years or the support period, whichever is longer.
For industrial equipment those numbers are conservative rather than generous. A control product installed in a plant may run for twenty years. Whatever period you publish becomes an obligation the business carries for its full length, and it is stated at the point of sale.
The overlap with what you may already run
If you operate an IEC 62443-4-1 secure development lifecycle, a large share of Annex I is already being produced: threat modelling, secure design and implementation practices, security verification and validation testing, defect management, and a security update process. It is not a one-to-one mapping and nobody should claim it is — but an OEM with a mature 4-1 process is closer than one starting from a blank technical file, and the gap analysis is genuinely short.
The honest sequence for most industrial OEMs: classify the products, run the Article 13 risk assessment properly, gap Part I against what development already produces, then treat Part II as the programme it is — because process, not product features, is where the work sits.
We do that gap assessment and build the evidence trail behind it. If you would rather run it in-house, the CRA Workbench is the same structure as a workspace you operate yourself.