Introduction
The Cyber Resilience Act (CRA) is an EU regulation aimed at improving cybersecurity and digital resilience for all products with digital elements, including IoT devices, medical devices, and industrial systems. It sets common standards for hardware and software products that connect directly or indirectly to a device or network.
Under the CRA, manufacturers must ensure security throughout the product lifecycle (Article 13) by meeting requirements such as reporting security incidents and providing automatic security updates, highlighting the critical importance of secure coding and development practices in these diverse digital products.
Non-compliance with CRA is costly, with potential fines up to €15 million or 2.5% of global turnover. This underscores the need for strong cryptographic controls, secure code signing, and end-to-end software supply chain integrity to ensure continuous CRA compliance and digital trust.
CRA-aligned code signing, defined: a code signing program where each control, key storage, access separation, timestamping, revocation, audit logging, maps to a specific CRA article, with a clear line drawn between what the regulation explicitly mandates and what is a strongly recommended practice for meeting its broader security-by-design objectives, backed by evidence a conformity assessment can actually verify.
Key Takeaways
- Not every good code signing practice is a literal CRA mandate; several, like MFA on signing access or separate test/production keys, are strongly recommended ways to meet a broader risk-based obligation the CRA does state explicitly. The distinction matters for how you document compliance.
- This page maps individual CRA-aligned code signing practices to specific articles, requirement by requirement. For the dual-regime architecture combining CRA with CA/Browser Forum ballot requirements and a consolidated action checklist, see CRA Compliance Architecture for Secure Code Signing.
- The CA/Browser Forum’s HSM mandate (FIPS 140-2 Level 2 or higher, effective June 1, 2023) applies to all publicly trusted code signing keys regardless of CRA scope; CRA compliance doesn’t replace that baseline, it sits on top of it.
- A broken chain of trust doesn’t require a stolen key: the BootHole vulnerability compromised secure boot through a flaw in GRUB2’s signature verification logic itself, with valid keys and secure boot enabled throughout.
What Is Code Signing?
Code signing is like a digital stamp that proves software or updates come from a trusted source and haven’t been changed. It works using a pair of special keys, one private and one public, that help verify the software’s identity and make sure it’s safe to use.
There are two main types of code signing certificates:
- Standard certificates: These provide basic proof that software is from the right publisher and hasn’t been altered.
- Extended Validation (EV) certificates: These go a step further by requiring stricter identity checks and extra security measures, like storing keys on secure hardware. Products following the Cyber Resilience Act often use EV certificates because they offer higher trust and reduce warnings when users install the software.
In short, code signing helps users trust software by confirming where it comes from and ensuring it’s safe and untampered.
How Code Signing Works
- Creating a Unique Fingerprint: A cryptographic hash (such as SHA-256) is generated from the software. This hash acts as a unique digital fingerprint; if even a single byte changes, the fingerprint changes too.
- Generating the Digital Signature: The publisher encrypts that hash using their private key, creating a digital signature that’s unique to both the software and the signer.
- Attaching Proof of Identity: The digital signature and a code signing certificate (which includes the publisher’s public key and verified identity) are bundled with the software.
- Verifying the Code: When users download or install the software, their system uses the public key to verify the signature. If it matches the software’s current hash, the code is confirmed as genuine and untampered.
Why Code Signing Matters for CRA Compliance
Code signing plays a vital role in meeting CRA requirements by ensuring that software is authentic, trusted, and protected from tampering. It directly supports several key areas of compliance:
- Security in Supply Chain: Code signing is vital for CRA compliance as it directly strengthens supply chain security by verifying the authenticity and integrity of every software component, including dependencies prone to tampering or malicious insertion. This ensures software delivered to users is trusted and tamper-free, addressing critical CRA requirements for software integrity, traceability, and supply chain risk reduction.
- Integrity Protection: The CRA requires that software, commands, and configurations remain secure from unauthorized changes (Article 6 and Annex I specify technical cybersecurity requirements). Code signing fulfils this by using cryptographic signatures to prove that the software hasn’t been modified since it was signed, safeguarding both developers and end users from compromised code.
- Secure Boot: Under the CRA, devices must verify the authenticity of software at every stage of startup (Articles 6 and 13, supported by Annex I). Secure boot mechanisms depend on code signing to establish a chain of trust, beginning with hardware-based roots and extending through each layer of firmware and software that loads during boot.
- Secure Updates: To comply with CRA standards, devices must only accept authentic and trusted software updates (Articles 5, 6, and 13). Code signing ensures that updates are verified before installation, protecting systems from malicious or unauthorized modifications.
- Auditability and Traceability: CRA compliance requires organizations to demonstrate control and accountability over software signing processes (Articles 13 and 31). Code signing systems generate comprehensive audit trails that record who signed what, when, and with which keys, providing clear evidence during CRA conformity assessments.
Secure Boot: Building the Chain of Trust
Secure boot is a cornerstone of CRA compliance, ensuring that only authenticated and unmodified code runs every time a device powers on. It establishes a chain of trust, a step-by-step validation process that begins in hardware and extends through every software layer of the system.
- Hardware Root of Trust (RoT): The secure boot process begins with the hardware root of trust, usually an immutable boot ROM embedded directly into the device’s silicon. Real-world implementations of hardware root of trust include technologies like Trusted Platform Module (TPM) and Secure Enclave. These modules store and protect hardcoded public key hashes or root signing keys that cannot be altered after manufacturing. When the device starts, this ROM or secure module is the first to execute, anchoring the trust chain for everything that loads next.
- Bootloader Verification & Cryptographic Agility: After secure boot begins, the boot ROM verifies the bootloader’s digital signature using a trusted public key stored in secure hardware (e.g., TPM or Secure Enclave). If verification fails, the device halts or enters recovery mode to block unauthorized code. Once validated, the bootloader checks subsequent software components like secondary bootloaders or the OS kernel. These stages can be updated to enhance security or adopt new cryptographic algorithms without breaking the chain of trust.
- Operating System and Application Verification: After the kernel and core OS components are loaded, secure boot continues its validation chain. It verifies the integrity of root filesystems, device drivers, and user-level applications, executing them only if their cryptographic signatures are valid. In more advanced systems, this protection can extend to firmware, encrypted filesystems, and individual applications, ensuring trust is preserved at every layer of operation.
- Real-World Implementation: In practice, secure boot uses industry-standard cryptography, commonly RSA or ECC for digital signatures and SHA-256 for hashing. Each stage of the boot process is signed by a trusted authority, and any update or configuration change must be validated before execution. Many modern devices also implement certificate-based key hierarchies and leverage Hardware Security Modules(HSMs) to store private keys safely.
If this chain of trust is ever broken, for example, if a leaked or unpatched key lets an attacker slip in a malicious bootloader, secure boot protections can fail entirely. The “BootHole” vulnerability is a clear example where attackers exploited flaws in GRUB2’s signature checks to take control of devices, despite secure boot being enabled. This shows why CRA-covered devices must use strong cryptography, protect signing keys, and keep security patches current to avoid these risks.
The Crucial Role of HSMs
Protecting the private keys used for code signing is essential. If these keys are compromised, attackers could issue malicious software that appears legitimate. To prevent this, code signing keys must be stored in HSMs, tamper-resistant devices that securely generate, store, and use cryptographic keys without exposing them to software or external access.
Since June 1, 2023, the CA/Browser Forum mandates that all code-signing private keys be stored on hardware certified to FIPS 140-2 Level 2 or higher (or an equivalent standard) for obtaining trusted code-signing certificates. Many modern HSMs also meet the newer FIPS 140-3 standard, offering a future-proof option. Additionally, these HSMs often support remote and cloud-based signing with secure attestation, enabling distributed teams to safely manage cryptographic keys without compromising security. This enhances software supply chain security and aligns with up-to-date cybersecurity standards.
Benefits of HSMs include:
- Non-extractable keys protected inside the HSM.
- Tamper detection with automatic key destruction upon intrusion attempts.
- Role-based access control, ensuring only authorized personnel have access to keys.
- Immutable audit logs of all cryptographic operations.
Best Practices for CRA-Aligned Code Signing
The table below separates what the CRA actually mandates from what’s a strongly recommended practice for meeting it, since conflating the two is a common documentation mistake during a conformity assessment.
| Practice | Status | CRA Basis |
|---|---|---|
| Access control and secure key management | Required | Article 13(1)(c) |
| Specific mechanism: MFA or role-based access | Recommended (not a specific CRA mandate) | Supports Article 13(1)(c)’s general obligation |
| Timestamping signed artifacts | Recommended | Supports Article 6 / Annex I traceability objectives |
| Separate test and production signing keys | Recommended (not explicitly specified) | Supports Article 13’s risk-based environment separation |
| Tamper-proof audit logging and technical documentation | Required | Article 31 |
| Pre-signing malware/vulnerability scanning | Required (products must ship without known exploitable vulnerabilities) | Annex I |
| Periodic key rotation | Recommended | Supports Article 13(1)(c) and Annex I Part II vulnerability handling |
| Automated signing in controlled CI/CD pipelines | Required (rigorous control of production/update processes) | Article 13(1)(b) |
| Documented, tested revocation procedure | Required (prompt incident response) | Article 13(1)(e) |
Renewal Cadence Under Current Ballot Rules
Independent of CRA itself, the CA/Browser Forum has cut the maximum validity of publicly trusted code signing certificates to 460 days for certificates issued on or after March 1, 2026. Whatever CRA-aligned key management process you build should assume renewal roughly every 15 months, not the 39-month cadence many teams were used to, since a certificate lapse blocks signing new releases regardless of how CRA-compliant the rest of the pipeline is.
How Encryption Consulting Can Help
Encryption Consulting offers CodeSign Secure, a comprehensive, enterprise-grade code signing solution designed to help organizations meet strict cybersecurity requirements like those mandated by the EU CRA.
CodeSign Secure addresses key CRA compliance challenges by providing:
- HSM-backed key protection: Private signing keys remain securely stored within FIPS 140-2 Level 3 certified HSMs, ensuring zero risk of key exposure or theft, fully aligning with industry requirements and best practices essential for CRA compliance.
- Automation and CI/CD integration: The solution seamlessly integrates with popular DevOps pipelines and automated build workflows, ensuring that security never impedes development velocity or innovation.
- Policy enforcement and granular access control: Organizations can define and enforce detailed security policies, automate signing permissions, and control signing lifecycle management across teams, supporting CRA’s audit and accountability demands.
- Comprehensive audit trails: Detailed event logging, multi-tier approvals, and quorum controls ensure every signing action is tracked, validated, and compliant, simplifying CRA conformity assessments.
- Scalable deployment models: Encryption Consulting supports cloud, hybrid, and on-premises deployments, enabling organizations of all sizes to adopt robust code signing without excessive infrastructure overhead.
- Supporting hybrid signing algorithms (traditional & PQC): We enable the use of both traditional cryptographic algorithms like RSA & ECC (ECDSA) and post-quantum cryptography (PQC) algorithms like ML-KEM, ML-DSA, LMS and more in hybrid signing workflows. This ensures long-term digital signature resilience against emerging quantum threats.
An organisation producing IoT devices faced challenges with CRA compliance, particularly in managing code signing keys securely and proving traceability for every release. We addressed these issues by integrating HSMs in their environment for key protection, multi-factor authentication for access, and automated code signing in their CI/CD pipeline. Tamper-proof audit logging was also enabled to satisfy CRA’s strict traceability and documentation requirements, while strong key revocation procedures ensured any compromised keys could be rapidly invalidated, critical for CRA vulnerability handling and incident response.
Frequently Asked Questions
Does the CRA specifically require code signing?
The CRA doesn’t name “code signing” as a line-item requirement, but its integrity, secure-update, and traceability obligations under Articles 6, 13, and Annex I are difficult to satisfy without it in practice. Code signing is the practical mechanism most manufacturers use to meet those obligations, not a separately named mandate.
Is multi-factor authentication on signing access a CRA requirement?
Not explicitly. Article 13(1)(c) requires appropriate access control and secure key management generally; MFA is a strongly recommended way to satisfy that obligation, not a named requirement itself.
How is this different from Encryption Consulting’s other CRA compliance article?
This page maps individual code signing practices to specific CRA articles, one requirement at a time. CRA Compliance Architecture for Secure Code Signing covers the broader architecture, including how CRA obligations interact with separate CA/Browser Forum certificate rules on the same signing infrastructure, and provides a consolidated action checklist.
Can a broken chain of trust happen without a stolen signing key?
Yes. The BootHole vulnerability compromised secure boot through a flaw in how GRUB2 checked signatures, not through key theft. Keys remained valid and secure boot remained enabled throughout; the verification logic itself was the weak point.
Conclusion
Complying with the EU CRA is about building trust in every line of code your organization delivers. Code signing, combined with secure boot and HSMs, ensures only verified, tamper-free software reaches users and devices. Organizations are advised to perform a CRA gap analysis or audit their current code signing workflows to identify and address compliance gaps.
Properly implemented CRA compliance reduces supply chain risks, enables secure updates, and fosters user trust, while protecting signing keys, maintaining audit trails, and integrating code signing into development workflows strengthens security posture and ensures full alignment with CRA requirements.
With Encryption Consulting’s CodeSign Secure, you can automate and simplify compliance, protect your software supply chain, and keep innovation moving safely. In today’s connected world, secure code signing isn’t just a compliance step; it’s how you prove your software can be trusted.
