EU Cyber Resilience Act Requirements: In Scope Guide

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force in December 2024. Most of its obligations apply from December 2027, with vulnerability and incident reporting requirements applying from September 2026. For manufacturers, importers, and distributors of connected products, the compliance window is shorter than it looks.

This article answers the questions that matter most to product teams and compliance leads: does the CRA apply to your product, which obligations apply to you specifically, and what does compliance actually require? It also addresses the question that generates the most confusion — whether SaaS and cloud-delivered software falls within scope.

The short answer on SaaS: the CRA applies to products placed on the market, not to remote services. For most pure SaaS offerings, the regulation does not apply. But there are edge cases that matter, and this article covers them directly.

For a broader introduction to the regulation, see our EU Cyber Resilience Act explainer. For enforcement dates and transition timelines, see our CRA compliance timeline guide.

The CRA's scope is built around a single concept: a product with digital elements (PDE). Under Article 2, the regulation applies to any hardware or software product whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

That definition is deliberately broad. It covers:

1. Consumer IoT devices (smart speakers, home routers, wearables)
2. Industrial control systems and operational technology
3. Desktop, mobile, and embedded software
4. Software components and libraries sold or distributed separately
5. Firmware and operating systems

The key trigger is connectivity. A product that cannot connect to a network or another device falls outside scope. A standalone offline application with no network functionality is not a PDE. In practice, almost every commercial software product sold today connects to something, which means the scope is wide.

The regulation also covers components placed on the market separately. If your business sells a software library or hardware module that is integrated into another manufacturer's product, you are still subject to CRA obligations as the manufacturer of that component.

What "Made Available on the Market" Means

Scope is limited to products made available on the market — meaning supplied for distribution or use in the EU in the course of a commercial activity. This distinction matters. Products developed for internal use only, or bespoke software built exclusively for a single customer that is not distributed commercially, fall outside scope. Free and open-source software is generally not covered when it is not monetised, though Recital 18 of the regulation clarifies specific conditions.

Key point: The CRA applies to the act of placing a product on the EU market. If you manufacture in the UK or US and sell into the EU, you are in scope. Where the manufacturer is based is irrelevant — what matters is where the product is sold.

Not all products with digital elements carry the same risk, and the CRA reflects this through a three-tier classification system. The class your product falls into determines how you demonstrate compliance.

The vast majority of products fall into the default category and can self-certify. The stricter routes apply to specific product types listed in Annexes III and IV.

Annex III: Important Products

Class I includes: identity management and privileged access management systems, standalone browsers, password managers, anti-malware software, VPN products, network management systems, SIEM systems, boot managers, and PKI software, among others.

Class II includes: hypervisors and container runtime systems, firewalls, intrusion detection and prevention systems, tamper-resistant microprocessors and microcontrollers, and industrial automation and control systems.

Annex IV: Critical Products

Critical products — those requiring European cybersecurity certification — include hardware security modules (HSMs), smart card readers with security functions, and smart meter gateways. This is a short, specific list. Most manufacturers will not fall into this category.

The practical implication: if your product is a SIEM, a VPN solution, or an identity management platform, you are in Annex III and face stricter assessment requirements. If you build general-purpose business software that connects to a network but does not perform core cybersecurity functions, you are likely in the default category and can self-assess.

Annex I is the heart of the CRA. It sets out the essential cybersecurity requirements that every product with digital elements must meet before it can be placed on the EU market. The requirements are split into two parts: product properties (Part I) and vulnerability handling processes (Part II).

Part I: Product Security Requirements

Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity based on the risks. Specifically, when placing a product on the market, manufacturers must ensure it:

1. Is free of known exploitable vulnerabilities at the point of release
2. Ships with a secure by default configuration, including the ability to reset to the original state
3. Uses no default passwords that are universal across a product range (each unit must have a unique credential, or force the user to set one)
4. Protects data confidentiality through encryption of data at rest and in transit where relevant
5. Minimises the attack surface, including disabling unused interfaces and functions
6. Limits the impact of incidents through resilience and recovery mechanisms, including protection against denial-of-service attacks
7. Applies data minimisation principles: only processing data that is necessary for the product's intended purpose
8. Provides secure update mechanisms that can deliver security patches throughout the product's support period
9. Allows users to permanently delete data from the product, and to do so securely

These requirements are not novel for security-conscious manufacturers. What changes is that they become legally mandated, enforceable obligations rather than best practice recommendations.

Part II: Vulnerability Handling Requirements

Beyond the product itself, manufacturers must put in place processes to handle vulnerabilities throughout the product's support period. This includes:

1. Identifying and documenting vulnerabilities and components, including open-source components (this is where the software bill of materials requirement originates — covered in detail in our CRA SBOM and certification guide)
2. Addressing and remediating vulnerabilities without undue delay
3. Applying coordinated vulnerability disclosure policies
4. Providing free security updates for the duration of the support period
5. Reporting actively exploited vulnerabilities and severe incidents to ENISA within 24 hours of discovery

The support period obligation is significant. Manufacturers must define a support period for each product. The CRA does not prescribe a fixed duration, but it must reflect the product's expected use life. For many software products, this will be at least five years. Manufacturers who cannot commit to this timeline should factor it into product planning now.

The CRA assigns obligations across the supply chain, distinguishing between three economic operator roles. Understanding which role applies to your organisation determines which obligations you carry.

The Manufacturer Bears the Heaviest Burden

Manufacturers carry the full weight of CRA obligations. If you design and sell a product — even if manufacturing is outsourced — you are the manufacturer under the CRA. The regulation does not allow manufacturers to transfer their obligations to downstream parties.

Critically, if a manufacturer is based outside the EU and has no EU establishment, they must appoint an authorised representative established in the EU. This representative handles conformity assessment documentation and acts as the point of contact for market surveillance authorities. Non-EU manufacturers who sell into the EU without an authorised representative are in breach of the regulation from the point of market entry.

Importers and Distributors: Due Diligence Obligations

Importers and distributors are not passive. Both must verify that:

1. The CE marking is affixed to the product
2. The manufacturer has drawn up the required technical documentation
3. The product is accompanied by the instructions and information required under Annex II

If an importer or distributor has reason to believe a product does not comply, they must not place it on the market and must inform the manufacturer and relevant market surveillance authorities. This creates a real compliance obligation, not just a formality.

This is the question that generates the most confusion in the market, and most published guidance either avoids it or hedges. Here is a direct answer.

Pure SaaS is largely out of scope. The CRA applies to products with digital elements placed on the market. A software-as-a-service offering that is accessed remotely via a browser or API — where no software is installed on the user's device — is not a product placed on the market. It is a service. The regulation explicitly states it applies to products "made available on the market," and Recital 12 of the regulation clarifies that services are not covered.

The European Commission's own summary confirms this: "Products with digital elements that are not made available on the market, i.e. not supplied in the course of a commercial activity, are not subject to the CRA."

Where SaaS Companies Are Not Off the Hook

The clean SaaS exclusion has three important caveats that software companies must understand.

1. Downloadable client software is in scope. If your SaaS product includes a desktop application, mobile app, or browser extension that users download and install, that component is a product with digital elements. The downloadable element — not the cloud service — is subject to CRA requirements. Many SaaS vendors ship desktop clients, offline sync tools, or mobile apps without recognising these as separately regulated products.

2. On-premise or hybrid deployment changes the picture. If your software can be deployed on a customer's own infrastructure (on-premise or private cloud), and you distribute that software to customers, you are placing a product on the market. The fact that you also offer a cloud-hosted version does not exempt the on-premise edition.

3. Embedded software in connected hardware. If your SaaS platform is accessed through a connected hardware device that you supply — for example, a smart meter, industrial sensor, or consumer IoT device — the hardware and its embedded software fall within scope.

The Practical Test for SaaS Companies

Ask three questions:

1. Do we distribute any software that users install on their own devices? If yes, that software is in scope.
2. Do we offer an on-premise or self-hosted version of our product? If yes, that version is in scope.
3. Do we supply connected hardware as part of our offering? If yes, the hardware and embedded firmware are in scope.

If the answer to all three is no, and your product is delivered entirely as a remote service, the CRA does not apply to you. This is a genuine and significant exclusion that most competitor guidance fails to state clearly.

Important caveat: The CRA is a new regulation and guidance from the European Commission is still developing. Organisations in genuinely ambiguous situations should seek legal advice specific to their product architecture.

The CRA is a horizontal regulation, designed to fill gaps in EU product safety law. Where sector-specific legislation already addresses cybersecurity requirements for a product category, the CRA either does not apply or applies only to requirements not already covered.

The main exclusions under Article 2 are:

The exclusion is not a blanket exemption. For medical devices and motor vehicles, the CRA exclusion applies only where the sector regulation addresses all or some of the cybersecurity risks covered by Annex I. Where gaps exist, the CRA may still apply to those specific requirements. Manufacturers in these sectors should not assume full exemption without a detailed gap analysis against both the sector regulation and CRA Annex I.

Products developed or modified exclusively for national security or defence purposes are excluded entirely, as are products designed to process classified information.

