This guide is designed as a practical Cyber Resilience Act compliance roadmap for manufacturers, importers and distributors. It connects the main CRA concepts – scope, roles, deadlines, risk assessment, secure development, documentation, SBOM, vulnerability handling, conformity assessment and enforcement – into a coherent plan. Throughout the article, we link to in-depth guides and templates hosted on Regulus so you can go deeper in each area.

If you are just starting, you can read this guide end-to-end. If you already understand the basics, jump directly to the sections that matter most for your organisation and use the links to detailed CRA articles, checklists and documentation resources.

1. Why Cyber Resilience Act compliance matters now

The CRA aims to create a uniform baseline of cybersecurity for products with digital elements placed on the EU market. It applies to a wide spectrum of hardware and software, including:

• Connected consumer and industrial devices (IoT, IIoT, OT gateways).
• Embedded systems, firmware-driven products and controllers.
• Software that processes data remotely and interacts with networked environments.
• Combined hardware–software products where the software is essential to the function.

For these products, Cyber Resilience Act compliance introduces mandatory obligations on risk assessment, secure by design/default, vulnerability handling, updates, logging and monitoring, lifecycle support and technical documentation. It also defines strong penalties (up to €15 million or 2.5% of global turnover) and powerful enforcement tools, including recalls, withdrawals and market bans.

Rather than treating CRA as a late-stage legal add-on, forward-looking organisations treat it as a driver for improving their entire product security lifecycle.

2. Step 1 – Clarify CRA scope and applicability

Any Cyber Resilience Act compliance roadmap starts with a clear view of whether and how the CRA applies to your products. Without this, you risk over- or under-scoping your efforts.

2.1 Determine if your products are in scope

The CRA applies to products with digital elements placed on the EU market. This includes most hardware and software that:

• Contains software or embedded software.
• Has direct or indirect network connectivity.
• Processes, transmits or stores digital data.

Some product categories are covered by sectoral legislation (for example, certain medical devices and automotive systems) and may be partially or fully excluded. Similarly, pure SaaS without installable components is typically out of scope. To work through these nuances in detail, use our in-depth guides:

• Cyber Resilience Act Applicability: Does the CRA Apply to Your Product?
• CRA Scope Explained: What Products Are In and Out

2.2 Map your product portfolio and roles

Once you know which product types are likely to be in scope, you need to map actual products and roles:

• Create an inventory of all products with digital elements you place, or plan to place, on the EU market.
• For each product, determine whether you are acting as manufacturer, importer, distributor or a combination.
• Identify where you might unintentionally become a manufacturer (for example, if you rebrand or substantially modify a product).

For a structured view of responsibilities, see our guide on CRA Manufacturer, Importer and Distributor Obligations.

2.3 Understand Default vs Critical Class

Products are further divided into classes, often summarised as Default and Critical, depending on their impact and use. Your Cyber Resilience Act compliance plan must account for this classification, because it determines the conformity assessment route and overall risk level. For a deeper dive, see:

• CRA Scope: What Products Are In / Out?
• CRA Risk Assessment Guide

3. Step 2 – Build your CRA risk assessment foundation

Risk assessment is at the heart of Cyber Resilience Act compliance. The regulation expects manufacturers to understand threats and vulnerabilities affecting their products with digital elements, and to use that understanding as input for design and control selection.

3.1 Product-level cybersecurity risk assessment

Your CRA risk assessment should typically cover:

• Architecture, interfaces and data flows.
• Assets (functions, data, services) that require protection.
• Threat scenarios and likely attack paths.
• Vulnerabilities in architecture and components (including third-party and open source).
• Impact and likelihood ratings that drive prioritisation.

We provide a detailed methodology, including example structures and templates, in our CRA Risk Assessment Guide.

3.2 Connecting risk assessment to controls and design

Risk assessment is not just a document. For credible Cyber Resilience Act compliance, regulators expect a clear link between risk assessment results and:

• Security requirements for the product.
• Architecture and design choices (for example, segmentation, authentication, encryption).
• Operational controls (logging, monitoring, update strategies).

This traceability also becomes part of your technical documentation, which we cover in Section 5.

4. Step 3 – Align your development lifecycle with CRA requirements

Once you understand your risk landscape, the next step in the Cyber Resilience Act compliance roadmap is integrating cybersecurity into your development lifecycle.

4.1 Secure by design and by default

The CRA explicitly requires that products with digital elements are designed and developed according to secure by design and secure by default principles. In practice, this implies:

• Defining security and safety objectives early in the lifecycle.
• Minimising attack surface and unnecessary functionality.
• Applying least privilege, strong authentication and robust access control.
• Providing secure default configurations and avoiding weak or hard-coded credentials.

4.2 Secure Development Lifecycle (SDL)

A structured SDL is one of the most effective tools for CRA compliance. It ensures that security activities are embedded into stages such as requirements, design, implementation, verification and release.

We explore this in detail in CRA Secure Development Lifecycle (SDL): Practical Guide for Manufacturers, including specific activities you can adopt and how to scale them across multiple product lines.

4.3 Logging, monitoring and post-market surveillance

Cyber Resilience Act compliance is not limited to pre-market design. The regulation expects manufacturers to monitor products after deployment and detect security-relevant events. Logging and monitoring requirements include:

• Generating logs for security-significant events (authentication, changes, updates).
• Protecting logs against tampering and unauthorised access.
• Using logs to investigate incidents and support reporting obligations.

See our in-depth article on CRA Logging and Monitoring Requirements for a detailed breakdown.

5. Step 4 – Build CRA-ready technical documentation

Even if your controls are strong, Cyber Resilience Act compliance will be judged partly on your documentation. Your technical file must show how you meet the essential requirements and support conformity assessment.

5.1 Technical documentation (Annex II and VII)

A CRA technical file usually includes:

• Product description, intended use and target environment.
• Architecture and data flow diagrams.
• Security controls and rationale, linked to risk assessment outcomes.
• SBOM and third-party component inventory.
• Vulnerability handling and update procedures.
• Logging and monitoring approach.
• Testing and validation evidence.

Use our article Cyber Resilience Act Technical Documentation: Complete Guide and CRA Technical File Structure as blueprints.

5.2 SBOM and supply-chain visibility

Many of the CRA obligations connect to supply-chain transparency. A reliable SBOM helps you:

• Understand which libraries, components and frameworks your product depends on.
• React quickly to new vulnerabilities in third-party components.
• Demonstrate due diligence to regulators and customers.

We explain expectations and practical implementation strategies in CRA SBOM Requirements: Complete Guide.

5.3 Declaration of Conformity (DoC)

Your EU Declaration of Conformity is the formal document where you state that your product meets CRA requirements (and any other applicable legislation). It must be based on your technical documentation and conformity assessment route.

See CRA Declaration of Conformity (DoC) Guide for structure, mandatory content and example formulations.

6. Step 5 – Implement vulnerability handling and update management

