EU Cyber Resilience Act (CRA) Compliance: A Comprehensive Guide

Connected products are becoming part of almost every consumer and industrial product category. Smart appliances, security cameras, wearable devices, network equipment, mobile applications, embedded software and cloud-connected products can all create cybersecurity risks if they are not designed, maintained and updated securely.

The European Union has responded with the Cyber Resilience Act, formally known as Regulation (EU) 2024/2847.

The Cyber Resilience Act (CRA) introduces mandatory cybersecurity requirements for hardware and software products placed on the European Union market. It changes cybersecurity from a largely voluntary technical practice into a formal product compliance obligation.

Manufacturers must assess cybersecurity risks, build security into the product, document their compliance, manage vulnerabilities, provide security updates and, where required, report actively exploited vulnerabilities and severe security incidents.

For many products, CRA compliance will also become part of the CE-marking process.

What Is the EU Cyber Resilience Act?

The Cyber Resilience Act is a horizontal EU product cybersecurity regulation. It applies broadly to hardware and software products with digital elements that are made available on the European Union market.

Its purpose is to ensure that products are developed securely and remain secure throughout their expected period of use. It also aims to give users clearer information about product security, available updates and the duration of cybersecurity support.

The CRA addresses two recurring problems in the digital product market:

1. Products are often placed on the market with inadequate cybersecurity safeguards or known vulnerabilities.
2. Manufacturers may provide insufficient security updates, vulnerability information or post-market support after a product has been sold.

Under the CRA, manufacturers must consider cybersecurity during the planning, design, development, production, delivery and maintenance of a product. Cybersecurity is therefore no longer limited to a final penetration test or pre-launch review. It must be integrated into the product lifecycle.

Further information is available in the European Commission’s Cyber Resilience Act summary.

When Does the Cyber Resilience Act Apply?

The CRA entered into force on 10 December 2024, but its requirements apply in stages.

• 11 June 2026: Provisions concerning the notification of conformity assessment bodies begin to apply.
• 11 September 2026: Reporting obligations for actively exploited vulnerabilities and severe security incidents begin to apply.
• 11 December 2027: Most remaining CRA requirements become fully applicable.

Products placed on the EU market before 11 December 2027 are generally subject to the main CRA requirements only if they undergo a substantial modification after that date. However, the reporting obligations applying from 11 September 2026 can also affect products that were already made available on the EU market.

Manufacturers should not wait until December 2027 to begin preparing. Establishing a secure development process, producing a Software Bill of Materials, completing cybersecurity testing and implementing vulnerability-reporting procedures can take considerable time.

Which Products Are Covered by the CRA?

The CRA generally applies to a product with digital elements whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

A product with digital elements may include:

• A hardware product
• A software product
• Hardware or software components sold separately
• Embedded firmware
• Remote data-processing solutions necessary for the product to perform one of its functions

Remote data processing may include a manufacturer-controlled cloud service where the absence of that service would prevent the product from performing one of its intended functions.

Examples of Potentially Covered Products

Depending on their functions and how they are supplied, products covered by the CRA may include:

• Internet of Things devices
• Smart-home products
• Connected household appliances
• Smart security cameras and alarm systems
• Smart locks
• Connected toys
• Wearable devices
• Routers, modems and network switches
• Computers, smartphones and tablets
• External storage devices
• Network interface products
• Industrial control products
• Connected sensors
• Access-control systems
• Operating systems
• Mobile and desktop applications
• Password managers
• Virtual private network software
• Firewalls
• Antivirus and malware-detection software
• Embedded software and firmware
• Software libraries and commercial software components
• Video games and other standalone software

The definition is deliberately broad. A product does not necessarily need to connect directly to the internet. An indirect connection to another device or network may be sufficient.

For example, a Bluetooth-enabled product that connects to a smartphone application may fall within the CRA even if the product itself does not connect directly to the internet.

Does the CRA Apply to Standalone Software?

Yes. Standalone software made available on the EU market can fall within the scope of the CRA.

This may include:

• Mobile applications
• Desktop applications
• Operating systems
• Security software
• Commercial software libraries
• Device-management software
• Network-management tools
• Software sold through download platforms
• Software supplied without a separate physical product

Whether software is covered depends on how it is supplied, whether it is made available as part of a commercial activity and whether a specific exclusion applies.

