Understanding the Cyber Resilience Act: What UK IT Directors & CISOs Need to Know 

The European Union’s Cyber Resilience Act (CRA) has been described as one of the most significant cybersecurity regulations in years. It sets mandatory standards for products with digital elements, covering everything from smart devices and software to cloud-based services. For UK organisations, the Cyber Resilience Act is particularly important if you manufacture, sell, or distribute digital products into the EU. Even though the UK has left the EU, your products will still fall within scope if they are placed on the European market. 

The CRA entered into force in December 2024, with core obligations applying from December 2027. That might feel far away, but the scale of the changes means you should start preparing now. This guide explains what the CRA requires, who it affects, where it overlaps with existing frameworks such as ISO 27001 and NIST, and the practical steps you can take to get ahead. 

Key Takeaways 

• The Cyber Resilience Act is an EU regulation setting cybersecurity requirements for digital products 
• It entered into force in December 2024, with full compliance required from December 2027 
• Early obligations of the Cyber Resilience Act around reporting and market surveillance begin in mid to late 2026 
• UK businesses selling into the EU must comply, regardless of Brexit 
• Penalties include fines of up to 15 million euros or 2.5% of global turnover 
• Organisations with ISO 27001 certification or NIST alignment already meet many underlying requirements, but CRA-specific processes such as technical documentation, SBOMs, and CE marking are still required 

What is the EU Cyber Resilience Act? 

The Cyber Resilience Act (CRA) is designed to raise the overall security of digital products across the EU. It introduces legally binding requirements that manufacturers, importers, and distributors must follow before products can be placed on the market. 

Purpose and objectives 

The purpose of the CRA is to ensure that hardware and software products are secure by design and continue to be maintained securely throughout their lifecycle. It aims to reduce the number of exploitable vulnerabilities, improve transparency on security updates, and create a consistent approach across the EU market. 

Goals of the Cyber Resilience Act: 

• To enhance the cyber security of digital products and improve the overall resilience of the EU and EU suppliers’ digital infrastructure.  
• To create a safer digital environment for citizens and businesses.  
• To rebalance responsibility by placing greater emphasis on manufacturers to ensure the security of their products.  
• To foster trust and transparency in the digital products available on the EU market. 

Scope of the regulation 

The regulation applies to any product with digital elements. This includes operating systems, network equipment, IoT devices, SaaS applications, and even development tools. Both physical products and software-only offerings are in scope. Products are also classified according to risk, which affects the level of assessment required before market entry. 

Mandatory requirements under the CRA 

Organisations that are in scope to comply with the CRA must ensure that: 

• Products are secure by design and by default, with strong baseline configurations 
• Products are free from known exploitable vulnerabilities when placed on the market 
• Security updates are provided free of charge during the declared support period 
• Vulnerability handling processes are in place, including coordinated vulnerability disclosure 
• Incidents and actively exploited vulnerabilities are reported to ENISA within strict timelines (24 hours, 72 hours, and 14 days) 
• Technical documentation and a Declaration of Conformity are produced to demonstrate compliance 
• A Software Bill of Materials (SBOM) is created in machine-readable format for each product 
• Products carry the CE marking before being sold in the EU market 

Key Dates and Compliance Timeline 

• 10 December 2024: CRA entered into force 
• 11 June 2026: Provisions on notified bodies and market surveillance start to apply 
• 11 September 2026: Vulnerability reporting obligations begin, requiring early warnings within 24 hours, notifications within 72 hours, and final reports within 14 days 
• 11 December 2027: All products placed on the EU market must be CRA compliant and carry CE marking 

Who Must Comply With the CRA? 

The CRA casts a wide net. It is not limited to large technology firms or manufacturers inside the EU. Any organisation that develops, imports, or distributes products with digital elements into the European market falls within scope. This means UK companies selling software, connected devices, or cloud-based services to EU customers will need to meet the same requirements as their European counterparts. 

Scope and classification of products 

If your organisation places products with digital elements on the EU market, you must comply with the CRA. This includes manufacturers based outside the EU, such as UK companies exporting software or devices. 

Products are divided into three categories: 

• Default: This covers most products, subject to self-assessment and internal documentation 
• Important (Class I and II): Higher risk products such as operating systems (OT), network management software, and industrial controls. These require stricter assessment routes 
• Critical: The highest risk products, such as identity management systems or SIEM platforms, which require third-party certification by notified bodies 

Core Obligations You Need to Prepare For

The CRA is built around a set of essential requirements that manufacturers, importers, and distributors must follow. These obligations apply throughout the product lifecycle, from design and development, to market placement and ongoing support. Understanding them early will help you to plan your compliance roadmap and avoid any last minute surprises. 