Vulnerability handling is one of the most visible aspects of Cyber Resilience Act compliance. The CRA expects manufacturers to maintain continuous processes for identifying, evaluating, mitigating and communicating vulnerabilities throughout the support period.

6.1 Vulnerability handling requirements

Key elements include:

• A documented vulnerability handling policy and process.
• Publicly available channels for vulnerability reporting (for example, security.txt, web forms, dedicated email).
• Prioritisation based on severity, exploitability and impact.
• Documentation of analysis, decisions and remediation steps.

We cover these responsibilities in depth in CRA Vulnerability Handling Requirements (Annex I – Section 2).

6.2 Update and patch management

Secure and timely updates are essential. Your CRA compliance roadmap should include:

• Mechanisms for authenticated and integrity-verified updates.
• Processes for planning, testing and deploying security patches.
• Clear communication to customers about update availability and impact.

For technical and organisational patterns, see CRA Update & Patch Management Requirements: Complete Guide.

7. Step 6 – Choose the right CRA conformity assessment route

Depending on the classification of your products and the standards you use, Cyber Resilience Act compliance may require different conformity assessment approaches:

• Internal control (self-assessment) for many Default Class products that implement harmonised standards.
• Third-party conformity assessment for certain important or critical products, or where harmonised standards are not fully applied.

We explain how to choose and implement the right route in CRA Conformity Assessment: Internal Control vs Third-Party Assessment.

8. Step 7 – Align with CRA deadlines 2025–2027

A realistic Cyber Resilience Act compliance roadmap must be aligned with the CRA timeline. The regulation includes a transition period leading up to full applicability in December 2027, with some obligations (such as reporting actively exploited vulnerabilities) taking effect earlier.

In practical terms:

• Use 2025–2026 to build or mature your risk assessment, SDL, documentation and vulnerability handling processes.
• Ensure that new products entering the EU market during the transition are designed with CRA requirements in mind from the start.
• By late 2027, your portfolio should have a clear conformity path for each in-scope product.

For detailed dates and planning suggestions, see CRA Deadlines 2025–2027: Key Dates and What Manufacturers Must Do.

9. Step 8 – Understand penalties and enforcement risk

No roadmap is complete without understanding the risk of inaction. As explained in our dedicated article on CRA Penalties and Enforcement, the CRA introduces significant administrative fines and strong enforcement powers.

Key points:

• Top-tier fines can reach €15 million or 2.5% of global annual turnover for serious infringements.
• Authorities can order recalls, withdrawals and bans on making products available.
• Importers and distributors can also be targeted, especially if they place obviously non-compliant products on the market.

The best mitigation for CRA enforcement risk is a transparent, documented compliance programme with clear responsibilities, traceability and continuous improvement.

10. Using the Regulus CRA Readiness Checklist and resources

To make the Cyber Resilience Act compliance roadmap more actionable, we have created a downloadable checklist and a set of supporting resources:

• CRA Readiness Checklist – assess scope, roles, risk assessment, SDL, documentation, SBOM, vulnerability handling and roadmap status.
• CRA Resources Library – curated checklists, guides and templates.
• In-depth blog articles for specific topics across CRA basics, documentation, requirements and conformity assessment.

Use the checklist to establish a baseline and revisit it periodically as your products and processes evolve.

11. Cyber Resilience Act compliance – FAQs

11.1 Who needs Cyber Resilience Act compliance?

Any organisation that manufactures, imports or distributes products with digital elements in the EU may need Cyber Resilience Act compliance. This includes manufacturers of connected devices, embedded systems, firmware-based products and combined hardware–software solutions.

11.2 Does CRA apply to pure SaaS?

Pure SaaS services without installable software or firmware are generally out of scope. However, SaaS offerings that control or update in-scope hardware, distribute firmware or include installable agents may bring the overall solution into CRA scope. It is essential to analyse the architecture rather than relying on labels like “SaaS”.

11.3 How long does CRA compliance take?

The answer depends on your current maturity. Organisations with existing secure development practices, vulnerability handling and structured documentation will move faster. Others may need the full transition period to build these capabilities. In any case, starting early is one of the most effective ways to reduce enforcement risk.

11.4 Can we rely only on external consultants?

Consultants can help interpret the regulation and design frameworks, but Cyber Resilience Act compliance ultimately depends on what your organisation actually does – the security of your products, your documentation and your post-market processes. Responsibility cannot be outsourced.

11.5 How does CRA relate to other regulations like GDPR and NIS2?

GDPR focuses on personal data protection; NIS2 focuses on network and information system security for essential and important entities. The CRA complements them by focusing on the cybersecurity of products with digital elements. Many organisations will need to manage all three frameworks in parallel.

12. How Regulus supports your Cyber Resilience Act compliance roadmap

Regulus is building self-service tools to help EU digital product companies operationalise Cyber Resilience Act compliance in a structured, repeatable way. Instead of managing CRA work in static spreadsheets and scattered documents, we aim to provide:

• Scope and role mapping workflows to clarify which products are in scope and what CRA obligations apply.
• Requirements mapping views that connect regulation text to concrete security controls, documentation tasks and processes.
• Documentation templates for technical files, SBOM, risk assessments, vulnerability handling and Declarations of Conformity.
• Readiness dashboards aligned with CRA deadlines 2025–2027 so you can track gaps and progress in real time.

To move forward:

1. Download the CRA Readiness Checklist and perform an initial assessment.
2. Deep dive into specific topics through the Regulus CRA Blog and Resources.
3. Join the Regulus Early Access list to receive updates on tools that support your CRA roadmap.

La entrada Cyber Resilience Act Compliance Roadmap 2025–2027: Complete Guide se publicó primero en Regulus.

In this guide we explain how CRA penalties are structured, which violations trigger the highest fines, what additional enforcement powers authorities have and how organisations can reduce the risk of sanctions through a structured compliance programme. The article is written for product, engineering, legal and security teams preparing their roadmap for CRA enforcement between 2025 and 2027.

If you are new to the CRA, start with our overview on Cyber Resilience Act requirements, scope and how to prepare, then use this guide to understand the consequences of non-compliance.

1. What are CRA penalties and why do they matter?

Under the Cyber Resilience Act, non-compliance can lead to administrative fines that are comparable to GDPR in magnitude. The highest CRA penalties can reach up to €15 million or 2.5% of the company’s total worldwide annual turnover, whichever is higher, for the most serious infringements such as failing to meet essential cybersecurity requirements or reporting duties.

In addition to the financial CRA penalties, market surveillance authorities can order product recalls, withdrawals and bans on making a product available on the market. For many manufacturers, losing access to the EU market can be more damaging than the fines themselves.

For this reason, CRA penalties are not only a legal topic. They shape product strategy, risk appetite, engineering priorities and post-market support commitments.

2. CRA penalty tiers and maximum fines

The Cyber Resilience Act uses a tiered structure for fines. Different categories of infringements trigger different maximum CRA penalties. The amounts are aligned with GDPR style sanctions and can scale with the size of the undertaking.

2.1 Highest tier – essential cybersecurity requirements and reporting

