The EU Cyber Resilience Act's First Deadline Just Hit: Is Your Product Security Program Ready?

September 11, 2026 passed five days ago. If your company sells any connected hardware or software into the EU market and you are not yet actively reporting exploited vulnerabilities to ENISA, you are already out of compliance. Most product team leaders I speak with either underestimated this deadline or missed it entirely. That is not a reflection of negligence. It is a reflection of how quietly consequential this regulation has been, right up until the moment it became legally binding.

As of September 11, 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements.

This is not a soft obligation.

The penalties sit at €15 million or 2.5% of total worldwide annual turnover, whichever is higher, and the Article 14 reporting duties that activated on September 11 are in the top penalty tier.

For a mid-market software company, that exposure can represent a meaningful share of annual revenue. For an enterprise product company, the number is existential.

What makes this particularly urgent is the second deadline sitting 15 months out.

On December 11, 2027, the full application of all remaining requirements takes effect, including essential cybersecurity requirements, conformity assessment, CE marking, and technical documentation obligations.

Companies that scramble to satisfy September's reporting mandate without building toward the 2027 architecture will find themselves doing this work twice. The smarter play is to treat these two deadlines as phases of a single infrastructure build, not separate compliance events.

What the Law Requires, Right Now

As of September 11, manufacturers must report vulnerabilities and incidents to ENISA and their designated national CSIRT. The timeline is sequential: submit an initial early warning within 24 hours of becoming aware of an exploited vulnerability, including whether the event might be malicious; then provide more detailed information within 72 hours, including an initial assessment of severity, the nature of the vulnerability, mitigation steps taken, and recommended actions for users.

Perhaps the most consequential dimension of this obligation is its retroactive reach. Article 69(3) of the CRA explicitly extends Article 14's reporting requirements to all in-scope products already on the EU market, including hardware shipped years before the regulation existed and software licensed to European businesses long before anyone had heard of the CRA.

The product your engineering team shipped in 2021 is in scope today.

The 24-hour clock runs from the moment of awareness, defined by the European Commission's July 27, 2026 guidance as the point when an initial assessment reaches reasonable certainty about active exploitation. Manufacturers must therefore maintain their own separate timestamped records of when awareness occurred; the SRP alone cannot document compliance with the legal trigger.

That is a process and architecture requirement, not merely a legal one.

The Compliance Gap Is Larger Than Most Executives Realize

The data here is sobering, and your competitors are in the same position.

The 2026 CRA Awareness and Readiness Report found a blunt headline: 62% of respondents had little to no familiarity with the regulation. Far from narrowing, the awareness gap has since widened, with the proportion unfamiliar rising to 66%.

That survey was conducted across 843 organizations.

Unfamiliarity in the United States and Canada sits at 72%, suggesting that a major segment of the global supply chain remains materially unprepared, given that any organization placing commercial products on the EU market must comply.

ENISA's own research confirms the structural problem.

ENISA published a new SME Cyber Resilience Maturity Assessment Model alongside survey data showing that most small and medium-sized manufacturers know the CRA is coming but lack the documentation, staffing, and technical processes to meet it. Of the 194 organizations surveyed across 31 countries, roughly two-thirds had heard of the CRA, yet practical understanding of the regulation's requirements consistently lagged behind awareness.

Knowing a regulation exists and being able to operationalize it are two entirely different capabilities.

The widest gaps found were the software bill of materials, used by only about 35 percent of respondents, threat modeling, and incident response.

These are not peripheral capabilities. They are the operational core of what the CRA demands.

Reporting to ENISA within 24 hours is the visible output of a detection pipeline, an escalation runbook, a product inventory, and an SBOM that most engineering organizations have never had to build before. The report is the easy part.

Phase One vs. Phase Two: Know What You Owe and When

Understanding the two-phase structure is the prerequisite for building a sensible roadmap. The table below maps the key obligations to their activation dates and the underlying infrastructure each one requires.

By December 11, 2027, every product with digital elements must be secure by design, ship without known exploitable vulnerabilities, carry a declared support period of at least five years, unless the expected lifetime of the product is naturally shorter, and keep each issued security update available for a minimum of 10 years after that update is issued, or for the remainder of the support period, whichever is longer.

The vulnerability detection pipeline, the legal escalation path, the incident response runbook, and the SRP registration that are necessary to meet the September 2026 obligations are the same infrastructure necessary to meet the 2027 requirements. Companies that treat September 2026 as a soft deadline may find December 2027 far harder to meet than anticipated.

Framework Alignment: Where the CRA Maps to What You Already Know

If your organization operates under ISO 27001, NIST CSF 2.0, or the CIS Controls, the CRA does not require you to start from scratch. It does require you to extend existing frameworks to the product layer specifically.

The CRA's secure-by-design mandate maps directly to NIST CSF's "Protect" function, specifically PR.DS (Data Security) and PR.PS (Platform Security). The 24-hour vulnerability reporting obligation aligns to the "Respond" function, specifically RS.CO (Incident Response Communication). The SBOM requirement connects to NIST SSDF (Secure Software Development Framework) practice PW.4, which covers reusing existing, well-secured software. ISO 27001's Annex A control A.12.6 addresses technical vulnerability management, but the CRA extends that obligation to every product across its entire support lifetime. Companies with mature ISO 27001 programs have the governance scaffolding; they typically lack the product-layer operational processes.

