As the European Union’s Cyber Resilience Act (EU CRA) prepares to publish a final draft, product manufacturers with any “digital” component must comply three years after final publication. If passed, the EU CRA will be enacted into law and enforced by penalties. The act aims to reduce vulnerabilities in products sold to the EU market by making manufacturers responsible for cybersecurity throughout the product’s lifecycle, improving transparency via SBOMs (Software Bills of Materials) and attestations, and protecting businesses and consumers utilizing that software.
Yet, in its current draft form, the act is one of the most flawed, unachievable cyber security acts Tony Rutkowski has seen in his long career in legal, regulatory and compliance across a variety of critical sectors.
“In the EU, they try to do the right thing and often do,” Rutkowski says, pointing to good legislation like the EU GDPR. “But the CRA is the ultimate over-the-top example of cyber security zeal running wild amongst government regulators. Ultimately, one can envision the unfortunate result that it will not have made cybersecurity any better, may even make it worse, because manufacturers might refuse to do business in EU if the requirements are too onerous and expensive.”
Deconstructing the EU CRA
Now consulting on international regulations to the Center for Internet Security (CIS), Rutkowski spends a lot of time in Europe to “deconstruct” and assess the confusing and sometimes conflicting regulations and standards behind the EU CRA. He also provides critical feedback through working groups and peer gatherings, most recently at the ETSI Security Conference (ETSI stands for the European Telecommunications Standards Institute, one of the standards bodies that would back up this act).
The EU CRA currently applies to 26 product sectors while excluding products subject to other EU legislation (such as those certified under medical, vehicle, aviation and marine equipment requirements, and/or developed exclusively for national security or military purposes).
Product sectors subject to the CRA regulations “range from basically an extraordinarily broad product sector – including operating systems and network management software – to a very specific set of devices – handhelds and microprocessors for example. But no one has attempted to rationalize the list, although lobbyists in Brussels and Strasbourg have tried to evolve that list in various ways,” Rutkowski notes.
Race to the Top
Depending on the product type, many CRA requirements are set to compete with good legislation and standards under development for those specific product types, such as those supporting the financial, water, nuclear power, DNS providers, IOT, and other parts of the critical infrastructure. Additionally, Rutkowski points to the EU AI act, which also overlaps with CRA requirements, in what he calls a race to see which regulations come out on top. If the CRA goes into effect ahead of these other, well-planned, product-specific regulations, he says, then these sectors will fall under the jurisdiction of the CRA.
This makes setting up testing rules and certifying against these different overlapping requirements a nightmare for product companies wanting to do business in the EU. He also cautions that many of the requirements under the CRA are unreasonable. He points to lifetime liability on the part of the vendor and responsibility for end user security, which he considers to be impossible when you factor in the myriad and unique ways software is implemented, configured, and used in organizations, how it is repurposed by third parties using that software in larger products, and how consumers configure their own devices.
He also points out potential issues with jurisdiction. “The flow of software is porous. Most of the product vendors in the world are not based in the EU, and users can access and download anything they want from around the world,” Rutkowski explains.
SBOM Conflicts
Given these and other unreasonable requirements, he says, “most other countries are already signaling they are not going to buy into this. Companies are not going to open their books and code to the EU. And the detailed documentation they’d have to provide, on a continuing basis, is mind-boggling.”
The CRA calls for attestations and SBOMs similar to what the CISA wants manufacturers to provide for government purchases of software, but also different enough to cause more confusion among manufacturers.
“The CRA is a forcing function for SBOM requirements, which is a good thing. On the other hand, the danger is that whatever they adopt as a requirement for SBOMs may not be what Allan Friedman who’s heading these efforts at the CISA would want,” Rutkowski continues. For example, he cites variations in the naming of the software, the dynamics in trees of linked software, what vulnerability databases to test against, standards for expressing SBOM data, lifetime upkeep and maintenance, open-source program ownership, and other problematic areas still being worked out under CISA guidelines.
Manufacturers Could Revolt
During his long career helping to form cyber policies, Rutkowski regularly raises the issue of “proportionality.” As with other requirements, he says, if implementing to the CRA becomes disproportional with the benefits, then vendors might bail on the market or lobby to get it struck down. “That’s happened in the past. So, I suspect one or more vendors, as soon as this is adopted, will immediately be in the EU Court of Justice to raise that issue,” he adds.
To product manufacturers doing business globally, Rutkowski advises that they follow the CISA’s SBOM developments, join SBOM working groups, and attend the CISA’s SBOM-A-Rama’s. He also suggests following standards and joining working groups specific to their critical industry in the U.S. and the EU, pointing specifically to ETSI.org for EU standards, along with the CISA’s Critical Security Controls in the U.S. including NIST standards mapped to these controls.
Also be sure to check out Mark Hermeling’s blog on how best to implement to to the CRA here: https://codesecure.com/learn/navigating-the-eu-cyber-resiliency-act/.
Example of critical infrastructure implementation elements, all of which would require proof of security and visibility across the software supply chain.
Willis H. Ware, The RAND Corporation, “Security and Privacy in Computer Systems”, AFIPS Conference Proceedings, April 1967, Atlantic City
