On December 10, 2024, the European Union’s Cyber Resilience Act (CRA) entered into force as Regulation (EU) 2024/2847. For the first time in history, cybersecurity requirements for products with digital elements became legally binding across the EU’s single market, not a voluntary framework, but a market access requirement backed by fines of up to 15 million euros or 2.5% of global annual turnover, whichever is higher.
As of September 11, 2026, manufacturers, importers, and distributors must actively report exploited vulnerabilities and severe security incidents to ENISA and national CSIRTs. For organizations that design, manufacture, or distribute connected devices, the CRA redefines what it means to ship a product.
This blog breaks down what the CRA specifically demands from a code signing architecture, maps those requirements to the technical controls needed to satisfy them, and explains why organizations that have not yet addressed their signing infrastructure are running out of time to do so before each compliance deadline passes.
What the Cyber Resilience Act Actually Requires
The CRA applies to any “product with digital elements” placed on the EU market, a category broad enough to contain virtually every connected hardware device and the software running on it. Routers, smart home devices, medical equipment, industrial controllers, laptops, servers, IoT sensors, and the firmware that runs on all of them are in scope.
The regulation is built on a foundational principle: security by design. Products must be designed, developed, and maintained in ways that ensure their cybersecurity across their expected lifetime. This is not a one-time certification, it is a continuous obligation that persists for a minimum support period of five years under Article 13(8), or the expected product lifetime if shorter.
For code signing specifically, the CRA establishes several obligations that flow directly from its core requirements:
Software and firmware integrity must be protected throughout the supply chain and the product’s operational life. Every firmware image shipped with a product and every update delivered to it must be verifiable as authentic and unmodified. This requires a cryptographic signing infrastructure with demonstrable controls over who can sign, what can be signed, and what audit trail exists.
Secure update mechanisms are explicitly required and as per Article 13, it mandates that manufacturers ensure security updates can be applied automatically and include mechanisms to verify update authenticity. An update system without cryptographic signature verification does not satisfy this requirement.
Coordinated vulnerability disclosure under Article 14 means manufacturers must have the operational infrastructure to identify which product lines are affected by a given vulnerability, notify ENISA within 24 hours of becoming aware of an actively exploited vulnerability, and deliver a full triage report within 72 hours.
Machine-readable SBOM is required, documenting all software components included in the product. For signing purposes, this means the provenance of every firmware component must be traceable and documentable.
Mapping CRA Annex I to Technical Signing Controls
The CRA’s Annex I sets out the specific security requirements that products with digital elements must meet. For firmware and embedded software, these requirements translate directly to concrete technical controls.
| CRA Annex I Requirement | Article Reference | Required Technical Control |
|---|---|---|
| Security by design: address risks appropriate to intended use | Art. 1 | Secure Boot Chain: immutable BootROM/OTP anchors with device-unique keys; each boot stage cryptographically verified before execution |
| Data and code integrity: protect integrity of stored data, transmitted data, and executable programs | Art. 2(f) | Firmware Signing: HSM-bound keys sign every firmware artifact; SUIT/FIT/UEFI manifests provide proof of origin and tamper evidence |
| Access control: protect from unauthorized access | Art. 2(d) | M-of-N Signing Quorum: no single person signs production firmware alone; enforced through signing platform RBAC |
| Incident mitigation: reduce the impact of security incidents | Art. 2(k) | Per-Product Key Isolation: one breach affects one product, not an entire portfolio |
| No known vulnerabilities: products must ship without known exploitable vulnerabilities | Art. 2(a) | Pre-signing vulnerability scanning: firmware artifacts scanned against known CVE databases before signing approval |
| Minimized attack surface: limit all external interfaces | Art. 2(j) | Device Attestation: DICE/TPM/PSA/TEE provide runtime proof that only verified, unmodified code is executing |
Key Isolation Architecture
The most operationally significant architectural change the CRA demands from most organizations is the transition from shared signing key infrastructure to per-product key isolation.
The shared key model is the default for organizations that adopted code signing without formal governance. A single signing key, perhaps stored on a USB token or a build server, is used to sign firmware for every product. It is simple to manage and works technically. Under the CRA, it is a structural compliance failure.
Here is why the distinction matters:
Shared Key Architecture
All product lines share a single signing key. If that key is compromised:
- Every product signed with it is simultaneously affected
- The blast radius covers the entire portfolio
- Article 14’s 24-hour ENISA notification must cover every affected product at once, with no ability to scope the impact
- Compliance answer: impossible within 24 hours without per-product records
Per-Product Key Architecture
Each product line has its own dedicated key, generated inside and stored in a separate HSM partition. If one key is compromised:
- Only the product associated with that key is affected
- The blast radius is contained to a single product line
- Article 14’s notification covers a defined scope that can be answered precisely and quickly
- Compliance answer: the audit trail immediately identifies affected products, signing events, and firmware versions
For a manufacturer with four product lines, the shared key model means a potential market withdrawal proceedings, and remediation obligations across every product at once. Per-product isolation means one product is affected, three continue operating normally, and the notification is filed with precision rather than panic.
The transition to per-product key isolation also satisfies the CRA’s supply chain accountability requirements under Article 13 §5. Conformity assessment documentation for CE marking will need to demonstrate that each product’s signing key has its own governance, access controls, and audit trail.
Vendor-Neutral Signing
One of the practical challenges for manufacturers building toward CRA compliance is the diversity of silicon architectures in their product portfolios. A company making both a consumer router (ARM TrustZone), a smart appliance (MCU/IoT), an industrial controller (RISC-V), and a server product (x86/UEFI) faces four distinct platform ecosystems, each with different signing toolchains, different firmware formats (SUIT, FIT, UEFI manifests), and different hardware root of trust mechanisms (DICE, TPM, PSA, TEE).
The CRA does not care about this complexity and requires consistent, auditable controls across every product in scope. A vendor-neutral signing architecture resolves this by decoupling the platform-specific signing toolchain from the policy engine that governs it. Rather than building four separate signing workflows with four separate key management practices and four separate audit trails, a centralized policy engine applies consistent governance to all platform types, while platform-specific integrations handle the format and protocol details for each.
The architecture layers work as follows:
Hardware Root of Trust layer: FIPS 140-2 certified HSMs provide the key storage and signing operations for all platforms. ML-DSA and SLH-DSA support ensures quantum-resistant signing is available from the same infrastructure used for classical algorithms.
Centralized Policy Engine: HSM-backed signing governance applies consistent RBAC, M-of-N quorum requirements, and approval workflows across all product lines and all platforms. A change to signing policy takes effect everywhere simultaneously.
CI/CD and Audit Layer: Build-time signing, attestation, and immutable log generation happen at the pipeline stage, producing the artifact hash, key ID, approver identity, pipeline stage, and timestamp that CRA’s audit requirements demand.
Compliant Outputs: Each platform receives the signed firmware in its native format with the appropriate manifest type, SUIT for IoT/MCU, FIT for ARM/embedded Linux, UEFI manifest for x86 server platforms, and RISC-V specific attestation. The ENISA reporting workflow receives structured, SRP-ready output that directly supports the 24-hour notification requirement.
This architecture satisfies the CRA’s requirement for consistent controls across product lines without requiring a separate compliance program for each silicon platform.
How Encryption Consulting’s CodeSign Secure Helps
CodeSign Secure is Encryption Consulting’s enterprise-class code signing management platform, designed to provide the infrastructure controls that CRA compliance requires across every dimension covered in this blog.
HSM-Backed Key Management: CodeSign Secure stores all private signing keys inside FIPS 140-2 Level 3 certified Hardware Security Modules, integrating with Thales Luna, Entrust nCipher, Utimaco, Securosys, and cloud HSMs from AWS and Azure. Per-product key isolation is enforced at the HSM partition level: each product line receives its own dedicated key, generated inside hardware and never exported. This directly satisfies the CRA’s Hardware Root of Trust requirement under Article 13(1)(c) and the per-product isolation requirement under Article 13 §5.
M-of-N Signing Quorum and RBAC: The platform’s Role-Based Access Control model enforces M-of-N approval requirements for production firmware signing. No single individual can initiate and approve a signing operation. Signing requests, approvals, and rejections are all logged. The RBAC configuration itself is auditable and version-controlled, providing the documented signing policy that CRA conformity assessments require.
Immutable Audit Logging: Every signing event in CodeSign Secure generates an immutable log entry capturing the artifact hash, the key identifier, the certificate used, the approving identity, and the RFC 3161 timestamp. Logs are centralized, separately stored from the signing infrastructure.
Cross-Platform Firmware Format Support: CodeSign Secure supports signing of firmware artifacts across the full range of formats that a diverse product portfolio requires: .bin, .img, .hex, .fw, .dfu, and .efi, satisfying the CRA’s requirement for consistent controls across product lines without rebuilding the signing infrastructure for each platform.
Post-Quantum Cryptography Support: CodeSign Secure v3.02 supports production-grade ML-DSA (FIPS 204, at ML-DSA-44, ML-DSA-65, and ML-DSA-87 security levels) and SLH-DSA (FIPS 205) as detachable signatures alongside classical algorithms. For manufacturers building products with five-plus year CRA support obligations, PQC signing today is the architecture that protects against the HNDL threat before a CRQC arrives.
CI/CD Pipeline Integration: CodeSign Secure integrates with Azure DevOps, Jenkins, GitLab CI, and other major pipeline platforms through API and command-line interfaces. Firmware signing is a controlled, policy-enforced stage in the build pipeline, not a manual step.
Conclusion
The Cyber Resilience Act has moved firmware signing from a security best practice to a legal obligation with teeth. The first enforcement milestone, Article 14’s incident and vulnerability reporting requirements, is active from September 11, 2026. Full compliance including CE marking is required by December 11, 2027. And the infrastructure needed to support both of those deadlines, per-product key isolation, HSM-backed signing, M-of-N quorums, 10-year audit trails, and vulnerability-gated signing workflows, takes 12 to 18 months to design and implement properly.
The organizations that are best positioned for CRA compliance are not the ones that will start building their signing architecture when December 2027 arrives. They are the ones building it now, before the September 2026 reporting obligations expose the gaps in their current infrastructure.
At Encryption Consulting, CodeSign Secure provides the signing infrastructure that CRA compliance demands, from HSM-backed key isolation to immutable audit trails to post-quantum signing that addresses the HNDL threat within the CRA’s support window.
