What it is

Regulation (EU) 2024/2847 — the Cyber Resilience Act, “CRA” — attaches essential cybersecurity requirements to nearly every product with digital elements placed on the EU market, from consumer devices to B2B software. It is the first horizontal EU instrument to make secure development and ongoing vulnerability handling a condition of market access rather than a best practice.

Its obligations arrive in two waves. Reporting duties for actively exploited vulnerabilities and severe incidents apply from 11 September 2026; the full regulation — essential requirements, conformity assessment, CE marking, market surveillance — 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 of its vulnerability-handling processes; an assessment of the cybersecurity risks; and the information needed to demonstrate that the product meets the essential requirements — including a software bill of materials for the product’s components.

That documentation is not a one-off artefact 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.

Who it applies to and when

The CRA addresses manufacturers first — the party that develops or has developed a product with digital elements and places it on the market under its own name — and, in defined roles, importers and distributors. Open-source software developed or supplied outside a commercial activity is largely outside the regulation, with a lighter regime for open-source stewards; once software is monetised or integrated into a commercial product, the ordinary obligations apply. Which category your product falls into — default, important (class I/II) or critical — determines the conformity route and is a legal and product decision for your counsel.

The dates, again, because they are the ones that turn this from policy into operations:

  • 11 September 2026 — reporting obligations begin: early warning within 24 hours of becoming aware of an actively exploited vulnerability, a fuller notification within 72 hours, and a final report once a corrective or mitigating measure is available. Severe incidents run on the same 24/72-hour rhythm with their own final report.
  • 11 December 2027 — full application of the regulation.

The CRA is the technical-documentation counterpart of the Product Liability Directive: the PLD reaches development records through disclosure orders in litigation from 9 December 2026, 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 decides it: the record either existed before the question arrived, or it does not exist at all.

What it asks of your development process

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 artefacts, vulnerability tickets. Pile one asserts; pile two shows. The CRA’s “description of the development process” is only as strong as pile two.

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

Then the clock makes it operational. From 11 September 2026, anyone who has run an incident knows what the 24-hour 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.

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

What OLOBOLO evidence supports

OLOBOLO records the trail the CRA’s documentation duty asks about — per-change authorship, review and test evidence, sealed releases with the SBOM and license snapshot riding along, time-anchored by an independent RFC 3161 authority. The table mirrors our regulatory mapping v1 for the CRA, line for line.

Requirement What you need to show Chain evidence Support
Annex VII — technical documentation of the secure development process Demonstrate a documented development, review and testing process for products with digital elements Per-change authorship/review/test evidence, release.sealed segments, SBOM + license snapshots, release evidence reports Supports
Annex I Part II — vulnerability handling, incl. remediation and updates Evidence of when a vulnerability fix was authored, reviewed, tested and released The fix’s chain trail: change.authored → change.reviewed → test.evidenced → release.sealed, with RFC 3161 time anchors Partially supports
Conformity assessment and CE marking Formal conformity procedures — Out of scope

The chain is the process record, and the SBOM rides with each release — that is why the first line is “Supports”. The second is “Partially”: the chain evidences the remediation timeline, while the actual reporting to ENISA and the CSIRTs is an operational duty outside it. And, as with every EU regime on this site: evidence in, assessment elsewhere — OLOBOLO performs no conformity assessment.

Evidence, not a legal opinion: this maps what the chain supports as documentation — your counsel decides what compliance requires.

How to start

  1. Record the process you already run. Install the recorder on the repositories behind your products; from that moment every change, review and test run lands in the chain as it happens.
  2. Seal every release with its SBOM. A release.sealed segment ties the release to the changes, reviews and tests behind it; the SBOM and license snapshot generated alongside it are the “complete on components” part of your documentation.
  3. Rehearse the 24-hour question. Pick a past fix and trace it from the record: which releases contained the component, when the fix was authored, reviewed, tested and shipped. If the answer takes minutes, your documentation is evidence; if it takes days, start with step 1.
  4. Hand the mapping to whoever owns your technical file. They decide what the essential requirements demand of your product; the chain supplies the development-process part of the answer.