The most serious infringements involve core cybersecurity obligations, such as:

• Failure to comply with essential cybersecurity requirements in Annex I.
• Placing products on the market without required conformity assessment.
• Using CE marking without fulfilling CRA conditions.
• Failure to comply with vulnerability and incident reporting obligations.

These violations can trigger CRA penalties of up to:

• €15 million, or
• 2.5% of the total worldwide annual turnover of the previous financial year,

whichever amount is higher.

2.2 Mid-tier – other obligations under the CRA

Less severe, but still significant, infringements include failure to comply with other CRA obligations, for example:

• Inadequate technical documentation.
• Failure to perform proper risk assessment.
• Missing or incomplete vulnerability handling procedures.
• Inconsistent application of secure development and lifecycle requirements.

These issues can lead to CRA penalties of up to:

• €10 million, or
• 2% of total worldwide annual turnover,

whichever is higher.

2.3 Lower tier – incorrect or misleading information

The lowest tier of CRA penalties still represents a serious risk. It targets behaviour such as:

• Providing incorrect, incomplete or misleading information to authorities.
• Obstructing market surveillance activities.
• Refusing to provide documentation when requested.

These infringements can result in fines of up to:

• €5 million, or
• 1% of total worldwide annual turnover,

whichever is higher.

3. Enforcement powers beyond CRA penalties

Financial sanctions are only part of the enforcement toolbox. The CRA gives national market surveillance authorities a wide range of powers that can be used in combination with or instead of monetary fines.

3.1 Product withdrawal and recall

Authorities can require economic operators to:

• Withdraw non-compliant products from the market, preventing them from being made available to new customers.
• Recall products that have already been supplied to users, forcing the manufacturer or importer to recover and remediate or destroy affected units.

For companies with large installed bases, the operational and reputational impact of a recall can far exceed direct CRA penalties.

3.2 Prohibition on making products available

In severe cases, authorities can issue decisions that temporarily or permanently:

• Prohibit a product from being placed on the EU market.
• Restrict its availability until non-conformities are resolved.

This effectively removes the product from the EU market and can have a decisive impact on revenues and customer relationships.

3.3 Corrective actions and public communication

Authorities can also require economic operators to:

• Implement specific corrective actions, such as security updates, configuration changes or architectural mitigations.
• Inform customers and users about the risks, the non-compliance and the corrective steps being taken.

These measures are part of the broader enforcement landscape and are often combined with CRA penalties in high-profile cases.

4. Typical non-compliance scenarios that trigger CRA penalties

While every case is different, several recurring patterns are likely to attract attention from authorities and lead to CRA penalties or other enforcement measures.

4.1 Shipping products with known vulnerabilities and no update path

Examples include:

• IoT devices that ship with hard-coded or unchangeable default passwords.
• Embedded devices without secure update mechanisms or no update mechanisms at all.
• Software components with publicly known vulnerabilities that remain unpatched.

These situations point directly at failures to meet essential cybersecurity requirements and vulnerability handling obligations, which can fall in the highest tier of CRA penalties.

4.2 Incomplete or missing technical documentation

Another common scenario is when manufacturers cannot provide technical documentation that demonstrates compliance with Annex I, Annex II and Annex VII. Typical gaps include:

• No structured risk assessment.
• No Software Bill of Materials (SBOM).
• No documented vulnerability handling or incident response procedures.
• Missing information about update mechanisms or lifecycle support.

These issues are closely linked to mid-tier CRA penalties and can also trigger corrective actions. For a detailed breakdown of documentation expectations, see our guide to CRA technical documentation.

4.3 Misleading information to authorities or notified bodies

Providing incorrect, incomplete or misleading information during conformity assessment or market surveillance is directly addressed in the CRA penalty structure. Even if the technical compliance issues are limited, lack of transparency can escalate enforcement and lead to separate fines.

5. Who faces CRA penalties: manufacturers, importers and distributors

CRA penalties can apply to any economic operator that violates the regulation, but manufacturers carry the heaviest exposure because they are responsible for design, development, documentation and lifecycle security.

• Manufacturers face the full range of CRA penalties if they fail to meet essential requirements, do not implement vulnerability handling processes or place non-compliant products on the market.
• Importers can be sanctioned if they place products on the EU market that they know or should know are not CRA compliant.
• Distributors can be targeted if they make clearly non-compliant products available or ignore obligations to cooperate with authorities.

Importantly, importers and distributors can become manufacturers in the eyes of the CRA if they rebrand products or substantially modify them in ways that affect cybersecurity. In that case they inherit the full set of manufacturer obligations and the associated CRA penalties. For a detailed breakdown of responsibilities, see our guide on CRA manufacturer, importer and distributor obligations.

6. How CRA penalties interact with deadlines and transition periods

The CRA is expected to apply fully from December 2027, with some obligations, such as vulnerability and incident reporting, becoming effective earlier. This transition period is designed to give organisations time to adapt their processes and architecture to the new requirements.

In practice, this means:

• Authorities will expect visible progress towards compliance during the transition period.
• Companies that ignore preparation entirely are more likely to face early enforcement actions once the CRA is applicable.
• Those that can demonstrate active risk assessment, documentation and vulnerability handling will be better positioned if issues arise.

For more details on key dates and milestones, see our article on CRA deadlines 2025–2027.

7. How to reduce CRA penalty and enforcement risk

The most effective way to reduce exposure to CRA penalties is to treat the regulation as a product and process improvement framework rather than a last-minute compliance exercise. Several measures are particularly important.

7.1 Build a CRA risk assessment and classification baseline

Start with a structured CRA risk assessment for each product with digital elements. This is essential for:

• Identifying relevant threats and vulnerabilities.
• Determining whether the product is Default or Critical Class.
• Choosing the right conformity assessment route.

You can follow the methodology described in our CRA risk assessment guide.

7.2 Implement vulnerability handling and update processes early

Because reporting obligations and lifecycle security are central to the CRA, gaps in vulnerability management are likely to attract enforcement attention. To reduce CRA penalty risk, manufacturers should:

• Define a vulnerability handling policy and workflow.
• Set up a clear intake channel for vulnerability reports.
• Integrate secure update and patch management processes.

Our articles on CRA vulnerability handling requirements and CRA update and patch management provide detailed guidance.

7.3 Create audit-ready technical documentation

Because mid-tier CRA penalties are closely linked to documentation gaps, building a robust technical file significantly reduces enforcement risk. Focus on:

• Risk assessment documentation and traceability to controls.
• SBOM and third-party component tracking.
• Logging, monitoring and post-market surveillance procedures.
• Declaration of Conformity that correctly references applicable legislation.

Our checklist-style article on CRA technical file structure can be used as a blueprint.

7.4 Align governance and roles with CRA expectations

Finally, CRA penalties often arise in environments where responsibilities are unclear. Manufacturers, importers and distributors should assign:

• A clear CRA compliance owner.
• Defined responsibilities for vulnerability handling and incident reporting.
• Processes for escalating potential non-compliance and cooperating with authorities.

