CRA Cyber Resilience Act.

What the Cyber Resilience Act actually regulates

The Cyber Resilience Act puts security obligations on the product, not just on the organisation that runs it. Anything sold in the EU that contains digital elements, meaning hardware or software with a data connection, falls in scope: connected consumer devices, industrial controllers, operating systems, libraries, mobile apps, even firmware shipped inside a component. The regulated party is the economic operator who places the product on the market, so manufacturers carry the main load, with importers and distributors held to verification duties. This is a shift in liability. For years the buyer inherited the risk of insecure software; the CRA moves a defined baseline of responsibility back onto whoever builds and sells it.

Because it regulates products rather than entities, the CRA reaches small vendors and open components that no organisational security law would ever touch. A firmware maker with no EU office still has to comply if the device reaches an EU shelf. That product framing is the single most important thing to grasp before reading anything else about it.

The obligations that bind a manufacturer

The CRA is built around a lifecycle. A product has to be secure when it ships and stay supportable while it is reasonably expected to be in use, which the regulation sets at a baseline support period of around five years for handling vulnerabilities. The concrete duties cluster into two groups.

• Secure by design and by default: ship without known exploitable vulnerabilities, minimise attack surface, protect data confidentiality and integrity, and provide secure default configuration so the product is not insecure straight out of the box.
• Vulnerability handling across the support period: maintain a coordinated disclosure process, provide a Software Bill of Materials so the components inside the product are documented, deliver security updates promptly and, where feasible, automatically, and report actively exploited vulnerabilities and severe incidents to ENISA within the regulation deadlines.

Conformity is demonstrated the way the EU handles other product safety law: an assessment proportionate to the product risk class, technical documentation, and CE marking that signals the security baseline has been met. Higher-risk and so-called important or critical product categories face stricter, sometimes third-party, assessment rather than self-declaration.

How it sits next to NIS 2 and the AI Act

These three EU instruments are deliberately complementary and practitioners should not confuse their scopes. The CRA is the product angle: it makes the thing you sell secure. NIS 2 is the organisational angle: it obliges essential and important entities to manage cyber risk, govern security and report incidents at the company level. The AI Act is the model angle: it governs how AI systems, especially high-risk ones, are built and placed on the market. A connected industrial device sold by a regulated operator that embeds an AI component can touch all three at once, each from a different direction.

The practical consequence is that CRA readiness is largely an engineering and product-governance programme, not a paperwork exercise bolted onto an existing ISMS. Teams that already run coordinated vulnerability disclosure, maintain dependency inventories and patch on a predictable cadence are most of the way there. Teams that ship and forget have the most work to do, because the obligation to support and patch for years is exactly what a release-and-move-on culture is built to avoid. The regulation was adopted in late 2024 and its core obligations apply from December 2027, which leaves a defined runway to build the vulnerability handling and SBOM processes before they become enforceable.