Under Article 13(2), manufacturers must undertake a cybersecurity risk assessment for each product with digital elements. This is not a one-time exercise at launch. The assessment must be taken into account across the entire product lifecycle: planning, design, development, production, delivery, and maintenance.

The risk assessment must address:

1. Threat identification: what threats are plausible given the product's intended use, deployment context, and connectivity?
2. Vulnerability analysis: what weaknesses exist in the product's code, components, and configuration?
3. Impact assessment: what would be the consequences of exploitation for the user, for connected systems, and for third parties?
4. Risk treatment: which risks require mitigation at the design stage, which can be addressed through configuration guidance, and which must be covered by post-market vulnerability handling processes?

Risk Assessment Is Not a Document Exercise

The CRA's risk assessment requirement is substantive. It must genuinely inform product design decisions. A risk assessment completed after the product is built, to justify decisions already made, does not meet the requirement. The regulation is explicit: the outcome of the assessment must be taken into account during the planning and design phases.

Manufacturers must also document the assessment as part of their technical documentation (see below). Market surveillance authorities can request this documentation at any time. Assessments that are superficial, incomplete, or disconnected from the actual product architecture will not withstand scrutiny.

For manufacturers managing multiple products or product versions, maintaining consistent, up-to-date risk assessments across the portfolio is one of the most operationally demanding aspects of CRA compliance. This is where compliance management tooling adds direct value — automating the mapping of Annex I requirements against product assessments and tracking documentation currency across the portfolio.

Before placing a product with digital elements on the EU market, manufacturers must draw up technical documentation demonstrating that the product meets the essential requirements in Annex I. This documentation must be maintained and kept up to date for the duration of the product's support period, and for at least ten years after the last unit is placed on the market.

What the Technical Documentation Must Include

1. A general description of the product, including its intended purpose and reasonably foreseeable uses
2. The cybersecurity risk assessment (Article 13(2))
3. A description of the design and development processes and the security measures applied
4. Details of the conformity assessment procedure followed
5. A copy of the EU declaration of conformity
6. The software bill of materials (SBOM) for the software components included in the product
7. Vulnerability handling policies and procedures

The SBOM requirement is one of the most operationally significant aspects of CRA compliance for software manufacturers. Maintaining an accurate, machine-readable inventory of all software components — including open-source dependencies — requires tooling and process discipline that many organisations do not currently have in place. Our CRA SBOM and certification guide covers this in detail.

CE Marking Under the CRA

Products that meet the CRA's essential requirements and have completed the required conformity assessment must bear the CE marking before being placed on the EU market. The CE marking signals that the manufacturer has taken responsibility for the product's compliance with all applicable EU legislation, including the CRA.

For default-category products, the manufacturer self-certifies and affixes the CE marking without third-party involvement. For Class II important products, the CE marking can only be affixed after a notified body has conducted the EU-type examination. For critical products, European cybersecurity certification is required.

The CE marking is not a quality endorsement. It is a legal declaration that the product meets the applicable requirements. Affixing a CE marking to a non-compliant product is a regulatory offence subject to enforcement by national market surveillance authorities.

Penalties for non-compliance under the CRA can reach €15 million or 2.5% of global annual turnover, whichever is higher, for the most serious violations. For manufacturers placing products on the EU market, this is not a compliance exercise to defer.

The CRA creates a structured compliance journey for manufacturers. The sequence matters: scope determination comes first, then product classification, then risk assessment, then technical documentation, then conformity assessment, then CE marking.

A practical starting point for most manufacturers:

1. Audit your product portfolio against the PDE definition. Identify every product that connects to a network or device and is sold commercially in the EU.
2. Classify each product against Annexes III and IV. Determine whether you face self-assessment or third-party conformity requirements.
3. Initiate risk assessments for each in-scope product. These must be completed before the product is placed on the market and kept current throughout its support period.
4. Establish vulnerability handling processes — including an SBOM programme, a coordinated vulnerability disclosure policy, and a patching commitment aligned to the support period.
5. Prepare technical documentation for each product, including all elements required by Annex V.
6. Complete conformity assessment and affix CE marking before the December 2027 deadline.

For the incident and vulnerability reporting obligations that apply from September 2026, see our CRA reporting obligations guide.

SureCloud's Compliance Management platform automates Annex I requirements mapping and tracks your documentation obligations in one place. For manufacturers managing multiple products across complex portfolios, the ability to maintain a single, auditable record of risk assessments, technical documentation status, and vulnerability handling processes significantly reduces the manual overhead of CRA compliance.