Secure by design and default 

Products must be designed to prevent known exploitable vulnerabilities and shipped with secure default configurations. Update mechanisms must be built into the design of the product and users must be able to reset products securely.

Vulnerability handling and reporting 

Manufacturers must implement a vulnerability management process covering discovery, coordination, disclosure, and remediation. Security incidents must be reported to ENISA via the new single reporting platform within strict timeframes. 

Technical documentation and CE marking 

Before placing a product on the EU market, you must create a technical file that demonstrates compliance. This includes a risk assessment, Software Bill of Materials (SBOM), vulnerability handling policies, test results, and details of support periods. Products must also carry the CE marking and an EU Declaration of Conformity. 

Consequences of non-compliance 

Failure to comply with the CRA can result in fines of up to 15 million euros or 2.5% of your annual global turnover, whichever is higher. In addition, non-compliant products may be withdrawn from the EU market. 

What the CRA Means for UK Businesses 

Brexit doesn’t remove your obligations under the CRA if your products are sold in the EU market. UK businesses will need to demonstrate conformity with CRA mandates and affix CE markings in the same way as EU-based companies. 

At the same time, the UK has introduced its own Product Security and Telecommunications Infrastructure (PSTI) Act and is working on the Cyber Security and Resilience Bill (CS&R).  

While PSTI is narrower in scope, covering consumer IoT, the CS&R Bill is set to expand reporting and resilience requirements for organisations operating in the UK. For many businesses, the best approach is to align compliance strategies so that preparation for one regime supports the other. 

CRA and Overlapping Frameworks: Where You’re Already Ahead 

One of the most common questions IT and compliance leaders ask is whether existing certifications or frameworks reduce the work required for CRA compliance. The answer is yes – but not completely: 

CRA vs. ISO 27001 

ISO 27001 already requires secure development, vulnerability management, secure disposal, supplier management, and monitoring controls. These map directly onto many CRA obligations. However, ISO 27001 is an organisational management standard, while CRA is a product regulation. You will still need product-level technical documentation and CE conformity evidence. 

CRA vs. NIST CSF 2.0 

NIST CSF 2.0 outcomes such as data security, platform security, supply chain management, and incident response align strongly with CRA Annex I requirements. If you already use NIST CSF for governance, you can reuse many processes for demonstrating compliance with vulnerability handling and incident reporting. 

CRA vs. NIST SSDF 

The NIST Secure Software Development Framework (SSDF) is particularly relevant. It covers threat modelling, dependency management, code review, build integrity, and secure update distribution. These practices align almost directly with CRA requirements for SBOMs, vulnerability disclosure, and secure update mechanisms. 

CRA vs. UK PSTI and CS&R Bill 

The UK’s PSTI Act overlaps with CRA in banning default passwords, mandating vulnerability disclosure contacts, and setting minimum update periods. However, CRA goes further in scope, covering a wider range of digital products and requiring CE marking. The upcoming Cyber Security and Resilience (CS&R) Bill will bring additional obligations for UK operators, including ransomware reporting, which makes harmonised preparation worthwhile. 

CRA Annex I Crosswalk with ISO 27001, NIST CSF and NIST SSDF 

How to Use This Crosswalk 

• If you are ISO 27001 certified or aligned with NIST, you already have policies and controls covering much of the CRA’s intent. 
• The gap is at the product-level evidence: CE marked technical files, SBOM formats, and ENISA reporting workflows. 
• Think of CRA compliance as taking your organisational security management and proving it at the product level. 

