The Cyber Resilience Act Explained: What Software and Technology Companies Need to Know
The EU Cyber Resilience Act raises the standard for secure software, connected products, vulnerability management and security updates.
What is the Cyber Resilience Act?
The Cyber Resilience Act is Regulation (EU) 2024/2847.
It creates a common set of cybersecurity requirements for hardware and software products made available on the European Union market.
The CRA covers the security of a product throughout its lifecycle, including:
Planning
Design
Development
Production
Delivery
Maintenance
Vulnerability handling
Security updates
The regulation follows a product compliance model similar to other European product rules.
Before placing an in-scope product on the EU market, the manufacturer must assess whether it meets the applicable cybersecurity requirements, prepare the required documentation and complete the relevant conformity assessment process.
When does the CRA apply?
The CRA entered into force on 10 December 2024.
However, its requirements apply in stages.
11 June 2026
The provisions concerning the notification of conformity assessment bodies began applying.
These are the organisations that may perform third-party conformity assessments for certain products.
11 September 2026
Manufacturers must begin reporting certain actively exploited vulnerabilities and severe security incidents.
This is the most immediate deadline for many companies.
11 December 2027
The main CRA obligations become applicable.
This includes the essential cybersecurity requirements, technical documentation, conformity assessment and CE marking obligations.
Companies should not interpret the 2027 date as permission to wait.
The reporting duties begin in September 2026, and building the necessary product security processes can take significant time.
Which products are covered?
The CRA applies to products with digital elements that are made available on the EU market.
A product with digital elements can include:
Software products
Hardware products
Software components
Hardware components
Remote data-processing solutions that are necessary for a product to perform one of its functions
The product must also have an intended or reasonably foreseeable direct or indirect connection to a device or network.
Examples may include:
Mobile applications
Desktop software
Operating systems
Network management tools
Security software
Internet of Things devices
Smart consumer products
Industrial software
Routers and firewalls
Embedded software
Commercial software components
Both final products and components sold separately can fall within the CRA.
Does the CRA apply to SaaS?
The answer is not a simple yes or no.
The CRA is not a blanket cybersecurity law covering every online service simply because it is described as SaaS.
The correct assessment depends on how the service operates and how it is supplied.
Important questions include:
Is the offering a software product made available on the EU market?
Is it connected directly or indirectly to a device or network?
Does it form part of another product with digital elements?
Is remote processing necessary for that product to perform one of its functions?
Is the software supplied under the company’s name or trademark?
Is another piece of EU legislation more specifically applicable?
A remote data-processing solution may fall within the CRA when it is designed or developed by the manufacturer, or under the manufacturer’s responsibility, and the product could not perform one of its functions without it.
Companies should therefore avoid making broad assumptions based only on labels such as SaaS, cloud platform or web application.
A product-level scope assessment is necessary.
Who is responsible?
The main responsibilities fall on manufacturers.
Under the CRA, the manufacturer is generally the person or company that develops or manufactures a product with digital elements, or has it developed or manufactured, and markets it under its own name or trademark.
This can apply whether the product is offered:
For payment
Through another form of monetisation
Free of charge as part of a commercial activity
The CRA can therefore affect companies outside the European Union when they make products available on the EU market.
Importers and distributors also have responsibilities.
Importers must check that the manufacturer has completed relevant compliance steps, including technical documentation, conformity assessment and CE marking.
Distributors must verify certain product information and must not continue making a product available when they know, or have reason to believe, that it does not comply with the CRA.
What about open-source software?
The CRA contains a specific approach to free and open-source software.
Software that is developed or supplied outside a commercial activity may fall outside the normal manufacturer obligations.
However, describing software as open source does not automatically remove it from the CRA.
The way the software is developed, supported, monetised and made available matters.
The Regulation also introduces the concept of an open-source software steward.
This can include a legal entity that provides sustained support for the development of specific open-source software intended for commercial activities.
Open-source organisations and companies using commercial open-source models should conduct a careful assessment rather than assuming they are excluded.
What does the CRA require from manufacturers?
1. Conduct a cybersecurity risk assessment
Manufacturers must perform a cybersecurity risk assessment for the product.
The assessment should influence decisions during:
Planning
Design
Development
Production
Delivery
Maintenance
The risk assessment should not be treated as a document created after development is complete.
It should guide the security measures built into the product.
2. Build security into the product
Products must be designed, developed and produced in accordance with the CRA’s essential cybersecurity requirements.
Depending on the product and its risks, this can include measures relating to:
Secure configurations
Access control
Protection against unauthorised access
Confidentiality and integrity
Data minimisation
Availability and resilience
Attack-surface reduction
Security logging
Secure updates
Protection from known vulnerabilities
The exact measures required will depend on the product’s purpose, functionality and cybersecurity risk.
3. Manage vulnerabilities throughout the support period
The manufacturer’s responsibility does not end when the product is released.
Manufacturers must establish processes to identify, document, remediate and disclose vulnerabilities.
They must also define a support period during which vulnerabilities will be handled effectively.
The end date of that support period must be communicated clearly to users.
Evidence of vulnerability handling may include:
Vulnerability reports
Triage records
Severity assessments
Patch decisions
Remediation records
Update logs
Disclosure communications
Component and dependency records
4. Report actively exploited vulnerabilities
From 11 September 2026, manufacturers must report actively exploited vulnerabilities that they become aware of.
The reporting process includes:
An early warning within 24 hours
A main notification within 72 hours
A final report no later than 14 days after a corrective or mitigating measure becomes available
The notifications will be submitted through the CRA Single Reporting Platform maintained by ENISA.
5. Report severe security incidents
Manufacturers must also report severe incidents affecting the security of their products.
The process includes:
An early warning within 24 hours
A main notification within 72 hours
A final report within one month of the 72-hour notification
This means companies need more than an incident response policy.
They need clear internal processes for identifying reportable events, escalating them, documenting decisions and meeting short regulatory deadlines.
6. Maintain technical documentation
Manufacturers must prepare technical documentation showing how the product meets the CRA requirements.
The documentation should include relevant information about:
The product and its intended purpose
Product design and development
The cybersecurity risk assessment
Security measures
Vulnerability-handling processes
Testing
Standards or technical specifications used
The conformity assessment
Supporting evidence
Market surveillance authorities may request this documentation.
It should therefore be accurate, current and connected to the product’s real implementation.
7. Complete a conformity assessment
Before placing an in-scope product on the EU market, the manufacturer must complete the relevant conformity assessment procedure.
For many standard products, self-assessment may be permitted.
However, stricter procedures apply to important and critical products with digital elements.
Important products are divided into Class I and Class II.
Depending on the category and the standards used, Class I products may require third-party assessment.
Important Class II products and critical products generally require a notified body or an applicable European cybersecurity certification route.
Examples of products that may face stricter requirements include certain:
Operating systems
Antivirus products
Routers
Firewalls
Hypervisors
Secure elements
Smart cards
Network management systems
Product classification should therefore happen early.
Discovering late that a notified body is required could delay market access.
8. Prepare the declaration and CE marking
Once the appropriate conformity assessment has been completed successfully, the manufacturer must prepare an EU Declaration of Conformity.
The product must also carry the CE marking in accordance with the applicable rules.
The CE marking does not mean that a regulator has personally inspected every product.
It represents the manufacturer’s declaration that the product meets the applicable EU requirements, supported by the required assessment route and technical documentation.
The biggest mistake companies can make
The biggest mistake is treating the CRA as a document-generation exercise.
A company might have:
A secure development policy
A vulnerability management policy
An incident response plan
A supplier security policy
A product security statement
Those documents are useful.
But they do not prove that the processes are working.
A stronger CRA compliance record would connect each requirement to:
The relevant risk
The documented control
The real implementation
The supporting evidence
The responsible owner
The review history
Any unresolved gaps
For example, a vulnerability management policy might say that critical vulnerabilities are remediated quickly.
The supporting evidence should show:
When the vulnerability was discovered
How it was classified
Who reviewed it
What corrective action was taken
When the fix was released
Whether affected users were informed
Whether regulatory reporting was considered
That is the difference between a written intention and a defensible compliance record.
How companies should prepare
Step 1: Build a product inventory
Identify the software, hardware, components and connected products your company develops or sells.
Do not assess the company as one single product.
Different products may have different scope and classification outcomes.
Step 2: Conduct a CRA scope assessment
For each product, determine:
Whether it is made available on the EU market
Whether it has a direct or indirect connection to a device or network
Whether remote processing forms part of its functionality
Whether it is covered by sector-specific legislation
Whether it may qualify as an important or critical product
Document the reasoning behind the decision.
Step 3: Assign responsibility
The CRA affects several teams, including:
Product
Engineering
Security
Legal
Compliance
Customer support
Incident response
Supply-chain management
Assign a clear owner for the CRA programme and define which teams are responsible for each obligation.
Step 4: Prepare for the September 2026 reporting deadline
Create a process for identifying and reporting:
Actively exploited vulnerabilities
Severe incidents affecting product security
The process should include:
Clear reporting criteria
Escalation contacts
Decision-making authority
Legal and technical review
Evidence preservation
24-hour and 72-hour response procedures
Final reporting responsibilities
Step 5: Review the secure development lifecycle
Compare current product-development practices against the CRA’s essential cybersecurity requirements.
Look for gaps in areas such as:
Threat modelling
Secure design
Code review
Dependency management
Security testing
Vulnerability disclosure
Patch management
Update delivery
Logging
Incident response
Step 6: Review third-party components
Manufacturers must exercise due diligence when integrating third-party components.
Create an inventory of:
Open-source dependencies
Commercial libraries
Embedded components
External services
Product integrations
Software suppliers
Record how component risks are assessed, monitored and addressed.
Step 7: Create an evidence structure
Do not wait until the conformity assessment to begin collecting evidence.
Evidence should be organised while the product is being designed, developed, tested and maintained.
Examples include:
Risk assessments
Threat models
Test reports
Code-review records
Vulnerability tickets
Patch records
Release notes
Incident logs
Supplier assessments
Product documentation
Approval records
Review histories
Common CRA misconceptions
“The deadline is in 2027, so we can wait.”
The main obligations apply in December 2027, but vulnerability and incident reporting begins in September 2026.
“Every SaaS platform is automatically covered.”
The SaaS label alone does not determine CRA scope. The product, functionality, delivery model and role of remote processing must be assessed.
“The CRA only applies to physical devices.”
Software products and separately supplied software components can also be covered.
“A cybersecurity policy is enough.”
The CRA requires real cybersecurity measures, vulnerability handling, technical documentation and evidence supporting conformity.
“Every product needs a third-party audit.”
Many standard products may use self-assessment. Important and critical products can face stricter conformity assessment requirements.
“CE marking means the product is completely secure.”
CE marking shows that the manufacturer declares conformity with applicable requirements. It does not guarantee that the product can never contain a vulnerability or experience an incident.
Final thoughts
The Cyber Resilience Act represents a major shift in European product cybersecurity.
Security will need to be considered before release, maintained after release and supported by evidence throughout the product lifecycle.
For many companies, the difficult part will not be understanding that cybersecurity matters.
The difficult part will be proving that security requirements were translated into real controls, real product decisions and real vulnerability-management processes.
The strongest preparation strategy is therefore not:
Write more policies before 2027.
It is:
Build a clear chain from risk, to control, to implementation, to evidence.
That is how companies prepare for regulatory review, customer scrutiny and product conformity without relying on last-minute paperwork.
Kodex Compliance helps growing companies organise requirements, controls, implementation evidence and review history across the CRA and other compliance frameworks.
Learn more at kodex-compliance.com
References
European Commission, Cyber Resilience Act, including scope, purpose and application dates.
European Commission, The Cyber Resilience Act: Summary of the Legislative Text, including definitions, manufacturer obligations, importer and distributor duties, reporting timelines, technical documentation and product classification.
European Commission, Cyber Resilience Act: Reporting Obligations, covering the reporting framework for actively exploited vulnerabilities and severe incidents.
European Commission, Cyber Resilience Act: Conformity Assessment, covering self-assessment, important products, critical products and notified bodies.
European Commission, Cyber Resilience Act: Manufacturers, covering risk assessment, secure product development, CE marking, support periods and post-market vulnerability handling.
Disclaimer: This article provides general information and does not constitute legal advice. CRA scope and obligations should be assessed based on the specific product, business model and applicable EU legislation.
Build the evidence trail
Kodex Compliance helps teams turn questionnaires, documents, implementation proof, and reviewer decisions into a clear compliance record.
Request demo