On this page · 10 sections
- What actually changes on 11 September 2026
- One report, one platform: how the CRA Single Reporting Platform works
- Who counts as a manufacturer, and which products are in scope
- The SBOM you will need whether you like it or not
- What non-compliance costs
- India-specific considerations
- The 24-hour workflow you need before September
- FAQ
- How eCorpIT can help
- References
Summary. On 11 September 2026, the reporting duties in the EU Cyber Resilience Act (Regulation (EU) 2024/2847) start to apply. From that date, any manufacturer of a product with digital elements sold in the EU must file an early warning within 24 hours of learning that a vulnerability in its product is being actively exploited, a fuller notification within 72 hours, and a final report within 14 days of a fix. Reports go through one channel, the ENISA Single Reporting Platform, which routes each notice to a national Computer Security Incident Response Team (CSIRT) and to ENISA at the same time. Breaching the core obligations can cost up to €15 million or 2.5% of worldwide annual turnover, whichever is higher. The rest of the CRA, including CE marking and conformity assessment, applies from 11 December 2027. This is not a European problem alone: an Indian SaaS company, an IoT vendor in Pune, or a firmware team in Bengaluru shipping into the EU is a "manufacturer" under the law and inherits the same 24-hour clock.
The reporting clock is the first hard deadline in the CRA, and it is the one most teams are unprepared for. Conformity assessment and CE marking feel distant at December 2027. A 24-hour reporting duty that begins in September 2026 does not. This article sets out exactly what changes on that date, the workflow you need in place before it, and the parts that Indian software and hardware exporters keep getting wrong.
What actually changes on 11 September 2026
The European Commission's own guidance is blunt: "As of 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements." Two triggers matter here, and they are narrower than the general duty to handle vulnerabilities.
The first trigger is an actively exploited vulnerability. A flaw sitting in your backlog with a CVSS score and no known exploitation does not start the clock. Evidence that someone is using it against your product in the wild does. The second trigger is a severe incident that affects the security of the product, such as a breach of your build pipeline or signing infrastructure that could compromise users downstream.
Once either trigger fires, the CRA sets a staged timeline drawn from Article 14. You file an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report once the matter is closed. The Commission specifies that the final report is due "no later than 14 days after a corrective measure is available" for an actively exploited vulnerability, and within one month for a severe incident.
| Reporting stage | Deadline (from awareness) | What you file |
|---|---|---|
| Early warning | 24 hours | That an actively exploited vulnerability or severe incident exists, plus whether you suspect unlawful or malicious action |
| Full notification | 72 hours | General information on the vulnerability or incident, its severity and impact, and any corrective or mitigating measures taken |
| Final report (exploited vulnerability) | 14 days after a fix is available | A description of the vulnerability, its severity and impact, and the corrective measures shipped |
| Final report (severe incident) | 1 month | Root cause, mitigations, and the type of malicious action if known |
| Voluntary updates | Ongoing | Additional detail as an investigation develops |
The 24-hour window is the part that reshapes engineering process. It is shorter than the 72-hour breach-notification window most teams know from data-protection law, and it starts from the moment anyone at the company reasonably becomes aware, not from the moment a manager decides it is worth reporting.
One report, one platform: how the CRA Single Reporting Platform works
Manufacturers do not report separately to 27 member states. The CRA channels everything through a single system. As the Commission puts it, "manufacturers report only once through the CRA Single Reporting Platform (SRP)." The notification is addressed to the CSIRT of the country where the manufacturer has its main establishment, and, barring exceptional circumstances, the information reaches ENISA at the same time. The receiving CSIRT then shares the notice without delay with other CSIRTs in whose territory the product is available.
ENISA is building this platform under Article 16 of the regulation. It has run a public tender, procured a contractor, and committed that the platform "will be operational by 11 September 2026, with a testing period before then." There is a wrinkle worth planning around: as of mid-2026, industry trackers noted the SRP was not yet live, and ENISA has signalled dry-run and registration support in the run-up. The reporting duty does not wait for the platform to feel finished. If the SRP registration opens, get onboarded early, because the 24-hour clock does not pause while you sort out access.
There is one relief valve. On 11 December 2025, the Commission adopted a delegated act specifying when a CSIRT may, on justified cybersecurity grounds, delay passing a notification to other CSIRTs. That protects a live investigation from premature disclosure. It does not change your deadline to file.
ENISA sits at the centre of this machinery, and its leadership frames the agency's expanding remit in operational terms. "For an organisation like ENISA, agility and innovation are key elements in effectively navigating our continuously shifting cybersecurity landscape," said Juhan Lepassaar, Executive Director at ENISA, in the agency's March 2025 restructuring announcement, which named the Cyber Resilience Act among the laws ENISA now supports. For manufacturers, the practical reading is simple: the regulator has built a single front door, and it expects you to use it fast.
Who counts as a manufacturer, and which products are in scope
The CRA reaches "products with digital elements", meaning software or hardware that can connect to a device or network, plus their remote data-processing solutions. That definition is deliberately wide. It covers operating systems, mobile apps, desktop software, firmware, IoT devices, industrial controllers, network gear, and connected consumer goods.
Scope is tiered. Most products fall in the default class and self-assess against the essential requirements. A smaller set of "important products with digital elements" is listed in Annex III, split into two classes, and a narrower set of "critical products" is listed in Annex IV. The higher the class, the stricter the conformity route, ranging from self-assessment up to third-party assessment by a notified body.
| Product class | Where defined | Examples | Conformity route |
|---|---|---|---|
| Default | Article 6 | Most business software, mobile apps, many IoT devices | Self-assessment against Annex I |
| Important, Class I | Annex III | Password managers, network management systems, VPNs | Self-assessment with standards, or third-party |
| Important, Class II | Annex III | Hypervisors, firewalls, tamper-resistant microcontrollers | Third-party assessment |
| Critical | Annex IV | Hardware devices with security boxes, smart meter gateways, smartcards | Third-party assessment, possible EU certification |
Two scope points catch teams out. First, the reporting duty from September 2026 applies regardless of class. A default-class mobile app has the same 24-hour obligation as a critical smart-meter gateway. Second, legacy matters. The reporting rules cover products already placed on the EU market before full CRA application, so a device you shipped in 2024 and still support is in scope for reporting today.
Free and open-source software gets tailored treatment. Software that is openly shared and genuinely non-commercial sits outside the manufacturer obligations. A middle category, the "open-source software steward" defined in Article 24, applies light-touch duties to foundations and organisations that steward projects used in commercial products. If you monetise or provide systematic commercial support around an open-source project, read Article 24 before assuming you are exempt.
The SBOM you will need whether you like it or not
The CRA never says "you must publish a software bill of materials to the world". What it does, in Annex I, is require manufacturers to identify and document the components in a product, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies of the product." Read alongside the 24-hour reporting duty, an SBOM stops being paperwork and becomes the tool that makes reporting possible at all.
Here is the mechanics. A vulnerability lands in a widely used library. To know within 24 hours whether your product is affected, you need a current, queryable inventory of what ships inside every version you support. Without an SBOM you are grepping through build files under deadline pressure. With one, affected-product triage is a database query. This is the same discipline that underpins any serious software supply chain security programme, and the CRA has now given it a legal deadline.
Practical SBOM steps that hold up under a 24-hour clock:
- Generate an SBOM automatically in CI for every build, in CycloneDX or SPDX format, rather than hand-maintaining a spreadsheet.
- Store SBOMs per released version so you can answer "which shipped artefacts contain component X at version Y" instantly.
- Feed SBOMs into a vulnerability-monitoring tool that watches your components against exploitation feeds, not just CVE publication.
- Cover at least top-level dependencies as the CRA requires, and go deeper for high-risk components where transitive flaws are common.
An SBOM does not make you compliant on its own. It makes the difference between meeting the 24-hour deadline and missing it.
What non-compliance costs
The CRA's penalty tiers are set in the regulation and mirror the structure of other EU digital laws. The heaviest fines attach to the obligations that protect users directly.
| Violation | Maximum fine | Or share of turnover |
|---|---|---|
| Breach of essential cybersecurity requirements and core manufacturer obligations (Articles 13 and 14) | €15 million | 2.5% of worldwide annual turnover |
| Breach of other obligations (importers, distributors, CE marking, conformity assessment, notified bodies) | €10 million | 2% of worldwide annual turnover |
| Supplying incorrect, incomplete or misleading information to authorities | €5 million | 1% of worldwide annual turnover |
The regulator takes the higher of the euro figure or the turnover percentage, so for any company above roughly €600 million in turnover, the percentage bites harder than the cap. The reporting duties sit in Article 14, inside the top tier. A pattern of missed or late reports is not a paperwork slip; it is exposure to the maximum band.
India-specific considerations
For Indian technology firms, the CRA is an export-market rule, and it lands on more of them than the AI Act did. Any company placing a product with digital elements on the EU market is a manufacturer, whether it sells a connected device, a licensed software product, or firmware embedded in someone else's hardware. A Gurugram product studio shipping a white-label IoT app for a German buyer, or a Bengaluru firmware team inside a European appliance, carries CRA duties even when the brand on the box is European.
That creates a dual-compliance reality. Indian teams already building toward the Digital Personal Data Protection Act 2023 (DPDP) now have a second, differently shaped regime to satisfy for their EU-facing products. The two are not interchangeable, and mapping them cleanly avoids duplicated work.
| Dimension | EU Cyber Resilience Act | India DPDP Act 2023 |
|---|---|---|
| Protects | Security of products with digital elements | Personal data of individuals |
| Reporting trigger | Actively exploited vulnerability or severe incident | Personal data breach |
| Fastest deadline | 24-hour early warning to a CSIRT and ENISA | Breach intimation to the Data Protection Board and affected users |
| Core artefact | SBOM and conformity documentation | Consent records and a data-processing inventory |
| Maximum penalty | €15 million or 2.5% of turnover | Up to ₹250 crore per instance |
The overlap is real: an incident that exposes personal data through an exploited product flaw can trigger both regimes at once, on different clocks and to different regulators. Teams that treat security engineering and privacy engineering as one programme, with a shared incident-response runbook, handle that far better than teams running two disconnected compliance tracks. The engineering discipline is the same one Indian startups are already building for local rules; the CRA raises the reporting speed and adds the product-security layer on top. For a grounding in the local baseline, our DPDP engineering work sits in the same compliance cluster as this CRA guidance.
The 24-hour workflow you need before September
A reporting duty is only as good as the process behind it. The 24-hour window fails quietly in most organisations not because the paperwork is hard, but because nobody owns the decision at 2am on a Saturday. Build the workflow now.
Start with a single accountable role, a product security incident response team (PSIRT) function or a named on-call owner, who can declare a reportable event without waiting for a committee. Wire your exploitation-monitoring and support channels into that role, because "awareness" under the CRA can come from a customer ticket, a threat feed, or your own telemetry. Pre-draft the early-warning template so the 24-hour filing is a form to complete, not a document to write from scratch. Rehearse it: run a tabletop against a fictional exploited-vulnerability report and time yourself from detection to a filed early warning. If that dry run takes longer than a few hours, you will miss the real one.
The organisations that will cope are the ones treating the CRA reporting duty as an operational capability rather than a legal document. The real cost is rarely the report itself. It is the missing inventory, the unclear ownership, and the absence of a rehearsed path from "a customer says they were breached" to "we filed within 24 hours." That gap is an engineering and process problem, and it is fixable before the deadline. It is the same muscle a mature corporate IT compliance and auditing practice already exercises, applied to product security.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based engineering organisation that builds and hardens software and connected products for Indian and global markets, and we design product-security and reporting workflows aligned with Cyber Resilience Act requirements rather than bolted on after launch. Our senior engineering teams set up automated SBOM generation in CI, vulnerability-monitoring pipelines, and a rehearsed 24-hour incident-reporting path, work that draws on our software supply chain security service and our ISO 27001:2022 and CMMI Level 5 practices. If you ship into the EU and want the September 2026 reporting duty handled as an engineering capability, talk to our team.
References
- European Commission, Shaping Europe's Digital Future, Cyber Resilience Act - Reporting obligations
- European Commission, Cyber Resilience Act - Summary of the legal text
- Crowell & Moring, EU Cyber Resilience Act: 11 September 2026 Reporting Deadline
- cyberresilienceact.eu, The Cyber Resilience Act Explained: Scope, Classes and Deadlines
- EU Cyber Laws, CRA Penalties and Sanctions
- Digital Personal Data Protection Act 2023, The Schedule (penalties, up to ₹250 crore)
_Last updated: 3 August 2026._
