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

Introduction

The Cyber Resilience Act (Regulation (EU) 2024/2847) is a European Union law that sets cybersecurity rules for products that include any digital components, which can be hardware or software.

The Cyber Resilience Act (CRA) is built on a principle: Only products that are secure should be allowed on the EU market.

To implement this principle, Article 6 of the regulation sets out two key pillars of compliance:

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

A product can only be considered compliant if:

It meets the essential cybersecurity requirements listed in Annex I, Part I.

• It is properly installed, maintained, and updated by the user or operator.

In other words, the product must be fundamentally secure and continue to operate securely when used as intended.

There are four product categories under the CRA as follows:

• Default category: This includes most products that are not explicitly listed in other categories (around 90% of all products with digital elements). Examples include general-purpose consumer electronics like smart speakers, hard drives, and basic photo editing software.
• Important products Class I: These products perform functions critical to cybersecurity, such as identity management systems, web browsers, password managers, VPN software, and smart home security devices (e.g., smart locks, cameras).
• Important products Class II: This class includes higher-risk products than Class I, such as firewalls, intrusion detection/prevention systems for industrial use, hypervisors, and tamper-resistant microprocessors.
• Critical products: These are the highest-risk products, deemed critical because essential entities depend on them and their compromise could cause extensive disruptions. Examples include secure elements in smartcards and smart meter gateways

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

Compliance isn’t just about the final device; it is about how it’s made and supported. As per Annex I, Part II, manufacturers must:

• Have a vulnerability management process, including receiving, assessing, and addressing security issues.
• Follow secure development practices throughout the product’s lifecycle.
• Provide updates and maintain the product’s security over time.

The CRA goes beyond checking a product once before it hits the market. It requires continuous security throughout the product’s entire lifespan. Therefore, the product must be built securely, and the manufacturer must keep supporting it with security updates, monitoring, and improvements.

So, CRA compliance is not a set-and-forget, but a long-term, strategic, and tactical initiative to ensure security is built into both the product and the processes behind it.

Who Needs to Comply With CRA?

When it says, “any EU or non-EU manufacturer selling products with digital elements in Europe”, it means:

• EU manufacturers

  Companies based inside the EU that make products with software/firmware and sell them in the EU.

• Non-EU manufacturers

  Companies based outside the EU (for example, in the US, China, etc.) that:

  • sell directly into the EU market, or
  • sell through EU distributors/importers.

If the product ends up on the EU market, the CRA applies, regardless of where the company is located. So you can not avoid CRA just because your headquarters are outside the EU, or you sell via online marketplaces; if EU customers can buy it, you’re in scope.

Types of Products Covered

The CRA covers software and firmware that runs on or is supplied with connected devices. This includes device operating systems, embedded firmware, mobile apps used to control IoT products, desktop management tools, and cloud-based interfaces that interact with these devices. If the software is part of the product’s functionality or impacts its security, it is subject to CRA requirements.

The CRA includes IoT and embedded devices, which are products that contain software or firmware and are typically used in homes, healthcare environments, and industrial settings.

It also applies to industrial control and automation equipment, which plays a critical role in factories and critical infrastructure.

Another major category is consumer electronics, which includes everyday smart devices such as wearables, smart appliances, home entertainment systems, and connected security solutions.

The Clock is Ticking for Manufacturers

As the CRA is being enforced on a strict timeline, manufacturers and vendors need to ensure they are up to speed. Below is a brief overview of the key milestones.

10 December 2024, CRA Enters Into Force

On this date, the CRA officially became law. This does not mean that all requirements must be met immediately, but it marks the beginning of the countdown. From this point on, manufacturers, importers, and distributors are expected to begin preparing their processes, documentation, and systems for compliance.

11 September 2026, Vulnerability Reporting Obligations Begin

Almost two years later, the first mandatory obligations start:

• Manufacturers must begin reporting actively exploited vulnerabilities and incidents to EU authorities within the required timeframes.
• They must already have in place a basic vulnerability management and disclosure process.
• This phase focuses on transparency and early warning, even before full product compliance is required.

This is essentially the “soft start” of the CRA, where organizations must demonstrate they can manage and communicate security issues properly.

11 December 2027, Full Compliance Required

This is the big deadline. By this date, all products with digital elements placed on the EU market must fully comply with the CRA’s requirements, including:

