Skip to main content
CISSP-ISSAP · 20+ Years · #10 OnCon Icon
Back to BlogCompliance
EU Cyber Resilience Act: September 2026 Vulnerability Reporting Deadline—What US Companies Must Know

EU Cyber Resilience Act: September 2026 Vulnerability Reporting Deadline—What US Companies Must Know

The EU Cyber Resilience Act's first deadline hits September 2026. US companies selling connected products in Europe must report vulnerabilities within 24 hours or lose market access.

April 24, 202610 min readBy Adil Karam

Your EU market access ends on September 11, 2026, if your products carry vulnerabilities you cannot detect, track, and report within 24 hours. That is not a hypothetical. It is the first enforceable deadline under the EU Cyber Resilience Act (CRA), and most US companies building connected products or software are not ready for it.

The CRA entered into force on December 11, 2024.

It will apply in full from December 11, 2027. However, two key building blocks apply earlier: obligations for the reporting of exploited vulnerabilities and severe incidents will apply from September 11, 2026, which is particularly important for all in-scope products already placed on the EU market before the full compliance date.

The common assumption that CRA compliance is a 2027 problem is a miscalculation that will cost companies access to one of the world's largest digital markets.

Manufacturers include anyone placing a product on the European market; this is not limited to European companies.

If your SaaS platform, IoT device, enterprise software, or connected hardware touches a single EU customer, you are in scope. The September 2026 reporting obligations arrive whether or not your legal team has finished reading the regulation.

The Penalty Math Every CFO Needs to See

The CRA's enforcement structure mirrors the GDPR in both architecture and severity.

Manufacturers who fail to comply with essential cybersecurity requirements or reporting obligations face the most severe penalties, which can reach up to €15 million or 2.5% of the total worldwide annual turnover of the previous financial year, whichever is higher. This category includes failures such as missing vulnerability management processes or neglecting to report actively exploited vulnerabilities within 24 hours.

Importers and distributors are also subject to substantial fines if they breach obligations related to the EU Declaration of Conformity, CE marking, technical documentation, conformity assessment procedures, or cooperation with market surveillance authorities. These violations can result in penalties of up to €10 million or 2% of global annual turnover, whichever is higher.

The financial exposure does not stop at fines.

If a product already on the market is deemed non-compliant or presents a significant cybersecurity risk, authorities can order its immediate withdrawal from sale or even a product recall from end-users. A continent-wide recall of millions of IoT devices would result in operational chaos, massive logistics costs, and immediate revenue loss, making the direct financial fine secondary to the commercial disaster.

Beyond product recalls,

many IoT devices process personal data. A security flaw that violates the CRA will almost certainly constitute a breach of the GDPR. This means a single incident could trigger dual enforcement actions and fines under both regulations, potentially compounding the financial risk dramatically.

Every US company selling connected products or software into the EU now carries a contingent liability on its balance sheet. Board members and CFOs who cannot quantify CRA exposure are carrying an undisclosed financial risk.

What the September 2026 Deadline Actually Requires

Starting September 11, 2026, manufacturers will be required to report actively exploited vulnerabilities and significant incidents impacting the security of the product to the designated Computer Security Incident Response Teams (CSIRT) and the European Union Agency for Cybersecurity (ENISA) via a single reporting platform operated by ENISA.

These reporting obligations are operationally demanding, as they come with very short statutory deadlines, including an early warning within 24 hours, notification within 72 hours, and follow-up reporting with final reports no later than 14 days after a corrective measure is available for actively exploited vulnerabilities and within a month for severe incidents.

Critically,

these reporting obligations apply to all products in scope of the CRA that are already placed on the EU market, including legacy products placed on the market before December 11, 2027.

A product you shipped in 2019 that still serves EU customers falls under these obligations today.

If you do not have a complete SBOM for that product and real-time vulnerability monitoring, you will not even know whether your product is affected. By the time you manually investigate, the 24-hour clock has expired, and you are in non-compliance.

The CRA Compliance Requirements at a Glance

The regulation creates distinct obligation tiers with different timelines and scope:

ObligationEffective DateWho It Applies ToPenalty Tier
Vulnerability and incident reporting (Article 14)September 11, 2026All manufacturers with products on EU marketUp to €15M / 2.5% global turnover
Conformity assessment body notificationJune 11, 2026Member States / Notified BodiesN/A
CE marking and full product conformityDecember 11, 2027All manufacturers placing new products on EU marketUp to €15M / 2.5% global turnover
Other obligation failures (Importers, Distributors)December 11, 2027Importers and DistributorsUp to €10M / 2% global turnover
Misleading information to authoritiesDecember 11, 2027All economic operatorsUp to €5M / 1% global turnover

The CRA introduces a legally binding obligation for manufacturers to create, maintain, and retain a Software Bill of Materials (SBOM) for all products with digital elements marketed within the European Union. This elevates the SBOM from a voluntary best practice to a legally required element of technical documentation, essential for conformity assessment, security assurance, and incident response throughout a product's lifecycle.

This SBOM must be in a commonly used, machine-readable format and include at a minimum the top-level dependencies of the product. While the CRA does not require manufacturers to make the SBOM publicly available, they must include it in the product's technical documentation and provide it to market surveillance authorities upon request.

How Existing Frameworks Map to CRA Obligations

US companies already aligned to major security frameworks have a meaningful compliance head start. The CRA's core requirements map closely to controls your security team may already operate.

The NIST Cybersecurity Framework directly maps to the CRA's Identify-Protect-Detect-Respond-Recover model.

The NIST CSF 2.0 "Govern" function, added in the 2024 update, aligns directly with the CRA's requirement for organizational accountability over product security throughout the lifecycle. Companies using NIST CSF as their internal risk governance backbone can trace almost every CRA obligation to an existing function.

