CRA Compliance Architecture for Secure Code Signing

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.

Code signing compliance, defined: operating a signing architecture that simultaneously satisfies two separate regimes governing the same signing operation, the EU Cyber Resilience Act’s product-level integrity and disclosure obligations, and the CA/Browser Forum’s certificate lifecycle rules for validity, revocation, key protection, and timestamping, both enforced through HSM-backed keys, documented approval workflows, and auditable logs.

Key Takeaways

• Two separate compliance regimes apply to the same signing operation: the CRA (EU law, product-focused) and the CA/Browser Forum Baseline Requirements (industry rules, certificate-focused). A compliant architecture satisfies both, not one or the other.
• CRA dates: force December 10, 2024; vulnerability/incident reporting from September 11, 2026; full compliance and CE marking by December 11, 2027.
• CA/Browser Forum dates: private keys in FIPS 140-2 Level 2+/Common Criteria EAL4+ hardware since June 2023; revocation triggers broadened to cover Suspect Code under Ballot CSC-22 (April 2024); Timestamp Authority keys required in offline hardware crypto modules since April 2025; 460-day maximum certificate validity under Ballot CSC-31 for certificates issued on or after March 1, 2026.
• Confirmed key compromise must be revoked within 24 hours under the Code Signing Baseline Requirements; a subscriber-requested revocation must be honored within one business day.
• For the full history of the certificate validity change itself, see Understanding the New Code-Signing Certificate Validity Change; this article focuses on the compliance architecture both regimes require, not the ballot history in isolation.

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

The Other Half of Code Signing Compliance: CA/Browser Forum Requirements

The CRA governs the product; it says nothing about the certificate the signing key is issued under. That’s the CA/Browser Forum’s Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates, and any organization signing with a publicly trusted certificate has to satisfy both regimes at once, on the same signing operation.

These are not recommendations; each carries a specific effective date and ballot reference:

Effective Date	Ballot / Change	Requirement
June 1, 2023	CA/B Forum key protection update	Code signing private keys MUST be generated and stored in a hardware crypto module meeting FIPS 140-2 Level 2 or Common Criteria EAL4+; software-based key generation is no longer permitted
April 2024	Ballot CSC-22	Revocation triggers broadened beyond confirmed key compromise to also cover Suspect Code and malicious or unauthorized signing activity
June 2024	CA/B Forum Signing Service requirements	Third-party Signing Services that manage keys on a subscriber’s behalf MUST undergo formal conformity assessment audits (e.g., WebTrust for CAs, ETSI EN 319 401)
April 2025	CA/B Forum timestamping update	Timestamp Authority private keys MUST be protected in offline Hardware Crypto Modules
March 1, 2026	Ballot CSC-31	Maximum code signing certificate validity reduced to 460 days for certificates issued on or after this date, down from 39 months

Revocation

Under Baseline Requirements §4.9.1.1, a CA must revoke a code signing certificate within 24 hours of confirming the private key was compromised. A subscriber-requested revocation, or a report that the original request was unauthorized, must be honored within one business day under §4.9.1.2. Since Ballot CSC-22, that same 24-hour clock also applies once Suspect Code, not just a confirmed key compromise, is identified as tied to the certificate. Operationally, this means an organization needs to know, within hours, which certificate signed which artifact, so it can request revocation before the CA’s own detection mechanisms do it for them at a less convenient time.

Timestamping

A trusted timestamp, applied per RFC 3161, is what keeps a signature verifiable after the signing certificate itself expires; without one, an artifact signed under a now-expired 460-day certificate would appear invalid the day that certificate lapses. Since April 2025, the CA/B Forum has required Timestamp Authorities to protect their own signing keys in offline hardware crypto modules, which raises the bar for which timestamping providers are acceptable for a compliant signing pipeline. Confirm your timestamp authority meets this requirement directly; it is not something a code signing platform can compensate for on its own.

Renewal

The drop from 39 months to 460 days roughly triples how often a code signing certificate needs renewing. A manual renewal process that was merely inconvenient under the old cycle becomes a real operational risk under the new one, an expired certificate mid-release cycle blocks signing entirely. Certificate lifecycle management needs to treat code signing certificates as a tracked, automatically renewed asset class, not a one-time procurement a team remembers to revisit every few years.

Key-Protection Consequences

The June 2023 HSM mandate closed the option that used to exist for lower-assurance certificates: software-based key generation. Every publicly trusted code signing key now has to be generated inside, and never exported from, a FIPS 140-2 Level 2 (or higher) or Common Criteria EAL4+ hardware module. This is the same architectural requirement the CRA’s Article 13(1)(c) hardware root of trust expectation drives independently, which is precisely where the two compliance regimes reinforce each other rather than create separate work.

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.

Compliance Action Checklist

Use this as an audit-readiness sequence, covering both regimes, rather than a one-time setup task:

1. Confirm every code signing private key, regardless of product line, is generated inside and never exported from a FIPS 140-2 Level 2+ (or Common Criteria EAL4+) HSM, per the June 2023 CA/B Forum requirement.
2. Move from a shared signing key to per-product key isolation, with each product line’s key in its own HSM partition and its own access control list.
3. Enforce M-of-N approval for production signing so no single person can sign and ship unilaterally, and confirm this is enforced by the signing platform’s policy engine, not by process alone.
4. Enroll every code signing certificate in a certificate lifecycle management process built for 460-day renewal cycles, not the old 39-month cadence.
5. Confirm your timestamp authority protects its own keys in an offline hardware crypto module, per the April 2025 requirement, and that every signature is timestamped at signing time.
6. Build (or confirm you have) the ability to identify, within hours, every artifact signed by a specific certificate or key, so a 24-hour revocation or ENISA notification deadline is achievable rather than aspirational.
7. Retain signing event logs, artifact hashes, approver identities, and certificate lineage for at least the CRA’s five-year minimum support period, longer if your product’s expected lifetime exceeds that.
8. If you use a third-party Signing Service, confirm it has completed the conformity assessment audit (WebTrust or ETSI EN 319 401) required since June 2024, rather than assuming it.

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.

Frequently Asked Questions

Are the CRA and the CA/Browser Forum Baseline Requirements the same thing?

No. The CRA is EU law governing the cybersecurity of products with digital elements. The CA/Browser Forum Baseline Requirements are industry rules governing how publicly trusted certificates, including code signing certificates, are issued and managed. An organization signing with a publicly trusted certificate for a CRA-in-scope product has to satisfy both at once.

How long do I have to revoke a code signing certificate after a key compromise?

Under the Code Signing Baseline Requirements §4.9.1.1, a CA must revoke within 24 hours of confirming key compromise. Since Ballot CSC-22 (April 2024), that same 24-hour window also applies to certificates tied to Suspect Code or unauthorized signing activity, not only confirmed compromise.

Why did code signing certificate validity drop to 460 days?

Ballot CSC-31 reduced the maximum validity for code signing certificates issued on or after March 1, 2026 from 39 months to 460 days, following the CA/Browser Forum’s broader industry trend of shortening certificate lifetimes to limit the exposure window of any single certificate.

Does timestamping still matter if certificates now expire faster?

It matters more. A trusted RFC 3161 timestamp is what keeps a signature valid after its certificate expires; with 460-day validity instead of 39 months, artifacts are far more likely to be verified after their original signing certificate has already lapsed.

What’s the minimum period I need to retain signing audit records?

At least the CRA’s five-year minimum support period under Article 13(8), or longer if your product’s expected lifetime exceeds five years. Records should tie each signing event to the specific key, approver, artifact hash, and certificate used.

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.