A factory in Hsinchu builds a Class I PwDE under the CRA — a smart industrial gateway, say, with a network stack and an embedded Linux distribution — and ships it to a German integrator on 12 September 2026. The product is on the EU market. It is unequivocally inside the CRA. Its support period clock has started. Its vulnerability handling obligations are alive.
And yet, on the engineering team’s shared compliance dashboard, the row for “Cyber Resilience Act” shows the project as on track. No SBOM has been generated. No security advisory pipeline exists. No notified body has been engaged. The compliance manager has marked the row green because, in his reading of the regulation, the binding deadline is 11 December 2027 — fifteen months out. He is half right and half wrong, and the half he is wrong about is what 11 September 2026 is for.
That date does bind something. It just doesn’t bind what most people think.
§ 01The thing that activates on 11 September 2026 is Article 14, not Article 13
Article 71(2) of the CRA is unambiguous: “Article 14 shall apply from 11 September 2026.” Article 13 — the article that contains every substantive obligation a manufacturer has to actually build a secure product — does not appear in 71(2). Article 13 applies from 11 December 2027, the same day as the rest of the substantive regulation. Fifteen months separate the two dates, and that fifteen-month gap is doing real work.
Article 14 is the reporting article. It says: when an actively exploited vulnerability comes to your attention, or when a severe incident affecting your product’s security comes to your attention, you must notify the relevant CSIRT and ENISA through the Single Reporting Platform within 24 hours, deliver a detailed notification within 72 hours, and a final report within 14 days (for vulnerabilities) or one month (for severe incidents). It is, structurally, a duty to tell on yourself when something bad surfaces.
Article 13 is the construction article. It says: design securely, do a risk assessment, handle vulnerabilities for the support period, prove it on paper, get a notified body to bless the result if the product is Important or Critical. It is, structurally, a duty to build the product right in the first place.
Reporting an actively exploited vulnerability you discovered is not the same as having built the product securely. Telling on yourself is not the same as compliance. The September 2026 date binds the first; the December 2027 date binds the second.
§ 02What you actually have to do by 11 September 2026
The list is shorter than most consultancies suggest, and the items on it are operational rather than architectural. They can be assembled in three to four months by a focused team that already has a security function. Without a security function, six to nine.
| What | Why | Source |
|---|---|---|
| A standing process to detect actively exploited vulnerabilities in your products — CVE feeds for your component stack, monitoring of your bug bounty inbox, a coordinated vulnerability disclosure (CVD) intake channel. | You can’t report what you don’t see. Article 14 obliges reporting upon becoming aware, and a regulator’s view of “reasonable awareness” is not generous to teams that didn’t have intake. | Art 14(1), Art 14(2) |
| A 24/72/14-day reporting capability — named owner, escalation path, drafting templates, a tested run-through. | The clocks start when a reasonable engineer first thinks “this looks like an actively exploited vulnerability in our product.” Designating the owner after the clock has started is a way to miss the 24-hour mark. | Art 14(2)(a)–(c), Art 14(4)(a)–(c) |
| A coordinator-CSIRT decision — for non-EU manufacturers, the four-step waterfall under Art 14(7) (auth. rep, then importer, then distributor, then users), with each step using a highest-volume tie-breaker. | You don’t pick the CSIRT. Art 14(7) picks one for you, and the answer can change as your distribution mix moves. | Art 14(7) |
| A user notification capability — how you reach owners of products in the field with a security advisory, in a structured machine-readable format where appropriate. | Art 14(8) requires it “without undue delay” to impacted users, and where appropriate to all users. CSAF (ISO/IEC 20153:2025) is the format. | Art 14(8) |
| An incident response plan with the SRP submission step embedded, not bolted on. | Article 14 is alive on day one. The plan has to work the first time a real incident hits, not after a tabletop on day thirty. | Art 14(3), Art 16 |
That’s the binding list. It is doable. It is also not a substitute for what arrives fifteen months later.
§ 03What you do not have to finish by 11 September 2026
This is the part the loudest consultancy decks tend to compress, because compressing it sells more services. The honest answer is that none of the substantive construction obligations bind on this date. They bind on 11 December 2027.
| What | When it actually binds |
|---|---|
| Full secure-by-design programme satisfying Annex I Part I | 11 Dec 2027 — Art 13 applies |
| Complete risk assessment integrated with technical documentation | 11 Dec 2027 — Art 13(2) |
| Vulnerability handling programme satisfying Annex I Part II in full (not just Article 14’s reporting subset) | 11 Dec 2027 — Art 13(8) read with Annex I Part II |
| SBOM and HBOM generated and maintained as the standard practice | 11 Dec 2027 — via Annex I Part II point 1 |
| Notified body conformity assessment for Important Class II and Critical products | Window opens with Chapter IV from 11 Jun 2026; certificates needed by 11 Dec 2027 |
| EU Declaration of Conformity and CE marking for new products placed on the market | 11 Dec 2027 — Art 28, Art 30 |
| Reporting obligations for products already placed on the market before 11 Dec 2027 | Article 14 binds them too, from 11 Sep 2026 — per Art 69(3) |
The last row is the genuinely awkward one. Article 69(3) means that products you shipped years ago are caught by the reporting obligations from September 2026, even though they were never built to Article 13 standards and never will be. The compliance posture for a 2018-vintage product still in the field on 11 September 2026 is: I will report any actively exploited vulnerability or severe incident through the SRP, but I make no claim that the product was built to CRA construction standards. That is the lawful answer, and a regulator who understands the regime knows that’s the only honest answer for legacy fleet.
§ 04Why the distinction is worth real money
Three reasons why getting the September 2026 / December 2027 distinction wrong is structurally expensive, and why getting it right releases capacity.
Reason one: capacity allocation. If a manufacturer treats 11 September 2026 as the day Article 13 binds, the engineering organisation gets a hard deadline pressing on every architectural decision: SBOM tooling, secure coding training, design reviews, threat modelling, notified body engagement, conformity assessment evidence binders. None of these can be delivered with quality in the runway available. The result is performative compliance — documents written to look right, processes that don’t survive contact with reality, and a notified body audit in 2027 that finds the substance missing. Treating September 2026 as a reporting deadline allows the construction work to be sequenced properly across the fifteen-month runway: SBOM and CI/CD integration in Q4 2026, secure-by-design uplift across H1 2027, notified body engagement in mid-2027, conformity assessment evidence by Q4 2027. The total work is the same; the schedule is realistic.
Reason two: vendor pricing. Consultancies and tool vendors price urgency. A “September 2026 or you cannot ship” framing supports premium pricing for compressed delivery. A “September 2026 reporting, December 2027 construction” framing exposes the runway, and the runway exposes the bargaining range. The same SBOM tool, the same advisory engagement, the same notified body negotiation costs materially less when the buyer knows the deadline is fifteen months further out than the seller is implying.
Reason three: legacy fleet posture. An organisation that conflates the two dates ends up either over-investing in retrofitting old products to construction standards they were never designed to meet, or under-investing in reporting capability for the products that are still in the field. Both are expensive. The right posture is binary: products you place on the market on or after 11 December 2027 are full Article 13 products with all the construction obligations, evidence, and conformity assessment routing; products already in the field before that date are reporting-only under Article 14, and the construction case is closed by support-period expiry, not by retrofit.
§ 05The 2026 calendar that actually matches the obligations
If 11 September 2026 is read correctly as the reporting activation date, the rest of the 2026 calendar falls into place around it.
Q2 2026: stand up the CVE monitoring, CVD intake, bug bounty pipeline. Pick the coordinator CSIRT under Art 14(7). Draft the 24/72/14-day reporting templates. Designate the owner. Tabletop the SRP submission flow once. By the end of June, the reporting machinery should be testable.
Q3 2026: tabletop the reporting flow twice more, once with engineering, once with executive notification included. Verify the user notification mechanism reaches the field installed base. Begin drafting the security advisory templates in CSAF format. By 11 September, the reporting capability is live and tested.
Q4 2026: Article 14 is in force. Reporting machinery runs in production. In parallel, the construction work begins: SBOM integration into CI/CD, secure development lifecycle uplift, supplier due diligence under Art 13(5), early conversations with notified bodies for any Important Class II or Critical product lines.
2027: the substantive year. Annex I conformance evidence assembled. Risk assessments documented. Notified body engagement formalised. Technical documentation written. Conformity assessment routes selected and traversed. All of this paced across the year, not compressed into a quarter.
11 December 2027: CE-marked products with full Article 13 construction evidence ready to be placed on the market. The fifteen-month gap between reporting activation and full construction binding has been used the way the legislator intended.
The factory in Hsinchu shipping its smart gateway on 12 September 2026 has, in this calendar, exactly what it needs. The product is in scope. The reporting machinery is alive. The support period clock is running. And the construction obligations — the heavy ones — will land on the next product placed on the market after 11 December 2027, by which time the CI/CD pipeline produces SBOMs, the secure development lifecycle is in place, the notified body is engaged, and the EU Declaration of Conformity is honest. That product is the real CRA product. The September 2026 product is a reporting-bound legacy product, and saying so is not weakness. It is precision.
The most expensive misreading of the CRA right now is the conflation of those two dates. Reading them as one date produces panic and waste. Reading them as two dates — with fifteen months of work in between, and a clear sequencing of which work belongs where — produces a calm 2026 and an honest 2027.