EU Cyber Resilience Act: Commission issues first draft guidance – 10 key points you need to know

On 3 March 2026, the European Commission published its first draft guidance on the EU Cyber Resilience Act (CRA). With the first CRA obligations starting to apply from June and September 2026, this guidance is the clearest signal yet of how the Commission expects manufacturers and other economic operators to apply the new rules in practice.

The CRA will require most hardware and software products with digital elements placed on the EU market to meet mandatory cybersecurity requirements across their lifecycle. Implementation projects over the past year have exposed several grey areas, especially around software, open source projects, remote data processing and legacy products.

The draft guidance, issued under Article 26 CRA and now open for public consultation, is intended to reduce some of this uncertainty and will likely become a key point of reference for both companies and market surveillance authorities once finalised.

Below is a summary of 10 key takeaways and what they mean in practice.

1. Why the guidance matters now

The CRA (Regulation (EU) 2024/2847) applies in stages:

• from 11 June 2026: rules on notification and designation of conformity assessment bodies
• from 11 September 2026: obligations to report vulnerabilities and incidents to authorities
• from 11 December 2027: full application of the CRA obligations to products with digital elements

Many organisations are already running CRA implementation projects, including scoping product portfolios, determining their role as manufacturer, importer or distributor, and building processes for security-by-design and vulnerability handling. The draft guidance builds on the Commission’s earlier frequently asked questions and implementing and delegated acts, but goes further by setting out a more structured interpretation of a number of core CRA concepts.

2. Scope and core concepts: how software is treated

A large part of the guidance is devoted to translating traditional EU product law notions into the software world.

Key points are:

• Placing on the market for software
  Software is treated as placed on the market when it is first supplied for distribution or use in the EU, including by making it available for download or via remote access. The guidance underlines that the non-tangible nature of software does not change this core concept.
• What is not treated as placed on the market
  The Commission indicates that some material commonly shared by developers falls outside CRA scope, such as sample or demonstration code included in tutorials, provided it is clearly not intended as a standalone product offered on the market.
• “Data connection” requirement
  A product must have at least one data connection, in the sense of exchanging digitally encoded information, to fall within scope. The guidance gives more nuance to the distinction between products that merely use electricity and those that actually communicate digital data, which is critical for borderline cases such as simple electronic devices.
• Combined hardware and software and complex systems
  The guidance explains how to define the “product” for CRA purposes when hardware and software are supplied together, or when multiple elements are integrated into a larger system. This impacts who is the manufacturer, how conformity assessments are carried out and how responsibilities are allocated in supply chains.

For businesses, this section is directly relevant to product scoping exercises and to deciding where CRA obligations actually bite.

3. Free and open-source software and the OSS Steward role

The CRA introduced the concept of an “open-source software steward” (OSS Steward), but left many practical questions open. The draft guidance begins to fill that gap.

Responsibility for a free and open source project is linked to who publishes and effectively controls the project through governance and decision-making, rather than to whoever happens to have commit rights. Purely technical permissions are not enough to create responsibility in CRA terms.

The guidance also clarifies when free software becomes part of a commercial activity. Even if software is distributed free of charge, it may still be treated as placed on the market if it is monetised, for example through paid support services, complementary offerings or by conditioning access on personal data processing that goes beyond security, compatibility or interoperability. Donations may be relevant where access to essential features or updates effectively depends on donating, or where donors receive contractual advantages that go beyond general communityadvantages.

The Commission confirms that the same legal entity can be an OSS Steward for one project and a manufacturer for another. In dual-track projects, where a community version is provided alongside a paid “enterprise” version, the paid product may trigger full manufacturer obligations, even if the community version remains under an OSS Steward model. The draft also gives examples of what “sustained support” can cover, such as hosting collaboration platforms, maintaining governance and steering development.

4. Substantial modifications, repairs and legacy products

Whether a change to a product qualifies as a “substantial modification” under the CRA is crucial: if it does, the modified product is treated as newly placed on the market and the party making or commissioning the change becomes the manufacturer for CRA purposes.

The Commission stresses that this is a case-by-case assessment. It should take into account the intended purpose of the product, whether compliance is affected and how the risk profile changes after the modification. For software updates, the guidance suggests focusing on whether the update introduces new threat vectors or materially alters existing attack scenarios.

The draft also provides practical markers for when repairs and replacement parts remain outside the concept of substantial modification. It confirms that products placed on the market before 11 December 2027 only fall within the CRA regime if they are substantially modified after that date.

To avoid unnecessary duplication, the Commission acknowledges that existing tests and documentation can be reused for unchanged aspects of a product and that conformity assessments should concentrate on the modified parts, while still considering their effect on the product as a whole.

5. Support periods: more than a five-year checkbox

Under Article 13(8) CRA, manufacturers must declare a support period during which they will provide security updates and handle vulnerabilities. The regulation sets a minimum support period of five years.

