What cybersecurity standards will products in the EU soon have to meet?

Standardisation for the Cyber Resilience Act (CRA) has begun

It’s understandably the most frequent question I get about the Cyber Resilience Act (CRA): “Do we know yet what cybersecurity standards the products will have to meet?”

For a long time, the answer was “no” — but now we are getting closer. In fact, the CRA’s drafting process took a step forward this month that was barely noticed by the public, but important, nonetheless. Hold on tight:

As the CRA supports the NLF, CEN/CENELEC have been given an SReq to develop hENs.

Uh, what?

Let’s sort this out. You’d better get a coffee first, it’s going to take a while.

CRA = Cybersecurity to become part of the CE marking

You may remember: the CRA means nothing more and nothing less than Security becoming part of the European CE marking. This is no small thing because the CE marking is not only a great success story (once you start paying attention to it in everyday life, you see it everywhere), but also a complex construct. Many of the European Union’s core values are hidden in it.

Goals of the “New Approach” and “New Legislative Framework” (NLF): Neither overregulation nor a regulatory jungle

Short excursion into the history of “Conformité Européenne”, because that is what “CE” stands for: The concept was born on 7 May 1985 and 21 December 1989 respectively, when the “New Approach” for product regulation and the overall concept for EU conformity assessment were decided by the European Council.

You can tell from the word “new approach” that there must have been pain points that made innovation necessary. And there were: Each EU member state had different rules for regulating products, and this regulatory jungle made it difficult for product manufacturers to export their products to other EU states.

The CE concept has therefore been based on some important principles since its birth:

No overregulation: The regulation of products by the EU and its member states is to be limited to an indispensable minimum, the so-called “essential requirements”. This is intended to promote industry’s flexibility and technical progress.

Risk-based approach: It is clearly regulated which products require CE marking — and this depends on their risk potential. This also means that all other products are not allowed to bear a CE mark.

Consistent, reliable requirements: EU directives (and also their transposition into national laws) are not the right place to set detailed technical requirements. First, such requirements tend to change faster than a law. Second, consensus-based standardisation procedures exist for technical requirements for good reason, to reflect the expertise of an entire industry. Therefore, the CE concept makes use of this expertise by referring to EU-wide standards — which are then called “harmonised European Standards (short: hEN, harmonised European Norms)”. If a product complies with these standards, conformity with the CE Directive for the respective product is presumed (“presumption of conformity”). This creates clarity and reliability for product manufacturers.

Free choice of technical solution: It is up to the product manufacturer whether he applies the harmonised standards or chooses another technical specification. Likewise, EU directives must not prescribe which technical solution is chosen for the implementation of the requirements.

In 2008, the New Legislative Framework (NLF) was introduced. It expands and standardises the existing concept and also contains important definitions of terms — some of which we will need later. An important addition to the content was the expansion of manufacturers’ obligations beyond the “placing on the market”: obligations to report hazards and to recall products in the event of suspected “conformity defects”. And a risk analysis also became mandatory.

You probably guessed it by now: That’s why vulnerability management is so prominently anchored in the CRA for a certain period of time after the product has been sold. Because the CRA must of course apply all the principles we just learned about to cybersecurity. Integrating cybersecurity into the CE mark means not starting with a blank sheet of paper, but literally, on the basis of dozens of pages of closely printed paper — the product of years of negotiation, balancing of interests, and learning from practice. When it comes to product regulation, the EU is now really an “old hand”.

It is therefore important to understand what values are behind all the closely printed paper — not the “regulation obsession” that the EU is often being accused of. Perhaps this sums it up better:

The CRA is standing on the shoulders of giants — with all its advantages and disadvantages.

Manufacturer, distributor: Who is responsible for the CE conformity?

There is one more term we need to quickly introduce before we get down to the meat of the matter: “placing on the market”.

The term is defined in Decision 768/2008/EC (part of the New Legislative Framework) as “the first making available of a product on the Community market”.