One critical gap in most existing frameworks: none of them require a machine-readable SBOM that is both maintained continuously and producible on demand for regulators.

Manufacturers must produce a machine-readable SBOM covering at least the top-level dependencies of every product with digital elements, keep it current, and provide it to market surveillance authorities on request.

If your engineering team generates an SBOM at release and never updates it, that does not satisfy the CRA's intent, even if it produces the right document format.

Emerging Trends Shaping the 2027 Deadline

Supply Chain Liability Is Moving Upstream

When a manufacturer discovers a vulnerability in a third-party component integrated into its product, it must notify the component's manufacturer or maintainer. This is an upstream notification obligation.

That changes procurement conversations permanently.

Commercial vendors who distribute open source components in their products remain fully responsible for those components under the CRA.

Your legal exposure does not stop at your own code.

Market Surveillance Authorities Will Compare Notes

National market surveillance authorities, designated by each member state, enforce the CRA. A manufacturer selling across the EU can face more than one authority looking at the same product.

The GDPR enforcement trajectory is instructive here. Regulators began with large, visible companies and progressively moved down market. Expect the same pattern from CRA market surveillance, with the first enforcement actions targeting the most visible non-compliance.

The CVE Volume Problem Makes Manual Processes Untenable

At the current pace of CVE publication, more than 48,000 entries in 2025 alone, roughly 131 new CVEs per day, manual correlation cannot keep pace.

Meeting a 24-hour reporting obligation against that volume without automated tooling is not a process problem. It is an architecture problem. Companies that have not embedded vulnerability scanning into their CI/CD pipelines and connected those pipelines to a live SBOM will consistently fail the detection speed requirement before they ever reach the reporting step.

Non-EU Manufacturers Face the Same Obligations

Manufacturers based outside the EU are in scope if their products reach the EU market.

If your company is headquartered in North America or Asia-Pacific and ships connected products into Europe, you are subject to the same requirements as an EU-based competitor, with the same penalty exposure and no jurisdictional relief.

CRA Readiness Assessment: Where Does Your Organization Stand?

Use this checklist to identify your current gap against both deadlines. Every "No" in the September 2026 column is an active compliance risk. Every "No" in the December 2027 column is a risk that requires 12 to 18 months of architecture work to close.

September 2026 Obligations (Active Now)

[ ] Registered on ENISA's Single Reporting Platform (SRP) with current product inventory

[ ] Incident response runbook updated to include CRA 24/72-hour reporting cascade

[ ] Timestamped awareness log process in place (separate from SRP submission)

[ ] Product inventory maps all connected products currently on the EU market, including legacy products

[ ] Upstream notification process defined for third-party component vulnerabilities

[ ] Designated contact in EU CSIRT for your primary establishment's member state

December 2027 Obligations (15 Months to Build)

[ ] Machine-readable SBOM generated automatically from build pipeline for every in-scope product

[ ] SBOM update process tied to each release and each significant dependency change

[ ] Threat modeling conducted and documented for each product category

[ ] Secure-by-design principles embedded in development standards and engineering onboarding

[ ] Coordinated vulnerability disclosure policy published and operationalized

[ ] Conformity assessment strategy defined (self-assessment vs. notified body) per product class

[ ] Security support period declared for each product, with lifecycle sunset process

Most companies are unable to manage the CRA transition using their own staff and in-house resources. 61% of companies have set aside a budget for this transition or are planning to do so. However, only 18% believe they do not need external assistance.

That self-assessment is accurate. The combination of DevSecOps tooling, supply chain mapping, legal process design, and regulatory documentation required here exceeds the bandwidth of a typical internal security team.

How I Help

Security Architecture is where CRA compliance becomes real. I work with product-led companies to design and build the security infrastructure that both deadlines actually demand: vulnerability detection pipelines integrated into CI/CD, SBOM generation and lifecycle management, DevSecOps process design, secure-by-design product standards, and the incident reporting workflows that tie all of it to the ENISA SRP. This is architecture work, not policy work, and it requires someone who has built these systems before. I start with a structured gap assessment against both the September 2026 reporting obligations and the full December 2027 requirements, so your leadership team knows exactly where you stand, what the risk exposure is today, and what to build first.

For the regulatory framing and ongoing compliance posture, my Compliance Advisory service translates CRA obligations into audit-ready evidence and keeps your program current as guidance evolves. If your board needs to understand the liability exposure and business risk, Board Advisory gives directors the briefing they need to ask the right questions and govern this effectively. I also help companies building AI-enabled connected products address the intersection of CRA and emerging AI governance requirements through Secure AI Deployment. And for organizations that need sustained security leadership without a full-time hire, Fractional CISO provides the senior oversight to hold all of this together.

The September 11 deadline has passed. The question is not whether you should act. It is whether you act now, before an enforcement notice or a product recall forces the decision for you.

See if I should be in the room