What the Cyber Resilience Act asks of manufacturers
Updated 1 November 2026 · This guide explains the law in plain words. It is not legal advice.
If you sell a connected product in the EU under your own name, the Cyber Resilience Act (CRA) treats you as its manufacturer. You have to build it securely, deal with its vulnerabilities for years after the sale, report actively exploited flaws within 24 hours and keep a technical file that proves the rest. Reporting has applied since 11 September 2026; everything else applies from 11 December 2027.
Who counts as a manufacturer
The law calls you a manufacturer if you develop or make a product with digital elements, or have one made for you, and market it under your name or trademark, whether you charge for it or give it away (Article 3(13)). A company that designs a sensor and pays a contract factory to build it is the manufacturer. The factory isn't.
A "product with digital elements" is hardware or software, including its remote data processing (Article 3(1)), that can connect to a device or a network (Article 2(1)). Medical devices, in vitro diagnostics and type-approved vehicles follow their own laws and sit outside the CRA (Article 2(2)).
The duties at a glance
Most of them live in Article 13. Here they are in roughly the order you'll meet them on a project.
| Duty | Where it is | What it means for you |
|---|---|---|
| Assess cybersecurity risks | Article 13(2) to (4) | A written risk assessment, kept up to date, saying which Annex I points apply and how you meet them |
| Build to the security requirements | Article 13(1), Annex I Part I | 14 points, covering secure defaults, updates, encryption, logging and secure deletion |
| Check third-party parts | Article 13(5) | Due diligence on components, open source included |
| Handle vulnerabilities | Article 13(8), Annex I Part II | 8 points, including an SBOM and a disclosure policy |
| Set a support period | Article 13(8) | At least five years, unless the product is expected to be in use for less |
| Keep updates available | Article 13(9) | Each security update stays available for 10 years or the rest of the support period, whichever is longer |
| Report exploited flaws and severe incidents | Article 14 | 24-hour early warning, 72-hour notification, then a final report |
| Write the technical file | Article 31, Annex VII | Ready before you sell, updated during support |
| Pass a conformity assessment | Article 32 | Self-assessment for most products; an outside body for some classes |
| Sign the declaration and add the CE mark | Articles 28 and 30, Annex V | You sign it and you carry the responsibility |
| Give users information | Article 13(18), Annex II | Contact details, support end date, how to install updates |
| Keep records | Article 13(13) | Technical file and declaration for 10 years or the support period, whichever is longer |
Annex I has 22 points in total: Part I(1), Part I(2)(a) to (m), and Part II(1) to (8). If one of them doesn't apply to your product, the technical file has to say why (Article 13(4)).
Security by design
Part I of Annex I is about the product itself. It must reach the market without known exploitable vulnerabilities (Annex I, Part I, (2)(a)), be secure by default with a way to reset it ((2)(b)), and accept security updates, automatic by default with an opt-out ((2)(c)). The other points cover access control, encryption, integrity, collecting only the data you need, staying up under attack, a small attack surface, exploit mitigations, security logging and secure deletion of user data.
You can show some of this from the firmware alone; a scan will tell you whether OpenSSL is current or whether binaries were built with stack protection. Other points, such as whether the device keeps working during a flood of traffic, need tests and design notes that only your team can write.
Vulnerability handling
Part II is about your process, and it runs for the whole support period. You identify and document the components in the product, including a software bill of materials (SBOM), which is a machine-readable list of the parts and versions inside your software, covering at least the top-level dependencies (Annex I, Part II, (1)). You also need a coordinated vulnerability disclosure policy (Part II(5)), a contact address for reports (Part II(6)), secure update delivery (Part II(7)) and security updates that are free and come with advisories (Part II(8)).
Found a flaw in a component you didn't write? You report it to whoever maintains it, open-source projects included (Article 13(6)).
Reporting
Since 11 September 2026 you must report any actively exploited vulnerability in your product, and any severe incident that affects its security, through ENISA's Single Reporting Platform (Article 14). The clock starts when you become aware. This duty also covers products you placed on the market before December 2027 (Article 69(3)), so devices already in customers' homes count.
The reporting guide walks through the 24-hour, 72-hour and final-report steps.
Paperwork and the CE mark
Before you sell, you draw up the technical documentation, carry out the conformity assessment, and only then sign the EU declaration of conformity and put on the CE mark (Article 13(12)). For most products the assessment is internal control, called module A, which you do yourselves. Products listed in Annex III or IV may need an outside body (Article 32).
Signing the declaration means you take responsibility for the product meeting the rules (Article 28(4)). Nobody can sign it on your behalf, and no software tool can either.
What Proofsheet does here
Proofsheet is a web app. You upload one firmware image, phone app or desktop app. In minutes the app lists the parts and versions it can see, matches exact versions against the NVD (the US National Vulnerability Database), marks any CVE that sits on CISA's known exploited list, and maps the evidence to all 22 Annex I points as evidenced, partial or open. No human reviews your file. "No known exploitable vulnerabilities" never goes above partial, because finding nothing isn't proof of nothing.
The Paperwork (€249) adds a generated document pack: an Annex VII technical file index that shows what you still need to add, a support-period record, an Article 14 reporting guide, a declaration checklist and templates for your vulnerability handling and update policies. It's technical evidence, not a legal certificate. You still sign, submit and decide.
See a sample report to see what the app generates. Or read on: CRA deadlines and technical documentation.