On 27 July 2026, the European Commission published extensive guidance on the application of Regulation (EU) 2024/2847 — the Cyber Resilience Act (CRA).

The document addresses several of the most debated issues that have remained unclear for software vendors, hardware manufacturers, IoT companies, component suppliers, and open-source projects.

Its practical significance is substantial. The CRA is gradually moving from a high-level regulatory framework towards a set of concrete expectations covering the entire lifecycle of a digital product: from determining what qualifies as a product with digital elements to vulnerability management, support periods, software updates, third-party dependencies, and incident reporting.

The key takeaway from the new guidance is straightforward:

The CRA should not be treated as a one-time certification exercise. It is a framework for continuous cybersecurity risk management throughout the product lifecycle.

1. Not Everything Digital Falls Within the Scope of the CRA

One of the most important clarifications concerns the boundary between a software product and a remote service.

Standalone software may fall within the scope of the CRA. This can include desktop applications, mobile applications, browser extensions, and applications built using web technologies where they are supplied to users and executed on their devices.

By contrast, a conventional web application accessed exclusively through a browser is not, by itself, considered a product with digital elements. The same generally applies to ordinary websites unless they provide functionality that forms part of a product covered by the CRA.

This distinction has direct implications for SaaS providers.

For example:

• a mobile banking application installed on a smartphone may fall within the scope of the CRA;
• a browser extension may also fall within scope;
• locally installed client software may be covered;
• a web-only SaaS application will generally not qualify as a product with digital elements by itself.

However, the architecture of a product can change this assessment. If a locally deployed client depends on remote data processing in order to perform one of its functions, the relevant remote data processing solution may itself become part of the product for the purposes of the CRA.

2. Software Versioning Becomes Part of the Compliance Model

For traditional hardware, the concept of placing on the market is relatively straightforward. For software, it is more complex.

The Commission clarifies that standalone software is placed on the market when its production phase has been completed and a specific version is first made available to users on the EU market.

This means that repeated downloads of the same version do not create a new placing on the market event each time.

For example, if version 1.0.0 is first released on 1 January and another customer downloads exactly the same version on 15 January, both copies are considered to have been placed on the market when that version was originally released.

The situation changes, however, when a software release constitutes a substantial modification.

Where a new version materially changes the cybersecurity risk profile of the product, it may be considered a new product for CRA purposes and may trigger new conformity assessment obligations.

As a result, software release management is becoming part of the compliance model.

It is no longer sufficient to simply manage releases as:

Version 1.0 → Version 1.1 → Version 1.2

For significant releases, manufacturers should be able to determine:

• whether the intended purpose of the product has changed;
• whether new attack vectors have been introduced;
• whether new external dependencies have been added;
• whether new attack scenarios have emerged;
• whether the likelihood of existing attack scenarios has changed;
• whether the potential impact has increased;
• whether the new or increased risks were already covered by the existing cybersecurity risk assessment.

If new or increased risks were not previously considered, the update may qualify as a substantial modification.

3. A New Feature Can Turn a Routine Update into a New Regulatory Event

The Commission provides a particularly useful example.

Imagine a dashboard that initially collects data from industrial equipment and displays trends and alerts. The manufacturer later introduces functionality allowing users to control machines, modify operational parameters, and restart equipment.

From a cybersecurity perspective, this is no longer merely a monitoring tool.

The product has moved from situational awareness to operational control, fundamentally changing its cybersecurity risk profile. Such a change may qualify as a substantial modification.

For manufacturers, this means that CRA assessment should be integrated directly into the development and release process.

A mature release pipeline should therefore include a regulatory security gate assessing:

1. whether the intended purpose has changed;
2. whether new trust boundaries have been introduced;
3. whether new interfaces have been added;
4. whether new third-party dependencies are involved;
5. whether the attack surface and threat model have changed;
6. whether the changes are covered by the existing risk assessment;
7. whether a new conformity assessment may be required.

4. Open Source Does Not Receive Automatic Exemption

One of the most detailed sections of the guidance concerns free and open-source software.

The fact that software is distributed under an open-source licence does not automatically place it outside the scope of the CRA.

The Commission distinguishes between:

• non-commercial FOSS;
• FOSS made available on the market in the course of commercial activity;
• paid versions and enterprise editions;
• open-core models;
• monetisation through other services;
• monetisation involving the processing of personal data;
• donations;
• paid support;
• open-source software stewards.

FOSS that is openly shared, freely accessible, and not monetised by the manufacturer will generally not be considered to have been made available on the market in the course of a commercial activity.

The situation may change where the software forms part of a commercial model.

Relevant examples may include:

• selling compiled binaries;
• offering paid enterprise editions;
• monetising other services through the software platform;
• requiring the processing of personal data for advertising or analytics purposes;
• effectively making donations a condition for access to the product or security updates.

In such cases, the software may be considered to have been made available on the market, and the relevant organisation may assume the responsibilities of a manufacturer under the CRA.

At the same time, paid support does not automatically make FOSS a commercial product.

A model such as:

Free software + optional consulting

may have a different regulatory status from:

Free software + paid access to updates, security fixes, or enterprise functionality.

This distinction is particularly relevant for companies building commercial ecosystems around open-source products.

5. Contributors Do Not Automatically Become Responsible for the Entire Project

The guidance also draws a clearer distinction between contributors and those who actually exercise control over a product.

An individual who submits a pull request or develops a security patch, but does not control releases, the product roadmap, or distribution decisions, does not automatically become responsible for CRA compliance for the entire project.

Responsibility is more closely associated with individuals or organisations exercising primary control over the development, release, and distribution of the software.

This is an important clarification for the open-source ecosystem. Ordinary participation in an open-source project does not automatically create the regulatory responsibility of a manufacturer.

6. Cloud and SaaS Dependencies Must Be Separated into Different Categories

One of the most technically important concepts in the guidance is the definition of remote data processing solutions (RDPS).

Not all cloud infrastructure automatically becomes part of a product.

The assessment requires, among other things, consideration of two key questions:

1. Is the remote data processing necessary for the product to perform one of its functions?
2. Has the relevant software been designed and developed by the manufacturer, or under its responsibility?

Where these conditions are met, the remote processing solution may be considered part of the product with digital elements.

For example, a smart thermostat may rely on a cloud backend developed by the manufacturer but hosted on third-party infrastructure. If the backend is necessary for the product to perform its smart functionality, the relevant backend may qualify as an RDPS.

The third-party IaaS infrastructure, however, remains an external dependency that must be considered as part of the manufacturer’s risk assessment and due diligence.

The situation is different where a product uses a generic third-party SaaS service.

For example, an e-reader may rely on an independent SaaS storage provider for storing electronic books. If that service is developed and operated independently and is not under the manufacturer’s responsibility, the SaaS service itself does not automatically become an RDPS.

However, this does not remove responsibility for the risks associated with that dependency.

The manufacturer may still need to consider:

• authentication;
• encryption;
• integrity protection;
• dependency failures;
• data flows;
• compromise scenarios;
• risks created by the integration itself.

The core principle is simple:

Even where an external system is not formally part of the product, the cybersecurity risks it creates for the product may still need to be addressed by the manufacturer.

7. Third-Party Dependencies Become a Formal Due Diligence Issue

The CRA guidance clearly distinguishes between two complementary obligations.

Cybersecurity Risk Assessment

Manufacturers must assess cybersecurity risks affecting the product, including risks originating from external systems, networks, infrastructure, and services.

Due Diligence for Integrated Components

Where third-party software or hardware components are integrated into a product, the manufacturer must identify the security properties required from those components and verify, on a risk-based basis, that they are capable of meeting those requirements.

For example, where a product relies on a third-party component for:

• cryptographic operations;
• secure communications;
• update mechanisms;
• authentication;
• key management;

the manufacturer should have sufficient evidence that the component can provide the required security properties.

Relevant evidence may include:

• technical documentation;
• security documentation;
• conformity evidence;
• assurance documentation;
• independent or internal testing.

This effectively creates a more formal model of software and component supply-chain governance.

Simply stating:

“We use a third-party library”

will not be sufficient.

Manufacturers need to understand:

• what function the component performs;
• what risks arise if it is compromised;
• what security assumptions are being made;
• how those assumptions are validated;
• what happens when a vulnerability is discovered;
• what happens when the component reaches end-of-life;
• who is responsible for ongoing maintenance.