ISO 27001:2022 provides the management system structure that CRA inspectors will expect to see.

The good news is that many requirements overlap. Companies already operating an information security management system according to ISO 27001 have covered most of the organizational requirements.

Vulnerability management policies, incident response procedures, and supplier controls under ISO 27001 Annex A map directly to Articles 13 and 14 of the CRA.

CIS Controls v8 provides the operational specificity that NIST and ISO do not prescribe.

If NIST CSF is the "strategy deck" and ISO 27001 is the "governance manual," CIS Controls are the "runbook for the SOC."

CIS Control 7 (Continuous Vulnerability Management) and CIS Control 17 (Incident Response Management) are the operational engines behind any credible 24-hour reporting capability.

The gap for most US companies is not the policy layer; it is the architecture layer. Knowing a vulnerability exists is different from detecting it in real time across all product versions, correlating it to an active exploit, and filing a structured ENISA notification within a single business day.

The AI Act and CRA Convergence

Some products with digital elements may also qualify as AI systems under the AI Act. Article 12 of the CRA establishes a link between the two regulatory frameworks. Where a product is a high-risk AI system under the AI Act, compliance with the product requirements and vulnerability handling processes in Annex I of the CRA can be used to demonstrate compliance with the AI Act's cybersecurity requirements in Article 15.

For US AI product companies selling into the EU, a single compliance program can address both regulations simultaneously, provided the security architecture supports it.

Supply Chain Liability Is Moving Upstream

The EU Cyber Resilience Act starts earlier in the story. It asks why the product was allowed onto the market in insecure form in the first place.

This is a fundamental reframing from incident-response regulation to product-liability regulation.

For US and UK companies serving the EU market, this supply chain focus is particularly important where key components originate from vendors not directly subject to EU law. Contract terms should include obligations to notify about security incidents affecting components within 24 hours, support coordinated vulnerability disclosure, and cooperate with incident response investigations.

CE Marking Becomes a Competitive Differentiator

Products will bear the CE marking to indicate that they comply with CRA requirements, and national market surveillance authorities will ensure enforcement of the rules.

Early-compliant US companies will use CE marking in enterprise procurement processes, particularly in sectors where EU customers require supply chain security attestations. Companies that delay will cede deals to competitors who can demonstrate conformity. Compliance is not just risk mitigation; it is a revenue protection strategy.

Your CRA Readiness Checklist

Use this assessment to identify the gaps your security architecture must close before September 11, 2026.

Immediate (Before September 11, 2026):

  • [ ] Complete a product inventory identifying every product with digital elements placed on the EU market
  • [ ] Confirm ENISA registration and access to the CRA Single Reporting Platform before it goes live
  • [ ] Establish a Product Security Incident Response Team (PSIRT) with defined roles and escalation paths
  • [ ] Deploy real-time vulnerability monitoring tied to threat intelligence feeds (CISA KEV catalog, NVD, vendor advisories)
  • [ ] Generate machine-readable SBOMs in SPDX or CycloneDX format for all in-scope products
  • [ ] Draft and test ENISA notification templates for the 24-hour, 72-hour, and 14-day reporting stages
  • [ ] Map legacy products to current component versions to assess exploitability exposure
  • Architectural (Before December 11, 2027):

  • [ ] Embed DevSecOps pipelines with automated SBOM generation at build time
  • [ ] Implement secure-by-design and secure-by-default configurations per CRA Annex I
  • [ ] Establish secure update delivery mechanisms with cryptographic verification
  • [ ] Complete supplier contract remediation to flow down vulnerability disclosure timelines
  • [ ] Conduct third-party conformity assessment for Important or Critical product classifications
  • Governance:

  • [ ] Present CRA exposure analysis to the board, quantifying maximum penalty exposure against current revenue
  • [ ] Update D&O briefings to reflect CRA reporting obligations and personal accountability implications
  • [ ] Align NIST CSF, ISO 27001, and CIS Controls documentation to CRA Article 13 and 14 obligations
  • How I Help

    CRA vulnerability reporting obligations are an architecture problem before they are a compliance problem. If your detection infrastructure cannot surface an actively exploited vulnerability in a product component within minutes, no policy or procedure will get you to a 24-hour ENISA notification. My Security Architecture service is where most organizations must start: I design Zero Trust architectures, DevSecOps pipelines with automated SBOM generation, cloud security controls, and infrastructure hardening programs that make real-time detection and reporting technically achievable. The architecture work is the foundation; everything else builds on it.

    From there, my Compliance Advisory service translates the CRA's regulatory obligations into your existing ISO 27001 and NIST CSF control environment, identifying gaps and producing the evidence trail regulators will expect. My Board Advisory service equips your board and executive team to quantify CRA exposure, satisfy D&O due diligence requirements, and frame compliance as the market access investment it is. For companies whose products intersect with the AI Act, my AI Governance service addresses the dual CRA-AI Act compliance pathway in a single coordinated program.

    If you are not certain where your organization stands against the September 2026 deadline, a focused readiness assessment is the right first step. Book a discovery call and we will map your current state to the CRA's immediate obligations in a single session, without a sales presentation.

    #EU Cyber Resilience Act#Vulnerability Reporting#EU Compliance#Cybersecurity Regulations#Connected Products#Product Security
    PDFShare:

    Adil Karam

    Security & AI Governance Advisor

    Helping organizations navigate security leadership and AI governance challenges.

    Ready to Put These Insights Into Action?

    Whether you need AI governance, security leadership, or compliance guidance—let's discuss how to apply these strategies to your organization.