How to Prepare for the EU Cyber Resilience Act: Timeline, Requirements and Checklist

Cyber Resilience Act compliance is no longer a future planning exercise, it’s here and if your business is in scope, you need to get started. In this article we’ll show you what the Cyber Resilience Act (CRA) is, what requirements it imposes, the timeline of reporting and enforcement and a checklist of steps to take.

What is the Cyber Resilience Act?

The EU Cyber Resilience Act (CRA) is a law that makes manufacturers responsible for the cybersecurity of connected products and software they sell in the European Union. This includes everything from smart TVs, cameras, baby monitors, and IoT devices to operating systems, applications, and business software or as the legislation puts it “products with digital elements”. 

It was created because of the increasing digitalization of our world, with products built with processors and software permeating every corner of our lives, many of those products are sold with poor security, weak default settings and no commitment to fix security issues after purchase.

Has the Cyber Resilience Act Been Passed?

Cyber Resilience Act compliance should be on your mind if you manufacture, import or distribute products with digital elements made available on the EU market. The CRA entered into force on 10 December 2024, while its main obligations apply from 11 December 2027. However, just as when GDPR passed in April 2016, but wasn’t enforceable until May 2018, there’s a timeline of steps for cyber resilience act compliance: 

• 10th December 2024: CRA entered into force.
• 11th June 2026: provisions on the notification of conformity assessment bodies apply.
• 27th July 2026: European Commission published its first practical implementation guidance.
• 13th August 2026: ETSI announced the approval process for 17 vertical draft European standards supporting the CRA.
• 11th September 2026: reporting obligations for actively exploited vulnerabilities and severe incidents begin.
• 11th December 2027: main CRA obligations apply.
• 11th June 2028: certain existing EU type-examination certificates and approval decisions remain valid until this date unless they expire earlier.

The main points to watch are the CRA reporting obligations and the development of supporting standards. Harmonized standards can help manufacturers demonstrate conformity, but draft standards do not by themselves provide a presumption of conformity. Check the latest European Commission and ETSI publications for the current status of each standard.

December 2027 is not that far off, and depending on your organization, your culture, skills in managing compliance against regulations and your business operations, starting now to make sure you’re ready might be required.

Who Needs to Care About EU Cyber Resilience Act Compliance?

The scope here is wide, but let’s start with manufacturers. If you’re in the EU, (or if you’re not but sell into it) you must design your products with security in mind, provide technical documentation and conformity assessments, plus handle discovered vulnerabilities.

CRA covers products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect data connection. This means connected consumer devices, business hardware, mobile and desktop apps, operating systems and associated software libraries and components. There’s a manufacturers guide and a software developers guide to help you.

Importers must check that products they bring in are compliant whereas distributors must check that the CE marking and documentation is present, see the importer and distributor guide.

The scope here is broad, if you’re an open-source software steward for example, you’ll need to check your processes for vulnerability discovery, reporting and patching. The phrase “products with digital elements” covers connected devices from baby monitors to smart watches to surveillance cameras, applications and their underlying software components, password managers and smart assistants.

Cyber Resilience Act Compliance Requirements

The main point to keep in mind is that cyber resilience act compliance isn’t a single check at the quality assurance stage – it requires a comprehensive approach starting with secure design, secure development, vulnerability handling throughout the products supported lifetime, technical documentation, conformity assessment, CE marking, user information and support.

You’ll also need to identify the product class: default products generally allow self-assessment; important products are divided into Class I and Class II; and critical products are subject to the strictest assessment requirements. For important Class I products, self-assessment may depend on applying harmonized standards, common specifications or an applicable European cybersecurity certification scheme. Important Class II and critical products generally require assessment by a notified body.

This guide steps you through finding your product class.

Here’s a checklist of actions to take at each stage of the lifecycle:

Phase 1: Determine Whether You Are in Scope

