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 that was planned for. Being in scope is a status. What the text asks of the product is a programme of work. This piece is about the second thing.

The reference is Regulation (EU) 2024/2847. Everything below points back to it; where something is interpretation rather than the text speaking, it is marked as such.

First, which product, and which class

The CRA governs products with digital elements made available on the EU market. That covers software and hardware that can connect, and their remote data-processing solutions. The scope is deliberately broad, and the first practical task is not "are we in", it is "in which category".

The text separates a default category from higher-risk ones. Most products sit in the default category and follow the lightest conformity route. A set of products the legislator considers more sensitive fall into the important classes listed in Annex III, and a narrower set into the critical category. The class decides how much external scrutiny the conformity assessment requires, from self-assessment at the low end to third-party involvement at the higher end.

The consequence is that classification is not a formality you do at the end. It sets the cost and the timeline of everything after it. Our reading, from client work, is that teams underestimate this step because the default category feels reassuring, and then discover a component or a function that pulls the whole product up a class.

The essential requirements, in two families

Annex I is where the obligations live, and it has two parts that are easy to conflate and shouldn't be.

The first family is about the product's own security properties: shipping without known exploitable vulnerabilities, a secure default configuration, protection of data in transit and at rest, minimisation of attack surface, and the ability to be updated. These are properties of the thing you sell.

The second family is about how you handle vulnerabilities over the product's life: identifying and documenting them, addressing them without delay, distributing security updates, and having a coordinated disclosure path so that someone outside your organisation can report a flaw and reach a human. This second family is a process, not a feature, and it is the part that outlives the launch.

The distinction matters because the first family can be closed by engineering before shipping, while the second is a standing capability you have to operate for years. Costing the first and forgetting the second is the common error.

What you must be able to show

The CRA is, in operation, a documentary regime. Meeting the requirements is necessary; being able to demonstrate that you meet them is what conformity actually is.

That means technical documentation that stands on its own, a conformity assessment appropriate to the product's class, an EU declaration of conformity, and the CE marking that asserts all of it. The documentation is not a snapshot taken once. It has to stay current as the product and its vulnerabilities change, which is why the vulnerability-handling process and the paperwork are the same problem seen from two angles.

The test to apply to your own file is simple and uncomfortable: if a market-surveillance authority asked to see it tomorrow, would it hold. That question is the subject of the next piece.

The dates that actually bite

Here is the reframing that changes most plans. The headline date in circulation is 11 December 2027, when the main obligations apply. Planning against it is a mistake, because it is not the first date that reaches you.

The reporting obligations under Article 14 apply from 11 September 2026. From that date, actively exploited vulnerabilities and severe incidents affecting the security of your products have to be notified, on tight timelines, to the designated authorities. This duty arrives fifteen months before full application, and it reaches products that are already on the market, not only new ones. The live countdown to both dates sits on the regulation tracker.

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.

That is the thread the next piece picks up.