The EU Cyber Resilience Act Reporting Deadline Is Here: What US Tech & Product Companies Must Do Now

If your company ships software or connected products to European customers, something changed on September 11th, 2026. As of that date, you became subject to mandatory 24-hour vulnerability reporting to the EU Agency for Cybersecurity. Most of the US tech executives I speak with have no idea they are in scope, and fewer still have the architecture to comply. The clock is already running.

The CRA is broad in scope from both a territorial and material perspective: it applies to companies inside and outside the EU, including those in the U.S., where their connected products are sold or made available in the EU, and it is a horizontal, sector-neutral law covering most modern connected hardware and software.

That means your SaaS platform with EU customers, your IoT firmware shipped to a European OEM, or your SDK embedded in a Berlin-based product company's device all qualify. "We're headquartered in Austin" is not a legal defense.

The financial exposure is not theoretical.

Non-compliance with the essential cybersecurity requirements set out in Annex I and the obligations set out in Articles 13 and 14 is subject to administrative fines of up to €15,000,000 or, if the offender is an undertaking, up to 2.5% of its total worldwide annual turnover for the preceding financial year, whichever is higher.

For a US software company doing $200 million in annual revenue, that is a $5 million fine per violation. And fines are not the worst outcome.

Market surveillance authorities carry an additional lever: ordering a non-compliant product withdrawn or recalled under Article 54, reaching products already on the market.

For companies where EU revenue represents 20 to 40 percent of total revenue, that is not a compliance footnote. It is a geographic revenue extinction event.

What the September 11 Deadline Actually Requires

Most US companies preparing for the CRA have been watching the December 11, 2027 full-compliance date. That date covers CE marking, conformity assessment, and technical documentation.

The CRA's reporting obligations apply from September 11, 2026, to all products with digital elements that fall within the CRA's scope, notwithstanding that the rest of the CRA's obligations do not come into force until December 11, 2027.

The reporting regime operates on a tiered timeline with real operational bite:

A manufacturer that becomes aware that any vulnerability in its product is being actively exploited must notify ENISA and the relevant national CSIRT within 24 hours of becoming aware. A follow-up report providing a more detailed assessment must be submitted within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available. For severe incidents affecting product security, the same 24-hour initial notification applies, with a detailed incident report within 72 hours and a final report within one month.

The mechanism for filing is equally important to understand.

The CRA mandates manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents using the Single Reporting Platform, as of September 11, 2026 onwards.

ENISA's Single Reporting Platform is the only channel through which CRA Article 14 notifications may be filed. Manufacturers cannot submit via email, national authority portals, or any other mechanism.

One misconception circulates widely and must be corrected directly.

Many manufacturers have assumed that CRA Article 14's reporting requirements apply only to new products launched after September 11, 2026. That assumption is wrong. Article 69(3) of the regulation explicitly extends the reporting obligation to every in-scope product already on the EU market.

The router your company shipped in 2022 and the firmware your team distributed during the pandemic both carry live reporting obligations starting now.

The 24-hour notification window is not a documentation exercise. It is a detection-to-disclosure workflow problem, and companies without automated vulnerability monitoring pipelines and pre-built ENISA reporting runbooks will fail it on the first real incident.

The Scale of the Vulnerability Problem

Manual vulnerability tracking cannot satisfy this requirement.

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

The CRA's formal SBOM mandate, requiring machine-readable component inventories in CycloneDX or SPDX format, does not technically apply until December 2027, but compliance with the September 11 reporting obligation is structurally near-impossible without one.

This is where most US companies discover a compounding problem. They do not have SBOMs. They do not have automated exploit-monitoring tied to product component inventories. And they have never designed a detection-to-regulatory-disclosure pipeline with a 24-hour SLA to a foreign regulator.

Complying with the CRA's reporting requirements requires more than a policy update. It requires a structural shift in product security that often impacts product design, technical and organizational controls, staff training, and internal procedure.

CRA vs. Existing US Frameworks: The Gap Analysis

The CIRCIA comparison deserves specific attention. CIRCIA's 72-hour window applies to covered entities experiencing cyber incidents, specifically breaches.

The CRA creates a reporting duty for two specific triggers: a vulnerability that is being actively exploited, and a severe incident affecting the product's security. Not every flaw and not every glitch; the trigger is active exploitation or severe impact.

That is a fundamentally different and earlier trigger than most US incident response programs are designed to detect and escalate.

Framework Alignment: Where CRA Maps to What You Already Know

The CRA's obligations are not entirely without precedent in US security frameworks, but they require materially different implementation than most companies currently have in place.

NIST Cybersecurity Framework 2.0 covers Identify, Protect, Detect, Respond, and Recover. CRA's 24-hour reporting obligation lives primarily in the Detect and Respond functions. Most US product companies have weak Detect function maturity at the component level, meaning they can detect a breach in their environment but cannot detect that a specific component in a shipped product is being actively exploited in an EU customer's deployment.