Action item	Required output or evidence	Suggested owner
Identify all hardware, software, firmware, applications, components and associated remote-processing services offered in the EU.	Product inventory	Product Management
Document whether each item meets the CRA definition of a “product with digital elements.”	CRA applicability register	Legal / Compliance
Identify the organization’s role for each product, such as manufacturer, importer or distributor.	Economic-operator classification	Legal / Compliance
Review any claimed exclusions or exemptions and document the supporting rationale.	Written scope determination	Legal
Identify products already on the EU market and products planned for future release.	EU product and release register	Product Management
For a manufacturer outside the EU, determine whether an EU authorized representative is required.	Representative appointment or documented decision	Legal

Phase 2: Product Classification and Assessment Path

Action item	Required output or evidence	Suggested owner
Classify each in-scope product as default, important Class I, important Class II or critical.	Product classification register	Security / Compliance
Record the evidence and reasoning supporting each classification.	Classification assessment	Compliance
Determine the applicable conformity-assessment route for each product.	Conformity-assessment plan	Compliance / Legal
Identify products that may require assessment by a notified body and plan accordingly.	Notified-body engagement plan	Compliance

Phase 3: Governance and Ownership

Action item	Required output or evidence	Suggested owner
Appoint an executive sponsor for the CRA compliance program.	Executive sponsorship record	Executive Management
Assign accountable owners across product, engineering, security, legal, compliance, support and supply-chain functions.	CRA responsibility matrix	Program Manager
Establish escalation and decision-making processes for product vulnerabilities and incidents.	Governance and escalation procedure	Security / Legal
Establish regular management reporting on CRA readiness, risks, gaps and remediation.	CRA status dashboard	Program Manager

Phase 4: Cybersecurity Risk Management

Action item	Required output or evidence	Suggested owner
Perform and document a cybersecurity risk assessment for every in-scope product.	Product cybersecurity risk assessment	Product Security
Consider threats, attack surfaces, intended use, reasonably foreseeable use and potential impacts.	Threat model and risk register	Security Architecture
Use risk-assessment results during planning, design, development, production, delivery and maintenance.	Traceability between risks and controls	Engineering
Reassess risks after significant product changes or changes in the threat environment.	Updated risk assessments	Product Security

Phase 5: Secure Product Development

Action item	Required output or evidence	Suggested owner
Establish and document a secure development lifecycle.	Secure Development Lifecycle policy	Engineering / Security
Define security requirements before product development begins.	Product security requirements	Product Management / Security
Conduct threat modelling and security architecture reviews during design.	Threat models and review records	Security Architecture
Implement secure coding, peer review and controlled build and release practices.	Development standards and review evidence	Engineering
Perform appropriate security testing before release.	Security test results	Quality Assurance / Security
Remediate known exploitable vulnerabilities before placing the product on the EU market.	Vulnerability remediation evidence	Engineering

Phase 6: Secure-By-Default Configuration

Action item	Required output or evidence	Suggested owner
Configure products securely by default and minimize unnecessary functionality and attack surfaces.	Secure configuration baseline	Engineering
Protect product data against unauthorized access, disclosure, modification or loss.	Security architecture and test evidence	Engineering / Security
Apply appropriate authentication, authorization and least privilege controls.	Access-control design and tests	Engineering
Provide secure reset, recovery, update and configuration mechanisms where applicable.	Product design and test evidence	Engineering

Phase 7: Software Supply Chain Management

Action item	Required output or evidence	Suggested owner
Identify third-party, commercial and open-source components included in each product.	Component inventory	Engineering
Create and maintain a machine-readable Software Bill of Materials for each product.	Current SBOM	Engineering / Product Security
Perform security due diligence before integrating third-party components.	Supplier and component assessments	Procurement / Security
Monitor components for vulnerabilities, security advisories and end-of-support conditions.	Dependency-monitoring records	Product Security
Establish a process to report discovered component vulnerabilities to the relevant supplier or maintainer.	Component vulnerability procedure	Product Security

