ConformanceHouse

Guides to the Cyber Resilience Act

What the regulation asks for, in plain language, with the wording quoted so you can check every statement against the text yourself. 23 guides, and more as we work through them.

Getting started

What to do about the CRA, in order Most CRA checklists are a flat list of thirty things. Order matters more than completeness here, because three of those things decide the shape of all the others. The CRA dates, and the standards timeline Two dates bind. A third set of dates — the harmonised standards — is what most people are really asking about, and those dates are delivery deadlines, not the date a standard becomes usable.

Scope and risk

Does the Cyber Resilience Act apply to your product? The three tests that decide scope, and every classification category with the conformity route it leads to. The CRA essential cybersecurity requirements Annex I is two lists doing two different jobs: thirteen properties your product must have, and eight processes you must run. One list is qualified by your risk assessment. The other is not. CRA penalties and enforcement Article 64 sets three fine ceilings, not one. It also switches the largest one off entirely for micro and small manufacturers in one specific situation — which almost nobody writing about this mentions. Do I need a notified body under the CRA? Most products sit in the default category and the manufacturer signs off their own conformity. Two lists decide whether that is you, and they are short. CRA vs NIS2: which one applies to you They overlap in the mind and almost nowhere in the text. The CRA attaches to a product; NIS2 attaches to an organisation in a listed sector. Plenty of businesses get both, and a few get neither. If you import, distribute or rebrand You have your own duties, and they are shorter than a manufacturer's. But two things move you across the line entirely — and one of them is putting your logo on the box. The CRA and the CE marking you already have If you already CE mark a product, the CRA adds to that marking rather than replacing it. Five sectors are carved out, one overlapping regime has already been repealed, and your existing conformity assessment earns you less than you would hope. Substantial modification under the CRA A substantial modification restarts your conformity obligations, and it is the single event that pulls a product placed on the market before December 2027 into the regulation. Security updates do not trigger it. Feature updates often do. The CRA for open-source maintainers and stewards Unmonetised open source is outside the regulation. Monetise it and you are a manufacturer. Sustain somebody else's project and you may be a steward — a third category with three duties and no CE marking.

Reporting

CRA reporting deadlines, and the two clocks people get wrong Two separate report tracks, not one. Six submissions, four deadlines, and the duty to tell your users as well. Which CSIRT do I report to under the CRA? It is not where your company is registered. The rule, the cascade for non-EU manufacturers, and a worksheet. Reporting on ENISA's Single Reporting Platform The platform went live on 11 September 2026 at initial operating capability. There is no API, voluntary reporting is not built yet, and the account you file from has to exist before the 24-hour clock starts.

Documents

The CRA cybersecurity risk assessment Annex I Part I has thirteen lettered requirements. With no harmonised standards to cite yet, this document is the whole of your argument that the product meets them. Choosing your CRA support period The support period is the one number in the whole regulation that you choose yourself. Six other obligations are measured from it, so choosing it casually is expensive in a way that only shows up years later. What the CRA technical file has to contain The eight points of Annex VII in plain language, what evidence each one needs, and the two that trip people up. The CRA's three ten-year retention duties Article 13 sets three separate ten-year duties running on three different clocks. Most manufacturers are tracking none of them. What the CRA actually requires of your SBOM The regulation asks for top-level dependencies, in a format it has not yet specified, and does not require you to publish it. Almost everything sold to solve this exceeds the bar. The EU declaration of conformity under the CRA The shortest document the regulation asks for, and the one that carries the most weight. Annex V is mostly transcription — the risk is in what signing it means. The information you must ship with the product The forgotten fifth document. Nine points of user information, a ten-year commitment to a URL, and an SBOM clause that is conditional rather than mandatory. The CRA vulnerability handling requirements Annex I Part II is eight process obligations with no risk-assessment qualifier and no exceptions. They start when you place the product on the market and run for the whole support period. Writing a CRA coordinated vulnerability disclosure policy Annex I Part II point 5 requires you to put in place and enforce a coordinated vulnerability disclosure policy. It does not say what the policy must contain — which makes the drafting decisions yours, and worth making on purpose.