CRA in fifteen months: what to do first
Article 14 starts in September 2026 and the essential requirements in December 2027. The first quarter is three decisions, not a compliance programme.
Regulation and audit5 Sept 20265 min read
On this page
What it says
The Cyber Resilience Act is being read as one deadline. It is two. The Regulation applies from 11 December 2027. Chapter IV has applied since 11 June 2026, and Article 14 applies from 11 September 2026 1. Fifteen months separate the date that changes how products are built from the date that changes what a regulator must be told.
The transitional rule is what makes the near date bite. Products placed on the market before 11 December 2027 take the substantive requirements only if substantially modified. Article 69(3) then applies the Article 14 duties to all of them 2. A fleet shipped three years ago sits outside the essential requirements and inside the reporting duty. That asymmetry is the shape of the next quarter.
Article 14 itself is short and specific. An early warning goes out within 24 hours of the manufacturer's awareness, and a fuller notification within 72 hours. The final report on a vulnerability falls due within 14 days of a corrective or mitigating measure becoming available. For a severe incident it falls due one month after the 72-hour notification 3.
Both tracks end at the same address. The notification goes at the same time to ENISA and to the CSIRT designated as coordinator, through the single reporting platform 4.
The Commission published its first application guidance on 27 July 2026, a communication numbered C(2026) 5252 with an annex, and it is non-binding 5. Non-binding is not the same as optional. Where a manufacturer and an authority disagree about scope, that annex is the authority's starting text.
ENISA states that its single reporting platform will be used by CSIRTs and manufacturers from 11 September 2026 6. An account nobody has signed into is not a reporting capability.
What we take from it
The reflex is to open a CRA compliance programme. For the first quarter that is the wrong shape. Fifteen months is enough to change how a product is built; the weeks before Article 14 applies are not. So the opening move is three decisions, and governance, risk and compliance each own one.
Which products the duty reaches. Governance owns this, because it fixes what the organisation is answerable for. The list is not the sales catalogue. It is every product with digital elements still on the market, including versions nobody develops any more. Write it down, date it, name its owner.
Who can notify inside 24 hours today. Risk owns this, because it is the exposure with no fallback. The clock runs from awareness, so the first artefact is a written definition of awareness and a role that timestamps it. The second is an end-point somebody has tested rather than bookmarked. Neither needs a budget line.
Which class each product sits in. Compliance owns this, because class decides the conformity route and the route decides the lead time. A product whose core functionality matches an Annex III category takes the Article 32(2) and (3) procedures 7. Where that route ends at a third-party assessment, the assessor's calendar sets the date, not the engineering plan.
October is three artefacts, not a programme. A scope list with the article beside each entry. A definition of awareness with a named role and a tested end-point. A class decision per product, with its route. All three can be finished by people who already hold the job.
What can wait is the substantive build. Designing and producing to Part I of Annex I is the December 2027 obligation 8. That is product engineering on a fifteen-month clock, and a quarter spent on it buys nothing the reporting duty asks for.
The three decisions meet in one artefact. The cybersecurity risk assessment is documented, kept current through the support period, and states whether and how the Part I point (2) requirements apply 9. Governance decided which products the organisation answers for, risk holds that assessment, and compliance later shows an authority that the route matched the class. One loop, three owners, not three programmes.
Where we would push back
The most common objection is that the organisation already holds ISO 27001. That certificate is worth having, and it answers none of the three decisions. A management-system certificate says an organisation runs an ISMS; it says nothing about which products are on the market, which class they sit in, or where a notification is filed. Its incident process reports on the organisation's own criteria, to its own authorities. It does not put an actively exploited vulnerability in a shipped product in front of a CSIRT coordinator and ENISA inside 24 hours.
What the certificate does buy is the habit: a defined event, a named owner, a dated record. Bring the habit into the product organisation; do not bring the assumption that the existing scope already covers it.
Two weaknesses in our argument are worth stating. The first is that a scope list built in three weeks will be wrong at its edges. The guidance spends its space on scope, including remote data processing and free and open-source software, on substantial modification and on support periods. It also covers the reporting and risk-assessment duties 5. Those are exactly the boundaries honest readers disagree about, and a list that is dated and owned still beats no list.
The second is that the 24-hour clock is cheap to draw and expensive to staff. It runs at night and at weekends, and no policy document makes somebody answer the phone. An organisation that cannot name the person on call this weekend has not made the second decision, whatever its process map says.
A board does not need the article numbers. One sentence tests the whole thing: if a vulnerability in a product the company shipped three years ago turned out this afternoon to be actively exploited, who files the early warning, and by when?
Related on GRCIDE
- CRA obligations by product class, the scope test and the obligations article by article.
- Cyber Resilience Act: manufacturer reporting starts on 11 September 2026, the dates and the transitional rule.
- Cyber Resilience Act: the Commission's application guidance, 27 July 2026, what the guidance covers.
Sources
- 1EUR-Lex, Regulation (EU) 2024/2847 Article 71 · verified 2026-09-03
- 2EUR-Lex, Regulation (EU) 2024/2847 Article 69 · verified 2026-09-03
- 3EUR-Lex, Regulation (EU) 2024/2847 Article 14(2) and 14(4) · verified 2026-09-03
- 4EU Publications Office CELEX 32024R2847 Art. 14(1), 14(7) and Art. 16(1) · verified 2026-09-04
- 5European Commission, C(2026) 5252 and its annex, digital-strategy.ec.europa.eu · verified 2026-09-05
- 6ENISA, single reporting platform pages, enisa.europa.eu · verified 2026-09-05
- 7EU Publications Office CELEX 32024R2847 Art. 7(1) and Art. 32(1) · verified 2026-09-04
- 8EU Publications Office CELEX 32024R2847 Art. 13(1) and Annex I Part I · verified 2026-09-04
- 9EU Publications Office CELEX 32024R2847 Art. 13(2) to 13(4) · verified 2026-09-04