The guidance makes clear that five years is not a one‑size‑fits‑all default. Instead, support periods must reflect realistic patterns of use. Products that are typically deployed for longer than five years should have correspondingly longer support periods. For software that evolves through multiple versions, each version placed on the market should have its own defined support period.

The Commission also offers indications on when it may be permissible to focus remediation on the most recent version and how to interpret “additional costs” for users when providing security fixes. This nudges manufacturers to align CRA support declarations with product lifecycles, commercial strategies and contractual commitments, particularly in sectors where systems are used for many years.

6. Important and critical products: focus on core functionality

The CRA distinguishes “important” and “critical” products, and that classification affects which conformity assessment route applies and whether involvement of a notified body is required.

The draft guidance underlines that classification must be based on the core functionality of the product as a whole, not on individual components in isolation. The mere integration of a component that would itself fall into a higher class does not automatically reclassify the entire product. The guidance also discusses how harmonised standards that cover the core functionality interact with the internal control procedure and reminds manufacturers that they still need to assess and address risks stemming from additional features that are not covered by such standards.

This has practical implications for product classification exercises and for planning testing and certification strategies under the CRA.

7. Cybersecurity risk assessment and use of third-party components

The CRA requires manufacturers to perform and document a cybersecurity risk assessment under Article 13(2), taking account of the entire product lifecycle.

According to the guidance, manufacturers should identify the intended use and reasonably foreseeable misuse of the product, map relevant threat scenarios and attack paths, and document the risk treatment measures adopted, including security‑by‑design principles and secure default configurations. Third‑party and open source components form part of this assessment and cannot be treated as “black boxes”.

While upstream suppliers remain responsible for their own products, the manufacturer of the product with digital elements retains overarching responsibility for assessing and managing cybersecurity risks arising from those components. The draft therefore gives a clearer sense of what authorities and notified bodies are likely to expect in technical documentation.

8. Remote data processing solutions and cloud dependencies

Remote data processing solutions (RDPS) are a recurring challenge in CRA scoping exercises, particularly in cloud-heavy architectures.

The draft guidance proposes a three-part test. First, it considers whether the processing occurs “at a distance”. Second, it looks at whether the product functionally depends on that remote processing, meaning that it would be unable to perform a function without it. Third, it examines whether the relevant remote software is developed by, or under the responsibility of, the manufacturer.

The Commission draws a distinction between remote processing under the manufacturer’s responsibility, which can be part of the CRA product through the RDPS concept, and reliance on third-party infrastructure-as-a-service, platform-as-a-service or software-as-a-service. The latter is treated more like an external component. Those third-party services are not, by themselves, brought into the manufacturer’s CRA scope in the same way. The guidance does not, however, fully resolve broader questions about how the CRA will apply to cloud service providers in their own right, so further clarification on that topic may still emerge.

9. Vulnerability handling, reporting and interaction with other EU regimes

The draft also elaborates on the CRA’s vulnerability handling and reporting framework. It addresses upstream reporting and sharing security fixes in layered software stacks, and clarifies that manufacturers are not required to ensure that upstream projects accept their proposed patches.

An “exploitable vulnerability” is treated as “known” in various situations, for example where it is listed in public vulnerability databases, disclosed under a coordinated vulnerability disclosure process, discovered during internal testing or reported prominently in reputable media. However, manufacturers must still verify that the vulnerability actually affects their product before treating it as a known issue for CRA purposes.

Finally, the draft touches on the interaction between the CRA and other pieces of EU legislation, including particular scope exclusions and how to treat components designed exclusively for integration into exempt products.

10. Next steps and practical actions

Stakeholders can submit comments on the draft guidance until 31 March 2026 via the Commission’s consultation portal. The Commission is expected to finalise the guidance afterwards, possibly with changes based on the feedback received. Even then, the document will remain non-binding; only the CJEU can provide an authoritative interpretation of the CRA.

In the meantime, companies affected by the CRA should:

1. Review the draft guidance against current CRA programmes
   Check whether your existing scoping, product classification and risk assessment approaches are aligned with the positions taken in the draft.
2. Revisit treatment of software and open source
   Confirm how you classify software-only products, RDPS, and free and open source components, including any monetised or dual-version models.
3. Define or refine support period strategies
   Ensure declared support periods reflect realistic use and are consistent with product lifecycle plans and contractual commitments.
4. Design update and modification policies
   Put in place clear internal criteria and processes for determining when changes may amount to substantial modifications.
5. Consider contributing to the consultation
   For organisations with significant CRA exposure, providing feedback to the Commission may help shape the final guidance, especially on unresolved areas such as cloud services and complex system architectures.

If you would like to discuss how the draft guidance may affect your CRA readiness work, or need support in preparing consultation responses or implementation plans, please contact us.