CRA Compliance and Firmware Security: What Embedded Teams Need to Know

Introduction

The EU Cyber Resilience Act (CRA) entered into force in December 2024, and its first enforcement deadline is now just months away. From 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities within 24 hours. Full compliance with all CRA requirements follows in December 2027. For embedded teams building connected products, these are not distant dates on a roadmap — they demand action now.

Among the CRA’s essential cybersecurity requirements, one is particularly relevant to firmware engineers: the obligation to protect the confidentiality of stored, transmitted or otherwise processed data by encrypting relevant data at rest or in transit by state-of-the-art mechanisms. In practical terms, this means unencrypted firmware sitting in flash memory is a compliance gap.

This article explains what the CRA’s encryption requirements mean for embedded development teams, how firmware encryption addresses them, and how IAR Systems’ ESecIP software combined with EPS Global’s secure provisioning infrastructure provides a clear, practical path to compliance.

The CRA at a Glance: Scope, Deadlines, and Penalties

The Cyber Resilience Act is the first EU-wide regulation to impose mandatory cybersecurity requirements on all products with digital elements — both hardware and software — placed on the EU market. Its scope is deliberately broad. If your product connects to a device or network, directly or indirectly, it almost certainly falls within scope. The only major exemptions are products already covered by sector-specific legislation, such as medical devices, automotive systems, and aviation equipment.

Key Deadlines

Product Categories

The CRA divides products into risk-based categories. Around 90% of products fall into the default category, where the manufacturer can self-assess conformity against the essential cybersecurity requirements. Class I products — such as password managers, network interfaces, and microcontrollers — must either apply a recognised cybersecurity standard or undergo a third-party assessment. Class II products, including operating systems and secure elements, require a mandatory third-party assessment.

Penalties

Non-compliance carries significant financial consequences. Fines can reach up to €15 million or 2.5% of global annual turnover, whichever is higher. Beyond fines, non-compliant products may be barred from carrying the CE marking, effectively locking them out of the EU market entirely.

The Encryption Requirement: What the CRA Actually Asks For

The CRA’s essential cybersecurity requirements include a clear directive on data confidentiality. Manufacturers must protect stored, transmitted, and processed data — whether personal or otherwise — using encryption and state-of-the-art mechanisms.

For firmware engineers, the phrase “data at rest” has a very specific meaning. When a microcontroller is powered off or idle, everything stored in flash memory — application code, configuration data, cryptographic keys, certificates, and any sensitive parameters — is data at rest. If that data is stored in plaintext, it is vulnerable to extraction, copying, and reverse engineering. An attacker with physical access to the device, or access to the programming supply chain, can read the contents of an unencrypted flash image.

How Firmware Encryption Addresses the Requirement

Firmware encryption provides a direct and demonstrable response to the CRA’s data-at-rest requirement. The operating model is straightforward: code and sensitive data are stored in flash memory in encrypted form. During runtime, they are decrypted into RAM by embedded libraries within the application. When the device is idle or powered off, everything in flash remains encrypted and unreadable.

This approach delivers several properties that align with the CRA’s broader requirements, beyond just data confidentiality.

Unique Per-Device Encryption

Each microcontroller receives a uniquely encrypted image, tied to the device’s own ID. The encryption keys are unique to each device and are themselves obfuscated within random data. This means that compromising the encryption on one device does not expose any other device in the fleet — a critical property for meeting the CRA’s requirement to minimise the impact of security incidents.

Anti-Cloning and Overproduction Prevention

Because each encrypted image is unique and bound to a specific device, it cannot be copied onto another microcontroller. Additionally, the provisioning system enforces a controlled production count — only the authorised number of devices can be programmed. This directly addresses the anti-cloning and anti-counterfeiting concerns that run through the CRA and adjacent IoT security legislation such as the ETSI EN 303 645 standard and the UK’s PSTI Act.

IP Protection

Encrypted firmware cannot be reverse-engineered or extracted in readable form. This protects the manufacturer’s investment in software development — often representing thousands of engineering hours — from theft or malicious modification.

Device Identity and Authentication

Firmware encryption systems can provision unique identity certificates and cryptographic keys alongside the encrypted code. These enable device authentication, which the CRA identifies as another essential requirement. A device that can cryptographically prove its identity is better equipped to participate in secure communication, cloud onboarding, and lifecycle management.

The Provisioning Side: From Encrypted Binary to Production Line

Encrypting firmware at the development stage is only half the story. The CRA’s requirements extend through the supply chain — meaning the manufacturing and programming process must also be secure. This is where secure provisioning becomes essential.

EPS Global operates 22 programming centres globally, all certified to ISO 27001 for information security management, alongside ISO 9001 and ISO 14001 certifications. The provisioning process uses Hardware Security Modules (HSMs) that are built to FIPS 140-2 Level 4 characteristics — meaning they are tamper-proof and physically protected against intrusion attempts.

