Product security regulation in 2024

An overview

We all know the cybersecurity of critical infrastructures has been regulated for years, and in Europe, there currently is a lot of buzz around NIS-2, which widens the scope of this regulation. But at the same time there’s a big regulatory shift happening from product users and operators (such as in critical infrastructures) to product suppliers. Here’s an overview over the 2024 product security landscape.

• In the EU, the Radioequipment (RED) directive addressing cybersecurity of everything communicating wirelessly is already in force, and the Cyber Resilience Act (CRA), turning cybersecurity into a market entry barrier for almost ALL products will likely enter into force this year.
• In the UK, the Product Security and Telecommunications Infrastructure Act (PSTI), something similar to the CRA, is already in force.
• For cars, there is are two new UN regulations (UNECE R 155 and R 156) that first applied this summer, making cybersecurity a mandatory requirement for car type approvals. It has already caused some Volkswagen and Porsche car models to be discontinued. If you’ve wondering why you cannot by a Volkswagen Up or a Porsche Cayman anymore — now you know.
• And in addition to all that, voluntary product cybersecurity labels are being developed in many countries, often specifically for IoT. Often, these labels are mutually recognized, for example between Singapore and Germany and Singapore and Finland. Singapore also leads an initiative to draft an ISO standard (ISO/IEC 27404) for IoT cybersecurity labels based on the experience with Singapore’s own cybersecurity label for consumer IoT.
• Although not a regulation, the US Cybersecurity and Infrastructure Security Agency (CISA) is leading a security by design initiative including a secure by design pledge asking product suppliers to finally implement security by design.

Goals

The goals of all these initiatives are very similar. Here you go:

1. Products become more secure (or at least aim for less vulnerabilities)
2. Manufacturers take security serioulsy (often you could add a „finally“ here). And they should do it throughout the product lifecycle, so including security updates when the product is in use.
3. Users — or buyers — can make informed cybersecurity decisions when they buy or use the product.
4. Raise awareness for or even enforce existing cybersecurity industry standards.

Regulations are not standards, that’s why that goal number 4 matters. For the CRA, the standards to be enforced are a longer list of harmonised EU standards, short hENs, which are still to be determined. (IEC 62443 is one hot candidate for OT products).

For PSTI, it‘s the IoT standard EN 303645.

For UNECE, it‘s the automotive security engineering standard ISO 21434.

For the IoT labels, that really depends on the country and label, but mostly at least one standard is referenced.

And then, specifically for the CRA, there’s another goal that is often overlooked. The CRA, coming only shortly after new critical infrastructure regulation NIS-2 in Europe, also has the goal to make life easier for critical infrastructure operators. They are responsible for the security of their plants, and have often struggled to demand secure enough components from their product suppliers (or even enough information to judge the components’ security) in the past. The CRA will help with both — product security features and their documentation.

Rigor / strategy

Here‘s an overview of what I‘d call rigor of the regulation. More rigor means manufacturers are forced to do more.

Rigor increases if a regulation is not voluntary but a true market entry barrier for products — you cannot sell your product any more if you don‘t demonstrate that your conformity with the regulation (y-axis). Also I‘d assume manufacturers do more if they must undergo a third-party assessment to demonstrate their conformity versus if they can self-declare conformity (x-axis).

In this landscape, the CISA secure by design pledge — unsurprisingly, because it is not a regulation! — is in the lower left corner with the least amount of rigor: It‘s voluntary, and manufacturers self-declare.

IoT labelling schemes are the same if they‘re based on self-declaration, but in some countries they do require a 3rd party assessment. By the way, although not regulation because not pushed by any government, ISA/IEC 62443 certificates can be mentioned as another voluntary product security label requiring 3rd-party-assessments.

In contrast to these voluntary labels, there are some that form actual market entry barriers:

In the UK for example, the government has been trying to convince manufacturers to follow the secure by design principles for IoT outlined in EN ETSI 303645. The standard was internationally recognized. Everybody agreed it was good. But few people implemented it. That‘s why the UK government now mandates product security for consumer IoT in ist PSTI act. It’s based on self-declaration though, so still not in the upper right corner of the rigor landscape.

