EU Cyber Resilience Act
Security to become part of the CE product marking
One year ago, on September 15, 2021, EU Commission President Ursula von der Leyen announced the Cyber Resilience Act (CRA) in her State of the Union address. Exactly one year later, on September 15, 2022, the European Commission has now done the groundwork and published a draft for the CRA.
If the EU directive is approved in this form, it will be a milestone: There will then be a CE marking for digital products, which will make security requirements mandatory — because without them, the products can no longer be sold in the EU’s single market. This article places the Cyber Resilience Act in the context of the EU’s other legislation on security and critical infrastructure and explains the details of the legislation proposal.
Before we dive into the details, we can state: With the naming of its new law, the EU is right on trend.
Everyone is talking about cyber and resilience. The rather unpopular word “cyber(security)” is seeping more and more into the accepted vernacular of the IT security bubble and usually means little more than “something to do with computers,” much to the chagrin of those who cherish the word’s origins in cybernetics.
“Resilience” has been a declared goal in many areas in the wake of the pandemic if not earlier: Where we can’t get any further with prevention, where we have to accept that crises will occur, we simply have to be resilient — in other words, able to function even in the event of a crisis. So cyber resilience sounds somehow more mature, but at the same time also somehow more resigned than cybersecurity, like “times are hard, we have to adapt our methods accordingly”.
… another EU regulation for security?!
Adapting methods is a good description for the content of the Cyber Resilience Act. For the first time, the Cyber Resilience Act will affect product manufacturers. Until now, European regulation in the area of cybersecurity has been aimed primarily at operators: The ECI Directive (Directive on European Critical Infrastructure, 2008) and the NIS Directive (Directive on Security of Network and Information Systems, 2016) are the European legal framework for the German IT Security Act, which regulates security obligations for operators of critical infrastructures (KRITIS). Both directives are currently being updated: The ECI directive is to be replaced by the RCE Directive (Directive on the Resilience of Critical Entities; there you go again, resilience…), the NIS directive by the NIS 2 Directive (Directive on Measures for a High Common Level of Cybersecurity across the Union). But that is not the focus of this article.
What problem does the Cyber Resilience Act solve?
Operator’s point of view: the cuckoo’s egg problem
Critical infrastructure operators are familiar with this problem: They are risk owners for their own facilities and their so-called “critical services,” which means they must take responsibility for cybersecurity themselves. You can only be responsible for your own security if you understand the technical systems you are operating. And that’s where operators, especially smaller ones, run up against limits.
They are reliant on the manufacturers of their control systems, their PLCs, but also their network technology: How do you configure the systems to be secure? Do they have any security functionalities at all? Can I install an anti-virus program on my control system without voiding the manufacturer’s warranty? And who will inform me if a new vulnerability becomes known in the implemented systems?
The only answer that the existing critical infrastructure regulation offered them was to extend their own measures to their suppliers: If you have a security management system yourself, you can audit your suppliers as an interface. This provides insight into how suppliers operate, but does not necessarily make their products more secure.
In recent years, there have been a number of security incidents that can be classified as supply chain attacks, meaning they spread through the supply chain of software and/or had high impact because they were built into many other products. Three examples: In the case of the Ripple 20 incident, a vulnerability deep in the TCP/IP protocol stack led to an immense number of affected products. In the Solarwinds incident, malicious code was spread via the update function of a commonly used monitoring software, and the Kaseya incident was similar, but this time a network administration software was the culprit. The EU Commission also cites Kaseya to justify the need for the Cyber Resilience Act.
These incidents have made the problem abundantly clear: operators have little chance to even keep track of the many different hardware and software components in their care, let alone their security vulnerabilities. In the supply chain security incidents, the first major challenge was usually to find out whether you were using the components in question at all, i.e. whether you were affected, because they were hidden so deep in the bowels of the installed components. And if you are affected, what do you do about the vulnerabilities? Who tells you?
The situation leaves many operators, whether critical infrastrucutre operators or not, with a shoulder-shrugging resignation. How are operators supposed to live up to their risk-owner responsibility in this context? Even if all security measures are meticulously implemented and the security management system is as clean as a whistle: The manufacturer components lie like cuckoo’s eggs in your own security nest. They are there, but you don’t really know what you are hatching.
Security problems at manufacturers: Three answers
The cuckoo egg problem is complex, and as with any complex problem, there is not one simple answer, but multiple possible answers.
One is the improved documentation of hardware and especially software down to deep technological levels such as libraries used or protocol stacks. One solution to this is the Software Bill of Materials (SBOM). The promise: Finally, you know exactly which software components you have installed, and in the event of a security incident, you can quickly find out which software you are using — even in purchased components.
Another answer is improved information sharing about vulnerabilities and reaction options.
This can be solved organizationally by establishing CERTs (Computer Emergency Response Teams) that collect, evaluate and publish information about vulnerabilities. One solution for this in Germany, for example, is the CERT@VDE, or for EU institutions the CERT-EU — we’ll get to that in a moment.
You can improve the exchange of information with technological approaches, through standardized, machine-readable vulnerability reports. One solution to this is the Cybersecurity Advisory Format CSAF. The promise: You no longer have to manually evaluate the abundance of vulnerability reports, but can quickly and automatically find out whether you are affected by a vulnerability.
As you can see: In the end, the ball is again in the operators’ court for both of these answers. Sure, manufacturers have to make SBOM and CSAF files available. But operators have to make sure that they can actually make use of them.
And then there is the third answer: certification of the security of components. Here, the ball is in the manufacturer’s court, because the manufacturer must obtain certification. This is time-consuming, comparable to the proof of compliance with the critical infrastructure obligations for operators.
Security certifications of digital products
What happened thus far
In 2019, the EU Parliament adopted the EU Cybersecurity Act (CSA). The CSA can be seen as a trailblazer. It has paved the way for EU-wide security product certification.
With the CSA, ENISA was re-launched with a new name and an expanded mandate. ENISA has existed since 2004 as the European Network and Information Security Agency. Since 2019, it is now officially called “European Union Agency for Cybersecurity” (you see: Cyber!), even if the acronym has remained the same. More importantly, the agency’s tasks have expanded. It plays an important role in implementing the European Cybersecurity Certification Framework, which is intended to provide EU-wide security certification schemes for products. Certification schemes define everything that is important for a certification: the products covered, the requirements to be met, how the requirements are tested, and in which metric the degree of fulfillment of the requirements (“assurance level”) is defined and communicated on the certificate.
Such EU-wide certification schemes are an important milestone. After all, mandatory security certification for manufacturers is not easy to implement in legal terms because it represents a barrier to market entry. Such things must be regulated throughout the EU so that manufacturers from all EU countries have equal opportunities to obtain a certificate and sell their products.
Even the trailblazing Cybersecurity Act is only slowly approaching the topic: Voluntary EU certification schemes are envisioned for the time being, which manufacturers can even achieve through self-assessment under certain conditions. It all sounds a bit toothless and reminiscent of the IT Security Label that is currently being phased in by the Federal Office for Information Security (BSI) in Germany. That, too, is voluntary, which has earned it a lot of criticism. But — see above — only the EU can prescribe mandatory certifications.
Mandatory security certificates: obligations for manufacturers
Drum roll!, we’re back to the topic at hand. Because this is precisely what the EU Commission is now planning to do with its draft Cyber Resilience Act — prescribe mandatory security certifications. The Commission itself describes the draft as the “first ever EU-wide legislation of its kind,” and that is no exaggeration: Because if the act is passed in this form, voluntary self-declarations will be a thing of the past for some products at least. Manufacturers now suddenly have obligations with regard to cybersecurity. Until now, this was only known to operators. More precisely, security will become a truly official product characteristic, as part of the CE marking. Software bill of materials (SBOM) and reporting of exploited vulnerabilities within 24 hours included. But let’s take it one step at a time.
The CE marking for security
How does the CE marking work?
Let’s consider a manufacturer who wants to sell a product in the EU, for example sunglasses.
This is not something he is allowed to do without further ado. The EU imposes requirements that manufacturers must meet before they can sell their sunglasses on the EU Single Market. To help buyers verify that the product meets EU requirements, such products are given a CE marking.
The CE marking (CE stands for Conformité Européenne) regulates the marking of products that must meet harmonized requirements across all EU member states. These requirements are described in “EU harmonization directives”. They exist for all sorts of things: Pressure tanks, childrens’ toys, personal protective equipment, medical devices… in fact, for everything that has to be “safe” in some way.
Perhaps you’ve heard someone say how you can only be sure that a pair of sunglasses really protects your eyes from UV rays if it bears the CE marking. In order for consumers to be confident that the CE-marked product has in fact been thouroughly inspected for EU requirements, the awarding of the CE marking must be precisely regulated — and of course it is:
A CE marking consists of an “EU declaration of conformity”, in which conformity with the relevant requirements is declared, and a “technical documentation”, which contains all the technical details supporting the satisfaction of the requirements. Both documents must continuously be kept up to date by the manufacturer.
Speaking of manufacturers: More precisely, EU legislation refers to “economic operators”, because the person responsible for obtaining a CE marking is the one who places the product on the market. These are not always the manufacturers, but sometimes also importers or distributors.
For a better overview, the graphic above marks which requirements originate from which EU directives: All the CE marking related vocabulary we have learned so far is defined in EU Directive 765/2008 (dark gray).
Now how do you get a CE marking? Conformity with the EU-wide specified requirements must be proven in a “conformity assessment”. The procedure for such an assessment is described in Directive 768/2008/EC (light gray in our graphic).
There are different types of conformity assessments. For the sake of simplicity, we will stick to two of them here: If the manufacturer (or importer, or distributor) demonstrates conformity himself, this is called “internal production control”, known as “Module A” in Directive 768/2008/EC.
For certain products and/or requirements, however, the rules are stricter, and then conformity must be demonstrated by an independent body — this is then called “EC type examination” or “Module B”. In the CE world, this independent body is called a “notified body” because it has been notified to EU authorities by a “notifying body”.
Less cryptic: The independent inspection bodies, i.e. the “notified bodies” are, for example, companies of the TÜV Group.
“Notifying bodies” translate to the responsible ministries in most EU member states.
And finally, there are “accreditation bodies” that ensure that the notified bodies are accredited according to certain criteria. In Germany for example, this is the Deutsche Akkreditierungsstelle (DAkkS). For all EU member states, you can check the NANDO database to find out who the “notifying bodies”, “notified bodies” and “accreditation bodies” are.
Which products does the Cyber Resilience Act apply to?
Now that we understand the CE marking, let’s move on to cybersecurity and the proposal for the Cyber Resilience Act (2022/0272/COD). The CRA draft uses the existing legal framework for the CE mark (gray in the graphic below) and supplements it with a CE marking for security properties (blue below and in the following graphics).
First, the product class to which the security requirements apply must be defined. These are the “products with digital elements”, which translates roughly to “everything with a data connection”:
“This regulation applies to products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.” — CRA, Article 2
This includes everything from the ordinary smartphone through smart toasters to industrial firewalls. That’s why there are two further subclasses, the “critical products with digital elements” or “Class I” and the “highly critical products with digital elements” or “Class II”. Annex III of the CRA defines what exactly falls into which class, but for us it is primarily relevant to know: The “(highly) critical products with digital elements” is the category where we find operational technology (OT): Microcontrollers and processors, IACS (Industrial Automation and Control Systems) according to IEC 62443 definition, IIoT (Industrial Internet of Things), robots and smart meters.
In addition, the Cyber Resilience Act is linked to the NIS-2 directive, which is also still in preparation, because digital devices that are used in “essential entities” according to NIS-2 — in other words, in critical infrastructures — also count as “(highly) critical” in the CRA.
Thus, the CRA is a proposed piece of legislation that explicitly addresses OT components and critical infrastructures.
What requirements does the CRA set for digital products?
Now it’s time for the crunch: We take a look at what a CE-marked “product with digital elements” must be capable of. And it really does read like something straight off the wish list of the supply chain risks-plagued security community.
Annex I of the CRA defines essential requirements. They are subdivided into requirements for security product properties and for vulnerability handling.
Let’s start with the product properties, some of which are rather product development properties: Digital products must undergo a risk analysis during development, they must not contain any exploitable vulnerabilities, and then comes a fairly standard, but nonetheless no less reasonable, litany of requirements: Among other things, secure by default configurations, access protection, CIA, data economy, hardening, logging and monitoring — and the requirement that vulnerabilities must be remediable through security updates.
Where it gets interesting is in the vulnerability handling requirements: An SBOM in machine-readable format is mandated, vulnerabilities must be fixed “without delay” and communicated publicly, a “responsible disclosure procedure” for vulnerabilities must be implemented, there must be regular vulnerability testing, and security updates must be delivered immediately, via a secure channel, free of charge and including a security advisory. Vulnerabilities, by the way, must be reported to ENISA — remember? That’s who runs CERT-EU. The Cybersecurity Act says hello.
Let’s be clear: If all manufacturers follow these guidelines, we will have already achieved a great deal.
In Annex V, the CRA also imposes detailed requirements on the “technical documentation”, which is mandatory for the CE mark in any case: In addition to architectural drawings, among other things the SBOM already mentioned and the technical details of the update mechanism must be included, as well as a risk analysis.
Well-sounding, but vague? That’s why there is the“presumption of conformity”
Especially the “essential requirements” we just briefly listed sound wonderful, but are far too generic to truly be tested. That’s why we’re coming to the last important vocabulary for today, which also opens the outlook.
Attention, legal jargon: There is a “presumption of conformity”. Because the “essential requirements” contain too much room for interpretation to be tested, the EU helps itself with cross-references. References are made to more specific requirements in other documents, and it presumed that if these other documents’ requirements are fulfilled, so are the essential requirements of the CRA.
The cross-referenced documents are mainly standards — but not any standards, but those explicitly published by the EU as “harmonized standards”. Harmonized standards must be European norms (EN) issued by CEN/CENELEC. Such harmonized standards already exist for other areas of the CE marking, but not yet for security. A list can be found here.
If there are no suitable standards that could be declared “harmonized”, the EU itself can define substitutes, which are then “common specifications”.
And — again, we see why the Cybersecurity Act is so important as a trailblazer — if you have gone through a certificate under the “Cybersecurity certification scheme” defined in the Cybersecurity Act, that certification also gives presumption of conformity for the CE marking.
Outlook: Which standards will set the pace?
This is where things will get interesting in the future. For some time now, manufacturers have been perplexed by the various security standards, some of which have multiple certification schemes, and have been asking themselves where to put their money.
So anyone looking for the answer now at least knows where to look: Which European standards are published by the EU as “harmonized standards”? And which certification schemes are being developed under the Cybersecurity Act?
There are some possible candidates for standards and certification schemes that could serve as “presumption of conformity”, for example:
- EN ISO/IEC 15408 (Common Criteria),
- prEN 17640 (Fixed time cybersecurity evaluation methodology for ICT products),
- EN IEC 62443–4–1, EN IEC 62443–4–2 and possibly future “profiles” for specific product groups,
- the evaluation methods in IEC 62443–6-x (not a EN yet),
- EN 303645 (Cyber Security for Consumer Internet of Things: Baseline Requirements).
Toothless tiger or true progress?
I can already hear it, the chorus of grumbling voices that accompanies every cybersecurity law: “Too little, too lax, too late, and generally a toothless tiger”.
And sure, you can bemoan all of that. There have been legal obligations for critical infrastructure operators since 2018, and the obligations for manufacturers are still not there in 2022 — at EU level. If the Cyber Resilience Act is passed, it becomes legally binding for EU member states 24 months later, which means it has to be implemented in national law, and then there will be transition periods for manufacturers as well. That takes tiiiiime.
On the other hand, the timing is not bad. The supply chain incidents of the last few years and also the regulation for critical infrastructure operators, which has been in place for a while now, have raised awareness of the need for cybersecurity regulations for manufacturers.
Mandatory CE marking is no piece of a cake. If you don’t have one, you’re no longer allowed to sell your product, and if you do have one but don’t meet the requirements, you could face penalties of up to €15 million or 2.5% of global annual sales, according to the current draft.
For such an undertaking to have a chance, there needs to be a broad consensus that it’s needed.
Furthermore, regulation like the CRA requires the existence of suitable technology. For example, the idea of SBOM (Software Bill of Materials) is not that old, and the solutions are just emerging. While making it mandatory in the Cyber Resilience Act now is ambitious; it would have been impossible a few years ago.
What remains at the bottom line: It’s happening, and it’s going in the right direction. Security as part of the CE marking would no longer be a product feature that manufacturers would “really like to include if customers were willing to pay for it,” but simply a must.
And the Cyber Resilience Act would be a real milestone to help security grow up as a discipline. “Look here”, it would say, “digital products are as safety-relevant as medical devices, sunglasses, toys and pressure vessels”. And for digital products to be “safe,” they have to be “secure.” Access control and security by design right next to UV protection, protection against electromagnetic radiation and explosion protection. Sounds good, huh?
This article was part of the monthly “Security-Briefing for Hard Hats” (in German).
