Checking CRA readiness: the evidence management should ask for

Ask how the implementation of the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) is going, and the answer arrives as a status report: traffic lights, percentages, completed work packages. That helps steer the project. It does not show whether your company can demonstrate that it meets its obligations as a manufacturer. The CRA asks for documentation that belongs to a specific product and a specific version. This article sets out that evidence, where the Regulation lays it down and how to tell whether it would stand up to scrutiny. For an overview of management's role, see the Cyber Resilience Act for management.

Why status reports alone are not enough

A status report describes activities: workshop held, template created, tool introduced. The Regulation attaches its obligations to the individual product with digital elements. On reasoned request, the manufacturer must provide the market surveillance authority with all information and documentation necessary to demonstrate the conformity of the product and its processes with the essential cybersecurity requirements in Annex I (Article 13(22)). A green traffic light is not such documentation.

There are three typical gaps between status and evidence:

• Scope: the report counts the products in the project, not whether all products and variants with digital elements are recorded.
• Effectiveness: "SBOM introduced" may mean a tool was installed. Whether a bill of materials exists for the shipped release, and whether anyone analyses it, is another matter.
• Pressure: "reporting process in place" may mean a document. Whether someone can submit an early warning within 24 hours at the weekend only an exercise shows.

Part of the obligations already applies. The Article 14 reporting obligation has applied since 11 September 2026; the other manufacturer obligations apply from 11 December 2027 (Article 71(2)). The reporting obligation also covers products placed on the market before 11 December 2027 (Article 69(3)). For non-compliance with Annex I and infringements of Articles 13 and 14, Article 64(2) provides for administrative fines on the economic operator of up to EUR 15 million or, if the offender is an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher; incorrect, incomplete or misleading information in reply to a request from a market surveillance authority or notified body carries separate fines under Article 64(4). The German implementing act, which is to govern competence and the fining procedure, exists as a government draft (Bundestag printed paper 21/6134) and, as of the date of this article, has been neither adopted nor promulgated. Personal liability of management is a separate question; see CRA liability for management.

What evidence the CRA requires from the manufacturer

The Regulation does not contain a ready-made list of evidence. The manufacturer obligations do, however, give rise to ten documents and capabilities that your company should be able to produce for every product in scope:

1. Cybersecurity risk assessment (Article 13(2) to (4)): documented, updated as appropriate during the support period, stating whether and how the requirements in Part I, point (2), of Annex I are applied; part of the technical documentation. See risk assessment and threat modelling.
2. Technical documentation (Article 31, Annex VII): among other things product description, architecture, vulnerability handling processes, risk assessment and test reports. Drawn up before placing on the market, kept up to date at least during the support period (Article 31(2)). See technical documentation under Annex VII.
3. Software bill of materials (SBOM, Annex I, Part II, point (1)): a list of software components in a commonly used, machine-readable format, covering at least the top-level dependencies. See SBOM requirements under the CRA.
4. Coordinated vulnerability disclosure policy (Annex I, Part II, points (5) and (6); Article 13(8)): how reports from outside are received, handled and published, with a contact address. A template is available in the CVD policy generator.
5. Support period (Article 13(8)): at least five years, shorter only where the expected use time is shorter; reasons in the technical documentation, end date with month and year clear at purchase (Article 13(19)). See support period and update duty.
6. Reporting process (Article 14): early warning of actively exploited vulnerabilities and severe incidents without undue delay and within 24 hours of becoming aware, via the single reporting platform to the CSIRT designated as coordinator and to ENISA. See reporting process and PSIRT.
7. EU declaration of conformity (Article 28, Annex V): by drawing it up, the manufacturer assumes responsibility for conformity (Article 28(4)). It presupposes the conformity assessment (Article 13(12)).
8. Information and instructions to the user (Annex II, Article 13(18)): including the contact point for vulnerabilities, the end date of the support period and instructions for security updates.
9. Information to market surveillance (Article 13(22)): being able to provide all necessary documentation on reasoned request in a language easily understood by the authority.
10. Retention (Article 13(13)): technical documentation and EU declaration of conformity kept for at least ten years after placing on the market or for the support period, whichever is longer.

How to recognise reliable evidence

For each piece of evidence, the table shows what reliable evidence looks like and which answers should give you pause. It does not replace a specialist review, but it gives you the right questions to ask.

The chain of evidence: from product to EU declaration of conformity

The pieces of evidence build on one another. It starts with the product register: which products and variants fall under the CRA, in which role your company acts and which product class applies. These are legal questions for your legal department or counsel. Next comes the risk assessment, which determines which Annex I requirements apply. Implementation, tests, SBOM and vulnerability handling show that they are met. All of this feeds into the technical documentation, followed by the conformity assessment under Article 32 and only then the EU declaration of conformity (Article 13(12)). More in conformity assessment and CE marking.