8. CRA penalties – frequently asked questions

8.1 What are the maximum CRA penalties for non-compliance?

The highest CRA penalties can reach up to €15 million or 2.5% of the company’s worldwide annual turnover for the preceding financial year, whichever amount is higher. This tier applies to serious breaches of essential cybersecurity requirements and key reporting obligations.

8.2 Are CRA penalties similar to GDPR fines?

Yes. CRA penalties follow a similar logic to GDPR: percentage of global turnover, use of the higher amount and a tiered structure based on seriousness of the infringement. However, the CRA focuses on cybersecurity and product security rather than data protection.

8.3 Can small or medium enterprises also face CRA penalties?

Yes. CRA penalties can apply to organisations of any size. While authorities may consider proportionality, the regulation does not exempt SMEs from essential cybersecurity requirements. Using proportionality as a planning assumption is risky.

8.4 Are fines the only consequence of CRA non-compliance?

No. Authorities can combine CRA penalties with product recalls, withdrawals, bans on market access and requirements to implement specific corrective actions. Reputational damage and operational disruption are often more costly than the fines themselves.

8.5 How can manufacturers show they are reducing CRA penalty risk?

Manufacturers can reduce their CRA penalty exposure by documenting a clear compliance programme. Evidence of structured risk assessment, secure development practices, vulnerability handling and technical documentation will be important if an incident or investigation occurs.

9. How Regulus helps you avoid CRA penalties

Regulus is focused on helping EU digital product companies turn CRA requirements into practical workflows that reduce enforcement risk. Instead of relying only on manual spreadsheets, you can use structured tools to:

• Assess CRA applicability and scope – determine which products are in scope and what obligations apply.
• Map requirements to controls – connect Annex I and documentation expectations to specific implementation tasks.
• Structure technical documentation – build a CRA-ready technical file with clear traceability.
• Track CRA readiness over time – monitor gaps that could lead to CRA penalties if left unresolved.

To start reducing CRA enforcement risk:

1. Download the CRA Readiness Checklist to assess gaps across scope, documentation and lifecycle security.
2. Explore our CRA articles and technical guides to deepen your understanding.
3. Join the Regulus Early Access list to receive updates on tools that help you operationalise CRA compliance.

La entrada CRA Penalties and Enforcement: Complete Guide se publicó primero en Regulus.

This guide explains how the CRA allocates responsibilities across manufacturers, importers and distributors, when an importer or reseller is treated as a manufacturer and what practical steps each role should take to be ready for enforcement. It is written for product, engineering, security and compliance teams who need a concrete mapping rather than high-level summaries.

If you are still validating whether your products fall under the CRA, start with our article on Cyber Resilience Act applicability and our overview of CRA requirements, scope and how to prepare.

1. Economic operators under the Cyber Resilience Act

The CRA uses a familiar New Legislative Framework structure. It defines several economic operators involved in making products with digital elements available on the EU market:

• Manufacturer – designs, develops or manufactures the product and markets it under their name or trademark.
• Importer – places on the EU market a product with digital elements that bears the name or trademark of a person established outside the Union.
• Distributor – makes a product available on the EU market in the supply chain without affecting its properties.
• Authorised representative – acts on behalf of the manufacturer for specific tasks.

From a practical point of view, CRA manufacturer obligations are the heaviest. Manufacturers must ensure security by design and by default, run cybersecurity risk assessments, implement vulnerability handling processes, perform conformity assessment, draw up technical documentation and keep products secure during the defined support period.

Importers and distributors have lighter, but still important duties. They must verify that only compliant products with a valid CE marking and technical documentation reach customers, and they must cooperate with authorities, especially when non-conformities or incidents are discovered.

2. CRA manufacturer obligations in detail

Manufacturers are at the center of CRA compliance because they control the design, development and support of the product with digital elements. At a high level, CRA manufacturer obligations cover five main areas: risk assessment, secure design and development, vulnerability handling, documentation and conformity assessment.

2.1 Cybersecurity risk assessment and secure design

Manufacturers must perform a structured cybersecurity risk assessment for each product with digital elements. This assessment should consider intended purpose, reasonably foreseeable use, interfaces, data flows and dependencies. The outcome must influence architecture, design decisions and security controls.

• Document risks and link them to security requirements and controls.
• Ensure the product is designed according to secure by design and secure by default principles.
• Consider the entire lifecycle, including updates, decommissioning and end of support.

For a deeper discussion of risk assessment expectations, see our guide to CRA risk assessment.

2.2 Secure development lifecycle and testing

Manufacturers are expected to integrate cybersecurity into their development lifecycle. In practice, this means:

• Defining security requirements early in the lifecycle, not only at the end.
• Embedding security activities in design, implementation, integration and system testing.
• Performing security testing that matches the risk level of the product.
• Ensuring that vulnerabilities found before release are triaged and addressed according to their severity.

You can find a more detailed breakdown in our article on the CRA Secure Development Lifecycle (SDL).

2.3 Vulnerability handling and incident reporting

One of the most visible CRA manufacturer obligations is the requirement to set up and maintain a vulnerability handling process that stays in place throughout the support period. Key elements include:

• A documented vulnerability handling policy and workflow.
• Clear intake channels for vulnerability reports from researchers, customers and partners.
• Prioritisation, remediation and communication processes based on severity and exploitability.
• Timely reporting of actively exploited vulnerabilities and severe incidents to the single reporting platform and the designated CSIRT.

We cover these topics in depth in our guide on CRA vulnerability handling requirements and in our article on CRA update and patch management.

2.4 Technical documentation and Declaration of Conformity

Manufacturers must create and maintain a technical file that demonstrates how the product meets essential cybersecurity requirements. This documentation is central to CRA manufacturer obligations and must be available to market surveillance authorities on request.

• Technical documentation in line with Annex II and Annex VII.
• Risk assessment, security architecture, SBOM, logging and monitoring descriptions.
• Test results, vulnerability handling procedures and update processes.
• An EU Declaration of Conformity referencing the CRA and other relevant legislation.

For structured templates and examples, see our article on CRA technical documentation and the guide to the CRA Declaration of Conformity.

2.5 Support period and lifecycle obligations

Manufacturers must define and communicate a support period for each product with digital elements and are expected to keep the product secure during that period. This includes:

• Providing security updates that address known vulnerabilities.
• Communicating lifecycle information, including end-of-support dates.
• Reassessing risk when new threats or vulnerabilities emerge.

All of these elements contribute directly to CRA manufacturer obligations and will be scrutinised if a product is involved in a serious incident or enforcement action.

3. CRA importer obligations – verifying compliance before entry

Importers act as the gateway for products with digital elements entering the EU market. They are not expected to redesign the product, but they share responsibility for ensuring that only compliant products are placed on the market. CRA importer obligations include several due diligence and documentation checks.

3.1 Verifying manufacturer compliance

Before placing a product on the EU market, importers must verify that:

