The EU Cyber Resilience Act is live: what changed in 2026 and what comes next

For most of the past two years, the EU Cyber Resilience Act (CRA) was something product and security teams planned for. As of 11 September 2026, it’s something they operate. Manufacturers of hardware and software sold in the EU now have a live duty to report actively exploited vulnerabilities and severe incidents. The remaining design, documentation, and conformity obligations arrive on 11 December 2027 (European Commission, CRA summary).

Here’s the key takeaway: the CRA isn’t a one-time certification exercise. It asks manufacturers to show, for the full life of a product, that security is designed in. It also asks them to show that vulnerabilities are handled and incidents are reported on a clock. That’s a program, not a project.

This post covers what the CRA requires and what’s happened in 2026. It also covers what’s still pending and how to turn the requirements into an operating capability.

What the Cyber Resilience Act covers

The CRA, formally Regulation (EU) 2024/2847, entered into force on 10 December 2024. It applies to “products with digital elements” made available on the EU market. That means hardware and software products, and their remote data processing solutions. It covers products whose intended or reasonably foreseeable use includes a data connection to a device or network (European Commission, CRA summary).

At a high level, manufacturers must:

• Perform a cybersecurity risk assessment and use it across planning, design, development, production, delivery, and maintenance.
• Exercise due diligence when integrating third-party components, including open-source components.
• Maintain technical documentation, complete the applicable conformity assessment, issue an EU declaration of conformity, and affix the CE marking.
• Define a support period, stated at the time of purchase, during which vulnerabilities are handled effectively (European Commission, CRA summary).

That support period must generally be at least 5 years. It can be shorter only when the product is expected to be in use for less time (Regulation (EU) 2024/2847, EUR-Lex).

Most products fall into a default category that allows self-assessment. Products listed as “important” or “critical” in Annexes III and IV face stricter conformity assessment routes. Examples include password managers, firewalls, and smart meter gateways (BSI). For some important products, a notified body must take part, especially when the manufacturer hasn’t applied harmonised standards (European Commission, conformity assessment).

The latest updates in 2026

Reporting obligations started on 11 September 2026

This is the biggest change of the year. Since 11 September 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents that affect the security of their products (European Commission, CRA reporting). The timelines are tight:

Two details are easy to miss. First, reporting applies to all in-scope products made available on the EU market. That includes products placed on the market before December 2027 (European Commission, CRA summary). Your installed base counts, not only your next release. Second, in a narrow exception, microenterprises and small enterprises can’t be fined for missing the 24-hour early-warning deadline. The remaining deadlines still apply (Regulation (EU) 2024/2847, EUR-Lex).

ENISA launched the Single Reporting Platform

To support these obligations, the European Union Agency for Cybersecurity (ENISA) launched the CRA Single Reporting Platform (SRP). Its initial operating capability went live on 11 September 2026 (ENISA). Manufacturers report once. The notification goes to the coordinating Computer Security Incident Response Team (CSIRT). That is usually the CSIRT in the Member State of the manufacturer’s main establishment. ENISA receives the notification at the same time. The coordinating CSIRT then shares it with CSIRTs in other countries where the product is sold (ENISA).

ENISA has published FAQs, user guidance, a glossary, and training materials for the platform (European Commission, CRA reporting). National authorities are publishing their own onboarding guidance as well. Germany’s BSI is one example (BSI, CRA Single Reporting Platform).

The Commission published its first CRA guidance

On 27 July 2026, the European Commission published practical, non-binding guidance on applying the CRA. It was issued as Communication C(2026) 5252 with a detailed annex (European Commission). It clarifies:

• When products fall within scope, including remote data processing solutions and free and open-source software.
• What counts as a “substantial modification.”
• How to understand and apply support periods.
• How to meet the reporting and risk assessment requirements.

The guidance includes 67 practical examples, along with use cases and flowcharts. It is written with microenterprises and small and medium-sized enterprises (SMEs) in mind (European Commission). The Commission says further guidance may follow as needed.

The Commission’s open-source page covers “open-source software stewards.” Under Article 24, stewards have lighter, specific obligations. Examples include maintaining a cybersecurity policy and cooperating with market surveillance authorities (European Commission, CRA open source). Their reporting obligations apply from 11 December 2027, not September 2026 (ENISA).

