# 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.

Source: https://counterproof.io/notes/the-standards-slipped-the-deadline-did-not/ · Published 14 August 2026 · CounterProof is a practice of Clavestra Capital Limited (Malta, C 113987).


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. See [*Crypto wallets and the Cyber Resilience Act: what the 24-hour rule assumes*](https://counterproof.io/cyber-resilience-act-crypto-wallets/).
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. See [CRA test report](https://counterproof.io/glossary/#cra-test-report).
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. See [*Vulnerability management under the Cyber Resilience Act: where adversarial review sits*](https://counterproof.io/vulnerability-management/).

## 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.*