The Cyber Resilience Act timetable is becoming operational. Companies that market software, connected equipment or digital solutions under their own name cannot wait until 2027: specific vulnerabilities and incidents will have to be reported from September 2026.
What has just happened
On 27 July 2026, the European Commission published “Commission publishes new guidance to support timely Cyber Resilience Act implementation”. The non-binding guidance clarifies product scope, substantial modifications, support periods and reporting obligations. It includes 67 practical examples, use cases, diagrams and decision trees, with particular attention given to smaller organisations. The CRA’s main compliance requirements will apply from 11 December 2027, but vulnerability and incident reporting starts on 11 September 2026. ENISA’s Single Reporting Platform is due to be operational on that date, with testing expected beforehand.
Why this affects your company — or does not
The Cyber Resilience Act does not directly regulate every organisation that uses computers, an ERP or cloud services. It mainly targets economic operators that make products with digital elements available on the European market: software, applications, connected devices and hardware components capable of communicating directly or indirectly with a device or network.
Your role in the supply chain matters more than your company’s size. Under the Cyber Resilience Act legal text, an organisation can be considered a manufacturer when it develops — or commissions the development of — a digital product and markets it under its own name or trademark. An importer or distributor can also assume manufacturer obligations by applying its own brand or substantially modifying the product.
| Your situation | Direct obligation from 11 September 2026 | Immediate decision |
|---|---|---|
| You publish software under your own brand | Yes, if the software falls within the CRA | Identify active versions and establish reporting |
| You sell connected equipment or machinery containing software | Yes, if digital connectivity is part of the product | Connect hardware, software and security records |
| You provide a third-party solution under a white-label agreement | Probably, as you may be treated as the manufacturer | Review contractual ownership immediately |
| You significantly modify a third-party product before marketing it | Potentially, if its purpose or cyber risk changes | Document the change and obtain a scope decision |
| You resell an unchanged product under the manufacturer’s brand | Not under Article 14 as the manufacturer | Establish an escalation channel to the manufacturer |
| You only purchase and use software or equipment | No, unless your role changes | Strengthen supplier and incident clauses |
| You develop an internal tool that is not placed on the market | Generally no | Continue applying normal security controls |
A generic SaaS or cloud service is not automatically covered by the CRA. However, remote processing developed under a manufacturer’s responsibility and required for a digital product to operate may form part of that product’s scope. Our cloud migration checklist provides a useful starting point for mapping services, dependencies and contractual ownership.
What this changes in practice
The September deadline does not require companies to have completed every technical file, CE marking activity and conformity assessment due in December 2027. It does, however, require affected manufacturers to recognise, qualify and report:
- vulnerabilities in their products that are actively being exploited by a malicious actor;
- severe incidents affecting product security, including availability, integrity, authenticity or the confidentiality of sensitive data and functions.
According to the Commission’s CRA reporting rules, manufacturers must submit an early warning within 24 hours of becoming aware of the event and a fuller notification within 72 hours. For an exploited vulnerability, a final report is due no later than 14 days after a corrective measure becomes available; for a severe incident, it is due within one month of the main notification.
These deadlines affect several operational processes.
Customer support can no longer treat every security alert as a normal ticket
A message stating that suspicious activity has been detected in an application, device or customer environment must be able to leave the standard support queue immediately. Support teams need a documented escalation reason, a named security contact and a method for preserving the original message, attachments and exact receipt time.
IT must start the clock before completing the investigation
The regulatory timetable begins when the manufacturer becomes aware of the event, not when a complete forensic report is available. IT or the security lead must record the discovery time, affected product and version, initial evidence of exploitation, countries where the product was supplied and mitigation measures already taken.
The process must allow an incomplete early notification to be submitted and then enriched as new facts become available. Waiting for perfect technical certainty can consume most of the reporting window.
Product owners need visibility over versions still in use
The reporting obligations also apply to in-scope products placed on the market before 11 December 2027. An older version still used by customers cannot be ignored simply because it is no longer being sold.
The product register should connect the commercial name, distributed versions, internal owner, known critical components, distribution territories and support status. This work supports the broader governance principles discussed in our article on building an effective digital strategy in 2026.
Development and hosting contracts become regulatory dependencies
An external developer, managed service provider or hosting company may detect the problem before the manufacturer. Contracts therefore need an immediate escalation requirement, a named communication channel, preservation of relevant technical logs and cooperation in preparing regulatory reports.
These clauses do not automatically transfer the manufacturer’s legal responsibility. Their purpose is to prevent critical information from remaining inside a supplier’s ticketing system while the reporting deadline continues to run.
Management must authorise someone to submit the notification
A process requiring consecutive approval from development, legal, sales and executive management is unsuitable for an urgent early warning. Management should appoint a primary and backup person authorised to use the ENISA platform and define which sensitive information requires legal review before submission.
This is a governance and continuity issue, not merely a security task. Companies without a permanent CIO can use the operating model described in our analysis of the part-time CIO role to assign clear accountability without creating a full internal department.
What to do by 11 September 2026
- By 7 August — CEO and CIO/security lead: approve a scope memo listing marketed software, equipment and components, the brand under which they are supplied, distribution countries and the company’s legal role. The deliverable is a product register with a named owner for each entry.
- By 21 August — IT and product owners: produce a CRA response sheet distinguishing an actively exploited vulnerability, a severe incident and an out-of-scope event. It must record the intake channel, awareness time, evidence to preserve, decision owner and information required for notification.
- By 28 August — Legal, procurement and IT: review contracts with developers, maintainers, hosting providers and component suppliers. Produce a standard amendment covering immediate escalation, access to relevant logs, technical cooperation and named contacts.
- By 4 September — IT, support and communications: run a tabletop exercise using an event explicitly identified as fictional. The deliverables are a chronological incident record, draft notification, qualification decision and user communication template.
- From 11 September — Executive management and IT: activate decision continuity, confirm access to the ENISA Single Reporting Platform and configure the official deadlines in the incident-management tool.
This work can become part of a broader product-compliance programme. Our IT Project Management service can structure the scope, product register, responsibilities, reporting workflow and operational acceptance tests.
What you can ignore for now
Not every security flaw must be reported under the September obligation. A theoretical vulnerability with no evidence of active exploitation does not automatically trigger mandatory CRA reporting. It should still be assessed and addressed through the company’s normal vulnerability-management process.
You also do not need to complete the full December 2027 conformity programme by September. The comprehensive risk assessment, technical documentation, EU declaration of conformity and CE-related requirements follow the later timetable. The immediate priority is an executable detection, qualification and notification process.
A security update intended solely to reduce cyber risk will not generally constitute a substantial modification. By contrast, a new feature that changes the intended use or increases the attack surface may require a fresh assessment. Companies do not need to freeze all updates; they need a CRA criterion in their change-approval process.
Our view at D1 Consulting
The main risk is not a missing legal memo. It is discovering during the first reportable incident that nobody can establish when the company became aware, who is authorised to qualify the event or who can submit the notification.
The Commission’s guidance reduces uncertainty, but it does not create an internal operating process. Software publishers, white-label integrators and connected-equipment manufacturers should aim for a short decision chain: an identifiable entry point, documented qualification, an available decision-maker and a complete audit trail.
This initial workflow should then feed the December 2027 programme, including product records, release management, risk documentation and supplier requirements. To strengthen detection and response in parallel, see our guidance on protecting your company from cyberattacks using AI.
👉 Book a free 30-minute diagnostic to confirm your CRA scope and receive a dated checklist of the documents, roles and workflows your organisation needs.