How the Process Works

The manufacturer uses IAR’s Orbit tool to create a Provisioning Package (PPKG) file. This file is cryptographically locked to a single, specific HSM — no other HSM can decrypt or use it. The PPKG file is transferred to EPS Global’s programming centre, where the HSM reads each device’s unique ID, generates unique encryption keys and certificates, and provisions a uniquely encrypted binary image into each microcontroller.

The production count is controlled at the PPKG level. If the manufacturer authorises 10,000 units, the system will programme exactly 10,000 and refuse a 10,001st. A certified report confirms exactly how many devices were provisioned, providing an auditable trail that supports CRA compliance documentation.

Why This Matters for CRA Compliance

The CRA requires manufacturers to ensure security throughout the product lifecycle, including during manufacturing. An unencrypted firmware image passing through an untrusted or weakly secured production environment represents a vulnerability. Secure provisioning through a certified facility with HSM-based key injection closes this gap, ensuring that firmware is encrypted from the moment it leaves the development environment to the moment it is running on the target device. For a deeper look at how this works, see our guide on how to implement embedded security into your microcontrollers.

Beyond Encryption: Other CRA Requirements to Keep on Your Radar

Firmware encryption is a significant and necessary step toward CRA compliance, but it is not the entire picture. Embedded teams should be aware of several adjacent obligations that will come into force over the same timeline.

Vulnerability Reporting and SBOMs

From September 2026, manufacturers must report actively exploited vulnerabilities within 24 hours. To do this, you need to know exactly what components are in your product — which means having a Software Bill of Materials (SBOM) in place. The CRA explicitly requires SBOMs covering at least top-level dependencies. Without one, you cannot assess whether a newly disclosed vulnerability affects your product, and you cannot comply with the reporting obligation.

Secure Update Mechanisms

The CRA mandates that manufacturers provide security updates throughout the product’s expected lifetime, or for a minimum of five years. Over-the-air (OTA) update mechanisms must protect both the integrity and confidentiality of the firmware being delivered. This means the update path itself needs to be encrypted and signed, not just the firmware at rest.

Device Authentication and Access Management

Products must implement appropriate authentication mechanisms and access controls. This includes ensuring that devices ship without default passwords — a requirement shared with the ETSI EN 303 645 standard and the UK PSTI Act. Per-device provisioning of unique credentials during manufacturing is the most straightforward way to meet this requirement at scale.

Documentation and Conformity Assessment

Manufacturers must document their cybersecurity risk assessments, maintain a hardware and software bill of materials, and demonstrate conformity with the CRA’s essential requirements. For products in the default category (the majority), this is a self-assessment. For Class I and Class II products, third-party assessment may be required. In either case, being able to demonstrate that firmware is encrypted, keys are securely managed, and production is controlled provides concrete evidence of compliance.

Where to Start

For embedded teams looking to address the CRA’s encryption requirements, the practical starting point is simpler than it might appear.

First, assess which of your products fall within the CRA’s scope. If they connect to a network or another device, they almost certainly do. Determine which product category they fall into — default, Class I, or Class II — as this determines your conformity assessment route.

Second, identify what code and data in your firmware needs to be encrypted. This includes application code, sensitive configuration data, cryptographic keys, certificates, and any personal data stored on-device.

Third, explore IAR’s ESecIP as a path to implementation. The integration process is streamlined into three stages: import the decryption libraries into your project, create a configuration file defining what to encrypt, and send the encrypted output to EPS Global for secure provisioning onto the microcontroller. The solution works with virtually any microcontroller and any IDE, so it fits into your existing development workflow without requiring a platform change.

Finally, engage early with EPS Global’s security specialists. Malcolm Kitchen, Global Embedded Security Specialist at EPS Global, is available to guide teams through the entire process — from initial design decisions through to high-volume production, where millions of devices can each receive unique encrypted images.

Conclusion

The EU Cyber Resilience Act is not a future problem. Reporting obligations begin in September 2026, and full enforcement follows in December 2027. For embedded teams, one of the most tangible and achievable steps toward compliance is encrypting firmware at rest — ensuring that code and data stored in flash memory is protected using state-of-the-art mechanisms, exactly as the regulation requires.

The combination of IAR’s ESecIP software and EPS Global’s HSM-based provisioning infrastructure provides a proven, production-ready approach. It delivers unique per-device encryption, anti-cloning protection, controlled production counts, and device identity provisioning — all from within your existing development environment, without requiring a redesign.

For most embedded teams, achieving CRA-compliant firmware encryption is a matter of weeks, not months. The tools exist, the process is defined, and expert support is available. The question is not whether to act, but how quickly you can begin.