Placing on the market thus defines a point in time, and at this point in time, the CE mark must be affixed. The manufacturer is the one who has to carry out the conformity assessment procedure and affix the CE mark. But of course, it may happen that someone else “places the product on the market”: a distributor or an importer. Importers must “warrant”, and distributors “verify” that the manufacturer has carried out the conformity assessment procedure and affixed the CE marking.

There is one condition that leads to the distributor or importer having to take over the obligations of the manufacturer, i.e. to carry out the conformity assessment themselves — to be read in Decision 768/2008/EC, Article R6: namely if he “places a product on the market under his own name or trademark or modifies a product already on the market in such a way that compliance with the applicable requirements may be affected”.

And here we come full circle to last month’s discussion on security responsibility for open source software: the open source community is campaigning for precisely this condition to apply to open source software. This is what they mean when they talk about the “entity placing the software on the market” (or sometimes just “distributor”) being responsible for its CE marking.

Harmonised European Norms (hEN): The specific requirements that products must meet for CE marking

Now, at last, we are getting to the real issue. So when a manufacturer (or “distributor” or whoever places a product on the EU market) needs a CE marking, they are less interested in the legislative hodgepodge and more interested in the question of what capabilities their products actually need. And this brings us to the harmonised European Standards (hENs).

A standard has to fulfil a few conditions to become a hEN.

Let’s have another look at Decision 768/2008/EC: a harmonised standard is a “standard adopted by one of the European standardisation bodies listed in Annex I to Directive 98/34/EC on the basis of a request made by the Commission in accordance with Article 6 of that Directive”. Great, open one EU directive and you get a reference to the next one (which, by the way, is no longer in force).

I’ll save you the trouble — we’ll cut a little short:

1. A European standard must be adopted by a European standardisation organisation (CEN, Cenelec and ETSI).
2. A harmonised standard is (in short) a European standard that fulfils the presumption of conformity for the CE marking and was requested by the EU Commission.
3. The EU Commission can mandate CEN, Cenelec, and ETSI to develop standards within a certain timeframe. The standards must be “market-oriented, take into account the public interest and the policy objectives clearly set out in the Commission’s mandate, and be consensus-based”.
4. Once there is a harmonised standard on a subject, there must be no more national standards that contradict or even do not fully comply with this standard.

You can read all this in EU Regulation 1025/2012 or here.

You see, a harmonised standard is an extremely important document. It defines which requirements actually apply in a certain area (e.g. cybersecurity) in order to get a CE mark (without which the product is not allowed on the EU market).

But that’s not all: if there is a harmonised standard, all national standards on the same subject must be withdrawn. There are good reasons for this: we remember — the EU wants to avoid regulatory confusion.

Nevertheless, it means that a decision will soon have to be made at EU level as to which cybersecurity standard will “win the race” and which will disappear into irrelevance (aka archive of “withdrawn standards”).

This is new. Until now, there was no CE mark for cybersecurity, and thus no harmonised cybersecurity standards. Until now, different national and international nomenclature could coexist comfortably. This will soon no longer be possible. One or the other national (e.g. German DIN, VDI or VDE) standard on cybersecurity will soon disappear, and possibly one or the other ISO or IEC standard will gain or lose importance.

Or completely new standards will emerge that we don’t even know about yet.

Draft Standardization Request (SReq): Soon the standards for the CRA will be selected (or written)

Now you have everything you need to understand the meaning of the statement at the very top:

As the CRA supports the NLF, CEN/CENELEC have been given an SReq to develop hENs.

Clearer now, isn’t it?

The EU does not want the implementation of the CRA to end in regulatory confusion (this is what the New Legislation Framework, NLF, says). Therefore, the European standardisation organisations CEN / CENELEC must now decide which standards (harmonised European standards, hEN) will become relevant (“fulfil the presumption of conformity”) for the implementation of the CRA — and possibly write entirely new standards.

