CRA governance: a file that has to survive being questioned
The checklist is done. The conformity assessment is signed, the CE marking affixed, and the product is on the market. Then, eighteen months later, on some unremarkable Tuesday, a market-surveillance authority asks to see the file. That question is the examination the checklist never sat.
The Cyber Resilience Act is written as a set of requirements. It operates as an evidentiary system: a claim you sign, and then defend for years, long after everyone who assembled the file has moved on to other products.
Conformity is a claim you have to be able to defend
A conformity assessment, in the CRA's own terms, is the process of verifying that the essential requirements in Annex I have been met: the product properties in Part I, and the vulnerability-handling processes in Part II. For most products, that assessment is a self-declaration, the internal control procedure in Module A under Article 32 and Annex VIII, where the manufacturer declares conformity on its sole responsibility. No third party reviews the work. No external audit signs off the file. Nobody looks at it at all, in fact, until somebody with a mandate does.
Self-declaration reads as the light option, and the wording invites that: you declare, you affix, you ship. The phrase doing the work is "sole responsibility". The whole weight of proof sits with you. The EU declaration of conformity, structured in Annex V, and the CE marking under Article 30 are assertions. What stands behind them is the technical documentation described in Annex VII and referred to in Article 31, which you keep at the disposal of the authorities for ten years after the product is placed on the market, or for the support period, whichever runs longer. Ten years outlasts most of the teams that will have written it.
The route changes as product risk climbs. The important products in Annex III split into two classes. Class I can use Module A where harmonised standards apply, or where a notified body has been involved in quality assurance. Class II cannot: it needs EU type-examination (Module B+C), or a notified body's full quality assurance (Module H). Critical products under Annex IV shut the self-declaration path altogether. A notified body, here, means a third-party conformity assessment body accredited by a Member State.
The distinct routes to conformity under the CRA.
So the heavy path is also the narrow one. Self-declaration carries more weight of proof than its name advertises, and for a good slice of the product scope, it is not on offer anyway. That second half has landed with fewer manufacturers than you would expect.
A notified body, in this context, is a third-party conformity assessment body accredited by a Member State. The practical consequence is that the self-declaration path — already the heavier burden it appears to be — is closed for a significant share of the product scope, and many manufacturers have not yet acknowledged this.
The file keeps moving after the product ships
Annex VII sets out what the folder holds: the cybersecurity risk assessment from Article 13(2), the reasoning behind the support period set under Article 13(8), the test reports, and the list of harmonised standards applied, or, where none were applied, a description of the solutions adopted instead. Assembling that once and archiving it is the intuitive reading, and it is wrong.
The obligations that turn the folder into a standing duty are scattered, which is why they are easy to miss. Products in series production must remain in conformity over time under Article 13(14). Where you come to know, or have reason to believe, that a product or process is no longer conformant, Article 13(21) requires immediate corrective measures, and requires them across the whole support period.
Changes in product design and changes in the harmonised standards to which conformity was declared both have to be taken into account. A file that accurately described the product at launch and was never updated will fail the question, precisely because it was accurate once.
What "compliant" means is not finished being written
Under Article 27, conformity is presumed when you apply harmonised standards whose references are published in the Official Journal. As of July 2026, no such reference has been published. The standards are still in development. The earliest deliveries, Type A principles and Type B vulnerability handling are expected in August 2026. The standard covering generic product-security requirements, the one most manufacturers need for Annex I, Part I, has a delivery deadline of October 2027, six weeks before full application on 11 December 2027. Citation in the Official Journal follows delivery, on a timeline the Commission has not confirmed. Six weeks, minus an unknown.
For most manufacturers, then, building a file with no published standard to point to is the baseline condition for the next 12 to 15 months. It is worth sitting with that, because it files neatly under transitional inconvenience, and it is nothing of the kind.
Annex VII documents a second path for exactly this case: describe your own solutions to each essential requirement where no standard was applied. It works. It also costs more in evidence, because arguing conformity from first principles asks a great deal more of you than pointing at a recognised benchmark and saying we did that. Building a file against a definition that is still being drafted is where this stops being paperwork and starts being governance.
You are vouching for code you did not write and hardware you did not design
The declaration you sign covers the whole product, including the parts you did not author. Annex I, Part II requires that you identify and document components and vulnerabilities throughout the support period, and you cannot evidence that obligation for components you cannot name. For software, the regulation names a software bill of materials as one means of doing this, in a commonly used machine-readable format, with top-level dependencies as the stated floor. There is no obligation to publish it, deliver it to users, or make it exhaustive by default. What is prescribed is the result: you know what is in your product, and you can show that you have been watching it.
The software side is well covered by guidance, tooling, and existing standards. The hardware side is almost entirely absent from the compliance conversation, and that is where files actually break.
A product with digital elements is rarely just software. It contains processors, radio modules, bootloaders, secure elements, storage controllers, and platform management chips. The obligation to document components and track them for vulnerabilities runs throughout it. There is no standardised tooling for hardware component inventory, nothing that plays the part Syft or Trivy play for software packages. BSI TR-03183, the most detailed implementation reference currently available for CRA compliance, is organised into three parts: general requirements, software bills of materials, and vulnerability reports. None of them defines a structure for hardware component documentation. The most thorough guidance in the field has a hardware-shaped hole in it.
Firmware is where hardware risk accumulates, and it accumulates below the line that software scanners see. The firmware running inside a Wi-Fi module, a bootloader, a baseboard management controller, or a storage controller is a software component of your product with digital elements under the CRA. It has its own version, its own vulnerability surface, its own maintainer, and its own advisory source. It belongs in your component inventory. CycloneDX has supported the type: firmware since version 1.2 and the type: device since version 1.0, and a single CycloneDX 1.6 document can carry both hardware and firmware entries with explicit dependency relationships between them. The capability has been sitting there for years. Almost nobody uses it for compliance.
Some firmware cannot be updated in the field at all: boot ROMs, vendor-locked radio modules, secure elements under certification constraints. The component stays in the file regardless. What changes is what the file carries: the update status, the reason it cannot be patched, the compensating controls, and the response route if an exploitable vulnerability turns up. Whether a component's firmware is immutable, and whether it runs out of support before the product's declared support period does, are questions with a natural moment for asking them, which is before the product goes on the market. They also have an unnatural one.
The CRA lets manufacturers account for the support periods of core third-party components when setting the product support period. The technical documentation then has to carry the information used to make that determination, which quietly promotes your suppliers' end-of-support dates into the conformity file, out of the procurement spreadsheet where they usually live.
The open-source software steward introduced under Article 24 is a distinct and deliberately lighter category. A steward cannot affix CE marking. When a manufacturer integrates an open-source component, the manufacturer assumes full conformity obligations for that component, including evidence that it meets Annex I requirements. The steward's obligations run alongside the manufacturer's; they relieve the manufacturer of nothing.
The processes are part of the file
Product properties are only half of Annex I. The other half is the processes, and the file has to connect to them: the coordinated vulnerability disclosure policy required under Annex I, Part II, point (5), the reporting duty under Article 14, and the obligation to keep security updates available across the support period, for a minimum of ten years under Article 13(9). A technical file can document a secure product beautifully and still describe only a snapshot, when what the regulation asks for is a manufacturer that keeps running.
Point (5) is the one that catches people, because a disclosure policy is both a clause in the file and a standing capability, and only one of those can be written in an afternoon. What the capability involves is in the box below. What the CRA bolts onto it is a clock.
[insérer ici les reporting timelines vulns + incidents d'après le CRA] CRA reporting timelines
When a manufacturer becomes aware of an actively exploited vulnerability in a product on the EU market, the clock starts immediately — including for products already on the market before 11 September 2026, which Article 69(3) brings into scope.
Article 14(8) runs parallel to authority notification: it requires notifying affected users of an actively exploited vulnerability, and of any corrective or mitigating measures available to them, within the same window.
The ENISA SRP was not operational as of 29 June 2026, 73 days before the 11 September 2026 enforcement date, as ENISA confirmed directly. The registration and credential setup for a 24-hour report cannot be completed on a platform that does not yet support them, and the first incident will not wait for the platform to be ready.
Why the file comes apart when it is kept on the side
Read cover to cover rather than article by article, the CRA is an evidentiary system built to withstand adversarial questioning years after a product shipped. It reaches into product design, quality process, legal standing and security operations at once, it has to be maintained without a break across the whole lifecycle through to decommissioning, and it points at a definition of "compliant" that is still being written while you comply with it.
Everything above is the terrain, and the terrain is readable. Where a prepared effort tends to run out of road is further in: which conformity class a product actually falls in, the weight of proof that self-declaration quietly transfers to you, how to document a deviation when no standard yet exists, how to evidence a hardware component you did not design, and what to do with firmware nobody can patch.
A file gets tested in exactly one place, and it is not a meeting room. Everything that goes into it is decided long beforehand, by people who will mostly have moved on by the time it is opened. You are writing for a reader you will never meet, whose questions you cannot see, on a date you do not choose. The files that hold tend to have been built by someone who has already watched one be taken apart.
Sources. Regulation (EU) 2024/2847 (Cyber Resilience Act): Articles 13, 14, 24, 27, 28, 30, 31, 32, 69, and Annexes I, V, VII, VIII. European Commission, "Cyber Resilience Act — summary of the legislative text" (digital-strategy.ec.europa.eu). BSI TR-03183-2 v2.1.0 (SBOM requirements), BSI TR-03183-3 v1.0.0 (Vulnerability Reports and Notifications). CEN/CENELEC standardisation timeline: CRA harmonised standards tracker (craevidence.com). Verified July 2026.
The map is free. Building a file that holds when an authority asks to see it is the work.
How RS Strategy runs CRA compliance