The Cyber Resilience Act, and what a survey can evidence

Who this is for: engineering, product and compliance leads at manufacturers of products with digital elements — connected products, embedded software, and software distributed to run on somebody else's machine. It sets out what the CRA asks for, which parts of it repository evidence can establish, which parts only a named person can attest, and where Watchdog's scope ends.

The Cyber Resilience Act is Regulation (EU) 2024/2847. It entered into force on 10 December 2024 and applies to products with digital elements placed on the EU market: hardware or software whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network.

Its obligations arrive in stages, which is why one date has already passed and the largest one has not.

Penalties for breaching the essential requirements reach €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Two carve-outs settle most of these conversations before any measurement is worth doing.

• Software delivered purely as a service is largely outside the CRA. The regulation governs products placed on the market. A remote data-processing solution is pulled in only where it is integral to the product's function.
• Free and open-source software supplied outside a commercial activity is outside it. Organisations that support such projects may fall under the lighter open-source software steward regime of Article 24 rather than the manufacturer obligations.

Products already governed by sector-specific rules — medical devices, motor vehicles, civil aviation, marine equipment — are handled under those instruments instead.

If you ship installable software, firmware, or a connected product into the EU, you are in scope, and the product's classification (default, important class I or II, critical) decides which conformity route applies to it.

Annex I Part I sets the essential cybersecurity requirements — properties of the product itself: a secure-by-default configuration, protection from unauthorised access, confidentiality and integrity of data and commands, data minimisation, availability of essential functions, a minimised attack surface, exploitation-mitigation mechanisms, logging of security-relevant activity, and the secure distribution of security updates.

Annex I Part II sets the vulnerability-handling requirements that run for the whole support period: identify and document components in a machine-readable SBOM covering at least the top-level dependencies, address and remediate vulnerabilities without delay, apply regular security tests and reviews, operate a coordinated vulnerability-disclosure policy, publish information about fixed vulnerabilities, and distribute updates securely.

Around those sit Article 13's due-diligence duty, the technical documentation of Annex VII, and the Article 14 reporting duty that is already live.

This is the split that matters, and getting it wrong in either direction is expensive. Roughly half of Annex I is a property of the code and the build, and a survey can read it on every commit. The other half is a property of your organisation — how you ship updates, how you receive a vulnerability report, what you publish when you fix one. No scanner can read those, and a vendor who implies otherwise is selling you a problem.

A clean survey is necessary, not sufficient. It closes the left-hand column and leaves the right-hand one exactly where the regulation puts it: with the manufacturer.

Every survey produces the same bundle regardless of framework: four rendered reports, a findings CSV, SARIF, a CycloneDX SBOM, a changelog draft, a security-watch feed, and an Ed25519-signed, commit-pinned delivery package that the recipient can verify without trusting us. That bundle is where the left-hand column of the table above is read today.

On top of it sits a CRA view, and it is worth being precise about what that is right now:

• It lays out all eighteen Annex I controls, Part I and Part II, each marked as tool-evidenced, assisted or human-judgement, so the split above is visible per control rather than asserted in prose.
• It carries the attestation workflow for the human-judgement half: a named person, a verdict, evidence notes and an expiry date, with lapsed attestations shown as gaps rather than quietly ageing into a pass.
• It records the descriptive context a technical file needs — scope, assessment methodology, vulnerability handling, SBOM and provenance.
• It ships as a preview. The control mapping is published and evolving rather than settled, and the tool-evidenced column of the CRA report is not yet fed from survey results — read those findings in the survey's own Security & Compliance lens for now, and use the CRA view for the control map and the attestations.

We would rather say that than let a coverage bar imply a machine-checked pass that has not happened.

The CRA assesses a product, not a repository — a product with digital elements is usually several repositories, and asking one repository to "be CRA" is a category error. So the CRA view lives on a product's compliance report, alongside NIS2, DORA, ISO 27001 and the technical measures of GDPR, which are scoped the same way. A repository's compliance tab names them and links through to the product that assesses them.

The frameworks that are declarable on a single repository — WCAG 2.2, EN 301 549, OWASP ASVS, SSDF and SLSA — stay on the repository tab, where a signed self-declaration is a meaningful artifact.

Watchdog is not a notified body. It does not perform conformity assessment, does not affix the CE mark, and does not file your Article 14 report. It produces evidence that supports those processes and is checkable by the party you hand it to.

The language boundary matters here more than anywhere else. C, C++, COBOL, ABAP, Simulink and IEC 61131 PLC code are not surveyed. For a connected product that is exactly the awkward case: the cloud, mobile and application layers are inside the boundary and the device firmware often is not. Say so at scoping. A checkable boundary opens more doors than a coverage claim, and on a CRA conversation an overstated one will be found.

Committed configuration is not proven runtime enforcement. A survey can see that a pipeline is configured to sign artifacts or that a manifest restricts egress. It cannot establish from repository evidence that the deployment platform enforces either.

1. Settle scope first. Decide whether each product is in scope at all, and which classification it falls under. A product that is out of scope needs none of the rest.
2. Get an SBOM you did not hand-assemble. Annex I Part II(1) wants it machine-readable and current, which means generated on every build rather than produced for an audit.
3. Close the vulnerability half continuously. The reporting duty is already live; the remediation duty runs for the whole support period. A cadence plus the daily watch is what turns that into something you can show.
4. Name the people who own the attested controls. Update distribution, disclosure practice and exploitation mitigation each need a person, not a tool. Record the attestation before the audit, not during it.
5. Keep the evidence pinned to commits. A signed, commit-pinned record answers "what was true when you placed it on the market" — which is the question the regulation actually asks.

On the dimension codes. D12, D13, D28, D29, D30, D31, D36 and D37 are published dimensions of the Codebase Assurance Index, and each one's evaluator is readable at codeassuranceindex.info/dimensions. The rubric is versioned and a survey freezes the version it was scored under, so a control mapping that cites a dimension can be checked against the catalogue that was live at the time.

Legal note. This page describes what a codebase survey can and cannot evidence. It is not legal advice, and nothing on it determines whether a particular product is in scope of Regulation (EU) 2024/2847 or which conformity-assessment route applies to it. Those are determinations for you and your advisers to make.