Software supplied entirely as a service may require a more detailed assessment. The CRA does not generally regulate every software-as-a-service arrangement, but remote data-processing functionality that is necessary for a covered product to perform one of its functions may form part of the product with digital elements.

What Products Are Excluded?

Certain product categories are excluded or regulated through other sector-specific EU legislation.

Depending on the circumstances, exclusions can apply to products covered by legislation governing:

• Medical devices
• In vitro diagnostic medical devices
• Civil aviation
• Motor vehicles
• Certain marine equipment
• Products developed exclusively for national security or defence purposes
• Certain free and open-source software supplied outside a commercial activity

The treatment of open-source software requires particular care. Software made available outside a commercial activity may be excluded, while commercially supplied open-source products and certain open-source software stewards can have CRA obligations.

A product should not be treated as excluded merely because it is subject to another EU law. Manufacturers must examine whether the other legislation specifically covers the relevant cybersecurity requirements and whether the CRA provides a full or partial exclusion.

Who Is the Manufacturer Under the CRA?

The manufacturer is the natural or legal person that develops, manufactures or has a product with digital elements designed, developed or manufactured, and markets that product under its own name or trademark.

A company may therefore be considered the manufacturer even when:

• The physical product is made by a third-party factory.
• The software is developed by an external contractor.
• Firmware is supplied by another company.
• The company imports a finished product and sells it under its own brand.
• Development work is outsourced to software engineers or technical service providers.

Outsourcing development does not outsource the manufacturer’s legal responsibility.

The company placing the product on the market under its name or trademark must ensure that the complete product, including third-party software and hardware components, meets the CRA requirements.

What Are the Manufacturer’s Main CRA Obligations?

Manufacturers carry the main responsibility for compliance.

Before placing a product with digital elements on the EU market, the manufacturer must generally:

1. Determine whether the product falls within the scope of the CRA.
2. Determine whether the product is a default, important or critical product.
3. Perform a cybersecurity risk assessment.
4. Design, develop and produce the product in accordance with the essential cybersecurity requirements.
5. Exercise due diligence when integrating third-party components.
6. Establish vulnerability-handling processes.
7. Determine and document the product support period.
8. Prepare the required technical documentation.
9. Carry out the appropriate conformity assessment.
10. Prepare and sign the EU Declaration of Conformity.
11. Affix the CE marking.
12. Provide the required product information and security instructions.
13. Monitor vulnerabilities and incidents after the product is placed on the market.
14. Provide security updates during the support period.
15. Take corrective action when a product is non-compliant or presents a cybersecurity risk.
16. Meet the applicable vulnerability and incident-reporting deadlines.

The manufacturer must be able to demonstrate compliance through records, procedures and technical evidence. A general statement that a product is secure will not be sufficient.

Essential Cybersecurity Requirements

Annex I of the CRA contains the essential cybersecurity requirements.

These requirements are divided into two main areas:

• Cybersecurity properties of the product
• Vulnerability-handling requirements

Security by Design and by Default

Products must be designed, developed and produced to ensure an appropriate level of cybersecurity based on their risks.

Depending on the product, this can require measures addressing:

• Secure default configurations
• Authentication
• Access control
• Confidentiality
• Encryption
• Data integrity
• Service and system availability
• Protection against unauthorised access
• Protection against manipulation
• Attack-surface reduction
• Limitation of exposed interfaces
• Secure communication
• Resilience against denial-of-service attacks
• Security logging and monitoring
• Secure data deletion
• Reduction of unnecessary data processing
• Protection against known attack techniques
• Secure update mechanisms
• Recovery from security incidents

The appropriate controls depend on the product, its intended use, reasonably foreseeable misuse, operating environment and potential consequences of a successful cyberattack.

No Known Exploitable Vulnerabilities

A product must not be placed on the market with known exploitable vulnerabilities.

This requires more than conducting a one-time test immediately before launch. Manufacturers need a process for identifying, evaluating, prioritising and resolving vulnerabilities affecting:

• Proprietary software
• Firmware
• Operating systems
• Open-source libraries
• Third-party software components
• Communication protocols
• Hardware components
• Cloud dependencies
• Mobile applications
• Application programming interfaces

Secure Updates

Where security updates are required, manufacturers must make them available without delay and generally free of charge during the support period.

For many products, security updates should be installed automatically by default where technically feasible. Users should generally be able to postpone or disable automatic installation through a clear and accessible mechanism.