• The product has been subject to the appropriate conformity assessment procedures.
• The manufacturer has drawn up the EU Declaration of Conformity.
• CE marking is affixed correctly and corresponds to the product and its cybersecurity claims.
• The required technical documentation exists and can be made available to authorities upon request.

In practice, CRA importer obligations mean checking that the manufacturer actually behaves like a CRA-compliant manufacturer, not just relying on marketing claims.

3.2 Labelling, instructions and traceability

Importers must also ensure that:

• The product bears the manufacturer’s name, registered trade name or trademark and contact details.
• Where required, the importer’s name and contact details are indicated on the product, its packaging or accompanying documentation.
• Required safety and cybersecurity information, including instructions for use and support period, are provided in the correct language.

3.3 Acting on suspected non-compliance or risks

If an importer has reason to believe that a product is not CRA compliant or presents a significant cybersecurity risk, they must:

• Refrain from placing the product on the market until it is compliant.
• Inform the manufacturer and, where necessary, notify relevant market surveillance authorities.
• Cooperate in any corrective actions, recalls or withdrawals requested by authorities.

Importers who ignore these CRA importer obligations risk being treated as part of the non-compliance, even if they did not design the product.

4. CRA distributor obligations – responsibility in the last mile

Distributors are the last link in the chain before a product reaches end users. Their obligations are lighter than those of manufacturers and importers, but they still play an important role in CRA enforcement and market surveillance.

4.1 Basic checks before making products available

Before making a product available on the market, distributors must verify that:

• CE marking is present on the product.
• The product is accompanied by the required documentation and instructions.
• Any safety or cybersecurity warnings or restrictions indicated by the manufacturer are respected.
• The product appears to be in conformity and does not show obvious signs of non-compliance.

These checks are part of core CRA distributor obligations and are designed to avoid obviously non-compliant products remaining in circulation.

4.2 Storage, transport and information

Distributors must also ensure that the way they store and transport products does not compromise their compliance with CRA requirements. For example, they should not remove labels, alter packaging or ignore manufacturer communications about vulnerabilities or recalls.

4.3 Responding to non-conformities

If a distributor has reason to believe that a product is not in conformity or presents a risk:

• They must not make the product available on the market.
• They should inform the manufacturer or importer.
• Where necessary, they should cooperate with market surveillance authorities in implementing corrective actions, including recall or withdrawal.

While CRA distributor obligations are narrower, distributors that repeatedly ignore obvious non-compliance can become enforcement targets, especially where they act as major channels for risky products.

5. When importers and distributors become manufacturers

A critical point in the CRA is that roles are determined by actual behaviour, not just job titles. In some cases, importers and distributors are treated as manufacturers and therefore inherit all CRA manufacturer obligations.

5.1 Placing products under your own name or brand

An importer or distributor becomes a manufacturer in the eyes of the CRA if they:

• Place a product with digital elements on the market under their own name or trademark.
• Rebrand products in a way that makes them appear to be the original manufacturer.

In such cases, authorities will look to the rebranding entity as the manufacturer, with full responsibility for design, documentation and vulnerability handling.

5.2 Substantial modifications affecting cybersecurity

An importer or distributor also becomes the manufacturer if they perform a substantial modification that affects the product’s compliance with essential cybersecurity requirements or its intended purpose. Examples include:

• Replacing firmware or software with a custom build that changes security properties.
• Adding remote management features or cloud components essential to product operation.
• Integrating third-party components that materially change the risk profile.

Once they cross this line, they must meet the same CRA manufacturer obligations as the original manufacturer, including technical documentation, conformity assessment and vulnerability handling processes for the modified product.

6. Shared obligations and practical RACI view

While each role has its own focus, many CRA duties are shared across manufacturers, importers and distributors. Thinking in terms of a RACI matrix (Responsible, Accountable, Consulted, Informed) can help clarify ownership.

6.1 Examples of shared obligations

• Ensuring only compliant products reach the EU market Manufacturers – Responsible and Accountable Importers – Responsible for verification Distributors – Responsible for basic checks
• Vulnerability handling and communication Manufacturers – Own the process and reporting Importers – Must inform manufacturers and, where necessary, authorities Distributors – Must forward information and support corrective actions
• Documentation and traceability Manufacturers – Maintain technical documentation and Declaration of Conformity Importers – Keep documentation available for authorities Distributors – Ensure documentation and instructions accompany the product

Mapping CRA manufacturer obligations and their importer and distributor counterparts in this way is a useful step when preparing for audits and supervisory questions.

7. How this fits with CRA deadlines and enforcement

The timing of your implementation matters. The CRA defines a transition period that culminates in full applicability in December 2027. Reporting obligations for actively exploited vulnerabilities and severe incidents start earlier, which means manufacturers must have at least a basic vulnerability handling process in place before that date.

For a detailed overview, see our article on CRA deadlines 2025–2027 and our guide on CRA penalties and enforcement.

In practice:

• Manufacturers that ignore risk assessment, technical documentation and vulnerability handling are at highest risk of enforcement.
• Importers and distributors that continue to sell clearly non-compliant products despite warnings are also likely to attract attention.
• Operators who can show structured work toward CRA compliance are in a stronger position if an incident or investigation occurs.

8. CRA manufacturer, importer and distributor obligations – FAQs

8.1 Who has the main responsibility for CRA compliance?

Manufacturers have the primary responsibility. They must design and build products to meet essential cybersecurity requirements, maintain vulnerability handling processes, manage documentation and ensure the product remains secure during its support period. CRA manufacturer obligations are the most extensive in the regulation.

8.2 What are the most important CRA importer obligations?

Importers must ensure that only compliant products enter the EU market. They need to verify that the correct conformity assessment has been performed, that the Declaration of Conformity exists, that CE marking is present and that documentation is available. They must also refrain from placing obviously non-compliant or risky products on the market.

8.3 What do CRA distributor obligations cover in practice?

Distributors focus on the last mile. They must check that CE marking and required documentation are present, that instructions and safety information accompany the product and that they do not place products on the market that are clearly non-compliant. They also need to cooperate with authorities and manufacturers in recalls and corrective actions.

8.4 When do importers and distributors become manufacturers?

An importer or distributor is treated as a manufacturer when they place products on the market under their own name or trademark, or when they substantially modify the product in a way that affects cybersecurity or its intended purpose. In that case, they inherit the full set of CRA manufacturer obligations.

8.5 Do micro and small enterprises have different obligations?

The CRA recognises the situation of micro and small enterprises in some recitals and supporting measures, but the core obligations around secure design, vulnerability handling and documentation still apply where their products present cybersecurity risks. Enforcement may take proportionality into account, but it does not exempt these organisations from their responsibilities.

9. How Regulus helps economic operators operationalise CRA

Regulus is focused on helping EU digital product companies turn CRA manufacturer obligations, importer diligence and distributor checks into repeatable workflows instead of ad-hoc spreadsheets.

