The Cyber Resilience Act, and the evidence Assert gives you

The CRA’s reporting duty began on 11 September 2026 and its essential requirements apply from 11 December 2027. About half of Annex I is a property of your code and your build, and Assert collects the evidence for that half at every survey. The rest is a property of your organisation, and Assert lists it for the people who declare it. This guide shows which is which, and how to have both ready before December 2027.

Who this is for: engineering, product and compliance leads at manufacturers of products with digital elements, meaning connected products, embedded software, and software distributed to run on somebody else's machine. It sets out what the CRA asks for, what Assert gives you evidence for at every survey, and what your named people declare.

1. What the CRA is, and the dates that bind

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.

Date	What starts
11 June 2026	Provisions for conformity-assessment bodies, meaning the notified-body machinery.
11 September 2026	Reporting obligations under Article 14: a 24-hour early warning to ENISA and the national CSIRT on an actively exploited vulnerability or a severe incident, a 72-hour follow-up, and a final report within 14 days.
11 December 2027	The essential requirements of Annex I, the technical documentation, conformity assessment and CE marking, which is the rest of the regulation.

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

2. Whether your product is in scope

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, such as medical devices, motor vehicles, civil aviation and 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.

3. What the regulation actually asks for

Annex I Part I sets the essential cybersecurity requirements, which are 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.

4. Which half the code itself gives evidence for

Roughly half of Annex I is a property of the code and the build, and Assert reads it at every survey. 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. Assert lists those for the named people who declare them, so both halves end up in one report.

Obligation	Who provides it	What produces the evidence
Components identified and documented (SBOM)	Assert	A CycloneDX SBOM in every result bundle
No known exploitable vulnerabilities at release	Assert	Dependency Vulnerabilities (D30), across every ecosystem the repository declares
Remediate vulnerabilities without delay	Assert, survey after survey	D30 across successive surveys, plus the daily security watch between them
Apply regular security tests and reviews	Assert	Static application security testing (D29) and dependency hygiene (D12)
No credentials in the product or its history	Assert	Native secret scanning (D13) and the full-history scan (D28)
Secure configuration shipped with the product	Assert	Infrastructure-as-code and container analysis (D31) of the committed configuration and, when Assert can start a copy of the product, a record of how its containers actually run
Build provenance and artifact signing	Assert	Provenance and signing (D36)
A coordinated vulnerability-disclosure policy exists	Assert	Vulnerability-disclosure policy (D37) reads the committed policy
Secure-by-default configuration; secure by design	Your named person	A named attestation
Exploitation-mitigation mechanisms	Your named person	A named attestation
Secure distribution of security updates	Your named person	A named attestation
Publishing information about fixed vulnerabilities	Your named person	A named attestation
Conformity assessment, technical file, CE marking, Article 14 reporting	Your named person	Assert’s signed report and the methodology and SBOM sections it drafts; for Article 14, libraries on CISA’s list of exploited vulnerabilities are flagged

A clean survey closes the code half of the table, and Assert’s report carries it to your auditor. The organisation half stays with your named people, which is where the regulation puts it.

5. What Assert gives you

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 themselves. On top of it sits the CRA report for your product:

Every Annex I control, Part I and Part II, one per requirement in the Official Journal’s own numbering, marked as checked by Assert, backed by Assert’s evidence or declared by a person.
Declarations with a named person, a verdict, evidence notes and a renewal after twelve months, so a lapsed declaration shows as open until it is renewed.
The context a technical file needs: scope, assessment methodology, vulnerability handling, SBOM and provenance, with the methodology and SBOM sections drafted by Assert from your surveys.
A control Assert checks counts as met only when every check behind it comes back clean on the latest surveys of all the product’s repositories, and nobody can tick it off by hand.
For Article 14, Assert flags any library in your product that is on CISA’s list of vulnerabilities attackers are known to be using.
A named person signs the report, and Assert seals it, in English and Danish.

6. Where to find it

The CRA assesses a product, and a product with digital elements is usually built from several repositories. So you open the CRA on the product’s compliance report, alongside NIS2, DORA, ISO 27001, the technical measures of GDPR and OWASP DSOMM, which are scoped the same way. A repository’s compliance tab names them and links through to the product that assesses them.

The standards that can be declared on a single repository, namely WCAG 2.2, EN 301 549, OWASP ASVS, OWASP SCVS, SSDF and SLSA, stay on the repository tab, where a signed self-declaration covers that repository on its own.

7. How Assert fits your conformity work

Assert supplies the evidence for your conformity assessment, your technical file and your Article 14 reports, and anyone you hand it to can check it. You, or a notified body where your product’s class requires one, carry out the assessment, and you affix the CE mark and file the reports.

Assert reads the languages your cloud services, apps and backends are written in. Device firmware written in C or C++ is outside what it reads today, so name that part when you set the scope.

Assert reads the configuration you commit, and when it can start a copy of your product in its own sandbox, it also records how the product actually runs.

8. What to do before December 2027

Start with a free survey. Connect the repositories behind the product. The first survey of every repository is free, with nothing held back, and the CRA report shows at once which controls are already clean.
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.
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.
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.
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.
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.

Learn more and verify

Published dimensions and scoring: codeassuranceindex.info/dimensions - the code, lens and evaluator behind every dimension named on this page
What a survey measures on the security side: Security is not a CVE list - the companion guide to the left-hand column above
Real survey reports, without an account: assert.canine.dev/publicreports
Verify a delivery you were handed: codeassuranceindex.info/verify

On the dimension codes. D12, D13, D28, D29, D30, D31, D36 and D37 are published dimensions of the Code 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 guide explains the CRA and the evidence Assert gives you for it. 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.