Core claim: The Cyber Resilience Act requires manufacturers of products with digital elements to maintain technical documentation of a secure development process — and the difference between documentation that survives scrutiny and documentation that collapses under it is not length or polish, but whether it is evidence generated by the process or prose written about the process afterwards.

What the CRA actually asks for

Regulation (EU) 2024/2847 — the Cyber Resilience Act — attaches essential cybersecurity requirements to nearly every product with digital elements placed on the EU market, from consumer devices to B2B software. Its obligations arrive in two waves: reporting duties for actively exploited vulnerabilities and severe incidents apply from 11 September 2026, and the full regulation applies from 11 December 2027.

Behind the headline requirements sits a documentation obligation that engineering teams will feel more than legal teams. The manufacturer must draw up and maintain technical documentation covering, among other things: a description of the product’s design, development and production and its vulnerability-handling processes; an assessment of the cybersecurity risks; and the information needed to demonstrate the product meets the essential requirements — including a software bill of materials for the product’s components. The documentation is not a one-off artifact for a certification binder: it must be kept current across the product’s support period, and market surveillance authorities can ask for it.

The phrase to sit with is “description of the development process.” The regulation does not ask whether your process was good in the abstract. It asks you to describe the process you actually ran — and a description is only worth what you can show underneath it.

Evidence is generated, documents are written

Every team that has been through a serious audit knows the two piles. Pile one: the process documents — the secure development policy, the review checklist, the testing strategy. Written by people, about the process, usually shortly before the audit. Pile two: the traces the process actually left — commits, review records, test runs, release artifacts, vulnerability tickets. Pile one asserts; pile two shows.

What distinguishes secure development evidence from secure development prose is a short list of properties:

  • Contemporaneous. Recorded when the work happened, not reconstructed for the occasion. A review logged at merge time is evidence; a spreadsheet of reviews compiled in the audit week is a memoir.
  • Attributable. Each event names its actor — human or machine. In codebases with meaningful AI authorship this is where most records quietly fail: the process description says “all changes are reviewed,” and the record cannot say by whom, or of what.
  • Append-only and tamper-evident. Documentation you can silently edit is documentation an authority can reasonably discount. A record whose integrity a third party can check — hash-chained, externally timestamped — does not depend on the reader trusting you.
  • Tied to releases. The CRA’s unit of obligation is the product you placed on the market. Evidence that cannot say “this is what release X contained, and this is how it was built and tested” is ambient history, not technical documentation.
  • Complete on components. The SBOM requirement makes third-party provenance part of your documentation surface: what you shipped includes what you included.

None of this requires a heavyweight process. It requires that whatever process you have leaves a verifiable trail as a byproduct — which is a tooling decision, not a maturity level.

The 24-hour clock makes it operational

From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in its product must submit an early warning within 24 hours — and that is only the first step in a fixed rhythm: a fuller vulnerability notification follows within 72 hours, and a final report is due once a corrective or mitigating measure is available (severe incidents run on the same 24/72-hour pattern with their own final report). The 24-hour step is deliberately light — awareness, not analysis — but the clock it starts is not. Anyone who has run an incident knows what that window is actually spent on: figuring out which products and versions contain the affected component, when it entered the codebase, who changed it last and what the fix path is. That is a provenance query. Teams with a contemporaneous, release-tied record answer it from the record; teams without one answer it by archaeology, under the worst possible time pressure, with a regulator waiting.

This is the practical convergence of the EU’s software regimes: the Product Liability Directive reaches development records through disclosure orders in litigation, and the CRA reaches them through documentation duties and reporting clocks. Different instruments, same underlying question — can you show how this was built? — and the same property that decides it: the record either existed before the question arrived, or it does not exist at all.

“Secure development evidence” is not a document you write. It is the trail your development process leaves when it is built to leave one — and September’s reporting clock is the first deadline that will tell teams which kind they have.

This builds on article 1, “Who wrote your code? The provenance gap in AI-built software” — the CRA’s documentation duty is the provenance gap turned into a standing regulatory obligation.

Sources