8. Support Is Not Simply Five Years for Every Product

One of the most common simplifications of the CRA is the assumption that:

Every digital product must be supported for five years.

The Commission’s guidance makes clear that this interpretation is too simplistic.

Five years represent a minimum benchmark unless the manufacturer can demonstrate that the expected use time of the product is shorter.

Where a product can reasonably be expected to remain in use for longer, the support period may need to extend accordingly.

In other words, five years should not be treated as a universal default for every product.

Manufacturers are expected to determine the expected use time based on the nature of the product and other relevant factors.

The guidance also introduces flexibility for software products. Under certain conditions, a manufacturer may focus vulnerability remediation on the latest version where users of earlier versions can upgrade free of charge and without incurring additional costs beyond normal operational efforts.

This is particularly relevant for companies operating continuous delivery and regular software release models.

9. A Substantial Modification Does Not Always Restart the Support Period

A substantial modification may require a reassessment of the product, but it does not automatically mean that the support period starts again from zero.

The key question is whether the modification changes the factors that originally determined the product’s expected use time.

For example, a software update may introduce new functionality to a hardware product without affecting the physical lifespan of the underlying device.

In such a case, the support period may remain linked to the originally determined expected use time.

However, where a manufacturer performs a major hardware modernisation or substantially rewrites the core software in a way that materially changes the expected lifecycle of the product, the support period may need to be reassessed.

10. Vulnerability Management Is Not Enough — Speed of Response Matters

One of the most operationally significant parts of the guidance concerns incident reporting.

Manufacturers may be required to notify the relevant coordinated CSIRT and ENISA of:

• actively exploited vulnerabilities contained in their products;
• severe incidents affecting the security of their products.

The reporting obligations under Article 14 begin to apply from 11 September 2026 for products falling within the relevant scope of the CRA, including certain products placed on the market before the full application of the main CRA requirements.

Importantly, reporting obligations may continue to apply even after the product’s support period has ended.

The guidance describes a staged reporting model:

• an early warning without undue delay and no later than 24 hours after becoming aware;
• a subsequent notification within 72 hours;
• a final report within the applicable regulatory deadlines.

A particularly important issue is determining the point of awareness.

The reporting clock should not necessarily start from the moment of an initial rumour, unverified researcher report, or suspicious event.

A manufacturer is considered to have become aware once an initial assessment provides a reasonable degree of certainty that:

• a vulnerability is being actively exploited; or
• a severe incident has occurred and compromised the security of the product.

However, the initial assessment must itself be performed without undue delay.

A manufacturer cannot use an indefinitely prolonged investigation to artificially delay the reporting deadline.

11. A Known Vulnerability Is Not Automatically an Exploitable Vulnerability

The guidance introduces an important practical distinction between a vulnerability that has merely been identified and a known exploitable vulnerability.

A vulnerability may become known to a manufacturer through:

• publicly accessible vulnerability databases;
• coordinated vulnerability disclosure;
• internal testing;
• security research;
• reliable public reporting.

However, the existence of a CVE or security advisory does not automatically mean that the vulnerability is applicable to, or practically exploitable in, a specific product.

The manufacturer still needs to assess:

• applicability;
• reachability;
• exploitability;
• practical operational conditions;
• potential impact.

This distinction is particularly relevant for organisations using Software Composition Analysis and automated vulnerability scanning.

A large number of CVEs in an SBOM does not, by itself, demonstrate non-compliance.

However, the absence of a documented process for assessing applicability and exploitability is likely to create a far more serious compliance problem.

12. Vulnerability Management Must Also Work Upstream

Where a manufacturer identifies a vulnerability in an integrated component, the CRA framework also addresses reporting and remediation at the upstream level.

Where appropriate, vulnerabilities should be communicated to the relevant maintainer or manufacturer of the affected component.

If the manufacturer develops a security fix for the component, the fix should also be shared upstream in an appropriate manner.

For open-source components, security fixes should be shared in a way that is compatible with the applicable licence and the governance model of the project.

At the same time, the CRA does not require a manufacturer to guarantee that an upstream maintainer will accept or merge the proposed patch.