Security updates should, where feasible, be separated from feature updates. This helps prevent users from being forced to accept unrelated functional changes merely to receive an essential security correction.

Cybersecurity Risk Assessment

The cybersecurity risk assessment is one of the central CRA documents.

It should not be a generic IT security checklist. It must relate to the specific product, its components, intended use, foreseeable use, users, data, connectivity and operating environment.

What the Risk Assessment Should Cover

A suitable risk assessment may consider:

• Product architecture
• Hardware and software components
• Communication technologies
• Network interfaces
• Cloud services
• Mobile applications
• User roles and privileges
• Authentication methods
• Data processed or stored
• Encryption and key management
• Update mechanisms
• Third-party dependencies
• Potential threat actors
• Attack vectors
• Known weaknesses
• Foreseeable misuse
• Consequences of compromise
• Existing security controls
• Residual risks
• Required testing
• Vulnerability-handling measures
• Post-market monitoring

When the Risk Assessment Should Be Updated

The assessment must inform the product’s design and development. It should also be reviewed when significant changes occur, such as:

• A major software update
• A new product function
• A change to the product architecture
• The integration of a new third-party component
• A significant new threat
• Discovery of an actively exploited vulnerability
• A change to the product’s intended use
• A substantial change to cloud or network infrastructure

The risk assessment forms part of the technical documentation and may be requested by market surveillance authorities.

Software Bill of Materials

A Software Bill of Materials, commonly called an SBOM, is a structured inventory of the software components contained in a product.

Information Commonly Included in an SBOM

An SBOM may identify:

• Proprietary software modules
• Open-source libraries
• Third-party dependencies
• Firmware components
• Component names
• Component versions
• Suppliers
• Licences
• Dependency relationships
• Known vulnerability references
• Package identifiers

The SBOM helps the manufacturer determine whether its products are affected when a vulnerability is discovered in a third-party component.

Why the SBOM Must Be Maintained

For example, if a widely used software library is found to contain a critical vulnerability, the manufacturer should be able to identify quickly:

• Which products use the affected library
• Which product versions are affected
• Whether the vulnerable function is reachable or exploitable
• Whether a corrective update is required
• Which customers or authorities must be informed
• Whether the CRA reporting obligations are triggered

An SBOM is not useful if it is created once and never updated. Manufacturers need version control and a process for maintaining it as the software changes.

Vulnerability-Handling Requirements

CRA compliance continues after the product has been placed on the market.

Manufacturers must establish processes to:

• Identify vulnerabilities
• Receive vulnerability reports
• Document vulnerabilities
• Assess their severity and exploitability
• Monitor vulnerabilities affecting third-party components
• Test and review product security
• Correct vulnerabilities without delay
• Distribute security updates securely
• Inform users about available corrections
• Publicly disclose information about fixed vulnerabilities where required
• Preserve the confidentiality of vulnerability information until a correction is available
• Maintain a coordinated vulnerability disclosure policy

Coordinated Vulnerability Disclosure

Manufacturers should publish a clear and actively monitored method through which security researchers, customers and other parties can report vulnerabilities.

The process should identify:

• The reporting contact
• The information reporters should provide
• The manufacturer’s acknowledgement process
• Expected response times
• Confidentiality expectations
• How the manufacturer coordinates disclosure
• How security researchers will be treated
• How corrections and advisories will be published

CRA Reporting Obligations From September 2026

The reporting obligations under Article 14 apply from 11 September 2026.

Manufacturers must report certain actively exploited vulnerabilities and severe incidents through the CRA Single Reporting Platform maintained by the European Union Agency for Cybersecurity (ENISA).

Reporting Deadlines

The reporting process generally includes:

• An early-warning notification within 24 hours
• A more detailed notification within 72 hours
• A final report within the applicable statutory period

Actively Exploited Vulnerabilities

For an actively exploited vulnerability, the final report is generally required no later than 14 days after a corrective or mitigating measure becomes available.

Severe Security Incidents

For a severe security incident, the final report is generally required within one month of the 72-hour notification.

The reporting deadline begins when the manufacturer becomes aware of the relevant vulnerability or incident. Manufacturers therefore need internal escalation procedures that allow information to reach the responsible compliance and security personnel quickly.

A vulnerability discovered by a customer-support team, external researcher, distributor, software supplier or overseas development office may trigger the same legal reporting process as a vulnerability discovered by the manufacturer’s central cybersecurity team.