• Scope and role mapping – clarify which products fall under the CRA, what role you play for each product and where you might accidentally become a manufacturer.
• Requirements mapping – connect CRA obligations to concrete controls, processes and documentation tasks for each role.
• Documentation templates – structure your technical file, CRA risk assessment, SBOM, vulnerability handling procedures and Declaration of Conformity.
• Readiness tracking – follow your progress against CRA deadlines and identify where manufacturer, importer or distributor obligations are still unmet.

To move forward:

1. Download our CRA Readiness Checklist and use it to assess current gaps.
2. Review CRA basics, scope and documentation in the Regulus Resources section.
3. Join the Regulus Early Access list to receive updates on tools that support CRA manufacturer obligations and related workflows.

La entrada CRA Manufacturer, Importer and Distributor Obligations: Complete Guide se publicó primero en Regulus.

In this guide we break down the official Cyber Resilience Act timeline, explain what happens in 2025, 2026 and 2027, and show how to build a realistic CRA roadmap for your products. We will focus on what the CRA deadlines mean for manufacturers of connected devices, embedded systems, firmware-driven products and other products with digital elements.

For a broader overview of the regulation, see our article on Cyber Resilience Act requirements, scope and how to prepare, and for product-level analysis, read our CRA applicability guide.

1. CRA deadlines 2025 2027 at a glance

Before diving into practical planning, it is useful to have a clear picture of the main CRA deadlines 2025 2027. At a high level, the timeline looks like this:

• December 2024: the Cyber Resilience Act enters into force at EU level.
• 2025: transition and preparation year – no hard application yet, but the clock is running and guidance begins to emerge.
• 11 June 2026: provisions on designation and notification of conformity assessment bodies start to apply (Chapter IV).
• 11 September 2026: vulnerability and incident reporting obligations (for actively exploited vulnerabilities and significant incidents) become mandatory.
• 11 December 2027: main CRA obligations become fully applicable; products with digital elements placed on the EU market must meet CRA cybersecurity, documentation and conformity assessment requirements.

From the perspective of a manufacturer, this means that serious reporting obligations start in 2026, while full product compliance (including CE marking under CRA) must be in place by December 2027 for new products placed on the market.

2. CRA timeline explained: from entry into force to full application

The CRA follows a familiar regulation pattern: entry into force, transition period, then full application. Understanding this structure is essential to interpret CRA deadlines 2025 2027 correctly.

2.1 Entry into force and transition period

The Cyber Resilience Act is already law at EU level. After entry into force, there is a multi-year transition period before most obligations apply to manufacturers and other economic operators. This is the window during which organisations are expected to:

• Map their product portfolio and determine CRA applicability.
• Perform initial CRA risk assessments for in-scope products.
• Design secure update, logging and vulnerability handling processes.
• Prepare technical documentation and conformity strategies.

Practically, the transition period is where you set up the foundations rather than wait for the final CRA deadline to react in a rush.

2.2 Early application of specific CRA obligations

Not all CRA provisions start at the same time. Some obligations are deliberately brought forward before full application, especially those that enable the whole framework:

• Notification and designation of conformity assessment bodies, so that they are ready before manufacturers need them.
• Vulnerability and incident reporting for products with digital elements, so that authorities have early visibility of serious issues.

This is why, in practice, 2026 is not a quiet year. It is when reporting expectations start to bite, even though full CE-level compliance under CRA only becomes mandatory in late 2027.

2.3 Full application of main obligations

From late 2027 onwards, the CRA is fully applicable. This means that products with digital elements placed on the EU market must:

• Meet the CRA essential cybersecurity requirements.
• Follow the appropriate conformity assessment route (internal control or third-party involvement, depending on classification and risk).
• Be supported by technical documentation and a Declaration of Conformity that covers CRA and other relevant legislation.

At this point, CRA becomes part of the standard regulatory backdrop alongside CE marking and sector-specific regulations.

3. What CRA deadlines mean in 2025

While there is no formal “2025 CRA deadline” in the regulation text, the year is strategically important. It is the first full year after entry into force and the earliest realistic starting point for serious CRA readiness work.

3.1 2025: inventory, applicability and gap analysis

In 2025, organisations should focus on building clarity rather than rushing into scattered implementation. Typical priorities include:

• Building a complete inventory of products with digital elements across the portfolio.
• Running high-level CRA applicability checks for each product (in scope vs out of scope, default vs higher-impact categories).
• Performing initial CRA risk assessments for representative products.
• Identifying major gaps in secure development, vulnerability handling, update mechanisms and documentation.

Our CRA Readiness Checklist is designed to support exactly this phase: mapping where you are today versus where you need to be by 2026–2027.

3.2 2025 for importers and distributors

Importers and distributors should also use 2025 to:

• Identify which supplier products fall under CRA scope.
• Clarify contractual responsibilities for vulnerability handling, updates and documentation.
• Plan how they will verify CRA conformity and documentation from 2027 onwards.

4. CRA deadlines in 2026: reporting obligations and infrastructure

The real “first hard date” in the CRA deadlines 2025 2027 is 11 September 2026

4.1 September 2026 – vulnerability and incident reporting

From 11 September 2026, manufacturers (and in some cases other economic operators) must:

• Report actively exploited vulnerabilities in their products with digital elements to the relevant EU-level bodies / national CSIRTs within defined timelines.
• Report significant cybersecurity incidents affecting the security of CRA-covered products.
• Maintain processes and evidence to show how they identify, analyse and remediate vulnerabilities.

Several legal and technical analyses point out that these obligations apply regardless of when the product was first placed on the market, which means legacy products still in support are within scope of the reporting framework.

4.2 What you should have in place by 2026

By the time reporting obligations go live, organisations should already have:

• A documented vulnerability handling process aligned with CRA expectations.
• Clear reporting lines, internal SLAs and responsibilities for vulnerability triage and incident response.
• Logging and monitoring capabilities sufficient to detect potential incidents involving their products.
• Initial versions of CRA technical documentation for key products, even if they will be refined before 2027.

If these foundations are not in place by 2026, it will be very difficult to satisfy reporting obligations in practice.

4.3 Conformity assessment ecosystem in 2026

In parallel, from mid-2026 onwards, Member States start designating and notifying conformity assessment bodies under CRA. This is a prerequisite for products that will require third-party assessment, and it is one reason why manufacturers cannot leave all conformity decisions to the last minute in 2027.

5. CRA deadlines in 2027: full application and market impact

The final and most visible milestone in the CRA deadlines 2025 2027 is the date when main obligations become fully applicable, currently planned for 11 December 2027.

5.1 What full application means for products

From full application onwards, when you place a product with digital elements on the EU market, you are expected to:

• Have implemented security-by-design and security-by-default controls aligned with CRA essential requirements.
• Have performed the appropriate conformity assessment route for that product (self-assessment vs notified body, depending on classification and risk).
• Maintain a CRA-compliant technical file, including risk assessment, architecture, security controls, testing evidence, logging and vulnerability handling descriptions.
• Issue and keep available a Declaration of Conformity that lists CRA and other applicable acts, and apply CE marking accordingly.

