The 60-second summary
The European Commission has published new guidance to support timely implementation of the Cyber Resilience Act (Regulation (EU) 2024/2847). The guidance does not change the Regulation or its dates. It explains how the Commission reads recurring scope questions — when software is placed on the market, how remote data processing and components are treated, and what is expected of different economic operators. The near-term pressure point is 11 September 2026, when reporting obligations for actively exploited vulnerabilities and severe incidents begin to apply, ahead of the main obligations on 11 December 2027.
Timeline that matters
10 December 2024
CRA enters into force
Regulation (EU) 2024/2847 entered into force and the transition period began.
11 September 2026
Reporting obligations apply
Obligations to report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements begin to apply.
11 December 2027
Main obligations apply
The main obligations of the Regulation, including the essential cybersecurity requirements, technical documentation and conformity assessment, begin to apply.
What changed
The Cyber Resilience Act has been in force since 10 December 2024 and its substance is unchanged. What is new is Commission guidance intended to support timely and consistent implementation while harmonised standards are still being developed. It addresses questions organisations have repeatedly raised about scope boundaries, software distribution models, components and the responsibilities attached to each economic-operator role. Guidance of this kind is not binding law — only the Court of Justice of the European Union can give an authoritative interpretation — but it is the clearest available indication of how the Commission expects the Regulation to be applied, and it removes much of the practical justification for delaying readiness work.
Who should pay attention?
Manufacturers of products with digital elements
Organisations that place hardware or software with digital elements on the EU market under their own name or trademark, including software supplied separately from a device.
Component, library and embedded-software suppliers
Suppliers whose components are integrated into products placed on the EU market may need to assess how the Regulation reaches their part of the chain.
Importers and distributors
Economic operators that place products on, or make products available to, the EU market carry verification duties that differ from those of the manufacturer.
Open-source software stewards
Organisations providing sustained support to open-source products used in commercial activity may carry tailored duties rather than full manufacturer obligations.
Product, security, legal and privacy teams outside the EU
Market placement rather than establishment is the relevant trigger, so non-EU organisations supplying the EU market may need to assess their position.
What the guidance clarifies
- When a product is placed on the market
- The guidance addresses the point at which obligations attach, including for software made available for download, and how later versions and updates are treated.
- Software as a product with digital elements
- It discusses how standalone software, software supplied with hardware, and software components are treated, which affects who holds the manufacturer role.
- Remote data processing solutions
- Remote functionality that a product depends on to perform its function may fall inside the product boundary, while functionality outside that dependency is generally treated differently.
- Open-source software and stewardship
- The guidance sets out how commercial activity and stewardship are approached, and what may be expected of each role.
- Conformity assessment and product categories
- It explains how product categorisation influences the conformity-assessment route, including where harmonised standards or third-party involvement may be relevant.
Practical relevance — not a statement of applicability
Why this matters for India-based companies
The Cyber Resilience Act applies to products with digital elements placed on or made available to the EU market, regardless of where the organisation behind them is established. Many India-based product companies, software and embedded-component suppliers and IT services firms may therefore need to assess whether, and in what role, the Regulation reaches their activities. This is not a statement that the Regulation applies to any particular organisation: not every Indian company is covered, and scope depends on the specific product, the supply arrangement and the economic-operator role involved. Where the Regulation does not apply directly, its expectations may still reach an organisation contractually, through EU customers and partners.
- Organisations placing products with digital elements on the EU market under their own name or trademark may hold manufacturer obligations, wherever they are established.
- Suppliers of software, libraries or components into EU product chains may be asked for evidence even where they are not themselves the manufacturer.
- Organisations supporting EU customers under service or maintenance arrangements may inherit flow-down expectations for vulnerability handling and security updates.
- Not every Indian company is covered — scope should be assessed per product and per role, with qualified legal advice where the position is unclear.
- Readiness evidence built for the CRA generally supports other frameworks, including customer security reviews and existing privacy obligations.
10 actions to start now
- Build an inventory of products with digital elements sold or supplied into the EU.
- Map whether remote data processing and software components may be in scope.
- Identify the organisation's economic-operator role for each product.
- Gap-assess lifecycle cybersecurity requirements.
- Document product-level cybersecurity risk assessments.
- Strengthen secure-development and vulnerability-handling processes.
- Define and evidence support periods and security-update commitments.
- Prepare the vulnerability and incident reporting workflow for 11 September 2026.
- Map technical documentation, conformity-assessment and CE-marking evidence needs.
- Assign owners, milestones and supplier dependencies ahead of December 2027.
Evidence worth retaining
- Product inventory recording, for each entry, the assessed economic-operator role and scope position.
- Product-level cybersecurity risk assessments, dated and version controlled.
- Software bill of materials per product release, including third-party and open-source dependencies.
- Documented vulnerability-handling and coordinated disclosure process, with a monitored contact route.
- Stated support period and security-update commitment as communicated to customers.
- Reporting runbook for actively exploited vulnerabilities and severe incidents, with a dry-run record.
- Technical documentation pack mapped to conformity-assessment and CE-marking evidence needs.
Questions to take to counsel or your conformity team
These are discussion prompts, not legal advice or conclusions.
- For each product we supply into the EU, what economic-operator role do we hold, and on what basis was that assessed?
- Does any remote data processing we operate form part of a product with digital elements?
- Which products, if any, fall into categories that affect the conformity-assessment route?
- What support period can we credibly commit to and resource for each product?
- Who is authorised to declare a severe incident and to report within the applicable deadlines, including out of hours?
- How would CRA reporting interact with our existing personal data breach and sectoral notification processes?
- Which supplier contracts need to change so that vulnerability information and security updates reach us in time?
Official sources
- European Commission — Commission publishes new guidance to support timely Cyber Resilience Act implementation
- European Commission — Cyber Resilience Act (policy overview)
- European Commission — Cyber Resilience Act implementation: frequently asked questions
Privacy Practice Lab / PrivacyBuilt is an independent educational publisher. It is not affiliated with, or endorsed by, any regulator or the European Union.
Privacy Practice Lab publishes educational and technical guidance. Nothing on this site constitutes legal advice, and it should not be relied on as a legal determination for your organisation.