Step-by-Step Guide to Cyber Resilience Act (CRA) Compliance

Published: January 2026. Updated: August 2026. Reviewed by Encryption Consulting’s Compliance Advisory team.

What Does the Cyber Resilience Act Require?

The Cyber Resilience Act (CRA), formally Regulation (EU) 2024/2847, is the European Union’s first horizontal law setting mandatory cybersecurity requirements for products with digital elements, hardware or software, sold anywhere in the EU market. Step by step Cyber Resilience Act (CRA) compliance comes down to one governing principle set out in Article 6: only products that are secure by design and supported for their full lifecycle can be placed on the EU market.

That principle splits into two pillars.

1. Products Must Be Secure by Design and Use (Annex I, Part I)

A product is compliant only if it meets the essential cybersecurity requirements in Annex I, Part I, and continues to be properly installed, maintained, and updated by the user or operator. In practice this means the product has to ship secure and stay secure across its supported life, not just pass a launch day check.

The CRA sorts products into four risk categories, and the category a product falls into determines how it is assessed for conformity:

• Default category: Roughly 90 percent of products with digital elements, including general purpose consumer electronics like smart speakers, hard drives, and photo editing software.
• Important products Class I: Products with cybersecurity relevant functions, such as identity management systems, web browsers, password managers, VPN software, and smart home security devices.
• Important products Class II: Higher risk products such as firewalls, industrial intrusion detection and prevention systems, hypervisors, and tamper resistant microprocessors.
• Critical products: The highest risk tier, where essential entities depend on the product, such as secure elements in smart cards and smart meter gateways.

2. Manufacturers Must Follow Secure Development and Lifecycle Processes (Annex I, Part II)

Compliance is not just about the shipped device. As per Annex I, Part II, manufacturers must run a vulnerability management process, follow secure development practices across the product lifecycle, and keep delivering security updates for as long as the product is supported. CRA compliance is a standing operational program, not a one time certification.

Who Needs to Comply With the CRA?

Any EU or non-EU manufacturer selling products with digital elements in Europe is in scope, which breaks down as follows:

• EU manufacturers based inside the EU that build products with software or firmware and sell them in the EU.
• Non-EU manufacturers based outside the EU, for example in the US or China, that sell directly into the EU market or through EU distributors and importers.

If the product ends up on the EU market, the CRA applies regardless of where the company is located. Selling through an online marketplace does not create an exemption; if EU customers can buy it, the manufacturer is in scope.

The CRA covers software and firmware that runs on or ships with connected devices: device operating systems, embedded firmware, mobile apps that control IoT products, desktop management tools, and cloud interfaces that interact with those devices. Typical categories include IoT and embedded devices used in homes, healthcare, and industrial settings; industrial control and automation equipment; and consumer electronics such as wearables, smart appliances, and connected security products.

What Is the CRA Compliance Timeline?

The CRA phases in on a fixed, EU-confirmed schedule. There is no grace period beyond these dates.

1. 10 December 2024, CRA enters into force. The regulation became law on this date. It does not require immediate compliance, but it starts the countdown; manufacturers, importers, and distributors should begin building the processes, documentation, and technical controls the later deadlines require.
2. 11 June 2026, notified body and market surveillance provisions apply. The Chapter IV provisions governing conformity assessment bodies and market surveillance authorities take effect, giving the enforcement infrastructure time to stand up before reporting obligations start.
3. 11 September 2026, vulnerability and incident reporting begins. Under Article 14, manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and national CSIRTs within set timeframes, and must already have a basic vulnerability management and disclosure process running. This is the soft start of the CRA: transparency and early warning, ahead of full product compliance.
4. 11 December 2027, full compliance required. Every product with digital elements placed on the EU market must meet the CRA’s requirements in full: secure by design and secure by default development, SBOM creation and maintenance, documented vulnerability management, working security update mechanisms, and CE marking tied to cybersecurity conformity. Non-compliant products cannot legally be sold in the EU after this date.