• Secure-by-design and secure-by-default development
• SBOM creation and maintenance
• Proper vulnerability management processes
• Security update mechanisms
• Documentation and CE marking related to cybersecurity

From this date onward, non-compliant products cannot legally be sold in the EU.

Products with digital elements that have been lawfully placed on the EU market before 11 December 2027 are generally exempt from the main requirements of the CRA. This exemption only applies as long as the product does not undergo a “substantial modification” after 11 December 2027. If a product is substantially modified after this date, it must then comply with the full CRA requirements, and the entity making the modification becomes the manufacturer for CRA purposes.

A key exception to the general exemption is that the obligations related to vulnerability and incident reporting (Article 14) do apply to all products that fall within the scope of the Regulation, including those placed on the market before 11 December 2027. These reporting obligations will become mandatory from 11 September 2026. 

Now, let’s understand the CRA Requirements in detail:

CRA Requirements Explained

The CRA defines specific security expectations for products with digital elements. These are divided into two major parts:

Part I – Cybersecurity Requirements Relating to the Properties of Products with Digital Elements

Requirement	Requirement Explained	How to Achieve the Requirement
Part I.1 – Secure by Design	Products must be designed and built with security appropriate to their risks, starting from early development.	Conduct risk assessments, apply secure development lifecycle (SDL), minimize attack surface, use secure coding practices, and include hardware/software security controls.
Part I.2(a) – No Known Exploitable Vulnerabilities	Products must not be released with vulnerabilities that are already publicly known or internally known.	Perform vulnerability scanning, penetration testing, static/dynamic code analysis, SBOM review, and fix issues before release.
Part I.2(b) – Secure Default Configuration	Products must ship with security settings enabled by default and allow factory reset.	Disable unnecessary services, enforce strong default credentials or none, use secure protocols, ensure reset-to-factory functionality, and harden system configurations.
Part I.2(c) – Timely Security Updates	Products must support security updates, ideally automatic, with opt-out, notifications, and postponement options.	Implement strong update mechanisms, secure update delivery, update signing, user notifications, and automated vulnerability monitoring.
Part I.2(d) – Protection Against Unauthorized Access	Devices must prevent unauthorized access and detect/report attempts.	Use strong authentication, identity and access management, role-based access control, logging, and secure credential storage.
Part I.2(e) – Confidentiality of Data	Devices must protect stored and transmitted data, often using encryption	Implement encryption for data in transit and data at rest, secure key management, and apply modern cryptographic standards.
Part I.2(f) – Integrity of Data & Commands	Devices must protect data, commands, and configuration from unauthorized changes and detect corruption.	Use digital signatures, checksums, signed updates, authenticated communication, and data integrity monitoring.
Part I.2(g) – Data Minimization	Devices must only collect the minimum data required for their intended purpose.	Review data flows from the ingress point to the egress point, remove redundancy, and document purpose limitations.
Part I.2(h) – Availability of Essential Functions	Critical features must remain functional even after an incident, including resilience against denial-of-service.	Implement redundancy, fail-safe modes, rate limiting, DoS protection, and define incident recovery measures.
Part I.2(i) – Minimize Negative Impact on Networks	Devices must not degrade or harm the availability of other networked systems.	Implement bandwidth controls, resource isolation, behavior monitoring, and safe communication practices.
Part I.2(j) – Attack Surface Reduction	Devices must minimize external interfaces to reduce possible entry points for attackers.	Remove unused ports/services, use modular design, restrict APIs, and enforce secure configuration defaults.
Part I.2(k) – Incident Impact Mitigation	Devices must include measures that limit the damage caused by security incidents.	Conduct impact assessments and immediate incident response mechanisms.
Part I.2(l) – Security Event Monitoring	Devices must record key security events and allow monitoring, with user opt-out options.	Implement logging, audit trails, event reporting, secure log storage, and monitoring.
Part I.2(m) – Secure Data Deletion & Transfer	Users must be able to securely and permanently delete data, and any data transfer must be done securely.	Provide encrypted storage deletion, protected data export workflows, and clear user controls.

Part II – Vulnerability Handling Requirements