Products that do not meet CRA requirements may be restricted, withdrawn or prevented from being placed on the market, and supervisory authorities can apply administrative fines.

5.2 Existing vs new products at the 2027 deadline

A frequent question is what happens to products already on the market before full application. In simplified terms:

• New products placed on the market after the CRA full application date are expected to fully comply with CRA requirements.
• Existing products already in the field may still be affected by vulnerability reporting and support commitments, especially if you continue to ship updates or sell new units after the deadline.

This nuance makes it even more important to understand your product lifecycle, support policies and CRA roadmap well before 2027.

6. Building a CRA roadmap around deadlines 2025 2027

The most useful way to think about CRA deadlines is not as isolated dates, but as anchors for a structured roadmap. Below is a practical view of what to do in each period.

6.1 2025 – foundation and visibility

• Create and validate your inventory of products with digital elements.
• Run CRA applicability and classification for each product (or at least for your main families).
• Perform initial CRA risk assessments and identify high-risk products and components.
• Define your high-level CRA strategy: which products will be prioritised, which processes must change, who owns what.

6.2 2026 – processes and reporting readiness

• Formalise your vulnerability handling process and reporting playbooks.
• Implement logging and monitoring capabilities that support CRA detection expectations.
• Align secure development lifecycle (SDL) practices with CRA requirements for new releases.
• Produce the first versions of CRA technical documentation for priority products.

If you need guidance on SDL, see our article on CRA secure development lifecycle.

6.3 2027 – product-level conformity and documentation

• Complete technical files and risk documentation for in-scope products.
• Decide and apply the appropriate CRA conformity assessment routes per product.
• Finalise Declaration of Conformity templates that include CRA alongside other legislation.
• Prepare internal training and documentation so that sales, support and partners understand CRA implications.

7. CRA deadlines 2025 2027: FAQs for manufacturers

7.1 Do CRA deadlines apply to non-EU manufacturers?

Yes. CRA obligations apply based on where the product is placed on the market, not where the manufacturer is located. Non-EU manufacturers selling products with digital elements into the EU must meet the same deadlines and requirements as EU manufacturers.

7.2 What if we cannot meet CRA requirements by 2027?

If products with digital elements do not meet CRA requirements when placed on the EU market after full application, they may be restricted or withdrawn by market surveillance authorities. This makes early planning for CRA deadlines 2025 2027 essential.

7.3 Are pure SaaS products affected by CRA deadlines?

Pure SaaS services without distributed software, firmware or hardware are generally out of CRA scope, although they may be regulated by other frameworks (e.g. NIS2 or data protection law). However, SaaS that distributes agents, firmware, apps or controls devices with digital elements can fall under CRA, and therefore indirectly under these deadlines.

7.4 How do CRA deadlines interact with other regulations?

The CRA complements, but does not replace, other EU acts such as NIS2, sector-specific safety regulations or data-protection rules. For many organisations, CRA deadlines 2025 2027 will overlap with NIS2 implementation and evolving sectoral guidance.

8. How Regulus can help you plan for CRA deadlines 2025 2027

Regulus is focused on helping EU digital product companies structure their response to CRA deadlines 2025 2027 in a practical way. Instead of working with static spreadsheets and scattered notes, our goal is to provide:

• CRA scope and classification workflows that clarify which products are in scope before 2026.
• Requirements mapping that links CRA articles and essential requirements to concrete controls and documentation.
• Documentation templates for technical files, risk assessments, SBOM, vulnerability handling and CRA declarations.
• Readiness views and roadmaps aligned with the key CRA deadlines in 2026 and 2027.

To move forward:

1. Download our CRA Readiness Checklist to assess your current position against CRA deadlines 2025 2027.
2. Review the CRA basics and documentation guides in the Regulus Resources section.
3. Join the Regulus Early Access list to receive updates on CRA tooling for scope analysis, documentation and roadmap tracking.

La entrada CRA Deadlines 2025–2027: Key Dates and What Manufacturers Must Do se publicó primero en Regulus.

In this guide, we break down the full CRA risk assessment process, including methodology, documentation requirements, threat modelling practices and examples aligned with EU regulatory expectations. Whether you build embedded systems, IoT devices, firmware, software components or connected hardware, this article explains how to perform a CRA-aligned risk assessment that stands up to regulatory scrutiny.

What Is a CRA Risk Assessment?

A CRA risk assessment is a structured evaluation required under the EU Cyber Resilience Act. It ensures that manufacturers identify cybersecurity threats, analyse vulnerabilities and document the security measures needed to comply with Annex I, Annex II and Annex VII of the regulation. The CRA risk assessment directly influences product classification, conformity requirements and technical documentation.

According to ENISA guidance on risk management, effective cybersecurity assessments must follow a clear methodology that includes threat identification, likelihood estimation and impact evaluation. The CRA expects the same level of structure and traceability.

Why the CRA Requires a Formal Risk Assessment

The Cyber Resilience Act makes risk assessment mandatory because it forms the foundation of secure-by-design and secure-by-default principles. Without a CRA risk assessment, an organisation cannot demonstrate that the product’s security controls are justified, proportionate and aligned with the threats relevant to its functionality.

• It ensures security measures are based on objective risk levels, not assumptions.
• It determines whether a product is Default Class or Critical Class.
• It directly influences the conformity assessment route.
• It ensures that vulnerabilities and attack surfaces are properly documented.
• It supports lifecycle security and post-market obligations.

Official European Commission CRA overview

Risk Assessment Requirements Under the Cyber Resilience Act

The CRA does not prescribe a specific methodology, but it requires manufacturers to follow a structured and documented approach. At minimum, every CRA risk assessment must include:

• Identification of intended use and reasonably foreseeable misuse.
• Identification of assets, attack surfaces and entry points.
• Threat modelling (e.g., STRIDE, LINDDUN, attack trees).
• Vulnerability analysis based on the product’s architecture.
• Risk evaluation using likelihood and impact criteria.
• Definition of risk-treatment actions and security measures.
• Traceability between risks and implemented mitigations.

This aligns with best practices from ISO/IEC 62443 and ISO/IEC 27005, both of which are referenced in EU cybersecurity guidance.

CRA Risk Assessment Framework: Step-by-Step

1. Define the Product and Its Operational Context

The Cyber Resilience Act risk assessment begins with a technical description of the product, including architecture, interfaces, data flows and connectivity. This establishes the baseline for identifying vulnerabilities and attack surfaces.

2. Identify Assets and Attack Surfaces

Common CRA-relevant assets include firmware, communication channels, authentication mechanisms, cryptographic operations and user data. Each asset must be mapped to potential attack paths.

3. Conduct Threat Modelling

Threat modelling methods such as STRIDE or attack trees help structure the analysis. The CRA does not require a specific model but expects a justified, repeatable approach.

4. Analyse Vulnerabilities

The CRA expects manufacturers to identify both known and potential vulnerabilities based on architecture, dependency chains and third-party components. This ties directly to SBOM requirements and open-source management.