What Is an Actively Exploited Vulnerability?

An actively exploited vulnerability is not merely a theoretical weakness or every entry in a vulnerability database.

In practice, the manufacturer must assess whether there is reliable evidence that a malicious actor has exploited the vulnerability in a system without the permission of the system owner.

This distinction matters because the CRA reporting obligation is linked to active exploitation, not simply to the existence of every potential vulnerability.

However, manufacturers must still identify, evaluate and remediate vulnerabilities that are not actively exploited as part of their general vulnerability-handling obligations.

Support Period and Security Updates

Manufacturers must determine a support period during which vulnerabilities will be handled and security updates will be provided.

Factors Affecting the Support Period

The support period must reflect factors such as:

• The expected period of use
• The nature and intended purpose of the product
• Reasonable user expectations
• The operating environment
• The duration for which similar products are normally supported
• The availability of spare parts or connected services
• The cybersecurity risks associated with discontinued support

The end date of the support period, including the month and year, must be communicated clearly to users at the time of purchase.

Manufacturers should avoid treating the support period as a marketing statement with no operational basis. They must have the technical and organisational ability to monitor vulnerabilities, develop updates and distribute those updates throughout the declared period.

Long-Term Supplier Arrangements

This may require long-term arrangements with:

• Software developers
• Firmware suppliers
• Cloud providers
• Component manufacturers
• Mobile application developers
• Cybersecurity monitoring services
• Testing laboratories
• Hosting and infrastructure providers

Product Information and User Instructions

Products covered by the CRA must be accompanied by clear information and instructions.

Depending on the product, the information may need to include:

• Manufacturer’s legal name
• Registered trade name or trademark
• Postal address
• Email address or other digital contact
• Product type, batch, serial number or other identifier
• Intended purpose
• Essential product functions
• Cybersecurity properties
• Secure installation instructions
• Secure configuration instructions
• Instructions for safe operation
• Information about relevant security updates
• Instructions for installing updates
• Information about automatic updates
• Instructions for disabling automatic updates, where applicable
• Support-period end date
• Vulnerability-reporting contact
• Coordinated vulnerability disclosure information
• Instructions for securely removing user data
• Relevant cybersecurity warnings or limitations

Instructions must be clear, understandable, intelligible and legible. They must be provided in a language that users and relevant authorities can easily understand in the Member State where the product is sold.

Technical Documentation

Manufacturers must prepare technical documentation before placing a covered product on the market.

The technical file should demonstrate how the product complies with the CRA and should normally include:

• General product description
• Product identification
• Intended purpose
• Intended users
• Product versions
• Hardware architecture
• Software architecture
• Firmware and software versions
• Communication interfaces
• Network architecture
• Remote data-processing dependencies
• Design and development information
• Cybersecurity risk assessment
• Essential requirement assessment
• Applied standards or technical specifications
• Security-control descriptions
• Test plans and test reports
• Vulnerability assessments
• Penetration-test reports, where relevant
• Software Bill of Materials
• Secure-development records
• Update and patch-management procedures
• Vulnerability-handling procedure
• Coordinated vulnerability disclosure policy
• Support-period justification
• Product labels
• User instructions
• Conformity assessment records
• EU Declaration of Conformity
• Details of the notified body, where applicable

The documentation must be specific enough to allow authorities to assess the product’s conformity.

A collection of certificates without a clear connection to the product, risks and CRA requirements will generally not constitute an adequate technical file.

Product Classification Under the CRA

The CRA uses different conformity assessment routes depending on the type and risk profile of the product.

Products generally fall into one of the following groups:

• Default products
• Important products, Class I
• Important products, Class II
• Critical products

The classification depends on whether the product has the core functionality of a category listed in Annex III or Annex IV.

Default Products

Products that are not classified as important or critical generally follow the default route.

Manufacturers of these products can normally use internal control, also known as Module A, to assess conformity.

This does not mean that no assessment or testing is required. The manufacturer must still:

• Complete the cybersecurity risk assessment
• Meet the essential cybersecurity requirements
• Prepare technical documentation
• Obtain suitable technical evidence
• Carry out required testing
• Establish vulnerability-management procedures
• Prepare the EU Declaration of Conformity
• Affix the CE marking

