CounterProof

The standards may slip. The reporting date does not.

A draft amendment would push the CRA's vulnerability-handling standards later. Article 14 is unmoved — which leaves manufacturers documenting a duty whose yardstick is still being drafted.

There is a gap opening in the Cyber Resilience Act, and it is worth being precise about, because precision here is the difference between planning and hoping.

What is fixed

Two dates in Regulation (EU) 2024/2847 are set by Article 71 and are not affected by anything happening in standardisation:

  • 11 September 2026 — Article 14 notification of actively exploited vulnerabilities and severe incidents, to the coordinating CSIRT and ENISA.
  • 11 December 2027 — the Regulation applies in full. Annex I binds, including Part II(3): “apply effective and regular tests and reviews of the security of the product with digital elements.”

What is moving

The harmonised standards under the Commission’s standardisation request M/606 (C(2025)618) are the instruments that will say what “effective and regular” actually requires. A draft amendment circulated in July 2026 would move the vulnerability-management deliverables later than originally requested.

We are deliberately not printing a successor date. As at the date of this note we have not seen an adopted amending decision published in the Official Journal, and the Commission’s own standardisation page still points at C(2025)618. A proposal is not a schedule, and stating one as though it were is the kind of small error that costs a reader’s confidence in everything around it.

The part that does not depend on the date

Even once a standard is delivered, delivery is not the operative moment. Under Article 27(1) a harmonised standard confers presumption of conformity only when its reference is published in the Official Journal — which is later than any delivery deadline, by an interval nobody controls.

So the shape of the problem is stable regardless of which dates land where:

Manufacturers will be documenting compliance with a testing duty for some period before the standard defining that duty is citable.

Records built in that interval cannot lean on conformity to a published standard, because there is not one to conform to yet. They have to stand on their own merits — traceable to a revision, honest about what was and was not examined, and legible to someone who was not in the room.

What we would actually do about it

Nothing dramatic. Three things, in order of how cheap they are:

  1. Know your classification. The conformity route is not a matter of company size or prevalence — it follows from Annex III / Annex IV classification, and the answer changes what you owe. Annex III products qualifying as free and open-source software have their own route under Article 32(5) if the technical documentation is public; that carve-out does not reach Annex IV.
  2. Start the technical file now, not in 2027. Annex VII(6) asks for “reports of the tests carried out to verify the conformity of the product … and of the vulnerability handling processes.” Those are produced release by release, or they are reconstructed under deadline from memory. The first is evidence; the second is a story.
  3. Keep the retention rule straight. It is Article 13(13) — technical documentation and the EU declaration of conformity kept for at least ten years after placing on the market, or the support period, whichever is longer. For infrastructure with long support commitments, the second limb is usually the operative one, and it is the one people drop.

Corrections

If any date or citation in this note is wrong, we would rather hear it than be right in public. Write to us and we will correct it here, with the correction visible rather than the original quietly edited.

Provisions checked against Regulation (EU) 2024/2847. Standardisation timelines move; confirm the current M/606 schedule before relying on it. Nothing here is legal advice.

← All notes