- The Cyber Resilience Act covers any hardware or software that connects to a device or network — the scope is broad, and most software vendors selling into the EU are in scope
- Manufacturers carry the primary compliance obligations; importers and distributors have lighter but real duties
- Products fall into three classes: default (self-assessment), Class I Important, and Class II Critical — with progressively stricter conformity assessment requirements
- Vulnerability reporting to ENISA and national CSIRTs becomes mandatory from 11 September 2026 — the 24-hour reporting clock applies from that date
- Manufacturers must provide a minimum 5-year support period and maintain a software bill of materials (SBOM) for each product
- Fines reach €15 million or 2.5% of global turnover for non-compliance with essential cybersecurity requirements
What the Cyber Resilience Act covers
The Cyber Resilience Act (CRA) plugs a longstanding gap in EU product regulation. Before it, manufacturers could legally sell products with known security flaws or without any vulnerability management process. From December 2027, placing an insecure connected product on the EU market — or failing to manage its security throughout its lifetime — will be a legal violation subject to substantial fines.
The Act applies to products with digital elements (PDEs): any product, hardware or software, that contains digital components and can connect to another device or network. That definition is intentionally wide. Smart home devices, industrial controllers, routers, network cameras, password managers, VPN clients, operating systems, enterprise software, development tools, and consumer mobile apps all fall within scope if they are sold or licensed commercially in the EU.
Pure Software-as-a-Service (SaaS), where software runs entirely on a provider's infrastructure and no software components are transferred to or installed by the customer, is generally excluded from scope. The Act is aimed at software that ships to the customer — downloaded, installed, or deployed on customer infrastructure. However, SaaS platforms whose primary function is to enable the remote capability of a hardware product remain in scope, and the boundary between SaaS and PDE is one regulators will be watching carefully.
Any business that designs, develops, manufactures, imports, or distributes products with digital elements on or into the EU market. If you sell software or hardware commercially to customers in the EU and that product can connect to a network or another device, this regulation applies to you — regardless of where your business is based.
The three roles: manufacturer, importer, distributor
The Act assigns different obligations depending on your role in the product supply chain.
Manufacturers are businesses that develop or design a product with digital elements and place it on the market under their own name or trademark. Manufacturers carry the bulk of CRA obligations: the full suite of essential cybersecurity requirements, vulnerability handling, conformity assessment, CE marking, technical documentation, and SBOM maintenance. If you build and sell software or connected hardware under your own brand, you are a manufacturer under the CRA.
Importers place products on the EU market that were manufactured outside the EU. Importers must verify that the manufacturer has carried out the required conformity assessment, that the CE marking and technical documentation are in order, and that the manufacturer has vulnerability handling processes in place. Importers must not place products on the market where they have reason to believe those requirements are not met.
Distributors make products available on the EU market without placing them there themselves. Distributors must verify CE marking, check that required information accompanies the product, and not supply products they know to be non-compliant. Distributors' obligations are the lightest but are not trivial — due diligence on supplier compliance is required.
If you take a product manufactured by someone else and sell it under your own name or brand — even if you have not modified it — you are treated as the manufacturer under the CRA and take on all manufacturer obligations. This applies to white-label hardware and OEM software arrangements.
The three product classes
The Act categorises PDEs by risk level. The category determines which conformity assessment route is available.
The essential cybersecurity requirements
All manufacturers must design, develop, and maintain their products in compliance with the essential cybersecurity requirements in Annex I. These cover both the product at time of release and the manufacturer's ongoing vulnerability handling processes.
Product security at time of placing on market
- No known exploitable vulnerabilities: Products must be placed on the market without known exploitable vulnerabilities in their components. This does not mean zero vulnerabilities — it means no known, unmitigated exploitable vulnerabilities.
- Secure by default: Products must be delivered with a secure default configuration and, where applicable, the ability to reset to that secure state.
- Data protection: Products must protect the confidentiality, integrity, and availability of data stored, transmitted, or processed, using appropriate cryptography where relevant.
- Minimal attack surface: Products must minimise attack surfaces, including by disabling or restricting interfaces and services not needed for intended functionality.
- Resilience against denial of service: Products must be designed to withstand denial of service attacks and to limit the impact on the availability of other services and networks they use.
- Limit impact of incidents: Products must be designed to limit the impact of a security incident on other products and the broader network environment.
Vulnerability handling requirements (ongoing)
- Vulnerability disclosure policy: Manufacturers must have a documented, publicly available coordinated vulnerability disclosure policy.
- Vulnerability identification: Manufacturers must identify and document vulnerabilities and software components in their products, including maintaining an SBOM.
- Prompt remediation: Manufacturers must address vulnerabilities without undue delay, including by providing security updates.
- Security update delivery: Security updates must be made available separately from functionality updates and delivered for the duration of the support period — without charge.
- Incident and vulnerability reporting: Actively exploited vulnerabilities and severe incidents must be reported to ENISA and the national CSIRT. See timeline below for when this applies.
Software bill of materials (SBOM)
The CRA requires manufacturers to maintain a software bill of materials — a formal, structured inventory of every software component included in the product. This includes first-party code, third-party libraries, open source components, and their respective versions and known vulnerabilities.
The SBOM does not need to be publicly disclosed, but it must be made available to market surveillance authorities on request. It must be kept up to date throughout the product's active support period and must be produced in a machine-readable format (the Act points to established industry formats such as SPDX or CycloneDX).
The SBOM requirement transforms vulnerability management from a reactive fire-fighting exercise into a documented, auditable process. Manufacturers who cannot produce an accurate SBOM on request will face difficulty demonstrating conformity.
For many manufacturers, the SBOM obligation will require investment in software composition analysis (SCA) tooling and a process for continuously tracking component updates and new CVEs. If you do not currently have a complete inventory of the open source and third-party libraries in your products, building that inventory is the most urgent preparatory step.
Support period and end-of-life obligations
Manufacturers must define and publish a support period for each product. The minimum is five years, or the expected product lifetime if shorter. During the support period, manufacturers must provide security updates free of charge and maintain the vulnerability handling process.
At end of support, manufacturers must notify users clearly and in advance, and must make the final security state of the product publicly available. Products must not be designed to expire suddenly — users must be given sufficient time to migrate or plan for end of support.
This has significant implications for product planning. Launching a product that you do not intend to support for at least five years — or that your business model does not accommodate supporting for that period — is no longer viable under EU law if you sell that product into the EU market.
Vulnerability reporting: what applies from September 2026
The vulnerability reporting obligations in Article 14 of the Act become enforceable from 11 September 2026, ahead of the full compliance deadline. From that date:
- Manufacturers must notify ENISA and their national CSIRT of any actively exploited vulnerability in a product they have placed on the market within 24 hours of becoming aware of it.
- A more detailed notification must follow within 72 hours, including an initial assessment of severity and impact.
- A final report must be submitted within 14 days of a corrective measure becoming available, or within 14 days of the close of the incident if no fix is available.
- Manufacturers must also notify affected users of severe incidents without undue delay.
ENISA will operate a Single Reporting Platform for these notifications. The platform is expected to be operational before the September 2026 reporting deadline. National CSIRTs will receive copies of notifications for products placed on their national market.
If you manufacture or distribute products with digital elements in the EU, you need a vulnerability monitoring and incident reporting process in place before 11 September 2026 — over a year before full CRA compliance is required. This means coordinating with your security team, legal function, and product owners now, not at the December 2027 deadline.
The implementation timeline
What to do now
With September 2026 less than a year away and December 2027 under 18 months out, the time available for preparation is shorter than it appears. Security documentation, SBOM tooling, and conformity assessment processes all take time to put in place properly.
Step 1: Determine if your products are in scope
List every product your organisation develops, manufactures, imports, or distributes that is sold or made available in the EU market. For each, ask: does it contain digital components that can connect to another device or network? If yes, it is almost certainly a product with digital elements. If you are a pure SaaS provider, examine whether any software components are transferred to or installed by customers, or whether your SaaS enables the primary function of a hardware product.
Step 2: Classify your products
Review Annex I of the Act to determine whether any of your products fall into Class I Important or Class II Critical. If you build identity management systems, VPNs, browsers, password managers, network management tools, or industrial control systems, you are likely Class I. Hardware security modules and similar products are Class II. Products not in Annex I are default class and can self-certify.
Step 3: Begin your SBOM
If you do not already maintain an accurate inventory of every software component in each of your products — including open source libraries, their versions, and known CVE status — start building it now. Software composition analysis (SCA) tools can automate much of this. The SBOM also gives you the foundation for your vulnerability monitoring process.
Step 4: Build your vulnerability reporting process
The 24-hour ENISA reporting obligation means you need a clear internal escalation path before September 2026. Define who is responsible for monitoring for exploited vulnerabilities, how that information reaches legal and product teams, who has authority to submit the ENISA notification, and how you communicate with affected customers. Document it and test it.
Step 5: Review your product lifecycle commitments
For each product, assess whether you can commit to and sustain a minimum five-year support period. If your product is close to end of life, plan your user communications and ensure you comply with the end-of-life notification obligations. Products that are launched after the December 2027 deadline must have their support period defined and published at launch.
Our cybersecurity team supports manufacturers and distributors with CRA readiness assessments, SBOM implementation, and vulnerability management process design. Our compliance practice works with organisations across the Netherlands and UK on product compliance documentation and conformity assessment preparation.
The fine structure
Market surveillance authorities in each member state are responsible for enforcement. The fine structure is:
- Non-compliance with essential cybersecurity requirements or vulnerability handling obligations: Up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher.
- Non-compliance with other CRA obligations (conformity assessment, CE marking, technical documentation, registration): Up to €10 million or 2% of total worldwide annual turnover, whichever is higher.
- Providing incorrect, incomplete, or misleading information to authorities: Up to €5 million or 1% of total worldwide annual turnover, whichever is higher.
Market surveillance authorities also have the power to require product recalls, to prohibit products from being placed on the EU market, and to issue public warnings. Persistent or serious violations may trigger EU-wide market restrictions through the RAPEX/Safety Gate alert system.