CRA essentials: what being in scope actually demands
Most teams reach the Cyber Resilience Act through a scoping question: does this apply to us. Once the answer is yes, the harder question arrives, and it is rarely the one anyone budgeted for. Being in scope is a status. What the text asks of the product is a programme of work, and this piece is about the second thing.
The reference throughout is Regulation (EU) 2024/2847. Everything below points back to it; where a line is our reading rather than the text speaking, it says so.
First, which product, and which class
The CRA governs products with digital elements placed on the EU market: hardware and software, and the remote data-processing components they lean on. The net is cast wide on purpose, so the first practical task is not "are we in", it is "in which category".
The text sorts products by what they do, not by what they are. Most of them, including a connected washing machine or a word processor, land in the default category and take the lightest conformity route. Annex III then carves out a tier of important products in two classes. Class I gathers products whose core job is itself a security job: identity and access management, password managers, VPN software, browsers, operating systems, routers, network management systems. Class II is for products where a compromise does more damage: hypervisors, firewalls, intrusion detection and prevention systems, tamper-resistant microprocessors. Above both sits a narrow critical category in Annex IV, its members defined partly by being a dependency for the essential entities NIS2 already regulates: smart meter gateways, smart cards, secure elements, the components other systems treat as a root of trust.
Where your product lands determines how much outside scrutiny its conformity assessment attracts, and that influence extends well beyond the audit itself.
The conformity routes by product category.
One caution before you trust a category label from memory. The Commission has now published the technical descriptions for these categories in Implementing Regulation (EU) 2025/2392, and several of them go further than the name suggests. It is worth reading the description rather than the heading.
Our reading, from client work, is that this step gets underestimated because the default category feels reassuring, right up until a single component or function drags the whole product up a class and the conformity route changes underneath you.
The essential requirements, in two families
Annex I contains the 21 obligations.
Part I is about the product's own security properties: shipping free of known exploitable vulnerabilities, a secure configuration out of the box, protection of data in transit and at rest, a minimised attack surface, cryptography used properly, and a way to be updated. These are properties of the thing you sell, settled by engineering decisions taken before it ever reaches a customer.
Part II is about how you live with vulnerabilities across the product's life: finding and documenting them, fixing them without dragging your feet, pushing out security updates free of charge for the declared support period, and keeping a coordinated disclosure path open so that an outsider who finds a flaw can report it and reach a human. This half is a process, not a feature, and it carries on long after launch.
The split matters because Part I closes before you ship, while Part II is a capability you keep running for years. Costing the first and quietly forgetting the second is the usual mistake.
Sitting alongside both, and easy to treat as an afterthought, is a transparency requirement.
Annex I Part II(1) asks the manufacturer to identify and document the product's components, including third-party and open-source parts, to a level "sufficient for the effective and timely handling of vulnerabilities". Annex VII adds that this inventory must be available to market-surveillance authorities upon request and to customers in a form they can actually use for risk management. Note what the text does not say: it never says "SBOM". The duty is a component inventory, and its depth is determined by what it must carry: the vulnerability-handling process, the risk assessment, and the conformity file. Industry has settled on SBOM formats such as SPDX and CycloneDX because they happen to hold that information well, but the regulatory requirement is the function, not the format. And the function is load-bearing: you cannot document what you handle, or evidence what you patched, in a component you never wrote down.
The support you are quietly promising
One line in Part II hides a commercial commitment most product plans never priced.
Security updates have to be free for the whole of the declared support period, and under Article 13(8) that period is at least five years, unless the product is honestly expected to be in use for less. You set the number; the floor and the free-of-charge duty are fixed for you.
The catch is when the support clock starts. It starts when the product is placed on the market, not when a customer buys it, so products placed on the market before the CRA officially starts to apply are also covered by the support obligation.
What you must be able to show
In operation, the CRA is a documentary regime. Meeting the requirements is the easy half to say; being able to prove you meet them is what conformity actually is.
The shape of that proof follows the class you settled earlier. Default products go through internal control, Module A of Annex VIII: the manufacturer assesses its own product against Annex I, assembles the technical file, and signs the declaration of conformity with nobody else in the room. Class I keeps that self-assessment door ajar under Article 32, but only where a harmonised standard, a common specification, or a European cybersecurity certification scheme at an assurance level of at least "substantial" already covers the requirements. Fall short of that, and the product goes to a notified body, under Modules B and C, or Module H. Class II and critical products never get the conditional door at all: a notified body is in the loop, whatever standards the manufacturer has applied.
That condition on the Class I door is not a formality either. A manufacturer banking on self-assessment because a CRA-specific harmonised standard will carry it should check, while planning rather than at the audit, whether such a standard yet exists, because the drafting timetable runs uncomfortably close to the application deadline it is meant to unlock.
Past the route, the file itself has fixed contents: technical documentation covering the design, the risk assessment, the secure development process, test results, the vulnerability-handling process, the component inventory, user instructions and the declared support period; an EU declaration of conformity; and the CE marking that stands behind all of it. None of this is a one-time snapshot. It has to stay current as the product and its vulnerabilities evolve, which is why the vulnerability-handling process and the paperwork amount to the same problem seen from two sides.
A word on open source
Open source trips up a good share of teams, because the answer depends on how the code reaches the market rather than on the license.
Free and open-source software developed or supplied outside any commercial activity sits outside the CRA. The moment it goes into a commercial product, the operator placing that product on the market carries the CRA obligations for it, the components they did not write included. A separate, lighter "open-source steward" status exists for certain upstream maintainers, and it is its own conversation. The practical point holds regardless: embedding a dependency does not embed someone else's compliance. It becomes yours.
The dates that actually bite
Here is the reframing that reorders most plans. The date doing the rounds is 11 December 2027, when the main obligations apply, and planning to it is a mistake, because it is not the first one to reach you.
The reporting obligations under Article 14 apply from 11 September 2026. From that day, actively exploited vulnerabilities and severe incidents touching the security of your products have to be notified, on tight timelines, to the designated authorities. The duty applies fifteen months before full application and covers products already on the market, not just new ones. The live countdown to both dates, alongside the rest of the CRA calendar, sits on the regulation timeline.
So the honest sequence is: the reporting path has to exist first, and the full conformity file second. Teams that read only the 2027 date tend to build in the wrong order.
Where this stops being a checklist
A checklist gets you a file. Whether that file survives contact with a real question, a third-party component whose provenance you can't fully account for, or a notification clock running while you are still assembling the facts, is a different matter. That is governance, and it is where CRA readiness is either real or cosmetic.
The test to put to your own file is simple and slightly uncomfortable: if a market-surveillance authority asked to see it tomorrow, would it hold. That question, and what self-assessment quietly asks you to shoulder alone when no one is checking your working, is where the next piece begins.