The obligation concerns responsible disclosure and the appropriate sharing of security fixes — not control over the decisions of an independent maintainer.

13. Security Testing Must Be Risk-Driven, Not Merely Periodic

The guidance also clarifies the concept of regular testing.

Regular testing does not necessarily mean mechanically repeating the same penetration test or vulnerability scan at fixed intervals.

Manufacturers are expected to regularly review new inputs such as:

• emerging threats;
• newly disclosed vulnerabilities;
• changes to the product;
• architectural changes;
• new attack scenarios;
• changes in the threat landscape.

Where these developments require new or modified testing, the manufacturer should update and execute the relevant tests.

The frequency, depth, and scope of testing should be proportionate to the cybersecurity risk profile of the product.

This moves the CRA much closer to a mature risk-based security assurance model rather than a simple checklist-driven compliance exercise.

14. Legacy Products Do Not Necessarily Need to Be Completely Redesigned

For manufacturers of legacy hardware and software, the guidance provides an important clarification.

A product designed before the CRA becomes applicable, but placed on the market afterwards, does not necessarily need to be completely redesigned.

Where a current cybersecurity risk assessment demonstrates that the existing architecture and security measures adequately address the relevant risks, the manufacturer may rely on those existing measures to demonstrate compliance.

However, the manufacturer must still:

• perform a current cybersecurity risk assessment;
• maintain appropriate technical documentation;
• complete the applicable conformity assessment procedure;
• implement vulnerability handling processes;
• prepare the EU Declaration of Conformity;
• apply CE marking where required.

The CRA does not necessarily require manufacturers to recreate the historical design and testing process retrospectively.

The primary objective is to demonstrate that the product, as it exists today, achieves an appropriate level of cybersecurity for its intended purpose and reasonably foreseeable use.

What Manufacturers Should Do Now

The new guidance makes it clear that preparation for the CRA should not be reduced to producing a single compliance matrix.

Manufacturers should establish at least the following capabilities.

1. Product Scope Assessment

Identify which products, components, locally deployed clients, and remote data processing solutions fall within the scope of the CRA.

2. Cybersecurity Risk Assessment

Treat the risk assessment as a living artefact that evolves with changes to the product, architecture, threat landscape, and third-party dependencies.

3. Release Compliance Gate

Before significant releases, determine whether the change constitutes a routine update or a substantial modification.

4. Dependency Governance

For critical software and hardware components, define:

• security requirements;
• maintainer or supplier status;
• support status;
• vulnerability management processes;
• available security evidence;
• integration risks.

5. Vulnerability Management and Coordinated Disclosure

Establish documented processes for:

• vulnerability intake and triage;
• applicability assessment;
• exploitability analysis;
• remediation;
• customer communication;
• upstream reporting;
• security fix sharing.

6. Incident Reporting Readiness

Organisations potentially subject to the Article 14 reporting obligations should already have a working process for initial assessment, escalation, and regulatory reporting.

A 24-hour initial reporting deadline leaves very little room for ad hoc decision-making during an incident.

7. Support Lifecycle Management

For each relevant product, manufacturers should determine and document:

• expected use time;
• the applicable support period;
• vulnerability handling responsibilities;
• end-of-support communication.

Conclusion

The most significant development in the new guidance is the shift of the CRA from an abstract regulatory framework towards a set of concrete engineering and governance expectations.

Compliance is increasingly connected to how an organisation:

• designs its products;
• performs threat modelling;
• manages software versions;
• makes architectural decisions;
• uses cloud and SaaS services;
• governs third-party dependencies;
• manages open-source components;
• handles vulnerabilities;
• performs security testing;
• manages the lifecycle and support of its products.

For mature organisations, this means integrating CRA requirements into existing Secure SDLC, product governance, vulnerability management, and third-party risk management processes.

For less mature organisations, the main risk is not simply the absence of a CRA policy or compliance document.

The more fundamental problem is the absence of a demonstrable chain of evidence linking cybersecurity risk, technical decisions, implemented controls, testing, software changes, vulnerability handling, and ongoing product support.

Based on the European Commission’s new guidance, this connection between cybersecurity engineering and regulatory compliance is likely to become one of the central elements of practical CRA implementation.