ISO 27001:2022 Annex A controls 8.8 (Management of technical vulnerabilities) and 5.24 (Information security incident management) are the closest analogs. However, ISO 27001 certification does not satisfy CRA obligations. The CRA requires product-level vulnerability disclosure to a specific regulatory platform on a specific timeline, which goes beyond what ISO 27001's management system requirements address.

CIS Controls v8 Control 7 (Continuous Vulnerability Management) and Control 17 (Incident Response Management) are directly relevant. Companies with mature CIS Control 7 implementations, specifically those using automated scanning tied to component-level SBOMs, are meaningfully better positioned to meet the 24-hour window. Those running periodic manual scans are not.

The honest assessment: CRA compliance requires a purpose-built vulnerability management and disclosure pipeline that sits on top of, not within, your existing frameworks. None of your current certifications grant exemption or presumption of conformity for Article 14 obligations.

Emerging Obligations to Anticipate Now

Supply Chain Liability Cascades Upstream

The obligations attach when a company carries software into a commercial activity, including integrating it into a product placed on the market. At that point, the commercial actor, not upstream volunteers, is the manufacturer. A commercial product built on open-source components carries CRA obligations for the whole stack it ships.

US companies selling SDKs, libraries, firmware, or middleware to OEMs now carry upstream liability. A vulnerability in your component can trigger your own reporting obligation even if you never sold directly to an EU end user.

Supplier contracts must be updated to reflect CRA obligations, with CRA compliance included in supplier due diligence procedures.

Legacy Products Create Surprise Exposure

Reporting obligations continue to apply even after a product's support period has ended. Manufacturers may still be required to report actively exploited vulnerabilities and severe incidents affecting older or no longer supported products, provided they are available in the EU market.

This creates a product inventory exercise most companies have not performed: cataloging every product currently available to EU customers, including legacy versions, and mapping each to a responsible legal entity.

The SBOM Becomes Operational, Not Just Compliant

Meeting the reporting deadline requires knowing which components a product contains, which means SBOMs need to be operational well before the 2027 deadline for products already on the market.

CycloneDX 1.6+ or SPDX 3.0.1+ in JSON or XML format

are the de facto standard formats. Companies that treat SBOM generation as a 2027 compliance checkbox will find themselves unable to answer a 24-hour reporting obligation today.

CRA Readiness Checklist: What Your Team Should Verify This Week

Use this to assess your current exposure. If more than three items are unchecked, your organization is carrying active enforcement risk right now.

[ ] Product inventory complete: Every hardware and software product available to EU customers is catalogued, including legacy versions

[ ] Legal entity mapping done: The responsible manufacturer under CRA is identified for each product

[ ] Exploit monitoring active: Automated monitoring is tied to product component inventories, not just network perimeters

[ ] SBOM generated: At minimum, top-level dependencies in CycloneDX or SPDX format exist for all in-scope products

[ ] ENISA SRP account registered: Your organization has registered on ENISA's Single Reporting Platform

[ ] 24-hour runbook exists: A documented escalation process names who detects, who triages, who decides, and who files

[ ] 72-hour and 14-day workflows defined: The follow-up report process is documented and assigned

[ ] User notification template ready: Article 14 requires timely notification to impacted users with available mitigations

[ ] Supply chain contracts reviewed: Upstream component suppliers have CRA obligations addressed in agreements

[ ] Tabletop exercise completed: Your team has practiced the detection-to-disclosure sequence at least once

Software makers should build a CRA incident and vulnerability reporting process that can detect reportable events, classify severity, identify affected EU member states, notify users, submit reports within 24 and 72 hours, and produce final reports within the required 14-day or 1-month windows.

None of this is achievable on the day an incident occurs without pre-built infrastructure.

How I Help

US product and SaaS companies selling into the EU need to redesign their security architecture before the next exploited CVE surfaces in their product stack. My Security Architecture practice builds exactly what CRA Article 14 compliance demands: SBOM generation pipelines integrated into your CI/CD process, exploit monitoring tied to component-level inventories, automated escalation workflows that route to the ENISA Single Reporting Platform within your 24-hour window, and DevSecOps infrastructure that makes secure-by-design a build-time property rather than a post-launch audit. This is not consulting in the abstract. It is concrete architectural work that produces billable, deliverable, audit-ready systems, typically structured as a 60 to 90 day engagement with immediate risk reduction at every phase.

For companies that need ongoing regulatory translation as CRA full compliance approaches in December 2027, my Compliance Advisory practice maps your product portfolio against the full CRA obligation set, including essential requirements, CE marking strategy, and technical file readiness. Organizations that need a senior security executive to own this agenda at the board level benefit from Virtual CISO engagement, where I carry the CRA program as an ongoing governance responsibility alongside your existing leadership team. If your product lines intersect with AI-driven features or autonomous systems, Secure AI Deployment addresses the compounding regulatory surface where CRA meets the EU AI Act. And for boards that need to understand their fiduciary exposure under CRA enforcement, my Board Advisory practice translates product compliance risk into the governance language directors and officers require.

The deadline has passed. Every day without compliant architecture is a day of active enforcement exposure.

See if I should be in the room