#KEYMASTER: Understanding the Cascading Impact of the EU Cyber Resilience Act (CRA)
2026-01-27
In this episode of #KEYMASTER, Sven Rajala, International PKI Man of Mystery, speaks with Guillaume Crinon, Director of IoT Business Strategy, about one of the most important upcoming regulatory shifts for connected products: the EU Cyber Resilience Act (CRA), and why its impact goes far beyond compliance checklists.
The CRA is not just another security regulation. It fundamentally changes how organizations must design, build, operate, and maintain products that are sold in the European market.
What is the Cyber Resilience Act?
The Cyber Resilience Act (CRA) is an EU regulation that applies to any product with digital elements sold in European Union (EU), regardless of where it is manufactured. Whether a product is built inside or outside the EU, if it is placed on the European market, the CRA applies.
One of the most significant obligations introduced by the CRA is that manufacturers and OEMs remain responsible for the cybersecurity of their products for a minimum of five years after they are placed on the market.
This responsibility encompasses both hardware and software, and applies to a wide range of devices, including consumer IoT devices, industrial systems, and embedded software.
Raising the Security Baseline — in Europe and Beyond
The CRA is designed to raise the overall level of cybersecurity across products sold in Europe. But its influence is likely to extend well beyond EU borders.
In practice, many global manufacturers use the same product Stock Keeping Unit (SKU) across regions. As a result, security improvements driven by the CRA are expected to become the global default, not just a Europe-specific requirement. In that sense, the CRA acts as a forcing function for better product security worldwide.
The Cascading Effect: From One Requirement to Many
One of the most impactful CRA requirements is how organizations must handle vulnerabilities.
Vulnerabilities are inevitable. The CRA assumes this, and requires manufacturers to be prepared.
Under the CRA, organizations must:
- Maintain a dynamic Software Bill of Materials (SBOM)
- Continuously monitor for vulnerabilities affecting components in their products
- Assess impact when new vulnerabilities are disclosed
- Report significant vulnerabilities to the relevant EU cybersecurity authority
- Notify customers
- Document remediation actions
- Provide security updates free of charge
This single requirement triggers a cascade of technical and operational consequences.
Firmware Updates Are No Longer Optional
Consider a real-world example: smart meters deployed by utilities in the hundreds of thousands, or millions.
When a vulnerability is discovered, it is not practical to manually update each device using physical access. As a result, secure over-the-air (OTA) firmware updates become mandatory.
But enabling remote updates immediately increases the attack surface, something the CRA explicitly warns against. This creates a tension that must be addressed through strong security design.
Security Foundations You Can’t Avoid
To safely support OTA updates and meet CRA requirements, manufacturers must implement several foundational security capabilities:
- Secure boot, ensuring devices only run trusted software
- A hardware root of trust, even on constrained devices
- Firmware and software signing, including bootloaders and updates
- Proper key management processes, ideally backed by HSMs
- Documented and auditable signing workflows
Relying on ad-hoc signing keys stored on developer laptops or default vendor tools may be convenient, but under the CRA, those practices, in most cases, won’t be sufficient.
Device Identity and Secure Communication
Once devices can update themselves, they must also securely communicate with backend services.
That means:
- Encrypted connections using TLS, Preferably mutual TLS (mTLS)
- A unique identity per device, typically implemented as a certificate
- A private or operational PKI to issue and manage those identities
- Trust validation of firmware delivery servers
Device identity is no longer a “nice to have”, it becomes a core requirement for operating securely and at scale.
From Compliance to Secure Operations
What starts as a single regulatory requirement, provide security updates, quickly expands into a full security architecture:
- Hardware root of trust
- Secure boot
- Firmware signing
- OTA update infrastructure
- Device identity
- PKI
- Secure communications
- Operational monitoring and incident response
Once these foundations are in place, organizations are not just compliant, they are set up for secure, scalable operations in the long term.
Key Takeaways
- The CRA applies to any product sold in Europe, regardless of where it’s made
- Manufacturers are responsible for cybersecurity for at least five years
- Vulnerability handling drives major architectural decisions
- Secure OTA updates are unavoidable and must be designed safely
- Device identity, PKI, secure boot, and signing are foundational, not optional
- CRA compliance will become a catalyst for stronger global product security
The Cyber Resilience Act may feel demanding, but it ultimately pushes the industry toward better security practices, for manufacturers, customers, and the broader ecosystem.
Learn more
Related resources
#KEYMASTER: Trusted Device Bootstrapping: The Foundation of Product Security