CRA Annex I Requirement	ISO 27001:2022 Alignment	NIST CSF 2.0 Alignment	NIST SSDF Alignment	Notes for CRA Compliance
Secure by design and default	A.8.28 Secure coding, A.8.9 Configuration mgmt	PR.PS (Platform Security), PR.DS (Data Security)	PW.1, PW.6 (define security requirements, threat modelling)	CRA requires you to evidence product-level design choices, not just organisational policy
No known exploitable vulnerabilities at release	A.8.28, A.8.32 Vulnerability mgmt	PR.MA (Maintenance), DE.AE (Anomalies & Events)	PW.7 (Identify and fix defects)	Must document test results and show CE conformity
Timely security updates & support period	A.8.33 Test & development mgmt, A.8.15 Logging	PR.MA, RS.MI (Mitigation)	RV.1–RV.4 (Release & update practices)	CRA requires free security updates during declared support period
Logging and monitoring	A.8.15 Logging, A.8.16 Monitoring	DE.MA (Monitoring), DE.DP (Detection Processes)	PW.9 (Log generation, review)	CRA requires logs to support both incident detection and reporting
Secure data deletion & reset	A.8.10 Secure disposal, A.8.11 Data masking	PR.DS (Data Security)	PO.5 (Define how to securely archive/dispose)	CRA requires user-friendly reset and deletion functions
Vulnerability handling process	A.8.32 Vulnerability mgmt, A.5.24 Contact with authorities	RS.MI (Mitigation), RC.CO (Communications)	PW.8, RV.3 (Vulnerability disclosure, patch distribution)	CRA mandates formal vulnerability disclosure policy and public contact point
Security incident reporting (24h, 72h, 14 days)	A.5.25 Incident reporting, A.5.27 Response	RS.RP (Response Planning), RC.CO	RV.3 (Report vulnerabilities externally)	CRA introduces strict reporting deadlines via ENISA platform
SBOM generation and sharing	A.5.20 Supplier relationships, A.8.29 Secure system architecture	ID.AM (Asset mgmt), ID.IM-SC (Supply chain)	PW.4, RV.1 (Document dependencies, generate SBOM)	CRA requires machine-readable SBOMs covering at least top-level dependencies
Technical file and CE marking	Not covered directly	Not covered directly	Not covered directly	Entirely CRA-specific; requires new documentation and conformity procedures
Coordinated vulnerability disclosure (CVD)	A.8.32 Vulnerability mgmt, A.5.29 Contact with suppliers	RS.CO (Response coordination), RC.CO	RV.3 (Report & publish)	CRA requires publication of CVD policy and ongoing disclosure process

Preparing for CRA: A Practical Roadmap for IT Directors and CISOs 

Step 1 – Portfolio mapping 

Start by identifying all products with digital elements that you sell into the EU. Classify them according to the CRA categories of default, important, or critical. 

Step 2 – Leverage existing frameworks 

If you are ISO 27001 certified or aligned with NIST CSF or SSDF, map existing controls against CRA Annex I requirements. This will highlight where you are already compliant and where the gaps remain. 

Step 3 – Build SBOM and vulnerability disclosure processes 

Standardise SBOM generation across your product portfolio. Establish a coordinated vulnerability disclosure policy and make contact details public. Ensure you can issue updates securely and free of charge during the declared support period. 

Step 4 – Develop a technical file factory 

Create a repeatable process for generating technical documentation in line with Annex VII. This should include risk assessments, test reports, SBOMs, vulnerability handling policies, and declarations of conformity. 

Step 5 – Test your reporting processes 

Prepare for the strict reporting timelines that begin in September 2026. Run drills to ensure your teams can issue an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days. Integrate reporting with ENISA’s single platform. 

Complementary Regulations to Watch 

• The UK Cyber Security and Resilience Bill will expand the NIS Regulations and introduce new incident reporting requirements with heavy fines for non-compliance. 
• NIS2, already adopted in the EU, focuses on organisational cyber resilience and incident management. 
• The EU’s Digital Operational Resilience Act (DORA) targets financial services, requiring ICT risk management and resilience controls. 

Final Thoughts: Getting CRA Ready 

The Cyber Resilience Act (CRA) represents a major shift in how digital products are regulated and secured. While many of its requirements overlap with frameworks you may already use, there are CRA specific obligations that can’t be overlooked. By starting early, you can spread the workload, reduce compliance risk, and even use CRA readiness as a competitive differentiator in the market. 

DigitalXRAID can help you prepare by mapping your existing frameworks, developing SBOM and disclosure processes, and guiding you through technical documentation and conformity assessments.  

If you would like to discuss how CRA will affect your organisation, get in touch with our compliance experts today. 

FAQs about the Cyber Resilience Act (CRA) 

What is the EU Cyber Resilience Act in simple terms? 

It is an EU regulation that sets mandatory cybersecurity requirements for products with digital elements sold in the EU. 

When does the CRA compliance deadline start? 

Full compliance is required from 11 December 2027, with some reporting obligations starting in September 2026. 

Does the CRA apply to UK companies? 

Yes, if you supply and sell products with digital elements in the EU market, regardless of where your business is based. 

What products are considered critical under CRA? 

Critical products include high-risk items such as identity management systems, operating systems, and SIEM platforms. 

How does the CRA compare with ISO 27001 certification? 

ISO 27001 helps cover many underlying processes, but CRA also requires product-level evidence, SBOMs, and CE conformity. 

What happens if my company doesn’t comply with CRA? 

Non-compliance can result in fines of up to 15 million euros or 2.5% of global turnover, and products may be withdrawn from the EU market.