The process for this begins as soon as CEN/CENELEC receive a Standardisation Request (SReq) from the EU Commission, which they must then answer. As the CRA has not yet been adopted, CEN/CENELEC have received a draft of the planned SReq in advance for comment. This way, the standardisation process can start as early as possible (right now!).

Standardisation works like this: national standardisation organisations (like DIN and DKE in Germany) send so-called “experts” to European organisations (like CEN/CENELEC). I am an expert in the DKE, working on ISA/IEC 62443. Therefore, I was sent the Draft Standardization Request (SReq) — and we can take a look at it together:

The document has three parts:

1. The main text, which explains the the context of the (not yet adopted) Cyber Resilience Act and calls for the addressees (CEN / CENELEC) to develop standards or revise existing standards.
2. The first annex, which lists in detail the contents of the standards to be created / revised. It is divided into product-agnostic security requirements, product-specific security requirements and requirements for vulnerability management. In the case of product-specific requirements, requirements for industrial automation systems (IACS), PLCs, IoT, etc. are also explicitly demanded. In addition, deadlines are specified that lie between the end of May 2025 and the end of May 2026.
3. The second annex, which contains formal and content-related requirements that the developed/revised standards must fulfil. These are very specific requirements in terms of content — for example, the need to define requirements for secure software development and SBOMs.

Why does this matter?

Let’s summarize why the existence of the Draft Standardisation Request (SReq) for the CRA is such big news:

We know for sure that in the next three years European standards will be created or existing standards will be adopted as European standards. These standarsd will define the security requirements product manufacturers (or “distributors”) must fulfil in order to be able to sell their product in the EU. And from the SReq document it is already quite clear what will be in these standards — partly because it is explicitly required (see SBOMs and the like), partly because there are hints in the metadata and between the lines.

For ICS specifically these ones pointing to ISA/IEC 62443:

First, the Draft SReq was also sent to the CLC/TC 65X technical committee, which “has already been identified as relevant”. TC 65X is the link from IEC committee TC 65 (international standardisation) to European standardisation at CENELEC. And TC 65 is responsible for an international series of standards that you have probably heard of: ISA/IEC 62443. So apparently the EU Commission expects that ISA/IEC 62443 could play a role in the selection of harmonised standards.

Second, the wording in the SReq. “IACS”, Industrial Automation and Control Systems, is a term coined and used by ISA — and not many more organizations.

The SReq offers more hints to what the future may hold if you look at it in detail. This is beyond the scope of this article… but if you are interested, we will take another look at the document in detail soon.

What happens next?

A “Standardisation Request Ad Hoc Group (SRAHG)” is now being convened at CEN/CENELEC to respond to the SReq (and comment on the draft). This group will decide on the harmonised European standards (hEN) that in turn will define the security requirements products sold in the EU have to fulfil in the future. Sounds exciting

Sarah Fluchs

Sarah Fluchs is the CTO of admeritia, which specializes in security consulting for the process industry, manufacturing, and critical infrastructures. A process and automation engineer herself, Sarah is convinced that creating solid engineering methods that speak the language of automation engineers is key for security in automation. Her main research interest is to help automation security engineering grow up as a discipline. More specifically, this includes security and systems engineering, understanding security (and safety) as part of a broader resilience engineering, the use of human-readable models to make security engineering more intuitive and the use of machine-readable models to make it more efficient. To drive these research interests, Sarah leads the government-funded research project IDEAS (Integrated Data Models for the Engineering of Automation Security) and has taken a side-role as a scientific researcher at Helmut Schmidt University Hamburg in 2021. Sarah is an active contributor to ISA and IEC standards regarding automation security and a board member at both the ISA Standards & Practices board and the German water industry digitalization organization KDW. She writes a monthly "security briefing for hard hats" (admeritia.de/hardhats, in German) and a blog (fluchsfriction.medium.com, German and English). Also, Sarah is one of the founders and leaders of the Top 20 Secure PLC Coding Project (plc-security.com).