Requirement	Requirement Explained	How to Achieve the Requirement
Part II.1 – SBOM & Component Tracking	Manufacturers must identify and document all software components and vulnerabilities in their products, including generating a Software Bill of Materials (SBOM).	Perform cryptographic discovery and maintain detailed inventory, perform vulnerability scans, keep component inventories updated, and monitor third-party libraries for new CVEs.
Part II.2 – Rapid Vulnerability Remediation	Manufacturers must fix vulnerabilities quickly and provide timely security updates. Security fixes should be separate from feature updates when possible.	Establish a vulnerability assessment program, prioritize remediation based on risk, release fast security patches, use CI/CD for rapid delivery, and separate security updates from feature updates.
Part II.3 – Regular Security Testing	Manufacturers must perform ongoing security testing and security reviews throughout the product lifecycle.	Conduct regular penetration tests, static/dynamic analysis, fuzzing, code reviews, and continuous security assessments before and after product release.
Part II.4 – Public Vulnerability Disclosure	After a patch is available, manufacturers must publicly disclose clear information about the fixed vulnerabilities unless there is a justified security reason to delay disclosure.	For Manufacturer- Notify users of patches, provide severity ratings, describe impacts, and document remediation steps.
Part II.5 – Coordinated Vulnerability Disclosure Policy (CVD)	Manufacturers must establish and enforce a formal policy that guides how external researchers can report vulnerabilities.	For Manufacture- Create a public CVD policy, define intake processes, set timelines for triage, acknowledge reports, and coordinate communication between researchers and internal teams.
Part II.6 – Share Potential Vulnerability Information	Manufacturers must make it easy to report vulnerabilities and share information about potential weaknesses in both their own software and third-party components.	Fore Manufacturer- Provide a dedicated security contact or email, use vulnerability intake platforms, share advisories with partners, monitor third-party security channels, and encourage responsible disclosure.
Part II.7 – Secure Update Distribution	Manufacturers must securely distribute updates in a way that ensures vulnerabilities can be fixed quickly and safely, including support for automatic updates where appropriate.	For Manufacturer- Use signed updates, encrypted delivery channels, secure OTA (over-the-air) mechanisms, update integrity checks, and automated deployment pipelines.
Part II.8 – Timely and Free Security Updates	Security updates must be delivered promptly and at no extra cost (except for custom business agreements). Updates must include clear advisory messages.	Publish updates rapidly, notify users promptly, provide free security fixes, include documentation explaining impact and recommended actions, and ensure easy installation.

Stake for Non-Compliance

Failing to meet the CRA requirements carries serious consequences for manufacturers and anyone placing products with digital elements on the EU market. Non-compliant products can be removed from sale, companies may be required to redesign or remediate their devices, and the reputational damage can be severe. Because cybersecurity incidents can jeopardize individuals, industries, and critical infrastructure, the CRA treats compliance as a high-priority obligation.

Beyond losing market access, companies face significant financial penalties. The CRA includes a strict enforcement system designed to motivate organizations to prioritize cybersecurity, product security, and lifecycle management.

Article 64 of the CRA provides authorities with both administrative fines and corrective enforcement powers. Market surveillance authorities can not only issue fines but can also:

• order products to be withdrawn from the market,
• restrict or prohibit further sales, and
• require manufacturers to fix or redesign a product before it can be sold again.

These powers apply when a product poses security risks or does not meet the CRA’s essential requirements.

Maximum Fine Levels

The CRA uses a tiered penalty system, where fines depend on:

• who committed the violation (manufacturer, importer, distributor, etc.), and
• how serious the violation is (security-related vs administrative).

Below are the three major fine categories.

Up to €15 Million or 2.5% of Global Turnover

This is the highest penalty tier and applies mainly to manufacturers, those ultimately responsible for product security. A company can face this fine if it fails to comply with any of the following:

• Essential cybersecurity requirements (Annex I requirements)
• Incident notification obligations
• Vulnerability reporting obligations
• Other core responsibilities are defined under the CRA

Because these failures directly impact user safety and cybersecurity risk, they carry the strongest sanctions.

Up to €10 Million or up to 2 % of Worldwide Annual Turnover (whichever is higher) 

This category applies when companies fail procedural or compliance obligations, even if the product itself is not actively insecure. The common failure for this penalty is: 

• Missing or incomplete technical documentation 

• Failure to perform or document conformity assessments 

