Most teams have spent the last year planning around 2027. That's the wrong horizon. September 2026 is a current-portfolio problem, not a future-product one, and it applies to software and hardware already sitting in EU customers' hands.
What Actually Changes on September 11, 2026
The CRA (Regulation (EU) 2024/2847) entered into force on December 10, 2024. From September 11, 2026, manufacturers of "products with digital elements" must report to ENISA and their national CSIRT whenever they become aware of:
- An actively exploited vulnerability in their product
- A severe incident affecting the security of the product
The timeline is unforgiving and staged:
- Early warning within 24 hours of becoming aware — a bare-bones notification, not a full report
- Full notification within 72 hours — more detail on nature, severity, and indicators of compromise
- Final report within 14 days after a corrective measure is available (for exploited vulnerabilities), or within one month for severe incidents
Reporting goes through the CRA Single Reporting Platform, and manufacturers report only once, with the notification routed to the relevant authorities. Note that vulnerability patching and remediation obligations don't formally kick in until December 11, 2027 but you can't report what you haven't detected, and you can't detect what you haven't inventoried. That's why the real work starts now.
Why Dev Teams, Not Just Legal, Own This
Compliance teams can write policy, but Article 14 is fundamentally an engineering problem. Reporting "actively exploited vulnerabilities" within 24 hours requires:
- Real-time visibility into every open-source and third-party component in production
- A working Software Bill of Materials (SBOM) generation pipeline
- Automated vulnerability monitoring tied to exploit intelligence feeds, not just CVE publication
- An internal escalation path that can move from "we detected this" to "regulator notified" in under a day
None of that exists overnight. If your team is only starting SBOM generation now, you're behind — most compliance practitioners recommend having automated SBOM and vulnerability-tracking pipelines operational well before the reporting clock starts, since accurate component-level visibility is the prerequisite for the 24-hour trigger, not a nice-to-have.
The Pre-September Checklist
1. Map your CRA scope. Inventory every product your organization manufactures, imports, or distributes that qualifies as a "product with digital element" under the CRA, and determine your role manufacturer, OEM, distributor, or importer since obligations differ by role.
2. Stand up SBOM automation. Every build pipeline should generate an SBOM automatically, in a machine-readable format, covering at minimum top-level dependencies. Manual, quarterly SBOM exports will not support a 24-hour reporting SLA.
3. Wire vulnerability monitoring to exploit intelligence. Article 14 triggers on actively exploited vulnerabilities, not every new CVE. Your tooling needs to distinguish the two, or your security team will drown in false alarms while missing the ones that actually require reporting.
4. Build the reporting workflow now, not in August. Register for the ENISA Single Reporting Platform, define who internally owns the 24-hour early warning, and rehearse the process with a tabletop exercise. This overlaps closely with incident-reporting muscle many EU-facing teams have already built for NIS2 organizations that have mapped out their NIS2 incident reporting timeline and 24/72-hour escalation paths have a head start, since CRA's staged reporting windows mirror that structure closely.
5. Test what you ship. Before September, run vulnerability assessments and penetration tests against production systems and flagship products to surface exploitable issues before an attacker or a regulator finds them for you. Structured, CREST-aligned penetration testing services give you a documented baseline of exploitable vulnerabilities and remediation priorities that directly feeds your CRA vulnerability-handling process.
6. Align CRA and NIS2 obligations. Many organizations in scope for the CRA are also "essential" or "important" entities under NIS2, which carries its own incident reporting and risk-management requirements. Rather than running two disconnected compliance tracks, unify governance, detection, and reporting workflows across both. Firms that already work with a NIS2 compliance consultancy and audit partner are finding it far easier to extend that same evidence base to CRA reporting, since the underlying detection and escalation infrastructure overlaps heavily. For teams also navigating financial-sector rules, this guide on NIS2 vs DORA is a useful companion for mapping overlapping obligations.
Don't Wait for December 2027 to Start Caring
It's tempting to treat the CRA as a 2027 problem because that's when full conformity assessment, CE marking, and secure-by-design documentation become mandatory. But Article 14 reaches products already on the market there's no grace period for legacy code. A single missed or late report after September 11, 2026 can trigger regulatory scrutiny, and for many organizations the operational cost of getting caught unprepared will exceed the cost of building proper readiness now.
If you need an outside view on where your organization actually stands, a structured gap assessment across CRA, NIS2, and related EU frameworks is the fastest way to find out. VISTA InfoSec's compliance and security advisory team works with engineering and compliance leaders across the US, UK, EU, and Asia to close exactly these kinds of gaps before regulatory deadlines land.
.png)
No comments:
Post a Comment