5. Evaluate Likelihood and Impact

Risks must be evaluated using clear criteria. Impact should consider safety, data integrity, security degradation, service continuity and downstream consequences.

6. Define Mitigation Measures

Security measures must be proportional to the risks identified and aligned with Annex I requirements, including secure configuration, update mechanisms, vulnerability handling and cryptographic protections.

7. Document Traceability

Regulators expect a traceability matrix linking:

• Risk → Vulnerability → Mitigation → CRA requirement → Evidence

This is essential for audits and for the CRA technical documentation file.

Risk Assessment Examples for IoT, Embedded and Software Products

Example 1: IoT Sensor

• Threat: network interception
• Vulnerability: unencrypted communication
• Impact: confidentiality breach
• Mitigation: TLS 1.3 with certificate-based authentication

Example 2: Embedded Controller

• Threat: local access exploitation
• Vulnerability: insecure debug interface
• Impact: unauthorised firmware modification
• Mitigation: secure boot, interface locking and debug authentication

Example 3: Software Application

• Threat: supply-chain compromise
• Vulnerability: outdated open-source package
• Impact: remote code execution
• Mitigation: SBOM tracking and automated dependency monitoring

How CRA Risk Assessment Influences Product Classification

The CRA risk assessment is the primary input for determining whether a product belongs to Default Class or Critical Class. Critical Class products must follow a more rigorous conformity assessment and involve a notified body.

Risk factors that increase the likelihood of Critical Class classification include:

• Connectivity to critical infrastructure
• Potential impact on safety or essential services
• High-value data processing
• Integration into industrial environments

Full guide: CRA applicability & product classification

Documenting Your Cyber Resilience Act Risk Assessment

Under Annex II and Annex VII, manufacturers must include the Cyber Resilience Act risk assessment in their technical documentation. At minimum, documentation must cover:

• Risk assessment methodology
• Threat and asset identification
• Risk tables and evaluation
• Security controls and mitigations
• Traceability mapping

This documentation must remain available for 10 years after the product is placed on the market.

Conclusion

A CRA risk assessment is a mandatory, foundational activity for Cyber Resilience Act compliance. It shapes product classification, guides security design, informs technical documentation and ensures that products meet EU cybersecurity expectations. Organisations that begin the CRA risk assessment process early will reduce compliance risk, accelerate audits and improve the security quality of their digital products.

La entrada CRA Risk Assessment: Requirements, Methodology & Templates se publicó primero en Regulus.

This guide explains both conformity routes—Internal Control and Third-Party Assessment—in depth, including requirements, documentation, testing expectations, timelines, and the criteria that determine your conformity path.

1. What Is a Conformity Assessment Under the CRA?

A conformity assessment is the formal process used to verify that a digital product meets the Essential Cybersecurity Requirements in Annex I of the CRA. It includes:

• Technical documentation
• Security design and architecture evidence
• Vulnerability handling processes
• Secure update mechanisms
• Post-market monitoring plans
• Testing and validation results

You cannot place a product on the EU market without completing a conformity assessment.

2. The Two CRA Conformity Assessment Procedures

The CRA offers two routes:

1. Internal Control (Self-Assessment) – available only for Default Class products
2. Third-Party Assessment (Notified Body) – mandatory for Critical Class products

Your conformity route depends entirely on your product classification.

3. Internal Control (Default Class Products)

Internal Control is a self-assessment process that allows manufacturers to:

• Prepare technical documentation internally
• Conduct their own testing and validation
• Prepare an EU Declaration of Conformity
• Affix the CE marking without external review

This route applies to Default Class products, which represent standard-risk digital products.

3.1 Requirements of Internal Control

Manufacturers must:

• Create and maintain all technical documentation required in Annex II
• Perform security testing aligned with Annex I
• Implement secure update mechanisms
• Document vulnerability handling procedures
• Prepare a post-market monitoring plan
• Compile an EU Declaration of Conformity

Authorities may review this documentation at any time.

3.2 Who Can Use Internal Control?

Products that fall under the Default Class—meaning they do not meet any of the criteria for Critical Class—may use this route.

Examples include:

• Developer tools without direct safety impact
• General-purpose embedded controllers
• Consumer IoT devices not used in critical contexts
• Software applications that do not interface with critical systems

4. Third-Party Conformity Assessment (Critical Class Products)

If your product is classified as Critical Class, you must undergo a full review by a Notified Body. This is a significantly more rigorous process.

4.1 What the Notified Body Examines

A Notified Body will:

• Review your architecture documentation
• Review your secure development processes
• Conduct penetration testing or verify your test results
• Verify the correctness of your vulnerability management process
• Validate your secure update mechanism
• Assess your post-market monitoring design
• Ensure SBOM coverage and supply-chain monitoring
• Assess risk management decisions

The Notified Body may request revisions or additional testing.

4.2 When Third-Party Assessment Is Mandatory

You must undergo a third-party assessment if your product is considered Critical Class according to Annex III. This includes products where:

• Security failures could significantly disrupt critical infrastructure
• The product processes highly sensitive data
• The product manages industrial control or operational technology
• The product performs network security or gateway functions

If any Critical Class criteria apply, Internal Control is not allowed.

5. Comparison: Internal Control vs Third-Party Assessment

6. Documentation Requirements for Conformity Assessment

Annex II requires manufacturers to prepare extensive documentation, including:

• Product architecture
• Secure design principles
• Threat models
• SBOM (Software Bill of Materials)
• Update mechanisms
• Vulnerability handling workflows
• Security testing evidence
• Post-market monitoring plan

This documentation must be maintained for the full support period.

7. Key Steps of the Conformity Assessment Process

1. Determine whether your product is Default or Critical Class
2. Define your conformity route (Internal or Third-Party)
3. Prepare Annex II technical documentation
4. Perform security testing and validation
5. Document all processes and evidence
6. Complete EU Declaration of Conformity
7. Affix CE marking
8. Maintain documentation for authorities

8. Common Mistakes to Avoid

• Incorrectly assuming a product is Default Class
• Missing evidence for update validation
• Incomplete SBOM or dependency tracking
• Not documenting security testing
• Weak post-market monitoring plans
• Not preparing risk assessments or threat models

9. How Regulus Helps Manufacturers

Regulus simplifies CRA conformity by providing:

• Automatic Default vs Critical Class classification
• Conformity route selection
• Annex II documentation templates
• Security testing and validation checklists
• SBOM generation and monitoring
• Post-market monitoring workflows

Start by evaluating your product: CRA Applicability Checker

Conclusion

Choosing the correct conformity assessment route is essential for meeting CRA requirements. Default Class products may use Internal Control, but Critical Class products require third-party validation from a Notified Body. Preparing documentation early and aligning your security practices with Annex I ensures a smoother path to compliance.

For templates and guidance, visit our CRA Resources.

La entrada CRA Conformity Assessment: Internal Control vs Third-Party Assessment (Complete Guide) se publicó primero en Regulus.