Self-assessment means that the manufacturer takes responsibility for the conformity assessment. It does not remove the underlying technical obligations.

Important Products, Class I

Class I includes specified products with significant cybersecurity functions or whose compromise could create broader security risks.

Depending on their core functionality, examples may include certain:

• Identity-management systems
• Privileged-access management products
• Browsers
• Password managers
• Antivirus products
• Virtual private network products
• Network-management systems
• Security information and event-management systems
• Boot managers
• Public-key infrastructure products
• Operating systems
• Routers, modems and switches
• Smart-home products with security functions
• Microprocessors and microcontrollers with security-related functionality

For Class I products, internal control may remain possible when the manufacturer fully applies relevant harmonised standards, common specifications or an applicable European cybersecurity certification scheme.

Where those routes are not available or are not fully applied, third-party conformity assessment through a notified body may be required.

Important Products, Class II

Class II covers higher-risk important products.

Depending on their core functionality, examples can include certain:

• Hypervisors
• Container runtime systems
• Firewalls
• Intrusion-detection systems
• Intrusion-prevention systems
• Tamper-resistant microprocessors
• Tamper-resistant microcontrollers

Class II products generally require third-party conformity assessment through a notified body or an applicable European cybersecurity certification scheme.

Critical Products

Critical products are listed separately in Annex IV and are subject to the strictest conformity assessment requirements.

Manufacturers should not classify a product based only on its commercial name. Classification depends on the product’s core functionality and the technical descriptions adopted under the CRA.

Conformity Assessment

Before placing the product on the market, the manufacturer must complete the appropriate conformity assessment procedure.

Depending on the classification, applicable options can include:

• Internal control
• EU-type examination followed by conformity to type
• Full quality assurance
• Third-party assessment by a notified body
• An applicable European cybersecurity certification scheme

The availability of self-assessment depends on the product category and, for certain Class I products, whether relevant harmonised standards or other recognised compliance routes have been fully applied.

Manufacturers should determine the conformity assessment route early. Discovering late in product development that notified-body involvement is required can delay market access.

Harmonised Standards

Harmonised European standards are expected to play an important role in CRA compliance.

When a relevant harmonised standard is cited in the Official Journal of the European Union and correctly applied, it may provide a presumption of conformity with the corresponding legal requirements.

Until suitable standards are available, manufacturers still need to demonstrate compliance through appropriate technical methods and evidence.

Relevant existing cybersecurity standards and frameworks may support preparation, depending on the product. However, using a recognised standard does not automatically prove compliance with every CRA obligation unless it has the required legal status and covers the relevant requirements.

Documenting the Use of Standards

Manufacturers should document:

• Which standard or specification was used
• Which version was applied
• Which CRA requirements it covers
• Whether it was applied fully or partially
• How any uncovered requirements were addressed
• What tests or assessments were completed

EU Declaration of Conformity

Once conformity has been demonstrated, the manufacturer must prepare and sign an EU Declaration of Conformity.

The declaration confirms that the manufacturer takes responsibility for the product’s compliance with the applicable EU requirements.

It should include the information required by Annex V, such as:

• Product name and identification
• Manufacturer’s name and address
• Statement of responsibility
• Object of the declaration
• Applicable EU legislation
• Relevant harmonised standards or specifications
• Notified-body information, where applicable
• Additional conformity information
• Place and date of issue
• Name, position and signature of the authorised person

Where several EU laws apply to the same product, the manufacturer can normally prepare a single EU Declaration of Conformity covering all applicable legislation.

For example, a connected wireless device may also fall under the Radio Equipment Directive, RoHS Directive, electromagnetic compatibility requirements and other product-specific legislation.

Importer Obligations

An EU importer placing a product from a non-EU manufacturer on the Union market must verify that the manufacturer has met the applicable CRA obligations.

Among other matters, the importer must check that:

• The appropriate conformity assessment was completed
• The technical documentation was prepared
• The EU Declaration of Conformity is available
• The product bears the CE marking
• Product identification is present
• Manufacturer information is provided
• Required instructions accompany the product
• The support period is indicated
• Vulnerability-handling processes are in place

If the importer believes that the product is non-compliant or presents a significant cybersecurity risk, it must not place the product on the market until the issue has been resolved.

Importers must also cooperate with authorities and may have obligations when they become aware of vulnerabilities affecting the product.

Distributor Obligations

Distributors must act with due care when making products available on the EU market.

