Cyber Resilience Act: Retrofitting Devices with Secure Storage
Since 11 September 2026, manufacturers of products with digital elements have had to report actively exploited vulnerabilities and severe incidents under the EU Cyber Resilience Act (CRA). From 11 December 2027, every such product placed on the EU market must also meet the CRA’s essential cybersecurity requirements. This includes devices built to designs that are already in production today.
For many manufacturers of industrial electronics, this raises a practical question: does an existing controller, gateway or HMI need a costly redesign, or can its security be raised to the required level? In many Linux-based systems, the storage medium is the place where security can be added without touching the main board. Secure storage turns memory from a passive component into a security anchor.
What the Cyber Resilience Act requires from manufacturers
The CRA, Regulation (EU) 2024/2847, entered into force on 10 December 2024. It covers hardware and software with digital elements, from industrial controllers, PLCs and gateways to sensors, HMIs and other connected embedded systems. Manufacturers have to address cybersecurity across the entire product lifecycle:
- Security by design: assess cybersecurity risks during development and protect against unauthorised access, manipulation and data disclosure.
- Vulnerability handling: identify and fix vulnerabilities, accept vulnerability reports and provide security updates throughout the support period.
- Documentation: carry out a cybersecurity risk assessment and keep technical documentation that demonstrates compliance.
- Reporting: notify actively exploited vulnerabilities and severe incidents, with an early warning within 24 hours and a notification within 72 hours.
- Conformity assessment and CE marking before a product is placed on the EU market.
Breaches of the essential requirements can be fined up to 15 million euros or 2.5 percent of total worldwide annual turnover, whichever is higher. For a general overview of who is affected, see our article Cyber Resilience Act: Who is affected by CRA, and what needs to be done now.
Key CRA dates at a glance
| Date | What applies |
|---|---|
10 December 2024 | The CRA enters into force. |
11 September 2026 | Reporting obligations apply, including for products already on the market. |
11 December 2027 | All essential requirements apply to products placed on the EU market. |
Does the CRA apply to devices that are already on the market?
Products placed on the market before 11 December 2027 only have to meet the CRA’s requirements if they are substantially modified after that date. The reporting obligations, however, apply to them as well. What matters is each individual unit: a controller that is still produced and sold after 11 December 2027 must comply, even if its design is ten years old.
This is where retrofitting comes in. It is relevant for every product line that will still be sold once the transition period ends.
Why secure storage matters for CRA compliance
The CRA is risk-based. It does not require a specific technology. It requires a level of cybersecurity appropriate to the risks, as set out in Annex I. Secure storage is one of the engineering controls a manufacturer can use to show that these risks are addressed, especially where cryptographic keys, firmware, configuration and credentials need protection.
| CRA requirement (Annex I, Part I) | How secure storage contributes |
|---|---|
Protection against unauthorised access | Hardware-based access control keeps keys, passwords and security parameters out of reach of ordinary software. |
Confidentiality of stored data | Data and keys are encrypted at rest by the storage controller, not in ordinary application memory. |
Integrity of programs and configuration | Protected partitions prevent firmware, boot data and security settings from being altered. |
Limited attack surface | Security-critical assets stay isolated from the operating system and applications. |
Reduced impact of incidents | An attacker who takes over the application cannot simply extract the device identity or signing keys. |
Security updates | Protected verification keys prevent the installation of manipulated firmware. |
The important distinction: secure storage does not make a product CRA compliant on its own. It provides a hardware anchor that supports the manufacturer’s risk assessment and technical measures. Vulnerability handling, security updates, documentation and reporting remain processes that every manufacturer has to establish.
Secure boot and secure storage: building a chain of trust
Secure boot proves that the software is authentic. Secure storage protects the secrets needed to establish and maintain that trust. Together they form a chain from the hardware to the application:
Secure storage holds the keys that the whole chain of trust depends on.
- The device holds a protected cryptographic key as its trust anchor.
- The bootloader verifies the firmware signature with this key.
- Only authentic firmware is executed.
- Before an update is installed, the device verifies its signature.
- Private keys remain inaccessible to normal application software.
If the Linux application is compromised, the attacker still has a much harder time extracting the device identity or signing credentials. That is considerably stronger than encrypting a file on ordinary flash memory, where the key is often stored on the same medium as the data.
Example: retrofitting a Linux-based industrial controller
Many industrial controllers, gateways and HMIs run Linux on an ARM processor and boot from a standard microSD card, Raspberry Pi-based systems being a typical example. On such a card, the operating system, firmware, configuration and credentials are usually unprotected. Anyone with physical access can copy, read or replace them.
Retrofit at storage level instead of a controller redesign.
| Standard microSD card | Swissbit Security Upgrade Kit | |
|---|---|---|
Data at rest | Unencrypted | AES-256 self-encrypting |
Access | Open to anyone who removes the card | Hardware-based access control with protection profiles per partition |
Boot process | Software is not verified | Secure boot, open-source example based on U-Boot |
Memory | Often consumer grade | Industrial-grade pSLC, operating temperature −40 °C to 85 °C |
The Swissbit Security Upgrade Kit (PS-66u) is designed for exactly this case. It uses the standard microSD form factor, so it fits into existing devices. For various Raspberry Pi models, Swissbit provides an open-source secure boot example based on U-Boot with full source code, which can be ported to other Linux systems. Tools for Linux and Windows cover security configuration, access control, firmware upgrades and lifetime monitoring. The kit is available with 16 to 64 GB and is made in Germany.
Instead of redesigning the controller, manufacturers add security at the storage level and document it in their CRA risk assessment. In its product material for the kit, Swissbit refers to the CRA, IEC 62443-4-2 and EN 303 645, among others.
Which Swissbit solution fits which case
| Situation | Swissbit solution | Contribution |
|---|---|---|
Existing Linux device that boots from microSD | Retrofit with encryption, access control and secure boot | |
New designs or devices with an SD or microSD slot | Protected storage, access protection and secure key storage | |
Device identity and key management | Tamper-proof key storage and device authentication |
Five steps manufacturers should take now
- List all products that will still be placed on the EU market after 11 December 2027.
- Check your reporting process: the 24-hour early warning has applied since 11 September 2026.
- Carry out a risk assessment for each product and identify the security-critical assets: keys, firmware, configuration, credentials and logs.
- Decide per product line whether to retrofit at storage level or to redesign with security by design.
- Document the chosen measures in the technical documentation for the conformity assessment.
Cyber Resilience Act: frequently asked questions
No. The CRA does not prescribe any specific technology. Secure storage is a technical measure that helps to meet several requirements of Annex I. Compliance also requires vulnerability handling, security updates, documentation and reporting.
No. Products placed on the market before 11 December 2027 only have to comply if they are substantially modified afterwards. Units sold after that date must comply, and the reporting obligations have applied to all products in scope since 11 September 2026.
A protected hardware component that holds the cryptographic keys on which the trust in a device is built. Secure boot and secure updates rely on it, because ordinary software can neither read nor change these keys.
Yes. Swissbit provides an open-source secure boot example based on U-Boot for various Raspberry Pi models, designed for use with the Security Upgrade Kit and portable to other Linux systems.
Since 11 September 2026. Actively exploited vulnerabilities and severe incidents require an early warning within 24 hours and a notification within 72 hours.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal of the European Union, 20 November 2024, eur-lex.europa.eu
- European Commission: Cyber Resilience Act, digital-strategy.ec.europa.eu
- Swissbit: Security Upgrade Kit, product information, swissbit.com
Meet us at electronica 2026
Munich, 10 to 13 November, Hall C6, Booth C6.261. See the Security Upgrade Kit live or talk to our experts about your CRA retrofit.