The Cyber Resilience Act does not have a single compliance deadline.
The EU regulation entered into force on December 10, 2024, but its obligations are being introduced in stages. The first major operational requirement arrives on September 11, 2026, when manufacturers must begin reporting actively exploited vulnerabilities and severe security incidents. The CRA becomes fully applicable on December 11, 2027, when the broader cybersecurity, vulnerability management, conformity assessment, technical documentation and CE-marking requirements apply.
For manufacturers of software and hardware products with digital elements, the practical question is therefore not simply "When does the CRA apply?"
It is:
What should we have completed already, what must be operational now, and what still needs to be in place before December 2027?
The easiest way to understand the CRA is to separate reporting readiness from full product compliance.
| Date | What happens | What manufacturers should focus on |
| December 10, 2024 | CRA enters into force | Start assessing product scope and compliance requirements |
| June 11, 2026 | Provisions on conformity assessment bodies apply | Plan conformity assessment and identify relevant assessment routes |
| September 11, 2026 | Article 14 reporting obligations apply | Operationalize vulnerability and incident reporting |
| Q3 2026 | First CRA standardisation deliverables | Start mapping technical controls and processes to emerging standards |
| Q4 2026 | Further product-specific standardisation deliverables | Refine product-specific compliance plans |
| December 11, 2027 | CRA becomes fully applicable | Meet the full set of applicable product cybersecurity and conformity requirements |
The dates are important, but they do not represent six independent compliance projects. They form one roadmap.
September 2026 is primarily about reporting readiness. December 2027 is about demonstrating that the product itself, its development process, and its lifecycle security meet the CRA's requirements.
The CRA applies to products with digital elements made available on the EU market. This includes software and hardware products, as well as certain components and remote data-processing solutions associated with those products. The regulation places cybersecurity responsibilities primarily on manufacturers, while also establishing obligations for importers, distributors and certain open-source software stewards.
For manufacturers, we can break up CRA compliance in six areas:
The important point is that compliance is not something added immediately before a product launch. The CRA requires cybersecurity to be a part of the product lifecycle.
Before creating a compliance plan, manufacturers need to establish exactly which products in their portfolio are in scope.
The CRA generally covers hardware and software products made available on the EU market where their intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Some products covered by other EU legislation are excluded or treated differently, so scope needs to be assessed product by product.
This makes product inventory one of the first practical CRA compliance tasks.
Your inventory should answer:
Do not treat the product inventory as a one-time spreadsheet. Product scope can change as products evolve, substantially change or move into different regulatory categories.
The CRA requires manufacturers to perform a cybersecurity risk assessment for products with digital elements.
That assessment should inform how the essential cybersecurity requirements are implemented throughout planning, design, development, production, delivery and maintenance. Manufacturers also need to document the risk assessment and the measures selected to address the applicable requirements.
In practice, this means security requirements should be connected to the actual product architecture and threat model.
A useful CRA risk assessment should help answer questions such as:
This is also where teams should begin connecting their CRA work to existing secure development, vulnerability management and product security processes.
One of the CRA's biggest changes is that cybersecurity becomes a requirement for the product itself, from design and development through its support period.
Under the CRA, manufacturers need to ensure that products are designed, developed and produced in accordance with the essential cybersecurity requirements in Annex I. The regulation addresses security throughout the product lifecycle, including vulnerability handling during the support period.
For engineering and product teams, this translates into areas such as:
Security needs to be considered during architecture, development and testing rather than added after the product is complete.
Products should be delivered with security-conscious defaults that reduce unnecessary exposure.
Manufacturers need to consider how unnecessary interfaces, services and functionality could increase cybersecurity risk.
Authentication, access control and other security mechanisms need to be appropriate to the product's risks and intended use.
The CRA includes requirements addressing the confidentiality and integrity of data handled by products with digital elements.
Manufacturers need processes for addressing vulnerabilities throughout the product's defined support period.
The goal is not to produce a generic "secure product" checklist. The CRA expects manufacturers to apply these requirements in the context of the specific product and its cybersecurity risk assessment.
This is one of the most important parts of the CRA compliance roadmap because vulnerability management does not end when a product ships.
Manufacturers must handle vulnerabilities affecting their products during the support period. The CRA's vulnerability-handling requirements cover activities such as identifying and documenting vulnerabilities, addressing them through security updates and communicating relevant information.
Your process should therefore answer:
How does a vulnerability move from discovery to remediation?
A mature workflow should cover:
Detection → Triage → Risk assessment → Remediation → Security update → Communication → Documentation
That process also needs visibility into the components that make up the product.
Which brings us to one of the most important CRA compliance artifacts: the SBOM.
A Software Bill of Materials (SBOM) provides an inventory of the software components and dependencies contained within a product.
Manufacturers need to keep track of the software components in their products and any vulnerabilities they contain. They must also maintain an SBOM that lists at least the product’s main software dependencies in a machine-readable format.
For compliance teams, the important question is therefore not simply:
"Do we have an SBOM?"
It is:
When a new vulnerability is found, do we know which of our products and versions are affected?
That requires the SBOM to be connected to the broader vulnerability management process.
For many organizations, this is where CRA preparation becomes an engineering and operational data problem rather than a documentation exercise.
From September 11, 2026, manufacturers must report:
The reporting process uses the CRA Single Reporting Platform. An early warning is due within 24 hours of becoming aware, followed by a fuller notification within 72 hours. Final reporting timelines then differ depending on whether the notification concerns an actively exploited vulnerability or a severe incident.
For actively exploited vulnerabilities:
24 hours → early warning
72 hours → main notification
14 days after a corrective or mitigating measure becomes available → final report
For severe incidents:
24 hours → early warning
72 hours → main notification
Within one month from the 72-hour submission → final report
The reporting requirement is particularly important because the clock starts when the manufacturer becomes aware.
That makes detection and escalation capabilities part of CRA reporting readiness. If your organization cannot identify a qualifying event quickly, a perfectly documented reporting process will not solve the underlying problem.
By December 2027, manufacturers need to demonstrate conformity with the applicable CRA requirements.
The assessment route depends on the product and its classification.
For some products, manufacturers can use internal control/self-assessment. Other products, particularly those classified as important or critical, may require assessment by a notified body, unless another permitted route is available.
That means manufacturers should identify the applicable product category early rather than waiting until 2027 to determine how conformity will be demonstrated.
Your roadmap should include:
The CRA's requirements are written at a regulatory level. Harmonized standards are intended to give manufacturers more concrete technical and process guidance for demonstrating conformity.
The first CRA standardisation deliverables are scheduled across 2026, including horizontal work covering areas such as cyber resilience and vulnerability handling, as well as product-specific standards for important and critical product categories. The broader standardisation programme continues into 2027.
This is why manufacturers should not treat standards development as something to watch passively.
As standards mature, teams can use them to map:
CRA requirement → standard → product control → evidence
Using the relevant standards can make it easier to prepare your technical documentation and show that your product meets the CRA requirements. However, the CRA standards are still being developed. Before relying on a specific standard, check whether it has been officially recognised as a harmonised standard and whether its reference has been published in the Official Journal of the EU. Only then can it help show that your product complies with the CRA.
A CRA roadmap should not be measured by how many documents have been created.
It should be measured by whether the organization can demonstrate that its processes actually work.
Ask these questions:
Not just your current flagship products. Include older versions that remain on the EU market or continue to receive support.
The 24-hour deadline means manufacturers need to detect reportable security issues quickly and have a clear process for escalating them.
If the answer requires manually searching engineering documentation, your SBOM and vulnerability-management processes probably need work.
A policy document is not enough. You should be able to show the workflow from discovery through remediation and communication.
Waiting until late 2027 to determine whether third-party assessment is required creates unnecessary scheduling and remediation risk.
CRA compliance is ultimately about more than implementing security controls. Manufacturers need technical documentation and evidence supporting their conformity claims.
If several answers are "not yet," that does not mean your product is necessarily non-compliant today. It means that those areas belong on the roadmap.
CRA compliance is ultimately tied to market access and enforcement.
Member States are responsible for establishing penalties, while market surveillance authorities can take corrective or restrictive measures when products present cybersecurity risks or do not comply with the regulation.
For certain serious infringements, the CRA provides for administrative fines of up to €15 million or 2.5% of the undertaking's total worldwide annual turnover from the preceding financial year, whichever is higher. The maximum does not automatically apply to every compliance failure, and the applicable penalty depends on the infringement and national enforcement rules.
The practical consequence is more important than the headline number:
CRA compliance needs to become part of product governance before the final deadline, not a final certification exercise in December 2027.
The most useful way to approach the CRA is not as a single regulatory deadline. It is a structured product security programme.
2026 is about operational readiness.
Get products inventoried. Establish vulnerability handling. Build reporting workflows. Prepare for Article 14. Start mapping requirements to controls and standards.
2027 is about demonstrating compliance.
Complete the remaining product security work, finalize technical documentation, complete the appropriate conformity assessment and prepare for the CRA's full application on December 11, 2027.
The organizations best positioned for the CRA are not necessarily the ones with the largest compliance teams. They are the ones that can connect product security, vulnerability management, engineering evidence and regulatory requirements into one repeatable process.
The deadline is fixed. Your roadmap should be too.
