The EU Cyber Resilience Act’s first hard deadline arrives September 11, 2026. The gap between what manufacturers have prepared and what the regulation actually requires is wider than most compliance teams realize. 

C2A Security  ·  June 2026  ·  8 min read 

A Regulation Built for a Different Kind of Compliance 

Most product regulations ask a straightforward question: does this product meet a defined standard at the moment it enters the market? The EU Cyber Resilience Act asks something fundamentally different. It asks whether a manufacturer can demonstrate ongoing security across every product, across the full lifecycle, at any moment a regulator decides to look. 

That distinction matters more than it might first appear. Organizations that have spent the past year reading CRA guidance documents and mapping requirements to existing frameworks have done useful preparation. But many have prepared for the wrong problem. They have built documentation where CRA requires a continuous system. 

WHAT THE CRA ACTUALLY REQUIRES 

The CRA is the first EU-wide regulation establishing mandatory cybersecurity requirements for products with digital elements: any hardware or software product that connects, directly or indirectly, to a device or network. It applies to manufacturers regardless of where they are headquartered. A North American or Asian manufacturer selling covered products into the EU faces identical obligations to an EU-based one. 

The September 2026 Deadline Is Not the One Most Teams Are Watching 

The CRA’s full enforcement date is December 11, 2027. That is the deadline that appears in most compliance roadmaps. It is also, in a meaningful sense, the wrong deadline to focus on. 

September 11, 2026 is when vulnerability reporting obligations go live. From that date, manufacturers must report an actively exploited vulnerability within 24 hours of becoming aware of it, filed once through the EU’s Single Reporting Platform, which routes the notification to the manufacturer’s designated national CSIRT and to ENISA in parallel. There is no grace period. The obligation does not ramp in. The clock starts the moment a manufacturer has awareness. 

For organizations that have not built automated incident response workflows by that date, day one of the reporting regime is also day one of non-compliance risk. The practical window to implement and test those workflows is a matter of weeks, not months, once typical enterprise procurement, integration, and validation timelines are accounted for. 

What CRA Actually Requires Manufacturers to Operate 

Reading through the CRA’s essential requirements, the individual obligations each seem manageable. Risk assessments, vulnerability disclosure, SBOM maintenance, security updates. Most organizations in regulated industries have some version of each of these in place already. The challenge is not any single requirement. It is what CRA demands of all of them together. 

The regulation requires these activities to be continuous, current, and retrievable on demand, across every product in scope, for up to ten years after market placement. That combination is where existing processes break down. 

The 24-hour reporting problem 

Consider what happens when a high-severity vulnerability is publicly disclosed affecting a widely used component. By the time a security team in Europe arrives at work the following morning, the clock may already be running. Within that same business day, the team must determine which of their products contain the affected component, assess whether the vulnerability is actively exploited, evaluate real-world risk in product context, route an escalation for approval, and produce a structured regulatory notification for submission to ENISA. 

Organizations that have tested this workflow manually know that it does not reliably close in 24 hours. Those that have not tested it are often operating on optimistic assumptions. Where the hours actually go is worth being precise about. The clock starts the moment a manufacturer is aware of active exploitation; it does not wait for forensic certainty. Confirming that a disclosed CVE is present in a product is usually quick. What consumes the time that remains is the work that follows: determining which products are actually affected, assessing real-world impact in the specific context of how each one is built and deployed, and deciding on a response. That product-context risk work is the demanding part, which has to happen against a clock that is already running, not before it starts. And that window is only the first of three: the 24-hour early warning is followed by a more detailed notification within 72 hours and a final report within 14 days of a corrective measure becoming available, so a single exploited vulnerability is a staged obligation, not a one-time alert. 

The continuous reassessment problem 

CRA requires risk assessments to remain current. Not just at market placement, but throughout the product lifecycle. Every firmware update, component substitution, or newly disclosed CVE has the potential to invalidate prior risk decisions. At the product level, this is demanding but manageable. Across a portfolio of dozens or hundreds of connected products, continuous reassessment without automation is not a planning challenge. It becomes operationally unsustainable at scale. 

The audit trail problem 

Market surveillance authorities can request technical documentation, including Annex VII conformity evidence, for any covered product at any time. CRA mandates a ten-year retention period for the underlying records. The question organizations should be asking is not whether their documentation exists, but whether it can be produced as a complete, version-controlled, auditable record for a specific product version, within a timeframe that does not itself create a compliance exposure. 

For organizations relying on document management systems, shared drives, and manual assembly, the honest answer to that question is often uncomfortable. 

Where the Multi-Framework Pressure Is Sharpest 

The CRA’s burden falls unevenly. For manufacturers already operating under IEC 62443, ISO 21434, or FDA post-market guidance, the regulation is not a first introduction to product security obligations. It is an additive layer on top of existing frameworks, with distinct reporting structures, timelines, and documentation requirements that do not map cleanly onto what came before. 

Industrial OEM manufacturers, automotive Tier 1 and Tier 2 suppliers, and medical device companies with connected components in the supply chain face the sharpest version of this problem. Their compliance programs are already resource-intensive. Running CRA as a separate process, with separate documentation workflows and parallel TARA processes, can significantly increase compliance overhead for the same underlying products. 

The organizations that manage this best tend to share one characteristic: they treat the risk assessment as a shared data layer that generates outputs for multiple frameworks simultaneously, rather than running parallel processes that duplicate the underlying analysis. 

The Enforcement Timeline in Practice 

What Operational CRA Compliance Actually Looks Like 

Manufacturers that are genuinely prepared for CRA, as opposed to documented for CRA, share a set of operational characteristics. They have continuous, automated visibility into their product component inventory, including legacy products where source code is unavailable. Their risk assessments update automatically when products change or new vulnerabilities are disclosed. They have tested their ENISA notification workflow, not written it down. And they can produce conformity documentation for any covered product on demand, not over the course of several weeks. 

Getting to that state requires more than a compliance program. It requires processes and tooling that stay current as products evolve and threats change. Organizations treating CRA as a documentation exercise are building toward a December 2027 milestone that will not protect them from the September 2026 deadline. More importantly, they are building toward a model of compliance that CRA’s continuous requirements are specifically designed to make insufficient. 

The manufacturers that will navigate CRA most effectively are those that recognize it for what it is: not a certification to obtain, but an operating obligation to sustain. The sooner compliance is treated as a system rather than a project, the less disruptive the transition to full enforcement will be. 

Meeting CRA requirements means turning product cybersecurity into a continuous engineering and governance process.

C2A Security helps manufacturers translate regulatory requirements into actionable workflows across development, architecture, vulnerability management, and lifecycle risk.

With EVSec, organizations can analyze software components, map vulnerabilities to product architecture, prioritize risk based on product context, and generate compliance evidence.

Preparing early helps identify gaps now and puts teams in a stronger position as CRA requirements take effect.

Schedule a CRA readiness consultation here.