Phase 8: Vulnerability Management

Action item	Required output or evidence	Suggested owner
Establish a coordinated vulnerability disclosure policy and make a security contact available.	Published disclosure policy	Product Security
Establish processes to receive, acknowledge, triage, investigate and remediate vulnerability reports.	Vulnerability-handling procedure	Security Operations
Define vulnerability prioritization and remediation criteria.	Vulnerability rating and remediation standard	Product Security
Track vulnerabilities and remediation decisions throughout the product support period.	Vulnerability register	Product Security
Conduct regular testing and reviews to identify new vulnerabilities.	Scanning, testing and review records	Security Testing
Preserve evidence of vulnerability investigation, remediation, testing and closure.	Vulnerability case records	Product Security

Phase 9: Security Update Management

Action item	Required output or evidence	Suggested owner
Define and document the support period for each product.	Product support policy	Product Management
Establish a process to develop, test, release and distribute security updates.	Security update procedure	Engineering
Ensure security updates can be delivered securely and without avoidable delay.	Update architecture and operational evidence	Engineering
Inform users about security updates, affected versions and necessary actions.	Security advisories and release notes	Support / Communications
Retain and make previously issued security updates available for the required period.	Update repository and retention records	Engineering / Support

Phase 10: Incident Reporting Readiness

Action item	Required output or evidence	Suggested owner
Establish a process for identifying actively exploited vulnerabilities and severe product-security incidents.	Detection and classification procedure	Security Operations
Document the CRA notification workflow, including responsible decision-makers and escalation contacts.	CRA reporting playbook	Security / Legal
Prepare to submit required notifications through the designated EU reporting mechanism.	Reporting access and operating procedure	Security / Compliance
Integrate CRA notifications with existing incident-response, legal and customer-communications processes.	Integrated incident-response plan	Security / Legal
Conduct tabletop exercises covering an exploited vulnerability and a severe product incident.	Exercise report and improvement plan	Security Operations

Phase 11: User Information and Communication

Action item	Required output or evidence	Suggested owner
Provide instructions for secure installation, configuration, operation and maintenance.	Product security guidance	Product Documentation
Clearly communicate the product’s support period and security-update arrangements.	Customer-facing support statement	Product Management
Provide accessible information about relevant vulnerabilities, mitigations and available updates.	Advisories and customer notices	Support / Communications
Review warnings, documentation and security information for accuracy before release.	Documentation approval record	Product / Legal

Phase 12: Technical Documentation

Action item	Required output or evidence	Suggested owner
Compile the technical documentation required to demonstrate CRA compliance.	CRA technical file	Compliance
Include product descriptions, architecture, intended use, cybersecurity risks and implemented controls.	Technical design and risk documentation	Engineering / Security
Include test reports, vulnerability-handling evidence, SBOM information and update processes.	Compliance evidence library	Security / Engineering
Establish document control, approval, versioning and retention requirements.	Document-control procedure	Compliance
Ensure evidence remains traceable to the relevant product version and release.	Product-to-evidence traceability matrix	Compliance / Engineering

Phase 13: Conformity Assessment and Market Access

Action item	Required output or evidence	Suggested owner
Complete the applicable conformity assessment before placing the product on the EU market.	Conformity-assessment record	Compliance
Resolve identified nonconformities and retain evidence of corrective actions.	Corrective-action records	Engineering / Compliance
Prepare and approve the EU declaration of conformity.	EU declaration of conformity	Legal / Compliance
Apply the CE marking only after the applicable requirements have been satisfied.	CE-marking approval record	Compliance
Provide importers and distributors with the information needed to verify compliance.	Supply-chain compliance pack	Legal / Channel Management

Phase 14: Importer and Distributor Controls