Products lawfully placed on the EU market before 11 December 2027 are generally exempt from the main requirements, as long as they do not undergo a substantial modification after that date; a substantial modification makes the modifying entity the manufacturer for CRA purposes, and pulls the product into full scope. The one requirement that reaches products already on the market regardless of that exemption is Article 14 vulnerability and incident reporting, which applies from 11 September 2026 onward to every in-scope product.

What Cryptographic and Algorithm Selection Guidance Does the CRA Give?

The CRA is deliberately technology neutral. Annex I, Part I requires manufacturers to protect data confidentiality “by encrypting relevant data at rest or in transit by state of the art mechanisms” (Article 2(e)) and to protect the integrity of stored and transmitted data, commands, and configuration against unauthorized modification (Article 2(f)), but it does not name specific algorithms. That choice, and the audit trail behind it, is left to the manufacturer, which is exactly where most conformity assessments find gaps.

A defensible baseline for CRA-scoped products looks like this:

• Data at rest and in transit: AES-256 for symmetric encryption, TLS 1.3 for network channels, and a documented reason wherever a weaker cipher suite is still in use for legacy interoperability.
• Digital signatures for firmware and update integrity: RSA-2048 or ECDSA P-256 as the classical minimum, moving toward hybrid signing that pairs a classical algorithm with a NIST post-quantum scheme such as ML-DSA (FIPS 204) for general purpose signing.
• Constrained and long-lived firmware: NIST SP 800-208 designates the stateful hash-based schemes LMS and XMSS for firmware and software signing where signature size and code footprint matter more than raw throughput, which is why NSA’s CNSA 2.0 currently names them as the near-term choice for firmware specifically.
• Key encapsulation for confidentiality: ML-KEM (FIPS 203) where a product’s expected support life extends into the 2030s and a harvest-now-decrypt-later exposure window is realistic.

Algorithm selection is not a one time decision. It needs to be documented as part of the technical file a notified body or market surveillance authority will ask to see, and it needs a defined path for replacing an algorithm without re-architecting the product, which is what the next two sections cover.

What Threat Model Does the CRA Assume?

The CRA’s essential requirements map to a specific set of attacker capabilities the regulation expects manufacturers to defend against, not a generic “be secure” mandate:

• Supply chain and update injection. An attacker who compromises a build pipeline, a signing key, or a distribution channel tries to push unauthorized firmware or software to devices already in the field. Annex I, Part I 2(c) and 2(f) address this directly by requiring signed, verifiable updates and tamper detection for code and configuration.
• Exploitation of known vulnerabilities. Annex I, Part I 2(a) assumes products will ship with vulnerabilities discovered after release and requires a working disclosure and patch pipeline, not just a clean scan at launch.
• Unauthorized access and credential attacks. Default or hardcoded credentials, exposed management interfaces, and weak authentication are treated as a design failure under 2(b) and 2(d), not a configuration mistake the customer should have caught.
• Harvest-now-decrypt-later. The CRA does not name quantum computing as a threat, but the five-year-plus support obligation under Article 13 means data or signatures protected today by classical algorithms alone may need to remain confidential or verifiable well past the point at which a cryptographically relevant quantum computer becomes a credible risk, which is why algorithm agility belongs in the threat model even though the regulation itself is algorithm neutral.
• Physical and manufacturing-stage compromise. For IoT and embedded devices, an attacker with physical access to a device or a foothold in the contract manufacturing process is a realistic actor, which is why secure boot anchored in hardware and per-device provisioning matter as much as the software controls above them.

What Are the Performance and Interoperability Trade-Offs?

Meeting the CRA’s cryptographic requirements is not free, and the trade-offs differ by product class.

