Building Digital Trust Through CRA-Aligned Code Signing

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. 

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 

• Restrict private key access to authorized personnel through strong access controls: This is aligned with CRA Article 13(1)(c), manufacturers have an obligation to implement appropriate access control and secure management of cryptographic keys. While the CRA does not explicitly mandate multi-factor authentication or role-based access, these practices are strongly recommended to meet the general security objectives. 
• Include timestamping with signatures to preserve validity beyond certificate expiration: In line with CRA requirements for software integrity and traceability as outlined in Article 6 and Annex I, maintaining timestamping helps ensure that the authenticity of code signatures remains verifiable even after certificate expiry, supporting compliance with traceability objectives. 
• Maintain separate cryptographic keys for testing and production environments: Article 13 requires manufacturers to implement risk-based separation of environments to mitigate security risks. While the CRA does not explicitly specify separate keys, this is a recommended best practice consistent with CRA goals to reduce attack surfaces and environment-specific risks. 
• Implement tamper-proof audit logging and detailed technical documentation: Article 31 mandates maintaining comprehensive technical documentation, including audit trails. Maintaining secure, immutable logs of code signing activities supports traceability and accountability in conformity assessments. 
• Integrate malware and vulnerability scanning prior to code signing: Annex I requires that products be delivered without known exploitable vulnerabilities or malware. Incorporating automated scanning into the signing process helps manufacturers comply with this essential cybersecurity requirement and supports secure product delivery. 
• Rotate cryptographic keys regularly and manage key lifecycle securely: This is aligned with CRA Article 13(1)(c) and vulnerability handling requirements in Annex I Part II, Effective key lifecycle management, including periodic rotation, reduces risks associated with key compromise across the product lifecycle. 
• Integrate automated code signing into controlled CI/CD pipelines: Article 13(1)(b) obligates manufacturers to ensure rigorous control and security of software production and update processes. Automating code signing within controlled build and deployment pipelines helps enforce policies and maintain supply chain security. 
• Establish clear and prompt revocation procedures for compromised keys: Article 13(1)(e) requires manufacturers to respond promptly to security incidents, including revocation and mitigation. Having clear revocation mechanisms ensures rapid invalidation of compromised code signing keys, preventing unauthorized or malicious software distribution. 

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. 

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.