• Incorrect or missing CE marking 

• Not maintaining required software bill of materials (SBOM) 

• Weak internal processes for compliance monitoring 

The EU relies on documentation and conformity evidence to enforce cybersecurity at scale. If auditors cannot verify compliance, enforcement becomes impossible. 

Up to €5 Million or 1% of Global Annual Turnover (whichever is higher) 

This is the lowest tier of penalties and it applies when an organization does the following: 

• Provides false, misleading, or incomplete information 

• Withholds requested data from market surveillance authorities 

• Misrepresents cybersecurity controls or testing results 

This includes intentional deception OR negligent inaccuracies. 

CRA Compliance High-Level Checklist

CRA does not just want “security work happening.” It wants proof that cybersecurity is owned, governed, and detailed, not ad hoc. If no one is clearly accountable, the manufacturer can’t reliably “undertake an assessment” across the lifecycle. Below is a checklist provided to ensure a quick self-assessment to ensure where your organization currently stands:

Risk Assessment

• Ensure a data protection risk assessment has been conducted, including risk identification, analysis, and prioritization of risks.
• Ensure a formal risk management process exists to identify, monitor, and manage security risks.
• Ensure risks are prioritized based on likelihood and impact, with documented risk acceptance criteria.
• Ensure a RACI matrix is defined for risk ownership, escalation, and decision-making.
• Ensure security risk management policies and procedures are documented, up to date, and approved.
• Ensure cryptographic policies are aligned with applicable regulatory and industry best standards, such as NIST, FIPS, GDPR, etc.
• Ensure continuous monitoring processes are in place for critical ICT systems and services.

Incident Response

• Ensure that an incident response plan and Business Continuity Plan are formally documented and approved.
• Ensure predefined procedures exist for detecting, responding to, containing, and recovering from cyber incidents.
• Ensure roles and responsibilities for incident response are clearly defined.
• Ensure the incident response plan is tested regularly.
• Ensure lessons learned from incident tests or real incidents are documented and addressed.
• Ensure Software Bills of Materials (SBOMs) are collected and maintained to support rapid incident triage and impact analysis.

Data Protection

• Ensure sensitive and personal data, such as PII, PHI, and PCI data, is classified according to confidentiality and regulatory requirements.
• Ensure controls are in place to protect data confidentiality, integrity, and availability (CIA).
• Ensure encryption is used for sensitive data at rest and in transit.
• Ensure mechanisms exist to detect, respond to, and contain data breaches.
• Ensure software and data integrity controls are implemented (e.g., checksums, code signing).
• Ensure regular security audits and assessments are conducted to validate compliance with internal policies and industry standards.

Reporting Obligations

• Ensure access controls enforce least privilege access principles using RBAC or IAM.
• Ensure all software and cybersecurity incidents are documented consistently.
• Ensure incidents are reported in accordance with regulatory and legal requirements.
• Ensure reporting timelines, thresholds, and responsibilities are clearly defined.
• Ensure SBOMs and other compliance evidence are produced and maintained.
• Ensure reporting and evidence generation are automated where possible to reduce response time and errors.

How Encryption Consulting Can Help

Encryption Consulting offers tailored advisory services to help your business efficiently and securely meet specific CRA compliance requirements. Through detailed assessments based on requirements and relevant CRA standards articles, we identify weaknesses such as outdated protocols, weak key management, or misconfigured SSL/TLS settings. Addressing these issues strengthens your encryption architecture and supports ongoing compliance. 

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 securely managing code-signing keys and demonstrating traceability for every release. We addressed these issues by integrating HSMs into their environment for key protection, enabling multi-factor authentication for access, and automating code signing in their CI/CD pipeline. Tamper-proof audit logging was also enabled to satisfy CRA’s strict traceability and documentation requirements. At the same time, strong key revocation procedures ensured any compromised keys could be rapidly invalidated, critical for CRA vulnerability handling and incident response. 

Conclusion

The CRA sets a new baseline for security, requiring manufacturers to treat cybersecurity as a continuous responsibility throughout a product’s lifecycle. By embracing secure design, proactive vulnerability management, and transparent reporting, organizations can protect users while maintaining access to the EU market.

Reference – http://cyberresilienceact.eu/the-cyber-resilience-act-annex-eu/