• Signature size on constrained devices. ML-DSA and SLH-DSA signatures run from roughly 2 to 8 times larger than an ECDSA P-256 signature, which matters directly for boot time and flash budget on microcontroller class IoT devices. This is the practical reason NIST SP 800-208’s LMS and XMSS, with their smaller signatures, remain the near-term choice for firmware even though they require stateful, crash-consistent key management inside a validated HSM.
• Hybrid signing overhead. Signing with both a classical and a post-quantum algorithm during the transition period roughly doubles signature generation and verification time. For high-volume CI/CD signing pipelines this is usually absorbed without issue; for a device verifying a signature during a power-constrained boot sequence, it is not.
• Harmonized standards still in progress. The European Commission has tasked CEN and CENELEC with drafting harmonized standards that will give manufacturers a presumption of conformity once published. Until those standards are finalized, manufacturers are assessing conformity against the Annex I text directly, which means two auditors can reasonably reach different conclusions on the same control until the harmonized standards catch up.
• Cross-border update distribution. A single update mechanism has to work across every EU member state’s network conditions and, for products also sold outside the EU, has to coexist with non-EU regulatory requirements without maintaining a separate signing pipeline per region.

What Key Management Does Secure Update Signing Depend On?

Article 13’s secure update requirement is only as strong as the key management behind it. A signed update built on a poorly governed key is not meaningfully different from an unsigned one once that key leaks. A defensible architecture separates at least three roles:

• Offline root key. Used rarely, typically only to issue or renew the certificate for the online signing key, generated and kept inside an HSM that stays disconnected from any network and brought online only for scheduled, witnessed key ceremonies.
• Online signing key. What the build pipeline actually calls on every release, HSM-backed and reachable over an authenticated API so signing can be automated, but never the same key as the offline root, so rotating it never touches the trust anchor already embedded in deployed devices.
• Per-device manufacturing identity. A unique key pair provisioned at manufacturing time, following the IEEE 802.1AR pattern, that lets a device authenticate itself to an update server as a genuine, non-cloned device before it ever receives a signed image.

On top of that separation, a working program needs FIPS 140-3 validated hardware protecting every signing key, an M-of-N approval requirement so no single person can sign and ship unilaterally, rollback protection that blocks reinstallation of an older signed but vulnerable firmware version, and a pre-provisioned successor key so a compromised key can be replaced without a field recall. Organizations that need the deeper mechanics of this should see Establishing a Firmware Signing Framework for CRA Compliance and CRA Compliance Architecture for Secure Code Signing, which cover the full key hierarchy and revocation workflow in detail.

What Do CRA-Compliant Deployments Look Like in Practice?

The same essential requirements land differently depending on the product category.

IoT device manufacturer (default category). A vendor shipping smart home sensors faced the common failure pattern: a single shared signing key used across every product line, generated on a build server rather than in hardware. The fix moved key generation into an HSM, split signing into per-product keys so a compromise on one product line does not expose the others, added multi-factor authentication for signing access, and automated signing inside the CI/CD pipeline with tamper-proof audit logging, satisfying both the integrity requirement and the traceability a conformity assessment expects.

Industrial controller manufacturer (Important Class II). A vendor of programmable logic controllers for factory automation needed secure boot anchored in an immutable hardware root, since these devices run in the field for a decade or more with infrequent physical access for maintenance. The design separated the boot verification chain, tied to the rarely rotated offline root, from the update verification chain, tied to the more frequently rotated online signing key, so a compromised or aging online key never requires re-flashing the immutable boot ROM itself.

Medical device manufacturer (Important Class I or Critical, depending on function). A connected diagnostic device manufacturer needed to reconcile the CRA’s SBOM and vulnerability reporting obligations with existing medical device regulatory requirements. The working approach treated the CRA’s SBOM as the master inventory feeding both the CRA’s Article 14 reporting workflow and the existing medical device vigilance process, rather than maintaining two separate component inventories that could drift apart.

CRA Requirements at a Glance: Requirement, Control, and Where EC Helps

The table below maps the essential cybersecurity requirements a manufacturer has to satisfy to the technical control that satisfies them and the Encryption Consulting service or product built for that control.