Action item	Required output or evidence	Suggested owner
Verify that manufacturers have completed the appropriate conformity assessment.	Supplier verification record	Importer / Distributor
Verify that CE marking, required documentation and user information are present.	Product acceptance checklist	Importer / Distributor
Establish a process to stop supply where noncompliance or a significant cybersecurity risk is suspected.	Distribution hold and escalation procedure	Supply Chain / Legal
Maintain traceability records for manufacturers, importers, distributors and affected products.	Supply-chain traceability register	Supply Chain

Phase 15: Continuous Compliance

Action item	Required output or evidence	Suggested owner
Monitor regulatory guidance, harmonized standards and conformity-assessment developments.	Regulatory monitoring register	Legal / Compliance
Review compliance whenever the product, component set, intended use or threat profile changes.	Change-triggered compliance review	Product Security
Periodically audit the secure-development, vulnerability-handling and update processes.	Internal audit reports	Internal Audit / Compliance
Track corrective actions to completion and retain supporting evidence.	Corrective-action register	Program Manager
Perform periodic CRA readiness reviews for every in-scope product throughout its support lifecycle.	Product compliance review	Compliance

Use this checklist as a starting guide to figure out what your organization needs to do for cyber resilience act compliance, here’s more complete documentation.

Build (or adapt existing) processes for vulnerability intake, triage, remediation and coordinated disclosure. Plan your support period. Manufacturers must define it based on the product’s expected period of use; it is generally at least five years unless the expected period of use is shorter.

You must report actively exploited vulnerabilities and severe incidents in your products using ENISA’s Single Reporting Platform, this requirement came into effect on the 11th of September 2026. Produce technical documentation as part of your compliance evidence, including declarations of conformity and CE marking.

Manufacturers must submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, followed by a full notification within 72 hours. A final report is due within 14 days after a corrective measure becomes available for an actively exploited vulnerability, or within one month for a severe incident.

What the 2026 Cyber Resilience Act Guidelines Changed

If this is the first time you’ve seen the scope of what the CRA requires, and you have products that you know will be affected, the checklist and information above may seem overwhelming.

Fortunately, the Commission provided guidance in July 2026 which helps you understand scoping, remote data processing, free and open-source software (FOSS), substantial modification, support periods, reporting obligations, and risk assessments.

There are practical examples, use cases and flowcharts which will help you, particularly if you’re a smaller business which doesn’t have resources for regulatory compliance.

---

Where 365 Permission Manager Fits Into CRA Readiness

When preparing documentation, controlling access to product and vulnerability data and implementing security governance around collaboration environments, Hornetsecurity’s 365 Permission Manager helps secure and govern your SharePoint and OneDrive estates.

Strengthen least-privilege access and compliance governance in Microsoft 365 with 365 Permission Manager.

Cyber Resilience Act compliance starts with product security, vulnerability handling and documentation, but strong governance also depends on controlling who can access sensitive compliance, engineering and customer data.

365 Permission Manager helps Microsoft 365 organizations manage permissions and enforce compliance policies across SharePoint, OneDrive and Teams, reducing permission sprawl and supporting a more disciplined security environment.

---

Conclusion

For consumers CRA will mean more products that are secure by default, and they will be patched when vulnerabilities are discovered, with more accountability for suppliers. The same goes for business, while many examples of how and where CRA will apply show consumer products, businesses use digital tools and hardware that will definitely be in scope.

For us in the cybersecurity industry, cyber resilience act compliance is just putting into law what we’ve been saying for many years:

• Design security into products from the outset.
• Test for vulnerabilities before release.
• Be responsible for the entire lifecycle of the product and manage the inevitable software risks with regular updates.
• Report actively exploited vulnerabilities and serious incidents to authorities.
• Supply information to help customers use the product securely.

In other words, this is common sense and the minimum quality bar expected from modern digital products.

The two dates to keep in mind are 11th of September 2026 for reporting obligations and 11th of December 2027 for the main obligations to kick in. Start now by building your product inventory, assign ownership, prepare reporting workflows, and strengthen access governance around compliance documentation and product security data. Good luck on your cyber resilience act compliance journey.