CRA Guide · 11 min
The EU Cyber Resilience Act (CRA): what it requires, when it applies, and what it means for your supply chain
The Cyber Resilience Act is the EU's first horizontal cybersecurity law for products. Where NIS2 governs how organisations run their security, the CRA governs the security of the hardware and software placed on the EU market (from connected devices to standalone software. It is already in force, its first reporting duties begin in September 2026, and from December 2027 a product that does not meet its requirements cannot legally be sold in the EU. This guide explains the scope, the timeline and the obligations) and, for the teams who buy and depend on these products, what to ask of your vendors and how to evidence it.
Key takeaways
- The CRA regulates products with digital elements (hardware and software) sold in the EU; it targets manufacturers first, with duties also for importers and distributors.
- Phased dates: in force since December 2024, vulnerability and incident reporting from 11 September 2026, all main obligations from 11 December 2027.
- Pure SaaS is generally outside the CRA, but if you procure products or components, your NIS2 supply-chain duty and the CRA now point the same way: demand evidence of secure-by-design and vulnerability handling.
What the CRA is
The Cyber Resilience Act (Regulation (EU) 2024/2847) sets mandatory cybersecurity requirements for “products with digital elements”: any software or hardware product, and its remote data processing solutions, that can be connected to a device or network and is placed on the EU market. It is a regulation, so it applies directly across all 27 member states without national transposition.
The bulk of the obligations fall on the manufacturer, who must design, build and maintain the product securely and prove conformity (the CE marking). Importers and distributors carry their own duties. They may only place compliant products on the market and must act when they learn a product is not compliant. The Act also defines two higher-risk tiers, “important” and “critical” products (for example password managers, network management systems or hardware security modules), which face stricter conformity routes.
In scope
Hardware and software products placed on the EU market that can connect to a device or network: connected devices, operating systems, applications, libraries, and the remote data processing solutions integral to them.
Outside scope (notably SaaS)
Pure software-as-a-service is generally not a “product” under the CRA and is instead addressed by NIS2: unless a remote data processing solution is essential to a product's function and built by that product's manufacturer. Products already covered by sector rules (e.g. medical devices, motor vehicles, certain aviation) are also carved out.
The timeline that matters
The CRA applies in phases. Two dates drive most planning:
Entered into force. The compliance clock starts; no substantive obligations apply yet.
Reporting obligations begin. Manufacturers must report actively exploited vulnerabilities and severe incidents (a 24-hour early warning, a 72-hour notification and a final report within 14 days) to their national CSIRT and ENISA via the single reporting platform.
Full application. All essential requirements apply; non-compliant products with digital elements may no longer be placed on the EU market.
What manufacturers must do
The essential requirements run across the whole product lifecycle. In summary, a compliant manufacturer must:
- Design securely (secure by design and by default): ship with a secure configuration, minimise the attack surface, and protect confidentiality and integrity.
- Handle vulnerabilities throughout the support period: identify, document and remediate them, and provide security updates free of charge for a support period that reflects the product's expected lifetime (the Commission points to at least five years for many products).
- Provide a Software Bill of Materials (SBOM): maintain a machine-readable inventory of components so that, when a new vulnerability surfaces in a dependency, affected products can be found fast.
- Operate a coordinated vulnerability disclosure policy: publish a contact point and process for reporting vulnerabilities (the role security.txt plays in practice).
- Report actively exploited vulnerabilities and severe incidents. On the 24-hour / 72-hour / 14-day timeline, from 11 September 2026.
- Demonstrate conformity and apply the CE marking: by self-assessment for most products, or a third-party assessment for the “important” and “critical” classes, backed by technical documentation.
How the CRA relates to NIS2
NIS2 and the CRA are complementary, not competing. NIS2 is about entities (how an essential or important organisation governs and operates its own security, including the cyber risk of its suppliers (Art. 21(2)(d)). The CRA is about products) whether the things placed on the market are secure by design and properly maintained. One regulates the operator; the other regulates what the operator buys and runs.
That is exactly where they meet. A NIS2 entity's supply-chain duty increasingly includes the question “are the products and components we procure CRA-ready?”: does the vendor handle vulnerabilities, ship updates, publish a disclosure channel and provide an SBOM? From December 2027 the CE marking will answer part of that; until then, and continuously after, buyers still need their own assurance that a vendor's security holds up in practice.
The CRA is a product-safety-style regulation, and some boundaries (especially the SaaS / remote-data-processing line and the “important” / “critical” classes) can be nuanced. Confirm how it applies to a specific product with qualified advice and the official text.
What it means for you
Your obligations depend on your role in the chain. A quick orientation:
A manufacturer of products with digital elements
The CRA applies directly. Build the secure-by-design, vulnerability-handling, SBOM, disclosure and reporting capabilities now: the reporting duty is live from September 2026 and full conformity is required by December 2027.
An importer or distributor
You may only place compliant, CE-marked products on the EU market, must check the manufacturer met its duties, and must act (and inform authorities) when you learn a product carries a significant cybersecurity risk.
A buyer or operator (especially under NIS2)
The CRA does not regulate you directly as a buyer, but it reshapes what “good” looks like in procurement. Require evidence of vulnerability handling, an SBOM, a disclosure policy and a support window, and monitor whether vendors actually deliver.
A pure-SaaS provider
Generally outside the CRA (you fall under NIS2 instead): unless your service is a remote data processing solution integral to a regulated product. Either way, your customers' due diligence will still ask the same security questions.
Sources: Regulation (EU) 2024/2847 (Cyber Resilience Act) and the European Commission's Cyber Resilience Act pages. Dates and scope reflect the published regulation; confirm specifics for your products with qualified advice.
How norppa.io helps
norppa.io will not make a product CRA-compliant (that is the manufacturer's job) but it gives buyers and operators the external evidence that procurement and NIS2 due diligence now demand. The signals the CRA is built around are the ones we monitor continuously: end-of-life software and unpatched vulnerabilities (weak vulnerability handling), a missing coordinated-disclosure channel, and exposed or misconfigured services.
Self-assessment questionnaires capture the parts no external scan can see (SBOM availability, the declared support and update window, conformity status) and each answer is set against the live technical profile. The result is current, corroborated evidence of a vendor's security posture, ready for your supplier file, rather than a one-off claim.