UNECE and CRA (and also RED) take this one step further: combining a true market entry barrier with a third-party assessment. They achieve that by leveraging existing market entry barriers and add security to them.

• For UNECE, this is the existing vehicle type approcal every vehicle has to undergo before being sold on the UNECE markets, which is way more than just the EU but also includes countries like the US, UK, and Russia.
• For the CRA, it is the CE marking, that many products in the EU already carry that have safety implications — be it sunglasses, pressure vessels, or children‘s toys.

The advantage of leveraging existing market entry barriers and adding security is that the structure to enforce it — market surveillance authorities, standard authorities, and entities carrying out third-party assessments — are already there. So UNECE and CRA also include third-party assessments, which really is the highest degree of rigor you can have in a regulation:

Not only do products have to meet cybersecurity requirements or they cannot be sold anymore, but conformity with these requirements is also audited.

To wrap this up, here art two different strategies that a regulatory authority can follow:

Security as a matter of course

You can encourage manufacturers and their customers to see security as a matter of course. As something you don‘t need to think much about any more, that‘s built into products. There are no products any more without at least some basic cybersecurity features. You protect buyers from buying a product without some basic cybersecurity.

Security as a competitive advantage

Or you can encourage manufacturers and their customers to see security as a competitive advantage; have product vendors compete who integrated the most security and trust that customers prefer the more secure solutions. You enable buyers to make an informed cybersecurity decision if they want to.

Regulations aiming for market entry barriers have a tendency towards the „security as a matter if course“ strategy, and voluntary labels, have a tendency towards the competitive advantage strategy.

But of course, the world is not that black and white. You can enforce some features and still provide customers with information to decide about others. And this is what most market entry barrier approaches do — CRA for example.

Scope

Up to here, we only looked at how the product security regulations differ regarding goals and strategy, but of course they also differ widely regarding scope:

• Most IoT labels address consumer IoT.
• PSTI is pretty similar, also addressing consumer IoT.
• RED only addresses radio equipment, which is of course used in some consumer IoT.
• The CISA pledge is mainly about software, which means it overlaps with the scopes we already discussed.
• Then there‘s the UNECE regulation that addresses vehicles, which may include radio equipment and definitely include software too.
• And then there‘s the CRA. The CRA really covers ALL of the above. Well, to be accurate, the vehicles are not in scope of CRA, because they are already regulated elsewhere.

In case you were wondering, I’ve also marked OT in the scope landscape. Each of the regulation also addresses a bit of OT, but non is JUST for OT — which explains why they often don’t quite seem to fit to OT products, but that’s a different story.

Requirements

Last question: If you’re affected by a product security regulation, what do you actually you need to do?

Here are some typical product security requirements. Parts or all of them can be found in all the regulations discussed above. They can roughly be divided into three categories:

Incident prevention — your toothbrush: everyday actions and principles to follow during design to keep your product as clean of vulnerabilities as you can. Here you can find security by design.

Incident readiness — your tire stack: everything that helps you crash less hard if an incident happens: measures to reduce impact (like backups, failovers or safety functions).

Incident handling — your firehose: everything you to handle an incident professionally and put out the fire fast, like good procedures for putting out advisories and releasing updates fast.

Product security regulations are all pretty similar regarding those requirements. They really are not controversial at all and can be regarded rather mature. There is broad consensus what is needed. The entire process of drafting and negotiating the CRA is a good indicator for that: the CRA was not political at all. No one questioned it was needed. All debates only addressed implementation details, like if open-source software should be in scope or how the support period for security updates should be defined.

What does this mean in practice?

The really interesting part will be to see how all that regulation actually materializes. By nature, regulation is always a bit vague. Currently, many product manufacturers are nervously eyeing their competitors and wondering how everybody else will approach product security.

What security features will actually become the new normal and what product security documentation will typically look like is a question of what the market asks for, what authorities audit and demand, if and how heavily non-compliance is fined, and what the first successful implementations look like (that will likely be copied a lot).

It has been like that for critical infrastructure regulation (EU: NIS), for data protection regulation (EU: DSGVO), and now this process starts for product security regulation. So this is the time for critical infrastructure asset owners to set standards by making demands, and it is the time for product suppliers to lead by example if they want to be known for exemplary security (see my follow-up article on what that could look like for the CRA).