CRA or Cyber Resilience Act: A New Era for Product Safety
In a world where everything from baby monitors to industrial sensors is connected, cybersecurity has become a legal obligation, not just an engineering preference. Europe is addressing the need for digitally safe products with the Cyber Resilience Act, known as the CRA.
For decades, the compliance sector focused on preventing shocks, fires, and mechanical failures. The rise of the Internet of Things has introduced a far more pervasive class of risk. The European Union has recognised that a poorly secured smart thermostat can cause systemic harm, and that an industrial controller with weak firmware is just as dangerous as a faulty circuit breaker. This recognition produced the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, a landmark piece of legislation that redefines what it means for a product to be safe. As of 2026, the transition from theory to enforcement is not approaching. It is here.
The CRA entered into force on 10 December 2024 and represents the first horizontal cybersecurity regulation for digital products in the European Union. Its first hard enforcement milestones fall in 2026, and the full application date is 11 December 2027. For manufacturers, importers, and distributors placing connected products on the EU market, the compliance window is narrowing fast.
The Digital Safety Revolution
In regulatory compliance, we distinguish between horizontal and vertical legislation. Most safety standards, like IEC 62368-1, are vertical: they apply to a specific product category. The CRA is different. It is a horizontal regulation, covering almost every product with digital elements that connects to a network. This includes the simple smart bulb in your living room and the complex sensors running a chemical processing plant.
If your product has a processor, runs code, and has any form of data connection, wired or wireless, the CRA likely applies to you.
The core philosophy is demanding but clear: security must be built into the product from the first day of design and maintained until the product is retired. This is not a documentation exercise. It requires a fundamental change in how organisations approach the product development lifecycle. The EU is demanding the same disciplined, documented, and transparent approach to digital safety that we have long applied to electrical safety and EMC compliance.
This article is your roadmap through the practical requirements of the CRA, with a particular focus on the 2026 milestones that demand immediate attention.
What Is the CRA?
The CRA addresses two persistent problems: low baseline cybersecurity in products with digital elements, and the absence of consistent security updates over the product lifetime.
Unlike the GDPR, which protects personal data, or NIS2, which focuses on the resilience of critical infrastructure entities, the CRA focuses on the product itself. It requires hardware and software to be secure by design and secure by default.
Key Obligations for Manufacturers
The regulation imposes four core obligations that every manufacturer placing in-scope products on the EU market must fulfil:
- Vulnerability Management: Identifying and patching security flaws throughout the product’s entire operational lifecycle, not just at launch.
- Transparency via SBOM: Providing a Software Bill of Materials, a machine-readable inventory of all software components inside the product.
- Lifecycle Support Period: Providing security updates for a minimum of five years, or the expected lifetime of the product, whichever is shorter.
- CE Marking: Products meeting CRA requirements carry the CE mark, confirming compliance before market placement.
These obligations are interconnected. An effective vulnerability management process depends on a complete SBOM. The support period obligation is meaningless without the operational capability to detect, patch, and distribute updates. Building these systems takes time, and that time is already running short for the 2026 milestones.
Risk Categories and Penalties
The CRA applies a risk-based approach to determine how much independent oversight a product requires, similar in structure to the class system used in medical device regulation. Understanding your product’s classification is the starting point for all compliance planning.
The three tiers are:
- Default category (roughly 90% of products): Most consumer electronics, smart home gadgets, and general software. Manufacturers may perform their own conformity assessment and apply the CE mark without involving a third party.
- Important category (Class I and Class II): Products with security-sensitive functions, including password managers, network interfaces, browsers (Class I), and firewalls, routers, and operating systems for critical sectors (Class II). Third-party conformity assessment is required.
- Critical category: The highest tier, covering products essential to the most sensitive infrastructure, such as smartcard chips and certain high-level industrial controllers. Managed directly by the European Commission and subject to the most stringent requirements.
Misclassifying a product is not a minor procedural error. Selling a product that should have undergone third-party assessment as a self-certified Default product means placing a non-compliant product on the market, with the full weight of enforcement consequences that follow.
The Cost of Non-Compliance
Fines under the CRA reach up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. Beyond financial penalties, authorities may order a full product recall or ban the product from the EU market entirely. The cost of a Notified Body audit is modest by comparison.
Defining Scope: What Counts as a Product with Digital Elements?
The definition of “product with digital elements” in the CRA is deliberately broad. It covers any software or hardware product and its remote data processing solutions, including components placed on the market separately. A software module sold as a standalone component for integration into a larger system is in scope.
In practical terms: if your device has a processor, runs code, and communicates with the outside world, you are in scope. This includes consumer goods, industrial equipment, and software-only products such as mobile applications or desktop programs that interact with hardware. For industrial equipment specifically, the CRA intersects with the requirements of prEN 50742, which addresses machine compliance from a digital tampering and data integrity perspective.
The regulation draws a clear line between the hardware you can hold and the software that makes it run. Your compliance file must now account for both. The software components you need to address include:
- Firmware and Operating Systems: The base-level code controlling the hardware.
- Application Software: The high-level programs providing user functionality.
- Network Components: Any part of the product handling data transmission, including Wi-Fi modules and Ethernet ports.
- Remote Processing: If your product depends on a cloud service to function, that cloud interaction forms part of the security assessment.
The CRA requires that hardware and software be treated as a single integrated unit for compliance purposes. This is precisely how we have always treated electrical insulation and electromagnetic shielding. The discipline is familiar. What is new is applying it to bits and bytes.
Critical Deadlines: The 2026 Milestones Are Already in Effect
Immediate priority as of April 2026: The CRA vulnerability reporting obligation takes effect on 11 September 2026, five months from now. Manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware. If your incident response process is not yet operational, this is your most urgent task. Read the full breakdown of what is required in our dedicated guide: CRA Vulnerability Reporting: What Manufacturers Must Do Before September 2026.
Many companies are still treating December 2027 as the CRA start date. This is a serious miscalculation. By that point, the infrastructure for third-party testing and conformity assessment will be heavily booked, and organisations that have not built their internal processes will face delays that push them past the deadline.
The 2026 milestones are already active. Here is where each one stands:
| Date | Milestone | What it means in practice |
|---|---|---|
| 10 December 2024 | Entry into Force — Regulation (EU) 2024/2847 | The regulation is law. Compliance work should already be underway. |
| 11 June 2026 | Notified Body accreditation rules apply | Third-party auditors are now formally accredited. If your product needs one, book now. |
| 11 September 2026 | Vulnerability reporting obligations begin | Your incident response team must be operational. 24-hour reporting is law from this date. |
| 11 December 2027 | Full application | No non-compliant products may be placed on the EU market. CE marking under CRA is mandatory. |
If you are starting your gap analysis today, prioritise the September 2026 reporting obligation first. It requires operational processes and trained personnel, not just documentation. Drafting a reporting policy the week before the deadline does not constitute readiness.
That said, 2026 is also a commercial opportunity. Manufacturers who can demonstrate CRA readiness are already finding it a genuine differentiator in procurement conversations, particularly in B2B and industrial markets where buyers are under their own compliance pressure.
The Pillars of Compliance: Secure by Design and Secure by Default
The CRA is built on two foundational principles that inform every specific obligation.
Secure by Design
requires that security be addressed from the earliest stages of product development. In traditional safety work, we do not design a high-voltage device and then figure out how to ground it as it leaves the factory. We design the grounding first. The same logic applies here. Threat modelling, security architecture, and mitigation measures must be embedded in the design phase, before a line of code is written or a component is selected.
Secure by Default
addresses the configuration state in which a product arrives at the customer. Products must ship with the most restrictive security settings active. Default passwords of “admin” or “1234”, disabled firewalls enabled for “ease of use”, and open ports left active for convenience are all compliance violations under the CRA. Security features must be on from the moment the device is unboxed, and users must be required to actively configure any relaxation of those settings.
These principles translate into a set of specific obligations that every manufacturer must integrate into their quality management system:
- Risk Assessment: A formal document identifying cyber threats specific to the product and demonstrating how the design addresses them.
- Vulnerability Management: A proactive system for discovering, documenting, and patching security flaws throughout the product’s supported lifetime.
- Software Bill of Materials (SBOM): A comprehensive, machine-readable inventory of every software component used in the product, including open-source libraries.
- Transparency and User Instructions: Clear documentation enabling users to configure and maintain the product’s security settings correctly.
- Reporting Obligations: Legal requirement to notify ENISA of actively exploited vulnerabilities within defined timeframes.
Tip: If your product incorporates AI functionality, the EU AI Act applies in parallel with the CRA. Several obligations overlap, and they should be assessed and documented together rather than treated as sequential workstreams.
The compliance documentation that results from these obligations is not optional overhead. It is what allows your product to carry the CE mark, and it is what market surveillance authorities will request during inspections.
The Software Bill of Materials: The CRA Ingredient List
The food industry requires every packaged product to list its ingredients. When a contaminated batch is identified, manufacturers can immediately determine which products are affected. The CRA applies the same logic to software through the Software Bill of Materials.
An SBOM is a formal, machine-readable record of every software component inside your product: the version numbers, the authors, the licence types, and the relationships between components. When a critical vulnerability is discovered in a widely used library, as happened with the Log4j flaw, an SBOM lets you and your customers know immediately whether your product is at risk. Without one, you are relying on hope rather than knowledge.
The creation and maintenance of an SBOM must be integrated into your automated build systems, not managed manually.
A complete SBOM needs to track the following for every component:
- Component Name: The specific name of the library or module.
- Version String: The exact version used in the final product build.
- Author or Supplier: Who created the code.
- Relationship: How the component connects to other parts of the system.
- Vulnerability Status: Known security issues associated with that specific version.
We covered the SBOM requirement in depth in our dedicated article SBOM Will Be a Must for Product Compliance, including the specific format requirements and the tooling available to automate generation. If your SBOM process is not yet running, that article is the right starting point.
The SBOM is also a key component of the technical documentation you must produce for market surveillance authorities. An inaccurate or incomplete SBOM on request can render a product non-compliant regardless of how well-secured the code actually is. Transparency under the CRA is a legal obligation, not a best practice.
Vulnerability Management and the Lifecycle Support Period
One of the most structurally significant changes introduced by the CRA is the mandatory support period. Historically, manufacturers of low-cost connected devices would ship a product and immediately stop investing in the software. A security flaw discovered twelve months after launch left the consumer entirely unprotected. The CRA closes this practice permanently by requiring manufacturers to provide security updates for the expected lifetime of the product, with a minimum floor of five years.
Your technical file and Safety File are no longer static documents filed at product launch. They are living records that must be updated throughout the product’s supported lifetime. The Vulnerability Management Process underpinning this involves continuously scanning your SBOM against public vulnerability databases such as the CVE list, triaging discovered flaws, developing patches, and distributing them to end-users.
A compliant vulnerability management system must cover five stages consistently:
- Identification: Regular automated scanning of software components against known vulnerability databases.
- Triage: Determining the severity of a discovered flaw and its specific impact on your product’s security posture.
- Remediation: Developing a patch or effective workaround to close the security gap.
- Distribution: Delivering the patch to end-users, ideally through an automatic update mechanism.
- Reporting: Notifying ENISA through the CRA Single Reporting Platform if a vulnerability is being actively exploited in the field.
The five-year support obligation changes the financial model for many products. The cost of ongoing software maintenance must be factored into the original pricing, not treated as an optional post-launch service. From a quality engineering perspective, this means auditing not just the product itself, but the organisation’s sustained capability to support it.
The 24-hour reporting deadline for actively exploited vulnerabilities is operationally demanding. It requires clear internal escalation paths, pre-established contacts with the relevant CSIRT, and a team that can act immediately, not after a management meeting. Building this process must happen before September 2026, not after.
CRA Risk Categories: Do You Need a Third-Party Audit?
The risk classification question is one of the most consequential decisions in CRA compliance planning. Getting it right determines whether your conformity assessment is a manageable internal process or a formal third-party engagement.
Roughly 90% of products fall into the Default category: most consumer electronics, smart home devices, and general-purpose software. Manufacturers may carry out their own internal assessment, document their compliance against the CRA requirements, and apply the CE mark.
If your product performs a security-sensitive function, however, you enter the Important categories:
- Class I: Password managers, network interfaces, browsers, identity management systems. Failure causes significant harm but is not necessarily catastrophic. Stricter documentation requirements and a choice between self-assessment with enhanced scrutiny or third-party review.
- Class II: Firewalls, industrial routers, operating systems for critical sectors. Full third-party conformity assessment is required. This is where the June 2026 Notified Body accreditation milestone becomes directly relevant to your planning.
- Critical: Reserved for products central to the most sensitive EU infrastructure. Classification managed by the European Commission. Subject to the most stringent requirements and direct Commission oversight.
The boundaries between Default and Class I, and between Class I and Class II, require careful analysis. If you are on the borderline, the advice is consistent: classify at the higher tier and invest in the additional rigour. The cost of a Notified Body audit is a fraction of the cost of an enforcement action and product withdrawal.
Practical Steps to Start CRA Compliance Today
The transition to CRA compliance requires a cultural shift, not just a documentation update. In practice, these transitions fail not from lack of technical expertise but from the absence of communication between hardware safety engineers and software development teams. They have historically operated in separate silos. The CRA makes that separation untenable.
The following actions are practical starting points that can be initiated immediately, regardless of where your compliance journey currently stands:
- Appoint a Cyber-Safety Liaison: Someone who understands both hardware safety standards and software security, able to bridge your engineering and compliance teams.
- Audit Your Supply Chain: Ask component and software suppliers for their SBOMs now. If they cannot provide them, treat that as a procurement risk and begin identifying CRA-ready alternatives.
- Automate Your Patching Infrastructure: Design products with over-the-air update capability wherever technically feasible. At production scale, manual patch distribution is not operationally viable.
- Scan Your Existing Codebase: Use automated tools to identify common vulnerability classes such as buffer overflows, hardcoded credentials, and unpatched third-party components.
- Document All Security Decisions: In the eyes of a market surveillance authority, if it is not documented, it did not happen. Apply the same rigour to your security logs as you apply to lab test reports.
Compliance is a specification requirement, not a post-development exercise. A product that ships fast but cannot legally be sold six months later is not a success.
Conclusion: September 2026 Is Your Immediate Deadline
The December 2027 full application date receives most attention in compliance discussions, but it is the 11 September 2026 vulnerability reporting obligation that requires action right now. From that date, any manufacturer with an in-scope product on the EU market must report actively exploited vulnerabilities to ENISA within 24 hours, submit a full notification within 72 hours, and provide a final report within 14 days of a corrective measure being available.
These are not targets. They are legally binding timeframes with enforcement consequences. If your incident response infrastructure is not operational before September, you will be in violation on the first day the obligation applies.
We have published a detailed step-by-step guide to the specific process, reporting formats, and what “actively exploited” means in practice: CRA Vulnerability Reporting: What Manufacturers Must Do Before September 2026. Read it alongside this article. The reporting process, the SBOM, and the secure-by-design framework are not independent workstreams. They depend on each other, and organisations building them in parallel will be considerably better positioned than those treating them sequentially.
We have mastered electrical safety. We have mastered EMC. Cyber resilience follows the same logic: understand the requirements, build the process, document everything. The discipline is familiar. The timeline is fixed.
Cyber Resilience Act (CRA) — Frequently Asked Questions
The EU has published an official CRA FAQ page. Below are some of the most searched questions on this regulation.
What is the Cyber Resilience Act (CRA)? The CRA is Regulation (EU) 2024/2847, which introduces mandatory cybersecurity requirements for products with digital elements. It covers the full product lifecycle from design through to end of support.
What are the penalties for non-compliance? Administrative fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. Authorities may also order product recalls or ban non-compliant products from the market.
Is the CRA a regulation or a directive? It is a regulation, meaning it applies directly and uniformly across all EU member states without requiring transposition into national law.
What is the difference between NIS2 and the CRA? NIS2 focuses on the resilience of entities, such as energy providers, healthcare organisations, and critical infrastructure operators. The CRA focuses on the security of products placed on the market.
What is the difference between the CRA and the GDPR? GDPR governs the protection of personal data. The CRA governs the cybersecurity of hardware and software products. The two regulations are complementary but address different obligations.
What are the CRA exemptions? Products already covered by sector-specific EU regulation that includes equivalent cybersecurity requirements, such as medical devices under the MDR, motor vehicles under UNECE regulations, and aviation equipment, may be wholly or partially exempt from CRA requirements.
How do I comply with the CRA? Start with a product risk assessment and gap analysis against the CRA essential requirements in Annex I. Build your SBOM, establish your vulnerability management process, prepare your incident reporting workflows for the September 2026 deadline, and confirm whether your product requires third-party conformity assessment. The CRA Vulnerability Reporting guide covers the most immediate practical steps.
