Sten Eikrem

Blog

CRA: The CE mark will not tell you what you bought

Seventeen draft standards now show what a CRA claim will consist of. The manufacturer declares its own scope, some requirements are handed to your environment, and for operational technology no standard exists yet.

By Sten Eikrem

One CE mark above three columns of requirements. The first column has three of ten rows filled, a narrow declaration. The second has all ten filled, a broad declaration. The third is empty: operational technology, where no standard exists yet. The same mark points at both filled columns.

The Cyber Resilience Act is a welcomed however complicated regulation to buy against, where the obligations sit with your suppliers but the interpretation of what they deliver ends up on your side of the contract.

It’s easy to misunderstand what a CRA claim will mean, and the misunderstanding is that a CE mark on a product with digital elements will tell you the product is secure. It won’t, and now we can read why.

In January I told you to write CRA compliance into your RFPs, and at the time nobody could say what compliance would consist of, because the harmonised standards didn’t exist.

What the drafts are

Over the summer ETSI put seventeen draft standards out for public enquiry, covering everything from browsers and operating systems to firewalls, routers, SIEM and connected toys.

In short a harmonised standard is the document a supplier applies to show a product meets the regulation, and once it’s cited in the Official Journal the supplier can claim compliance by citing it rather than proving it case by case.

As of September 2026 none of the seventeen is cited, all of them can still change, and two are at version numbers below 1.0, so what follows describes drafts, but the shape of them is clear enough to buy against.

Vulnerability handling is not in them

What is important to understand is that every one of the drafts covers the product properties in Annex I Part I and none of them covers Part II, the vulnerability handling requirements, and that is by design, since Part II sits in a separate CEN/CENELEC standard for all products that was still in approval when the drafts went to enquiry in August 2026.

The reporting duty itself does not wait for any standard, because the regulation sets it directly, it applies from 11 September 2026 and it reaches equipment already installed in your plant, so a controller commissioned ten years ago is inside it from day one.

What the standard will give you, once it lands, is some consistency in the process behind the reports, and until then the quality of what arrives will follow the maturity of the supplier sending it, where a supplier that already runs a disclosure process adds a channel and carries on, however a regional OT supplier or integrator with no such process today gets the duty with nothing behind it.

So the notifications will arrive on schedule and they will be uneven, and the one lever you hold over that is on your side, a standardised way to receive, triage and decide on them, which is the capability list in the January post.

The manufacturer declares its own scope

One important matter to be aware of is that the manufacturer assesses its own product, and that assessment decides which requirements bind, so a narrow declared use case carries a small requirement set and a broad one carries a large one.

The spread is not marginal, and a couple of examples would be the SIEM draft, where one defined use case has every requirement marked not required, or the operating systems draft, where a restricted operating system carries seven baseline mitigations and a general-purpose one carries twenty-six.

Both products can be CE marked and both are compliant, and the interesting part is that the mark only tells you the manufacturer answered a question without telling you which question it was.

Some requirements are handed to you

Regarding the requirements themselves, several drafts are written so that a requirement is satisfied not by the product providing a security property but by the product supporting the operational environment in providing it, and the network interfaces draft says in terms that products in its scope are not required to provide authentication and access control independently of their environment.

Read that as a procurement statement rather than a technical one, because whatever the product does not provide, you provide, and that list is your integration backlog.

For OT there is no standard yet

Regarding OT in manufacturing, the key point is that five of the drafts, covering firewalls and intrusion detection, routers and switches, network management, network interfaces and SIEM, exclude products intended for the industrial domain in their scope clause and defer them to a CENELEC series that has not been drafted in public.

So if you buy a firewall for the office network there is a draft describing what compliance means, and if you buy the same class of product for the process network there is not, and your OT suppliers face the same December 2027 restriction with nothing to build against.

Some will self-assess against the general essential requirements, some will apply the IT drafts and argue the case, and some will wait, and you can see which by asking, while the conversation is still on your terms.

The trade-off

For both IT and OT there is a trade-off to be conscious about and you have an option about whether you make it up front, by asking which standard and which declared use case sits behind a claim before you sign, or down the road when a product you assumed was covered turns out to have declared itself out of most of the requirements.

One recommended clarification is to ask a supplier for the list of conditions and requirements they determined did not apply, and the basis for each. If they can’t produce it you don’t have a compliance claim, you have a mark. A well founded claim names the standard and version, the declared use case or profile, the expectations to your environment, and for OT what they intend to do while no standard covers them.

Sources:

I advise industry and energy companies on security governance and risk management. More about my work.

Connect: Follow for more insights on security governance and risk management on LinkedIn • Mastodon • Bluesky