Common Cyber Resilience Act (CRA) misconceptions in the U.S.
At the S4x26 conference in Miami Beach, I had many conversations about EU Cyber Resilience Act (CRA) on and off stage. What struck me was that the CRA debate in the U.S. is very different from the one in Europe. More specifically, I kept encountering the same misconceptions again and again.
If they were all true, CRA would in fact be a very bad regulation. Luckily, they aren’t.
Time to get a few things straightened:
1. “The CRA is mainly about patching / not delivering products with vulnerabilities.”
This literally is only one out of 13 essential requirements of the CRA.
The other 12 essential requirements look like the secure by design wishlist of every security professional or like any best practice list in the world, including authentication, integrity and confidentiality protection, hardening, logging and monitoring, and impact reduction measures in case of incidents.
Does every requirement apply to every product? Only if there’s a risk. The overarching requirements is to do a risk assessment and based on that determine how to apply these essential requirements to the specific product.
Plus: Manufacturers must inform users of the product’s security capabilities in the “information and instructions to the user”, including how to securely use the product and what circumstances put them or the product at risk.
2. “The CRA makes it illegal to sell a product with an unpatched CVE”
No. The CRA says you can’t sell products with known exploitable vulnerabilities. That’s a huge difference to a CVE.
A CVE is just any of the 1000 vulns a vulnerability scanner will find. The exploitable vulnerability includes some manufacturer assessment.
3. “Exploitable vulnerabilities are basically all vulnerabilities. There’s always a way for attackers to exploit it…”
The CRA definition of an exploitable vulnerability contains three relevant criteria:
- It must be a vulnerability.
- It must have the potential to be effectively used by an adversary…
- …under practical operational conditions.
Criteria 1 and 2 are vulnerability characteristics. The manufacturer needs to evaluate them, but they’re not very product- or manufacturer-specific and likely simple to answer — with one important addition: Note that “effectively” also implies the adversary must be able to cause an effect, not just get in.
Criteria 3 (…under practical operational conditions) is a product characteristic. This really is something that manufacturers can (and must) define individually, as it can be very different for different products. Likely, this is where the line between exploitable or not will be drawn for most vulnerabilities.
See my CRA vulnerability FAQ for more details.
4. “The CRA wouldn’t have changed past incidents because they weren’t caused by unpatched vulnerabilities.”
The CRA is about incorporating security features by design and making it easy for users to securely use the product — not just about patching vulns.
The incident was due to default usernames and passwords? Some product has probably violated the CRA requirement to provide secure defaults.
The incident was due to an exploited remote access? That would at least lead to questions of how unauthorized access was prevented in the product.
Because strong product security (and CRA!) is not just about addressing vulnerabilities when they come up and applying patches — it’s about an inherently secure design. That includes controls against the popular intial attack vectors remote access and weak authentication.
Plus: Under CRA, the manufacturer of any involved product must report suchlike incidents to authorities. That’s uncomfortable, and a great motivator for manufacturers to educate users better and go out of their way to make sure users actually use the product securely.
That way, the CRA could in fact have prevented some of the past incidents. But for all future incidents, it will certainly bring to our attention that weak security isn’t necessarily only the users’ / asset owners’ fault.
For all future incidents, CRA will drive two changes:
CRA will change the way we look at incidents. Today, the manufacturer mostly disappears from the story, and all the blame goes to the asset owners. In the future, manufacturers whose products are involved in incidents will need to report, and if their product doesn’t meet CRA requirements, uncomfortable questions will arise.
CRA will change what we learn from incidents. Today, after an incident we mostly hear asset owner recommendations repeated over and over. In the future, every incident will force cybersecurity in involved products to improve, finally addressing problems at their root cause.
5. “The CRA makes it illegal not to patch”
This is wrong on four levels.
- Not all vulnerabilities: Manufacturers are required to mitigate all known exploitable vulnerabilities. That’s not all vulnerabilities; “exploitable” depends on the manufacturer’s risk assessment (see above).
- Mitigation doesn’t always mean patching: Mitigation isn’t equal to patching and can look different in different cases. Maybe it’s a config change. Maybe it’s a workaround.
- Manufacturers must provide a patch, not necessarily apply it: If it is in fact a patch, manufacturers are required to provide the patch. That’s all. The CRA doesn’t say it needs to be applied to all products in the field (it can’t, because they’re no longer under the control of the manufacturer). Yes, manufacturers must apply available patches if the product hasn’t shipped yet but frankly: this is what already happens and customers rightfully expect.
- Nobody is forced to patch: Customers / asset owners are not subject to CRA at all; they have the absolute freedom to decide what to do about a vulnerability. Only difference CRA makes: They have all options and all required information available — because the manufacturer is legally required to provide advisories some kind of mitigation for all vulnerabilities. Timely and for free.
6. “Under CRA, it’s no longer possible to differentiate between product use cases. Patching often doesn’t make sense for all product applications.”
Oh yes, it is. You can absolutely differentiate by intended use of the product, and could even give nuanced advice based on different use scenarios.
7. “The only change CRA will make is more paperwork for manufacturers”
Under CRA, what counts is that manufacturers meet essential requirements. That is what causes non-compliance complaints. That’s what can get you fines or sales bans. The documentation won’t save you if your product doesn’t meet the requirements, and customers, competitors and security researchers (all of whom can file non-compliance complaints) never see your documentation anyway.
CRA is unlike critical infrastructure regulation. It doesn’t require an information security management system, that can be excellent on paper but non-existent in reality. It requires actual security capabilities in the product, as well as actual organizational processes like providing free patches, public security advisories, incident reporting, and a responsible disclosure process.
8. “The CRA will only make products more expensive.”
That’s admittedly not really a misconception. Maybe it will. Maybe not. The reason why I think it won’t:
Right now, security often makes a product more expensive — because you can choose a secure and an insecure product. The cost for the more secure product is often hidden in premium fees (see CISA’s recent paper “Why Johnny Can’t Authenticate” which has extensive voice of customer research).
CRA takes away the cheaper, insecure option. You can’t hide security cost in additional fees since security must be the default. You’d just make your entire product portfolio more expensive. And that’s where competition kicks in: All manufacturers I talk with are afraid of becoming more expensive than their competitors.
Since everybody has to meet the same security requirements under CRA, I believe it will be an incentive to meet security requirements in the most cost-efficient way — which is a good thing.
This article was written as part of my monthly “Security Briefing for Hard Hats.” Subscribe here.
Need a helpful hand leading you through your CRA journey, from threat modeling to conformity assessment? Take a look at the Security Engineering Tool (SET).