They must verify relevant formal compliance elements, including:

• Product identification
• Manufacturer and importer details
• Required user information
• Security instructions
• Support-period information

A distributor must not continue supplying a product it has reason to believe is non-compliant. It may also need to inform the manufacturer or importer and cooperate with market surveillance authorities.

EU Authorised Representative

A manufacturer established outside the European Union may appoint an EU Authorised Representative through a written mandate.

The Authorised Representative may perform specified regulatory tasks on behalf of the manufacturer, such as:

• Keeping the EU Declaration of Conformity available
• Keeping technical documentation available for authorities
• Responding to reasoned authority requests
• Providing compliance information
• Cooperating with market surveillance authorities
• Supporting traceability and regulatory communication
• Informing the manufacturer of authority inquiries

However, appointing an Authorised Representative does not transfer the manufacturer’s core responsibility for the product.

Responsibilities That Remain With the Manufacturer

The manufacturer remains responsible for:

• Secure product design and development
• Cybersecurity risk assessment
• Essential requirement compliance
• Technical documentation
• Conformity assessment
• Vulnerability management
• Security updates
• Incident reporting
• Corrective action
• Continued product compliance

Substantial Modifications

A person who makes a substantial modification to a product and then makes that product available on the market may assume manufacturer responsibilities.

A modification can be substantial when it affects the product’s compliance with the essential cybersecurity requirements or changes its intended purpose.

Examples of Potentially Substantial Modifications

• Adding major connected functionality
• Changing authentication architecture
• Replacing the operating system
• Introducing a new cloud platform
• Adding remote-control functionality
• Enabling new network interfaces
• Making significant changes to security-critical software
• Changing the intended user group or operating environment

Routine security updates that restore or maintain conformity should not automatically be treated as substantial modifications. Nevertheless, manufacturers and downstream operators should document significant product changes and assess their regulatory effect.

Post-Market Monitoring and Corrective Action

CRA compliance is an ongoing obligation.

After placing the product on the market, the manufacturer must continue monitoring relevant cybersecurity information.

Potential Monitoring Sources

Sources may include:

• Internal security testing
• Customer complaints
• Vulnerability reports
• Security researchers
• Component suppliers
• Open-source security advisories
• Vulnerability databases
• Threat-intelligence services
• Importers and distributors
• Market surveillance authorities
• Computer Security Incident Response Teams
• ENISA communications

Possible Corrective Measures

Where a product is found to be non-compliant or to present a cybersecurity risk, the manufacturer may need to:

• Correct the product
• Issue a security update
• Provide a workaround
• Notify affected users
• Inform importers and distributors
• Notify relevant authorities
• Restrict product availability
• Withdraw the product
• Recall the product

The response should be proportionate to the risk, but inaction is not an acceptable compliance strategy.

Record Retention

Manufacturers must retain the required technical documentation and EU Declaration of Conformity for the applicable period under the CRA.

A sound record-retention system should preserve:

• Product versions
• Software versions
• SBOM versions
• Risk-assessment versions
• Test reports
• Vulnerability decisions
• Security advisories
• Corrective-action records
• Update histories
• Incident reports
• Authority communications
• Declarations of Conformity

Version control is particularly important. Authorities may need to determine which software, components and compliance evidence applied to a particular product version at a particular time.

Penalties for Non-Compliance

The CRA provides for substantial administrative fines.

Depending on the infringement, penalties can reach:

• Up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher, for certain serious infringements
• Up to €10 million or 2% of worldwide annual turnover, whichever is higher, for other obligations
• Up to €5 million or 1% of worldwide annual turnover, whichever is higher, for supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities

Authorities can also order corrective action, restrict or prohibit product sales, require withdrawal or order a recall.

The commercial consequences can therefore extend beyond the fine itself. Non-compliance may affect access to EU distributors, online marketplaces, retailers, customers, procurement programmes and insurance coverage.

A Practical CRA Compliance Roadmap

Step 1: Confirm the Product Scope

Determine whether the product is a product with digital elements and whether an exclusion applies.

Document:

• The product
• Software and firmware
• Connectivity
• Remote data-processing functions
• Intended purpose
• Commercial supply model
• Applicable exclusions

Step 2: Classify the Product

Determine whether the product is:

• A default product
• Important Class I
• Important Class II
• Critical

The classification determines the conformity assessment route.