Notified body rules switched on in June 2026

Chapter IV of the CRA, which governs how conformity assessment bodies are notified, has applied since 11 June 2026. Member States were required to designate notifying authorities by that date (European Commission, CRA summary). The Commission’s implementation timeline targets a sufficient number of notified bodies across Member States by 11 December 2026 (European Commission, CRA implementation). National authorities such as Finland’s Traficom are now accepting applications (Traficom).

Harmonised standards are progressing, but behind schedule

Harmonised standards matter because applying them gives a presumption of conformity. They’re still in progress:

• ETSI opened a public enquiry on 17 vertical, product-specific final draft standards in August 2026 (ETSI).
• A July 2026 analysis describes a Commission draft amendment to the standardisation request. It would move the horizontal and vulnerability-handling standards from 30 August to 31 October 2026. It would move the product-specific standards from 30 October to 31 December 2026. As of early September, that amendment had not been formally adopted (CyberResilienceAct.eu).

The practical point: using harmonised standards is voluntary, and the reporting clock didn’t wait for them. Teams that hold off on CRA work until standards are cited in the Official Journal are giving up time they’ll need later.

Simplification is happening, but the CRA’s core is unchanged

The Commission’s November 2025 Digital Omnibus proposes a single entry point for cybersecurity incident and data breach reports (European Commission, Digital Rulebook). The January 2026 cybersecurity package focuses on NIS2 amendments and a revised Cybersecurity Act (European Commission, Digital Rulebook). Industry groups including VDMA and ZVEI have noted that the Omnibus doesn’t meaningfully change the CRA’s substance (VDMA, ZVEI). Plan for the CRA as written.

Key dates to keep on your roadmap

What’s at stake for the business

The CRA is enforced through market access. Some breaches carry the highest fines: non-compliance with the essential cybersecurity requirements, or with the manufacturer obligations in Articles 13 and 14. Those fines can reach EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. Lower tiers apply to other operator obligations and to supplying misleading information to authorities (Regulation (EU) 2024/2847, EUR-Lex).

Fines get the headlines, but the larger business question is continuity. Can you keep selling into the EU? Can you answer customer and distributor due-diligence questions with evidence? Can you handle a vulnerability disclosure in 24 hours without pulling the whole engineering organization off its roadmap?

Our point of view: treat the CRA as a program, not a product checklist

Many organizations will approach the CRA one product and one deadline at a time. That works until the second product, the third regulation, or the first real incident. A more durable approach connects CRA obligations to the governance, risk, and compliance program you already run:

• Assign ownership before tooling. Name who decides whether a vulnerability is “actively exploited,” who submits the SRP notification, and who approves the final report. The 24-hour clock leaves no time to work this out during an event.
• Map CRA requirements to a unified control set. Secure development, vulnerability handling, supplier due diligence, and incident response likely already appear in your controls. Those may be ISO/IEC 27001, SOC 2, or NIST-aligned. Map the CRA to those controls and update them once, instead of building a parallel program.
• Make your product inventory decision-ready. Know which products are in scope, their classification, their declared support periods, and their components. A software bill of materials (SBOM) is part of the Annex I vulnerability handling requirements. It can’t stay an engineering side project.
• Practice the reporting workflow. Run a tabletop exercise that goes from detection to SRP submission to the 14-day and 1-month final reports. Capture the evidence each step produces.
• Build for change. Standards, guidance, and notified body capacity will keep evolving through 2027. Regulatory change monitoring should be a control with an owner, a cadence, and evidence. It shouldn’t be a calendar reminder.

The organizations that handle December 2027 well will be the ones that used 2026 to build an operating rhythm. They won’t be the ones that waited for every standard to be final.

How Semper Sec helps

Semper Sec works alongside product, security, and compliance teams to build cybersecurity governance, risk, and compliance programs that obtain and maintain trust. For the CRA, that means connecting obligations to clear ownership, a unified control set, and repeatable reporting processes. It also means continuous regulatory monitoring, so your team can operate the program long after the initial readiness work is done.

Want a clear-eyed view of where your CRA program stands today and what to prioritize before December 2027? talk with our team about Managed GRC.

This article is for general information and isn’t legal advice. CRA obligations depend on your products, role in the supply chain, and markets. Confirm specific requirements with qualified counsel and the official texts linked above.