What Is the EU Cyber Resilience Act? Scope, Products, and Who It Affects
Until recently, a digital product could be placed on the European market with essentially no binding cyber security standard attached to it. Manufacturers decided how much security to build in, and buyers had no assurances and no way to compare. When vulnerabilities emerged, there was no legal obligation to report or fix them. Products could be abandoned without prior notice, leaving them vulnerable to cyber attack.
The EU Cyber Resilience Act is the first EU regulation to require cyber security as a baseline condition for bringing digital products to market. Adopted in October 2024, its key obligations enter the enforcement phase in September 2026. [1] If you manufacture or distribute a digital enforcement phase in September 2026. [1] If you manufacture or distribute a digital product that is sold on the EU market, this regulation applies to you.
What Does ‘Cyber Resilience’ Actually Mean?
Cyber resilience refers to the ability to anticipate, withstand, recover from, and adapt to adverse cyber security events. The CRA operationalises cyber resilience at the market level by turning broad cyber security expectations into legally enforceable product obligations. Products must be designed to be resilient against attacks, and manufacturers must actively manage vulnerabilities throughout their product’s life cycle.
What Is a “Product With Digital Elements”?
The CRA uses the term ‘product with digital elements’ to define its scope. A product with digital elements is defined as any software or hardware product – and its remote data processing solutions – that can connect, directly or indirectly, to another device or network [2]. All things considered, this includes virtually all software that runs on a standard desktop computer, laptop, or mobile phone, and even simple hardware devices like a TV remote control.
The major product groups include:
- Enterprise software platforms: ERP systems, CRM software, security tools, and collaboration platforms
- Consumer hardware: smart home devices, connected appliances, routers, and IP cameras
- Industrial products: PLCs, SCADA systems, industrial sensors, and connected machinery
- Developer tools: IDEs, CI/CD platforms, and build tools with network connectivity
- Operating systems: desktop, server, and embedded OS products
- Mobile applications and other software components
Who Has to Comply?
The CRA places the primary obligation on manufacturers: the legal entities designing, developing, or producing products with digital elements and placing them on the EU market under their own name or trademark. But it does not end there. Importers and distributors also carry obligations. If you bring a third-party product to the EU market or make it available within the EU, you are responsible for verifying that it meets CRA requirements.
The CRA applies wherever you are based. A US software vendor selling to EU customers falls within its scope. Where a non-EU manufacturer’s products are sold in the EU by a European distributor, both parties carry obligations – the manufacturer as the entity responsible for the product, and the distributor as the entity making it available on the EU market.
The maximum fine for CRA non-compliance is €15 million or 2.5% of global annual turnover, whichever is higher – figures that concentrate board attention quickly.
What Is Explicitly Out of Scope?
- Products covered by equivalent sector-specific legislation, such as certain medical devices, aviation equipment, and motor vehicles, where existing rules provide comparable cyber security requirements
- Purely non-commercial open-source software (CRA still applies to open-source components of commercial products and open-source stewards)
- National security, intelligence, and military products
- Products not available on the market and designed exclusively for certain purposes, such as evaluation prototypes
What Does the CRA Actually Require?
At its core, the CRA requires manufacturers to do four things:
- Build secure digital products: Design, develop, and produce products with cyber security in mind from the start – not bolted on afterward. Products must ship without known exploitable vulnerabilities, with a minimal attack surface, and in a secure default configuration.
- Actively support product security: Provide security updates free of charge for at least five years. Responsibly document and manage security flaws. Maintain a Software Bill of Materials (SBOM) identifying all software components.
- Report exploited vulnerabilities: From 11 September 2026, report actively exploited vulnerabilities to ENISA within 24 hours and submit full technical details within 72 hours. [3]
- Assess and demonstrate conformity: Conduct a cyber security risk assessment before market placement. Maintain technical documentation for 10 years. Affix CE marking to demonstrate conformity. [4]
The September 2026 Deadline: Why It Matters Now
Most manufacturers are focused on the December 2027 full enforcement date – but the more immediately urgent deadline is September 11th, 2026, which kicks off vulnerability reporting obligations. That is less than five months away. From that date, any actively exploited vulnerability in your products must trigger a formal notification process to European cyber security authorities within 24 hours. [5]
Building and testing the internal process for that requires preparation. Not just a policy document, but an actual operational workflow, with tooling, escalation paths, and staff training. For security and engineering leads, September 2026 is the deadline that justifies budget conversations now — not after the 2027 full-enforcement date, when the window for orderly implementation will have closed.
What CRA Compliance Actually Requires in Practice
Meeting these obligations requires a technical foundation: you need to know what components are in your products, track which CVEs affect them, and have a way to prioritise what gets fixed first. In practice, this means vulnerability management tooling integrated into your pipeline — not as a compliance checkbox, but as a continuous process that produces a CRA-compliant audit trail. The CRA does not prescribe a specific tool, but it does prescribe the outcome: documented, traceable, repeatable vulnerability handling.
Done well, these processes can also make developers’ day-to-day work less chaotic: fewer emergency patch cycles, actionable alerts instead of raw CVE firehose output, and clear triage priority so the team is fixing what actually matters rather than everything at once.
If you are mapping out what that process needs to look like for your organisation, our upcoming posts will cover the core components of a CRA-ready vulnerability management workflow – including what an SBOM needs to contain, how exploitability scoring works in practice, and where open source tooling fits in.