Step 3: Map the Supply Chain and Responsibilities

Identify:

• Legal manufacturer
• Software developers
• Hardware manufacturers
• Component suppliers
• Cloud providers
• EU importer
• Distributors
• EU Authorised Representative
• Testing providers
• Notified body, where necessary

Contractual responsibilities should support the manufacturer’s legal obligations.

Step 4: Perform the Cybersecurity Risk Assessment

Identify cybersecurity threats, vulnerabilities, possible impacts and required controls.

The assessment should cover the entire product, including external components and cloud dependencies.

Step 5: Map the Essential Requirements

Create a compliance matrix linking each applicable CRA requirement to:

• Product control
• Design specification
• Procedure
• Test result
• Technical document
• Responsible person
• Outstanding action

Step 6: Establish the Secure Development Lifecycle

Document how cybersecurity is managed during:

• Requirements definition
• Architecture
• Development
• Code review
• Component selection
• Testing
• Release
• Maintenance
• Vulnerability remediation
• End-of-life

Step 7: Prepare and Maintain the SBOM

Identify all relevant software components and establish a process for monitoring vulnerabilities affecting them.

Step 8: Complete Technical Testing

Depending on the product and risks, testing may include:

• Vulnerability scanning
• Penetration testing
• Source-code analysis
• Software composition analysis
• Authentication testing
• Encryption review
• Interface testing
• Update-mechanism testing
• Fuzz testing
• Network-security testing
• Resilience testing
• Secure-configuration review

Testing should be based on the risk assessment and conformity route.

Step 9: Establish Vulnerability and Incident Procedures

Prepare procedures for:

• Receiving reports
• Triage
• Severity assessment
• Escalation
• Remediation
• Disclosure
• User communication
• ENISA reporting
• Authority communication
• Corrective action

Step 10: Determine the Support Period

Define and justify how long the manufacturer will provide vulnerability handling and security updates.

Ensure technical suppliers and development resources remain available for that period.

Step 11: Prepare User Information and Labelling

Review:

• Product identification
• Manufacturer information
• Importer information
• CE marking
• Security instructions
• Update instructions
• Vulnerability contact
• Support end date
• Secure data-deletion instructions

Step 12: Compile the Technical Documentation

Organise the evidence into a structured CRA technical file.

Step 13: Complete the Conformity Assessment

Use internal control, a notified body or another permitted route according to the product classification.

Step 14: Sign the EU Declaration of Conformity

The manufacturer should sign the declaration only after the applicable assessment has been completed and conformity has been demonstrated.

Step 15: Maintain Post-Market Compliance

Monitor vulnerabilities, provide updates, report relevant events and update the documentation when the product changes.

Common CRA Compliance Mistakes

Treating the CRA as a One-Time Certification

The CRA requires continuing vulnerability handling, security updates, monitoring and corrective action.

Assuming All Products Can Be Self-Certified

Important Class II and critical products generally require third-party assessment. Class I products may also require notified-body involvement where relevant recognised specifications are not fully applied.

Relying Only on Penetration Testing

Penetration testing can provide useful evidence, but it does not replace the risk assessment, secure-development process, vulnerability procedures, technical documentation or support obligations.

Ignoring Third-Party Components

The manufacturer remains responsible for assessing the risks created by integrated libraries, firmware, chipsets, operating systems and cloud services.

Creating an SBOM Without Monitoring It

An outdated component list does not provide an effective vulnerability-management system.

Declaring an Unrealistic Support Period

The manufacturer must be able to provide security updates and handle vulnerabilities throughout the declared period.

Failing to Connect Technical Teams With Regulatory Teams

The 24-hour reporting deadline requires rapid internal communication. Customer service, engineering, legal, compliance and management teams should understand the escalation route.

Waiting for Harmonised Standards Before Acting

Manufacturers remain responsible for compliance even while standards and supporting guidance continue to develop.

How EaseCert Supports CRA Compliance

EaseCert provides an EU Cyber Resilience Act Authorised Representative and Compliance Service for manufacturers of products with digital elements.

The service is designed particularly for manufacturers established outside the European Union that require regulatory compliance support and an EU-based Authorised Representative.

EaseCert CRA Compliance Services

Our service includes:

