The EU Cyber Resilience Act's September 11 Deadline: What Every Executive Needs to Do Right Now

Your compliance timeline has a critical error. If your organization sells software, connected hardware, or SaaS-adjacent products into the EU and you are planning around a December 2027 deadline, you are already exposed. The EU Cyber Resilience Act's first legally binding obligation takes effect September 11, 2026, not December 2027, and it applies to every product with digital elements currently on the EU market, including the ones your engineering team shipped three years ago.

The EU Cyber Resilience Act has two enforcement dates: Article 14 reporting from September 11, 2026, and full applicability from December 11, 2027.

Most CRA programs plan only for the later one.

That planning assumption is wrong, and the cost of discovering that error during an active exploit event rather than in a boardroom is significant.

Article 69(3) of the CRA states that the Article 14 reporting requirements apply to all products with digital elements that have been placed on the market before December 11, 2027. It does not matter if your product shipped in 2019. If it is still in use and contains an actively exploited vulnerability, you must detect it and report it starting September 2026.

This is not a future-product problem; it is a portfolio-wide problem you own today. Executives who believe this is their engineering team's issue to handle quietly are holding the wrong mental model. This is a board-level risk with board-level consequences.

What Article 14 Actually Requires

From September 11, 2026, a manufacturer that becomes aware of an actively exploited vulnerability has 24 hours to file an early warning, 72 hours for the full notification, and 14 days for the final report once a corrective measure is available.

These are not aspirational targets. They are legally enforceable timelines measured from the moment your organization becomes aware, not from the moment you finish investigating.

Article 16 of the CRA requires ENISA to establish a Single Reporting Platform giving each EU member state CSIRT its own electronic notification endpoint. A manufacturer reports to one CSIRT; that CSIRT circulates the report to ENISA and other relevant CSIRTs.

There is no reporting country by country, and emailing a national agency directly does not fulfill the obligation.

As of September 11, 2026, the Single Reporting Platform will be used by CSIRTs and manufacturers for mandatory reporting.

ENISA published updated guidance documents for the platform in August 2026, and

ENISA published a factsheet and step-by-step guidance in July 2026, with three guides available: registration and notification submission, both updated August 3, 2026, and platform interface functions, updated August 14, 2026.

The scope question matters just as much as the timeline.

If your product contains software or firmware and is made available on the EU market with a direct or indirect data connection, it is very likely in scope. Sector-specific products such as medical devices, vehicles, and aviation, along with non-commercial open source, are the main exceptions.

The requirements apply to manufacturers, importers, and distributors of products with digital elements placed on the EU market. They apply regardless of whether the company in question is based inside or outside the EU.

The Readiness Gap Is Real and Documented

The data on organizational readiness is not reassuring. According to the 2026 CRA Awareness and Readiness Report published by the Linux Foundation and OpenSSF:

Among organizations that are aware of the CRA, 41% have still not determined if the regulation applies to them.

Nearly half (46%) are uncertain about the timeline altogether, while 66% of industry respondents remain entirely unfamiliar or only slightly familiar with the CRA.

Unfamiliarity is especially high outside of Europe; about 72% of US and Canadian respondents are unfamiliar with the CRA, even though compliance is mandatory for anyone selling commercial software products into the EU market.

Article 14 reporting capability does not exist as a standard feature in most mid-market technology and manufacturing companies. No ENISA channel, no triage protocol calibrated to CRA definitions, no designated responsible person, and no tested 24-hour escalation path means non-compliance begins on day one, not after a grace period.

The financial stakes make the operational problem impossible to ignore.

Each Member State must establish effective, proportionate, and dissuasive penalties, with maximum fines reaching up to €15 million or 2.5% of the undertaking's total worldwide annual turnover for the preceding financial year, whichever is higher.

Non-compliance may result in product withdrawal orders, prohibition of market placement, financial penalties, and reputational damage, particularly where vulnerabilities lead to security incidents affecting users or critical infrastructure.

For companies generating 20 to 40% of revenue from EU markets, even a credible threat of market restriction during an active audit creates a material financial risk that demands disclosure to investors and boards.

CRA Article 14 at a Glance: What You Must Build Before September 11

Your existing incident response plan was almost certainly not drafted with Article 14 of the CRA in mind. Review and update it to integrate the CRA reporting workflows and timelines, ideally alongside parallel obligations under EU NIS2, GDPR, or sector-specific reporting regimes, as well as non-EU cyber laws your organization may be subject to.

Framework Alignment: What You Already Have and What the Gap Looks Like

Organizations with mature ISO 27001 or NIST Cybersecurity Framework programs are closer to readiness than those starting from scratch, but neither framework closes the Article 14 gap automatically. ISO 27001 Annex A controls cover vulnerability management (A.8.8) and incident response (A.5.26), but the CRA imposes specific timelines and a designated reporting channel that must be operationalized on top of existing controls.

