The EU Cyber Resilience Act sets cybersecurity requirements for hardware and software products with digital elements made available on the EU market. The main obligations apply from 11 December 2027, while the reporting duties in Article 14 start earlier, on 11 September 2026.
The practical scope question is not simply “product or SaaS?”. Standalone SaaS developed outside a product manufacturer's responsibility is not itself a product with digital elements. Remote software can nevertheless be part of an in-scope product when it meets the CRA definition of a remote data processing solution.
What changes, and when?
| Date | Milestone |
|---|---|
| 10 December 2024 | The CRA entered into force. |
| 11 June 2026 | The rules on notification of conformity assessment bodies in Chapter IV began to apply. |
| 11 September 2026 | Article 14 reporting obligations begin to apply. |
| 11 December 2027 | The rest of the CRA generally begins to apply, including the essential cybersecurity, vulnerability-handling, conformity, documentation and CE-marking requirements. |
Products placed on the market before 11 December 2027 generally become subject to the CRA's product requirements only if they undergo a substantial modification from that date. Article 14 is different: its reporting duties apply to in-scope products even if they were placed on the market before 11 December 2027.
Does the CRA apply to SaaS?
There is no safe blanket answer for every hosted product.
A standalone SaaS or cloud service is not itself a product with digital elements when it was designed and developed outside the responsibility of the manufacturer of such a product. It may instead be regulated as a service under another regime, including NIS2 where the relevant conditions are met.
Remote processing is part of an in-scope product when all three elements of the CRA definition are present:
Data processing occurs at a distance.
Without that processing, the product would be unable to perform one of its functions.
The remote software was designed and developed by the product manufacturer or under that manufacturer's responsibility.
“One of its functions” is broader than the product's core function. The Commission's 2026 guidance gives onboarding, configuration, identity and access management, file synchronisation, remote commands, and automated distribution of updates as examples that may satisfy the functional test.
Who operates the infrastructure is not decisive. Manufacturer-developed software running on third-party IaaS or PaaS can qualify as remote data processing. A ready-made third-party SaaS application generally is not developed under the manufacturer's responsibility, but its integration can still create cybersecurity risks that the manufacturer must assess and mitigate for the product as a whole.
Websites that only provide information about a product are not remote data processing solutions. A website that enables a product function, such as issuing credentials or tokens required for operation, may qualify when the other elements are also met.
Which products are in scope?
The CRA applies to software or hardware products with a direct or indirect logical or physical data connection to a device or network when they are made available on the EU market in the course of a commercial activity. Examples include:
Downloadable applications and standalone software
On-premises server software
Firmware and software components made available separately
Connected hardware and software supplied with hardware
Commercial free and open-source software
A product's qualifying remote data processing solutions
Important boundaries include:
Genuinely non-commercial free and open-source software is excluded from the ordinary manufacturer regime. Open-source software stewards have a separate, lighter set of obligations.
Certain products covered by specified sectoral EU legislation are excluded, including medical devices, in-vitro diagnostic medical devices, motor vehicles, civil aviation products and marine equipment.
Software made solely for an organisation's own use is generally not placed on the market unless it is later supplied as a product.
There is no general SME exemption. The CRA provides support measures and some proportionate treatment, not a blanket carve-out.
The product classification affects the conformity route. Most products can use manufacturer self-assessment. “Important” products in Annex III and “critical” products in Annex IV can require stricter assessment, depending on their class and the standards or certification route used.
What must an in-scope manufacturer do?
The principal duties include:
Assess cybersecurity risks. Design, develop and produce the product in light of a documented, lifecycle risk assessment.
Meet the essential cybersecurity requirements. These cover matters such as secure-by-default configuration, attack-surface reduction, confidentiality, integrity, availability and protection against unauthorised access.
Handle vulnerabilities. Identify and document components, maintain a software bill of materials in a commonly used machine-readable format, provide a vulnerability contact point, follow a coordinated disclosure policy, test and remediate risk without delay, and distribute security updates securely and free of charge subject to the CRA's rules.
Set and disclose a support period. Maintain effective vulnerability handling throughout that period and state its end date clearly to users.
Complete the conformity work. Prepare technical documentation and an EU declaration of conformity, follow the applicable assessment procedure, and affix the CE marking before placing the product on the market.
Report qualifying events. Use the EU reporting route for actively exploited vulnerabilities and severe incidents affecting product security.
How long is the support period?
The manufacturer must set a support period that reflects how long the product is expected to be used. Relevant factors include reasonable user expectations, the nature and intended purpose of the product, other applicable EU law, comparable products, the operating environment, and the support periods of integrated components providing core functions.
The baseline is at least five years. Five years is not sufficient when the product is reasonably expected to remain in use longer. A period shorter than five years is permitted only where the product is expected to be used for less than five years; in that case, the support period must correspond to that expected use time. The Commission gives a short-lived contact-tracing application and some subscription software that becomes unavailable when the subscription ends as examples.
The reasoning used to set the support period should be recorded in the product's technical documentation.
What are the Article 14 reporting deadlines?
From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in its product or a severe incident affecting the security of the product must report through the CRA reporting mechanism. Reporting runs through ENISA's Single Reporting Platform and the designated national CSIRT coordinator.
The reports are progressive:
| Stage | Deadline |
|---|---|
| Early warning | Without undue delay and no later than 24 hours after becoming aware |
| Main notification | Without undue delay and no later than 72 hours after becoming aware |
| Final report — actively exploited vulnerability | No later than 14 days after a corrective or mitigating measure is available |
| Final report — severe incident | No later than one month after the 72-hour notification |
An unexploited vulnerability is not reportable merely because it exists. The reporting trigger is awareness of active exploitation, or awareness of a severe incident that has compromised product security. The manufacturer must also inform affected users and, where appropriate, all users about the event and measures they can take, applying that duty proportionately to the risk.
Article 14 reporting continues after a product's support period ends. It also covers qualifying in-scope products placed on the market before 11 December 2027. The Commission's guidance says the CRA does not require retroactive reporting where the manufacturer was already aware of the active exploitation before 11 September 2026.
A practical CRA applicability check
Ask these questions in order:
What is supplied? Identify each downloadable, installed, embedded, hardware and hosted component separately.
Is it made available on the EU market? Record the commercial transaction and the date each unit or software version is first supplied.
Does it connect to a device or network? Test the CRA's direct or indirect logical or physical connection requirement.
Does hosted processing support a product function? If it does, determine who designed and developed that remote software and under whose responsibility.
Does an exclusion apply? Check sector-specific legislation and the rules for non-commercial open source; do not infer an exclusion from an industry label alone.
What is the classification? Map the product against Annex III and Annex IV before selecting the conformity route.
Was it placed on the market before 11 December 2027? Document whether a later change is a substantial modification, while treating Article 14 reporting separately.
For a company offering both hosted and customer-deployed editions, analyse the editions separately. The hosted delivery model does not remove a downloadable or on-premises edition from scope. Equally, calling a hosted service “software” does not by itself establish that the service is a product with digital elements.
Readiness checklist for 2026–2027
Assign a product manufacturer and CRA classification owner.
Inventory shipped software, connected hardware, remote processing and third-party components.
Document the remote-processing scope test for every material hosted function.
Establish the Article 14 detection, escalation and Single Reporting Platform workflow before 11 September 2026.
Define how the 24-hour, 72-hour and event-specific final-report clocks will be measured and evidenced.
Establish a coordinated vulnerability disclosure policy and single contact point.
Generate and maintain an SBOM in a commonly used machine-readable format.
Document the cybersecurity risk assessment and its link to product requirements and tests.
Set an evidence-based support period and record the factors used to determine it.
Plan the conformity assessment, technical documentation, declaration of conformity and CE marking for products placed on the market from 11 December 2027.
Related briefings
NIS2 overview — cybersecurity duties for covered entities and services
B2B SaaS SME profile — a hosted-software archetype that still requires a remote-processing scope check
ISO 27001 — security-management evidence that may support, but does not replace, CRA product compliance
This briefing explains the official sources reviewed on 15 August 2026. It is not legal advice; confirm product-specific conclusions against the current law and guidance.