CRA Requirement (Annex I)	Technical Control	Encryption Consulting Service
Secure by design (Part I.1)	Risk assessment, secure development lifecycle, attack surface minimization	Compliance Advisory
No known exploitable vulnerabilities (2(a))	Vulnerability scanning, SBOM review, pre-release remediation	Compliance Advisory, CBOM Secure
Secure default configuration (2(b))	Hardened defaults, factory reset support, disabled unused services	Compliance Advisory
Timely, verifiable security updates (2(c))	Signed update packages, HSM-backed signing keys, rollback protection	CodeSign Secure
Confidentiality of stored and transmitted data (2(e))	State of the art encryption at rest and in transit, managed key lifecycle	PKI-as-a-Service, HSM-as-a-Service
Integrity of data, commands, and configuration (2(f))	Digital signatures, checksums, authenticated communication channels	CodeSign Secure, PKI-as-a-Service
Security event monitoring and logging (2(l))	Immutable audit trails tied to every signing and access event	CodeSign Secure, CBOM Secure
SBOM and component tracking (Part II.1)	Cryptographic discovery, dependency inventory, CVE monitoring	CBOM Secure
Vulnerability disclosure and reporting (Part II.4, Article 14)	Coordinated disclosure policy, ENISA reporting workflow, documented timelines	Compliance Advisory

What Are the Penalties for Non-Compliance?

Article 64 gives market surveillance authorities both fining power and corrective enforcement powers: ordering products withdrawn from the market, restricting or prohibiting further sales, and requiring a redesign before a product can be sold again. Fines are tiered by the severity of the violation.

Violation	Maximum Fine	Turnover Cap (whichever is higher)
Breach of essential cybersecurity requirements (Annex I), Article 13 or 14 obligations	15 million euros	2.5% of global annual turnover
Other obligations: incomplete technical documentation, missing conformity assessment, incorrect CE marking, missing SBOM	10 million euros	2% of global annual turnover
False, misleading, or incomplete information to authorities	5 million euros	1% of global annual turnover

CRA Compliance Checklist

The CRA wants proof that cybersecurity is owned, governed, and documented, not ad hoc. Use this checklist to gauge where the organization stands today.

Risk Assessment

• A formal risk management process identifies, monitors, and manages security risks with documented risk acceptance criteria.
• A RACI matrix defines risk ownership, escalation, and decision-making.
• Cryptographic policies align with recognized standards such as NIST and FIPS.

Incident Response

• A documented incident response plan defines detection, containment, and recovery procedures, and is tested regularly.
• Software Bills of Materials (SBOMs) are maintained to support rapid incident triage and impact analysis.

Data Protection

• Encryption protects sensitive data at rest and in transit, using algorithms documented against a current standard.
• Software and data integrity controls, including code signing, are implemented and independently audited.

Reporting Obligations

• Reporting timelines, thresholds, and responsibilities for Article 14 notifications to ENISA are clearly defined and rehearsed.
• SBOMs and other compliance evidence are automated where possible to reduce response time and errors.

Limitations

This guide is a starting point, not a substitute for a formal conformity assessment or legal review. A few boundaries are worth stating plainly. The harmonized standards CEN and CENELEC are drafting will eventually give manufacturers a presumption of conformity for specific technical controls; until those are published, assessing against the Annex I text directly leaves room for differing interpretations between manufacturers and notified bodies. The product category examples in this guide are illustrative, not a substitute for the formal classification process, which determines the conformity assessment route a specific product must follow. Where a product also falls under NIS2, DORA, or a sector-specific regime such as medical device regulation, the CRA does not replace those obligations; it adds to them, and the overlap has to be reconciled case by case. Finally, algorithm and standard references in this guide reflect the current NIST and CA/Browser Forum landscape as of August 2026; PQC standards and CA/B Forum ballots continue to evolve, so a compliance program needs a process for tracking updates, not a one time reading of this article.

What Would Encryption Consulting Recommend?

Start with a gap assessment before buying any tooling. Encryption Consulting’s Compliance Advisory service runs a detailed assessment against the specific CRA articles and Annex I requirements that apply to a product’s category, and identifies concrete gaps such as outdated protocols, weak key management, or misconfigured TLS settings rather than a generic maturity score.