Most organizations do not start from zero. They already have incident response policies, patch management routines, secure development practices, supplier reviews, vulnerability scanners, and ISO 27001 evidence. But the CRA does not reward isolated documents. It demands a fast, defensible workflow that can answer five questions at the same time: Is this an actively exploited vulnerability or a severe incident affecting product security?

Which products are affected? Which authority do you notify? Who owns the 24-hour clock? And what evidence proves you reported on time?

CIS Control 7 (Continuous Vulnerability Management) gives organizations a baseline for detection, but the CRA's reporting obligation requires organizations to move from detection to regulatory notification within a window that leaves no time for committee decisions. The missing piece for most organizations is the decision tree: a documented, tested, executive-authorized escalation path that converts a threat intelligence signal into a filed notification without requiring a legal call at 2 a.m.

Emerging Obligations That Compound the September 11 Risk

The SBOM Dependency Is Invisible But Immediate

The dependency between SBOMs and the September 2026 reporting deadline is real: with full component-level visibility into your products, you can report on an actively exploited vulnerability quickly and with confidence. Practically speaking, SBOM readiness is required for the 2026 deadline even though the formal SBOM mandate is part of the 2027 requirements.

If you cannot identify within hours whether a newly reported CVE lives in your product's dependency tree, you cannot meet a 24-hour reporting clock. The SBOM is not a documentation exercise; it is the detection substrate that makes Article 14 operationally possible.

Supply Chain Exposure Flows Upstream

Without notification clauses in supplier contracts, you may not receive the information you need to comply with Article 14 in time.

If a component vendor discovers an actively exploited vulnerability in firmware your product ships, their silence becomes your enforcement exposure. Procurement teams need to treat CRA notification clauses the same way they treat GDPR data processing agreements: as a mandatory contractual baseline, not a legal nicety.

The December 2027 Work Starts Now

The full conformity requirements, including secure-by-design obligations, CE marking, and conformity assessments, apply from December 11, 2027. Organizations that build the Article 14 reporting infrastructure now create the operational foundation that December 2027 conformity depends on. The alternative is running two separate compliance programs sequentially, under regulatory scrutiny for the first and time pressure for the second.

Article 14 Readiness: Executive Checklist

Use this checklist to assess your organization's posture before September 11, 2026. Each item maps directly to an Article 14 obligation or a prerequisite for meeting one.

[ ] Scope determination complete. Have you mapped every product with digital elements sold or available in the EU market, including products placed before 2024?

[ ] Responsible person designated. Is there a named individual with authority to authorize and file a regulatory notification within 24 hours?

[ ] ENISA SRP registration initiated. Has your authorized representative created an EU Login account and registered on the ENISA Single Reporting Platform?

[ ] CRA trigger definitions documented. Does your security team have written criteria defining what constitutes "active exploitation" and a "severe incident" under CRA definitions, distinct from your general incident response thresholds?

[ ] 24-hour escalation path tested. Has your team run a tabletop exercise simulating discovery of an actively exploited vulnerability and traced the workflow through to a draft early warning notification?

[ ] 72-hour notification template ready. Is a template drafted, legally reviewed, and accessible to the on-call team without requiring a legal review cycle at the time of a live event?

[ ] SBOM coverage verified. Do you have component-level visibility across affected product versions sufficient to confirm or rule out impact within hours of a new CVE publication?

[ ] Supplier notification clauses reviewed. Have you audited vendor contracts for CRA-aligned vulnerability disclosure obligations and amended agreements where clauses are absent?

[ ] Board briefing scheduled. Has the board been informed of the September 11 obligation, the enforcement consequences, and the current readiness posture?

[ ] NIS2 and GDPR overlap mapped. For incidents that trigger both CRA Article 14 and NIS2 or GDPR reporting, is there a single, coordinated notification workflow or separate conflicting processes?

How I Help

Most companies do not know if Article 14 applies to their entire product portfolio, and the ones that do often lack the internal security leadership to convert that knowledge into an operational reporting program. As a Fractional CISO, I step into the gap between regulatory exposure and operational readiness. In a focused engagement, I scope your Article 14 exposure across product lines, identify which products trigger mandatory 24-hour reporting, coordinate the cross-functional work between legal, engineering, and security, and brief your board with precision. You get senior security leadership with 20+ years of regulatory program experience, without the timeline or cost of a full-time hire. For most mid-market technology and manufacturing organizations, a 6-week sprint is enough to move from unaware to reporting-ready.

For the longer road to December 2027, my Compliance services build the structured program that carries your organization through conformity assessment, CE marking, and full CRA applicability. If your products touch AI models or AI-enabled decision systems, Secure AI Deployment addresses the intersection of CRA obligations and emerging EU AI Act requirements. Boards that need a prepared, independent voice for regulatory risk discussions will find that Board Advisory services translate technical exposure into fiduciary language. If your architecture itself creates compliance risk through poor segmentation or unmanaged attack surface, Security Architecture review identifies and closes those gaps before a market surveillance authority does.

See if I should be in the room