Why the EU Cyber Resilience Act is Important
Episode 60: Better Built By Burkhard
Dear Reader,
Will you release an embedded device within the next 2.5 years? Of course, you will, because otherwise you will be out of business soon.
Will you support the device after 11 December 2027? Of course, you will, because otherwise developing the device won’t be worth it.
Then, you better make sure that your board, SoC, Linux system and applications satisfy the essential requirements related to product properties and to vulnerability handling (Annex I) already now. If you need hardware modifications to comply with the requirements, you should select different hardware. If your board vendor has a history of providing out-of-date Linux systems, you should select a different vendor. Following this advice will save you a lot of time and money. You are welcome 🙏
The essential requirements of the EU CRA are not “yet another lunacy from Brussels” but they help you make security incidents very unlikely and avoid high damages. I explain how the essential requirements would have prevented the CrowdStrike update fiasco. The requirements make a lot of sense but also take considerable time to implement. Act now to avoid resource bottlenecks closer to the penalty date: 11 December 2027.
Enjoy reading,
Burkhard 💜
My Content
EU CRA: Essential Requirements Related to Vulnerability Handling
In my previous post, I explained the essential requirements related to product properties (Annex I, Part I). In my current post, I explain the essential requirements related to vulnerability handling (Annex I, Part II): creating an SBoM with all components and their vulnerabilities, fixing vulnerabilities, regular testing, publishing fixed vulnerabilities, coordinated vulnerability disclosure policy, and secure distribution of updates.
Manufacturers must comply with all the essential requirements in Annex I, Part I and II, or give a well-founded explanation why a requirement doesn’t apply for their devices. The essential requirements are the practical rules applied while building a device. All other rules in the EU CRA are documentation and reporting obligations.
Why the EU Cyber Resilience Act is Important
Let’s face it. Your main motivation as a manufacturer most likely is to avoid the heavy penalties for violating the EU CRA and to avoid the high damages from the exploding numbers of cyber attacks. It’s about saving your money for what really matters: your core business! And there is nothing wrong about this motivation.
Complying with the essential requirements related to product properties and to vulnerability handling (Annex I) is not “bureaucratic nonsense from Brussels”, but the reasonable thing to do. Implementing these requirements for your embedded device will make cyber attacks a lot more difficult. Attackers are in for easy money. If they can’t find a quick and easy way into your device, they’ll turn their attention to easier and more worthwhile targets.
Act Now!!!
The EU CRA has been in force since 11 December 2024. If you release a product in the 3-year transitional period ending on 10 December 2027 and want to provide substantial functional updates (e.g., new features) after that period, you must satisfy all the regulations of the EU CRA (see Article 69.2). Updates for bug and security fixes are OK.
If, for example, your hardware (including SoCs, SoMs or SBCs) does not support secure boot, you will at least violate the essential requirement Integrity Protection. You will violate it now - and you will violate it after 10 December 2027. You must either select SoCs that support secure boot or add a secure hardware storage to your board. Yes, that’s a board modification, which may or may not be feasible.
Is your board and its accompanying system software (a.k.a. BSP = board support package) ready for the EU CRA? If not, take the appropriate actions now or end the support for your devices on 10 December 2027.
If you have started or will start the development of a new device in the transitional period, you should plan well in advance for the implementation of the essential requirements related to product properties and to vulnerability handling (Annex I). You easily need two person years for the implementation - even if you know what you are doing. You can’t add the implementation as an afterthought to a nearly ready product.
By 11 September 2026, you must notify the responsible bodies about actively exploited vulnerabilities and severe security incidents (Article 14.1-5). So, you should be ready to identify, address and remedy such vulnerabilities in all software packages on your devices, and to inform the responsible bodies and the users. This will be easy, if you implement the essential requirements for vulnerability handling.
Avoiding Heavy Penalties
From 11 December 2027, the EU can punish you with heavy penalties.
If you violate any of the essential requirements related to product properties and to vulnerability handling (Annex I), any of the obligations of manufacturers (Article 13) or any of the reporting obligations of manufacturers (Article 14), the EU can punish you - according to Article 64.2 - with fines up to 15 million Euro or up to 2.5% of your worldwide annual gross revenue, whichever is higher.
You face fines,
if you release devices with known exploitable vulnerabilities,
if you leave personal data unencrypted,
if you use the same password for multiple users,
if you don’t fix vulnerabilities in a timely way, or
if you don’t disclose vulnerabilities to users and authorities properly.
That’s not all! The EU can punish you - according to Article 64.4 - with fines up to 5 million Euro or up to 1% of your worldwide annual gross revenue, whichever is higher, if you provide “incorrect, incomplete or misleading information to notified bodies and market surveillance authorities in reply to a request”. In short, don’t even try to cheat if authorities ask for information.
The amount of the fine depends on the severity and duration of the violation and on the potential or real damages caused by it. The fine will be higher, if you are a repeat offender. The fine increases with the size and market share of a business (see Article 64.5 for determining the amount of the fee).
Avoiding High Damages
For 2024, Bitkom (the German trade association for the information and telecommunications industry) estimated the damages from cyber crimes at 179 billion EUR for Germany. Bitkom’s survey is representative by size and industry. The total number of attacks is divided up into 31% ransomware, 26% phishing, 24% password, 21% malware and 18% distributed denial of service (DDoS) attacks (multiple attack types possible per company).
For 2024, the BSI (Germany’s Federal Office for Information Security) put the amount looted by ransomware attacker worldwide at 1.1 billion USD. The average ransom for encrypted data is 300,000 USD per case and for unencrypted extracted data is 850,000 USD per case.
With a faulty update of its Falcon software, Crowdstrike sent 8.5 million Windows PCs into an infinite boot loop. Humans had to manually boot each of the 8.5 million PCs into safe mode, remove a file and reboot the PC. The total direct financial loss for the affected US Fortune 500 companies amounted to 5.4 billion USD. Delta Airlines had to cancel 5,000 flights. The operation of banks, retailers, manufacturers and hospitals was affected, too. The reputational damage to Crowdstrike seemed to be short-lived: The share price dropped by more than 50% within days but recovered within six months to new record highs.
While big companies have enough people or enough money to comply with the EU CRA, small and medium businesses (SMBs) will struggle. In its 2024 status report about IT security for Germany, the BSI reports that SMBs lack the expertise in IT security. SMBs also struggle to hire qualified people, because they can’t pay the salaries of the big companies and because these people are rare.
If SMBs can’t even cope with IT security, how should they cope with the much more difficult security for embedded devices! Problems will only exacerbate. There are even fewer knowledgeable people, who cost even more. The situation will only get worse the closer 11 December 2027 and the penalties come. This is not only true for small and medium companies but for all companies. It’s best to act now!
Impeding Cyber Attacks
Know Your Enemies
By implementing the essential requirements related to product properties and to vulnerability handling (Annex I), you make the life of attackers a lot more difficult. Most attackers are in for quick and easy money and will turn to other targets with a higher return on investment.
Actors sponsored or guided by nation states - including intelligence agencies, military and commercial hacker groups - are the most dangerous threat actors. They have enough money, skilled people and enough time to execute long-term and well-organised attacks. Their goal is industrial espionage (e.g., extracting company secrets and giving it to the local competition) and disruption (e.g., blackouts of the Ukrainian power grid in 2016 and 2023 and paralysing shipping giant Maersk with NotPetya - both caused by Russian state-sponsored cyber terrorists). Disruptions cause damages amounting to billions of dollars and - even worse - fear in people.
State-nexus actors take their time to find a way into the targeted systems. For example, the attackers planted NotPetya into Ukrainian tax software. When Ukrainian companies routinely updated their tax software, they infected their PCs with outdated Windows versions. Once present on a PC, NotPetya could also infect properly updated Windows systems. From there, NotPetya wormed its way to more and more vulnerable PCs all over the world - until it finally hit Maersk, TNT Express and other global companies. NotPetya destroyed the master boot records so that the infected PCs couldn’t boot anymore.
Hitting Ukrainian companies was planned, whereas hitting companies worldwide was a welcome collateral damage - except for the oil company Rosneft owned by the Russian state. If the security of your software or devices is shoddy, you can easily become an “unwitting” accomplice in a crime. Heavy penalties for violating the EU CRA are certain. Compensation for damages to other companies and people are likely. Criminal prosecution is possible. So, you better act now!
How the EU CRA Helps Avoid Cyber Incidents
The best way to avoid the penalties from the EU CRA is to implement the essential requirements related to product properties and to vulnerability handling (Annex I) diligently. This is also the best way to make security incidents very unlikely and keep damages in a tolerable range over the lifetime of your devices. There is no perfect security - but the risk is manageable. CrowdStrike’s update disaster is an excellent example how the EU CRA helps avoid cyber incidents.
The CrowdStrike disaster was caused by an out-of-bounds access while the Falcon software parsed a configuration file. The configuration file provided 21 elements but the array could only hold 20 elements. As Windows starts the Falcon software in kernel mode, the Falcon crash takes down the Windows PC. The PC reboots, crashes, reboots, crashes - indefinitely.
Providing bogus configuration files to make a parser crash or overwrite memory with malicious code is a common attack method. In this case, it wasn’t even an attack but “just” an update gone wrong. All three main actors - CrowdStrike, Microsoft and Delta Airlines - could have mitigated or even prevented the outage by following the essential requirements of the EU CRA.
CrowdStrike handles updates of configuration files differently than software updates. It rolls out configuration updates to all PCs at once, whereas it performs a staged rollout for software updates. Obviously, CrowdStrike doesn’t test changes in configuration files thoroughly. As Falcon runs in kernel mode, testing should be extra careful.
CrowdStrike could have easily found the out-of-bounds access by fuzz testing or by testing boundary conditions (the “B” in James Grenning’s method TDD Guided by ZOMBIES). Such testing is demanded by requirements Identify Components and Vulnerabilities and Regular Testing.
CrowdStrike could have minimised the negative impact by enforcing a staged rollout for configuration updates. Delta Airlines would have had to reboot 1,000 PCs manually - instead of 40,000 PCs. Delta could have operated nearly normally and would have avoided huge damages.
Microsoft takes insufficient precautions, if third-party software like Falcon crashes in kernel mode. Windows crashes, reboots, crashes again, reboots again - forever.
Microsoft could have used boot counting to make the PC boot into Safe Mode after the third failed boot attempt. Windows could apply the fix - replacing the faulty configuration file with the correct one - automatically and reboot into the normal mode. Alternatively, Windows could roll back the last faulty update automatically after the third failed attempt and reboot into a working system. This would require an update history like A/B copies or an artefacts repository. Both methods would minimise the negative impact on the PC.
Windows doesn’t have to run the Falcon software in kernel mode. It could use the same approach as Apple. MacOS provides an API - the Apple Endpoint Security Framework - that allows anti-virus software to access information from the macOS kernel. The anti-virus software can run in user mode. Microsoft could do the same. Running programs at the lowest privilege possible is one of the points of requirement Mitigation of Incidents.
Any of the two previous remediation measures would have ensured that Delta could have operated their flights as usual. The essential and basic functionality of Delta’s crew-tracking system would have been available.
Delta Airlines rolled out the configuration update to all its 40,000 PCs in one feel swoop without any testing. Microsoft stated publicly that Delta neglected to keep its IT infrastructure up-to-date. Delta buys its IT infrastructure and the crew-tracking software from service providers including IBM.
Delta should have run a staged rollout for both software and configuration updates - even if CrowdStrike didn’t mandate this. This would have drastically minimised the negative impact of the faulty update.
For a mission-critical system, Delta should have hot spares in sufficient numbers. Redundancy is a standard measure to mitigate security incidents. It is a rollback to a working system.
By combining hot spares and staged rollouts, Delta could have averted almost all cancellations. It would have minimised negative impact even further.
For a mission-critical system, rigorous and regular testing is a must. The requirements Identify Components and Vulnerabilities and Regular Testing provide exactly this. Delta can’t abdicate this duty to other companies.
In the days and weeks after the CrowdStrike disaster, CrowdStrike, Microsoft and Delta Airlines were furiously pointing fingers at each other. Instead of this childish behaviour, these companies should have worked together from the beginning to prevent this security catastrophe. All of them share responsibility. High-quality security can only be achieved if all relevant parties work together constructively.
CrowdStrike, Microsoft, Delta Airlines and all the other CrowdStrike customers were lucky that the penalties of the EU CRA only start on 11 December 2027.