For management this means: a declaration of conformity is only as reliable as the weakest link before it. Without a risk assessment, tests and documentation lack a point of reference. Three ongoing duties run alongside: Article 14 reporting, providing information to market surveillance, and retention.

How to check the evidence: samples and traceability

You need not read every document. Three techniques from internal audit give you a view of your own.

Sample a release that has been shipped

Choose one product and one release that has already shipped. Ask to see, for exactly that release, the risk assessment, the SBOM, the test reports and the corresponding version of the technical documentation. A programme with reliable evidence can present them as a coherent set. If they have to be searched for, recreated or are promised "for the next version", you have a finding.

Trace back to code and release

Check both ways. Top down: a requirement from the risk assessment, such as protection from unauthorised access (Annex I, Part I, point (2)(d)), should lead to an implementation in code or configuration and to a test. Bottom up: a component listed in the SBOM should appear in the build configuration of that release, and a known vulnerability in that component should have a rated ticket.

Have reporting capability demonstrated in an exercise

Use an announced exercise without a real notification: a fictitious report of an actively exploited vulnerability, outside core hours. Record when the responsible person was reached, who decided and whether the information for an early warning was available.

Record who checked what and when, so you can later show how you reviewed the status.

Gap analysis or CRA readiness audit

If your programme is just starting, the question is: what do we need to implement? The CRA gap analysis records your products, gives a technical assessment of scope, role and product class, measures the distance to the requirements and ends with a gap report per product and a prioritised action plan. Legal decisions rest with your legal department or counsel.

If the programme is already running, in-house or with a service provider, the question is: is the reported status evidenced? That is what the CRA readiness audit is for. Blackfort Technology reviews up to five areas, agreed with you in advance, independently of the project lead: scope and product register, risk assessment and Annex I, vulnerabilities and SBOM, Article 14 reporting capability, and documentation and governance. The review is based on samples from code, processes and documents. Management receives a report with a rating per product, findings with evidence and recommendations by urgency. More in CRA audit: process, scope and cost drivers.

Limits: the audit is neither a conformity assessment under Article 32 nor a certificate or attestation. Based on samples, it does not establish that all requirements are met. Blackfort Technology is not a notified body and does not provide legal services. If we have contributed to the CRA programme in your company, we disclose this before the engagement; you decide whether we carry out the review. Parts we implemented ourselves are marked in the report as not independently assessed. Penetration testing is not part of our offering.

Questions for your team

Ask these at the next status meeting. A good answer shows a document, a ticket or a record.

1. Which products and variants fall under the CRA in our view, and where is that reasoning documented?
2. For which products is there a risk assessment, and when was it last updated for a release?
3. Can you show me the SBOM of the most recently shipped release and the open vulnerabilities in it?
4. Who submits an Article 14 early warning on a Saturday evening, who deputises, and when did we last practise it?
5. Where is our coordinated vulnerability disclosure policy published, and what has happened to the reports received so far?
6. What support period have we set per product, on what grounds, and is it budgeted?
7. Which points of Annex VII are still missing from the technical documentation, and when will they be closed?
8. Which legal questions have gone to legal or counsel, and what has been decided?

Tracking progress: milestones with evidence

Percentages say little about what will exist. Agree milestones that each end in a checkable result:

1. Product register complete, role and product class documented, legal questions resolved.
2. Article 14 reporting process staffed with deputies and practised. This obligation has applied since 11 September 2026.
3. Risk assessment documented per product and linked to the technical documentation.
4. SBOM generated for every release, known vulnerabilities analysed with clear ownership.
5. Coordinated vulnerability disclosure policy published, contact address working.
6. Support period determined per product and reflected in user information and budget.
7. Technical documentation under Annex VII complete for the products placed on the market from 11 December 2027.
8. Conformity assessment under Article 32 carried out, EU declaration of conformity drawn up, retention storage set up.

For each milestone, ask for the evidence and take a sample. Products placed on the market before 11 December 2027 are subject to the requirements only if substantially modified after that date (Article 69(2)); the reporting obligation applies to them regardless (Article 69(3)). According to the Commission's guidance (Blue Guide, section 2.3), what counts is the individual unit: units of an older product model placed on the market from 11 December 2027 must meet the requirements. Whether a modification is substantial and how this applies to your products depends on the individual case and is a question for your legal department or counsel.

Note: this article is general information as of 9 October 2026 and does not constitute legal advice. For an assessment of your individual case, please consult your legal department or a law firm.