For the secure update and firmware signing requirement specifically, CodeSign Secure is built for exactly this control: private signing keys stay inside FIPS 140-2 Level 3 certified HSMs, M-of-N approval prevents unilateral signing, every signing event produces an immutable audit log, and hybrid signing supports both classical algorithms and post-quantum schemes like ML-DSA and LMS from the same signing infrastructure, so a manufacturer is not rebuilding the pipeline again when the harmonized standards land.

For the confidentiality and integrity requirements around data at rest and in transit, PKI-as-a-Service provides the managed certificate and key infrastructure that backs encrypted channels and device identity without an in-house CA build out, which matters most for manufacturers who need this running well before the September 2026 reporting deadline, not after it.

An organization producing IoT devices faced exactly this combination of gaps: a shared signing key, no traceability between certificates and releases, and no revocation runbook. Integrating HSM-backed key protection, multi-factor authentication for signing access, and automated CI/CD signing closed the integrity and access control gaps, while tamper-proof audit logging and defined key revocation procedures satisfied the CRA’s traceability and vulnerability handling requirements at once.

Frequently Asked Questions

When does the Cyber Resilience Act actually take effect?

The CRA entered into force on 10 December 2024. Vulnerability and incident reporting obligations under Article 14 apply from 11 September 2026. Full compliance, including CE marking, is required by 11 December 2027. There is no additional grace period after these dates.

Does the CRA require a specific encryption algorithm?

No. Annex I, Part I requires “state of the art” encryption for confidentiality and integrity protection for data, commands, and configuration, but it does not name specific algorithms. Manufacturers choose and document algorithms such as AES-256, TLS 1.3, and signature schemes appropriate to the product’s constraints and expected lifetime, and that choice becomes part of the technical documentation a conformity assessment reviews.

Are any products exempt from the CRA?

Products already lawfully placed on the EU market before 11 December 2027 are generally exempt from the main requirements, unless they undergo a substantial modification after that date. Certain categories, such as products already covered by sector-specific EU regulations for medical devices, aviation, or vehicles, follow separate carve outs defined in the regulation. Article 14 vulnerability and incident reporting still applies to in-scope products regardless of this exemption, from 11 September 2026 onward.

How does the CRA relate to NIS2 and DORA?

NIS2 and DORA govern the cybersecurity posture and operational resilience of organizations operating critical infrastructure and financial entities. The CRA governs the products those and other organizations buy and use. A bank subject to DORA, for example, still has to confirm the connected devices and software it purchases meet CRA requirements; the regulations are complementary, not overlapping substitutes for each other.

What is the biggest cryptography-related mistake manufacturers make preparing for the CRA?

Using a single shared signing key across every product line. It is the fastest path to compliance and the worst outcome under Article 14: a single key compromise forces an incident notification covering the entire portfolio at once, rather than one contained product line. Per-product key isolation, generated inside an HSM, is the fix most conformity assessments end up requiring anyway.

Conclusion

The CRA sets a new baseline: cybersecurity as a continuous, evidenced responsibility across a product’s lifecycle rather than a launch day checkbox. The 11 September 2026 reporting deadline arrives first and tests whether a vulnerability disclosure process actually works under pressure; the 11 December 2027 deadline tests everything else, from secure by design engineering to SBOM accuracy to signed, auditable updates. Manufacturers that treat algorithm selection, key management, and update signing as infrastructure to build now, rather than paperwork to assemble later, are the ones who will clear both dates without a scramble.

References

• Regulation (EU) 2024/2847 of the European Parliament and of the Council, Cyber Resilience Act, EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
• European Commission, Cyber Resilience Act, Shaping Europe’s Digital Future: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• CRA Annexes I to VIII, Essential Requirements and Product Lists: https://www.cyberresilienceact.eu/the-cyber-resilience-act-annex-eu/
• Cyber Resilience Act, Article 71, entry into force and application: https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_71.html
• NIST SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes: https://csrc.nist.gov/pubs/sp/800/208/final
• NIST FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), finalized August 2024: https://csrc.nist.gov/pubs/fips/204/final