• CRA applicability assessment
• Product and software scope review
• Product classification review
• Review of the conformity assessment route
• Review of existing technical documentation
• Review of cybersecurity documentation
• Cybersecurity compliance gap analysis
• Review of the secure software development lifecycle
• Review of product identification and traceability
• Review of labels and CE-marking information
• Review of user documentation and security instructions
• Review of vulnerability-handling procedures
• Review of software update and maintenance procedures
• Review of the Software Bill of Materials
• Review of support-period documentation
• EU Declaration of Conformity review
• Written compliance report and recommendations
• Written EU Authorised Representative mandate
• Appointment of EaseCert GmbH as EU Authorised Representative
• Retention of the EU Declaration of Conformity and technical documentation
• EU-based regulatory contact
• Support with market surveillance authority requests
• Regulatory guidance throughout the project

Where technical cybersecurity testing is required, EaseCert can assist with defining the testing scope and coordinating with a qualified cybersecurity laboratory or technical provider.

EaseCert does not perform penetration testing, source-code analysis or laboratory cybersecurity testing and does not act as a notified body. The manufacturer remains responsible for the product’s cybersecurity, conformity assessment, technical accuracy, vulnerability handling, updates, reporting and continued compliance.

EaseCert’s EU Authorised Representative Role

For accepted products manufactured outside the European Union, EaseCert GmbH can act as the EU Authorised Representative.

Within the agreed mandate, EaseCert can:

• Keep the EU Declaration of Conformity available for authorities
• Keep the required technical documentation available
• Respond to reasoned requests for compliance information
• Cooperate with market surveillance authorities
• Support traceability checks
• Support regulatory communications
• Inform the manufacturer of relevant authority inquiries

The appointment becomes effective after the documentation review has been completed, the products have been accepted by EaseCert and the written mandate has been signed by both parties.

Get CRA Compliance and EU Representation Support

Start Preparing for the CRA

The Cyber Resilience Act creates a new compliance framework for connected hardware, standalone software, embedded software and digital components.

For manufacturers, the largest challenge is not simply preparing a Declaration of Conformity. Compliance requires coordination between product development, cybersecurity, quality assurance, regulatory affairs, customer support, supply-chain management and senior management.

Four Questions Manufacturers Should Answer

1. Does the CRA apply to our product?
2. Which product classification and conformity assessment route apply?
3. Do we have sufficient cybersecurity evidence and technical documentation?
4. Can we monitor, update and support the product throughout its declared support period?

Manufacturers established outside the European Union should also determine whether they need an EU Authorised Representative and how they will manage requests from EU market surveillance authorities.

EaseCert supports international manufacturers with CRA applicability reviews, compliance gap assessments, technical documentation reviews and EU Authorised Representative services.

View the EaseCert EU Cyber Resilience Act Authorised Representative and Compliance Service

Official Sources and Further Reading

The following official European Union sources provide the legal text, implementation guidance and supporting information concerning the EU Cyber Resilience Act:

• Regulation (EU) 2024/2847, Cyber Resilience Act
  The official and legally binding text of the Cyber Resilience Act published in the Official Journal of the European Union.
• European Commission: Cyber Resilience Act
  The European Commission’s main policy page covering the purpose, scope, implementation and expected effects of the Cyber Resilience Act.
• European Commission: Summary of the Cyber Resilience Act Legislative Text
  An official summary of the CRA requirements, including product scope, economic operator obligations, conformity assessment and implementation dates.
• European Commission: Cyber Resilience Act Implementation Frequently Asked Questions
  Official answers to practical questions concerning product scope, software, remote data processing, support periods, reporting and implementation.
• European Commission: Cyber Resilience Act Implementation
  An overview of the CRA implementation process, including guidance, standardisation activities and resources for manufacturers and other stakeholders.
• ENISA: Cyber Resilience Act Single Reporting Platform
  Official information on the platform manufacturers will use to report actively exploited vulnerabilities and severe security incidents from 11 September 2026.
• ENISA: Cyber Resilience Act Requirements Standards Mapping
  An ENISA study mapping existing cybersecurity standards against the CRA requirements and identifying areas requiring further standardisation.
• ENISA: Cyber Resilience Act Implementation Through the EU Cybersecurity Certification Scheme
  An official study examining how the European Common Criteria-based Cybersecurity Certification Scheme may support CRA conformity assessment.

 

This article provides general regulatory information and does not constitute legal advice. Product scope, classification, conformity assessment and documentation requirements must be evaluated for each product individually.