---
title: "Europe gives software makers 24 hours to report an exploited flaw; India gives 6"
summary: "What the EU Cyber Resilience Act's reporting duty, live since 11 September 2026, asks of software and device makers, and the six clocks an Indian exporter can run for one incident."
url: https://www.thetechbag.com/blog/eu-cra-24-hours-exploited-flaw-india-6
format: Analysis
desk: "Security operations"
published: 2026-09-15
facts_checked: 2026-09-15
author: TechBag (The TechBag Journal)
tags: ["Cyber Resilience Act","ENISA","CERT-In","NIS2","DORA","GDPR","DPDP","SBOM","PSIRT","vulnerability disclosure"]
cover: https://www.thetechbag.com/blog/covers/eu-cra-24-hours-exploited-flaw-india-6.png
---

# Europe gives software makers 24 hours to report an exploited flaw; India gives 6

*What the EU Cyber Resilience Act's reporting duty, live since 11 September 2026, asks of software and device makers, and the six clocks an Indian exporter can run for one incident.*

Analysis · Security operations · By TechBag · Published 2026-09-15 · Facts checked 2026-09-15 · Canonical: https://www.thetechbag.com/blog/eu-cra-24-hours-exploited-flaw-india-6

The short version

- Since 11 September, any company that sells software or a connected device in the European Union must report an actively exploited vulnerability or a severe incident in that product within 24 hours, follow up within 72, and file a final report later. It applies wherever the maker is based, and to products already on sale.[1][2][6]
- It is the first EU reporting clock that binds the maker of a product rather than the operator of a service. For an Indian exporter it sits beside CERT-In’s six hours, NIS2’s 24 for in-scope cloud and managed services, GDPR’s 72, and from 13 May 2027 DPDP’s 72: up to six clocks for one bad day.[13][9][14]
- The 24 hours start when the maker becomes aware, so a report on time needs a product security team, a front door for researchers and customers, and a parts list of every release. That parts list, the SBOM, becomes a legal duty on 11 December 2027; the reporting duty did not wait for it.[3]

Europe’s Cyber Resilience Act (CRA) was signed in October 2024, and most of it waits until December 2027. One article did not wait. Article 14, the duty to report, has applied since 11 September 2026, the same day the EU cyber agency ENISA switched on the platform that receives the reports.[2][7] The question for any company that builds software or devices and sells some of them into Europe, including the many that do so from India: what exactly started last week, does it reach a firm with no office in the EU, how does it sit beside the clocks the company already runs, and what has to exist inside the company for a 24-hour report to be possible at all?

## Since 11 September, the maker reports, not only the victim

The text is short. A manufacturer “shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of”, at the same time to a national computer security incident response team (CSIRT) and to ENISA, through one single reporting platform. The same three steps apply to a “severe incident having an impact on the security of the product”: an early warning within 24 hours, a fuller notification within 72, and a final report.[1] “Actively exploited” is defined as a flaw for which “there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner”. A bug found in a code review does not start the clock; proof that someone used it does.[5]

**Figure: One exploited flaw, three filings and a message to users: the CRA clock starts when the maker becomes aware**

*Reporting steps for an actively exploited vulnerability under Article 14 of the EU Cyber Resilience Act, applicable from 11 September 2026*

1. 01Hour 0: the maker becomes awareReliable evidence that the flaw has been used against someone’s system. The clock starts here, not at the fix.
2. 02Within 24 hours: early warningFiled on ENISA’s platform. Must name, where known, the Member States in which the product is sold.
3. 03Within 72 hours: notificationThe product, the nature of the exploit, what the maker has done and what users can do, and how sensitive the information is.
4. 0414 days after a fix: final reportSeverity, impact, any known attacker, and the update. Impacted users must also be told, and what they can do.

Source: Regulation (EU) 2024/2847, Article 14; European Commission CRA reporting page (updated 11 Sep 2026) · as of 15 September 2026 · for a severe incident the final report is due one month after the 72-hour notification

Three clauses decide who is caught. First, the duty covers the installed base: Article 69 says the reporting obligations “shall apply to all products with digital elements” in scope that were placed on the market before 11 December 2027, even though the rest of the law reaches older products only after a substantial modification.[2] Second, a maker with no EU office still files. Article 14(7) simply tells it which country’s CSIRT to use: the Member State of its authorised representative, then of its main importer, then of its main distributor, then where most of its users are.[1] Third, pure software-as-a-service is outside. The CRA covers a cloud back end only when a product cannot perform one of its functions without it, and its recital 12 says SaaS, PaaS and IaaS fall under the NIS2 Directive instead.[5]

€15 million or 2.5%

The maximum CRA fine for breaching the reporting duty, whichever is higher

Article 64(2): up to €15 million or 2.5% of total worldwide annual turnover for the preceding financial year, for non-compliance with Article 14 or the essential requirements.[4]

ReportedOne filing, many countries

The maker files once. The receiving CSIRT passes the notification to the CSIRTs of the other countries where the product is sold, and ENISA sees it at the same time unless exceptional circumstances apply.[6] Crowell & Moring warns that the right CSIRT is the one where cybersecurity decisions about the products are mainly taken, “often an engineering site rather than headquarters” in its reading, and that a filing to the wrong one risks being rejected and redone.[8]

## One bad day, six clocks, and the fastest is Indian

Take one incident at an Indian product company: its build server in India is broken into and a poisoned update reaches customers in Europe. The company also runs a cloud console for those customers, holds their users’ personal data, and counts a European bank among its clients. Each of those facts starts a different clock, run by a different authority, from a different definition of “aware”.

CERT-In comes first. Since 2022 any “body corporate” must report the incident types in its Annexure I, which include unauthorised access, malicious code and data breaches, “within 6 hours of noticing such incidents or being brought to notice about such incidents”.[13] The CRA follows at 24 hours for the poisoned update. If the cloud console makes the firm a cloud or managed service provider of medium size or more under NIS2, a 24-hour early warning, a 72-hour notification and a one-month final report apply to the service as well, and a provider without an EU establishment must name a representative there.[9] GDPR gives a controller 72 hours to tell its data protection authority; a processor must tell its controller “without undue delay”.[10]

**Figure: Of the clocks an Indian exporter can face, India's is the shortest: 6 hours against the EU's 24 and 72**

*Hours from awareness to the first deadline that carries a number, by regime, as in force or scheduled at 15 September 2026*

CERT-In, India

any listed incident, body corporate

6 h

EU Cyber Resilience Act

the maker, for its product

24 h

EU NIS2

in-scope service, e.g. cloud or managed services

24 h

EU DORA (your bank client's clock)

4 h after classed major, 24 h at most

24 h

EU GDPR

controller, personal data breach

72 h

India DPDP Rules

detailed report, from 13 May 2027

72 h

|  | Value (h) |
| --- | --- |
| CERT-In, India | 6 |
| EU Cyber Resilience Act | 24 |
| EU NIS2 | 24 |
| EU DORA (your bank client's clock) | 24 |
| EU GDPR | 72 |
| India DPDP Rules | 72 |

Source: CERT-In Directions (28 Apr 2022); Regulation (EU) 2024/2847 Art. 14; Directive (EU) 2022/2555 Art. 23; Delegated Regulation (EU) 2025/301 Art. 5; GDPR Art. 33; DPDP Rules 2025, Rule 7 · as of 15 September 2026 · each regime defines its trigger differently; the US CIRCIA rule is excluded because no final rule was in force

Two clocks on that chart are not the exporter’s own. DORA binds the bank: its initial notification is due four hours after it classifies an incident as major and no later than 24 hours after it becomes aware.[11] The vendor is pulled in by contract, because DORA requires the bank’s ICT contracts to oblige the supplier to “provide assistance” when an incident related to its service occurs.[12] India’s DPDP clock is scheduled rather than running: Rule 7, which asks for a description to the Data Protection Board “without delay” and detail “within seventy-two hours”, takes effect on 13 May 2027.[14][15] The United States has no such rule yet: CISA’s final CIRCIA rule, which would set 72 hours for covered incidents and 24 for ransom payments, was expected in September 2026 and had not taken effect.[16]

Our view

Our view: the hours matter less than the start line. CERT-In counts from “noticing”, the CRA from becoming “aware” of reliable evidence, DORA from classification. A company that keeps one incident log with one timestamp, synced to the NTP time sources CERT-In already requires, can show each regulator when its own clock began. A company that reconstructs the timeline afterwards will argue about it.[13]

## Reporting now, the rest of the law in December 2027

The CRA’s product rules arrive on 11 December 2027. From then a maker must draw up “a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies”, run a coordinated vulnerability disclosure policy, publish a contact address for reports, and ship security updates without delay, free of charge and, where technically feasible, separately from feature updates.[3] The support period in which it must do all that “shall be at least five years” unless the product is expected to be in use for less.[3] Open-source stewards, the foundations that maintain code others ship, start reporting on the same December date.[6]

**Figure: The reporting duty arrived 15 months before the SBOM duty that makes it workable**

*Dated milestones of the EU Cyber Resilience Act and the Indian rules an exporter runs beside it, October 2024 to December 2027*

| Date | Event | Detail |
| --- | --- | --- |
| Oct 2024 | CRA signed | Regulation (EU) 2024/2847, done at Strasbourg |
| Jul 2025 | CERT-In BOM guidelines v2.0 | SBOM and related bills of materials; advisory, aimed at exporters among others |
| Dec 2025 | Rule on delaying reports | Commission delegated act on when a CSIRT may hold back a notification |
| Jun 2026 | Conformity bodies | CRA Chapter IV (notified bodies) applies |
| Sept 2026 | Reporting live | Article 14 applies; ENISA's single reporting platform opens |
| May 2027 | DPDP breach rule | Rule 7: 72-hour detailed report to the Data Protection Board |
| Dec 2027 | The rest of the CRA | SBOM, disclosure policy, free security updates; stewards report |

Source: Regulation (EU) 2024/2847 Art. 71; European Commission CRA reporting page; ENISA; AZB & Partners on CERT-In BOM guidelines; DPDP Rules commencement · as of 15 September 2026 · dates after 15 September 2026 are fixed in the texts, not forecasts

The order is backwards for the maker. The question an early warning has to answer within 24 hours, which of our products and versions carry this flaw and in which countries they are sold, is the question an SBOM answers.[1] The law makes the parts list compulsory 15 months after it makes the report compulsory.

## What a product company needs before the next exploited flaw

Lawyers advising makers name the same pieces: named owners, an updated incident and vulnerability policy, notification templates written in advance, an internal incident log, continuous monitoring, and supplier contracts that require notice.[8] ENISA’s platform registers the people who will file, a primary representative and up to 20 secondary ones, each signing in with an EU Login account and multi-factor authentication, though ENISA does not recommend registering as a manufacturer before there is something to report.[8] In our sequence, that becomes six things to have working before the next exploited flaw.

**Figure: A 24-hour report is the output of a product security team that already exists**

*Six capabilities a maker needs for CRA Article 14 and the Annex I duties of December 2027, TechBag's sequence, September 2026*

Step 1 of 6

1. A PSIRT with authority to file

A named product security incident response team, on call, with a deputy, and the authority to send an early warning without waiting for a board meeting. Decide now which person files for which product.

Source: TechBag analysis of Regulation (EU) 2024/2847 Art. 14 and Annex I; Crowell & Moring (11 Sep 2026); ENISA SRP guidance (9–10 Sep 2026) · as of 15 September 2026

TechBag countTechBag count: almost no one in our catalogue sells on SBOMs yet

Of the 779 vendor hubs and product intel pages in TechBag’s catalogue on 7 September 2026, two mention software bills of materials, both for GitLab, and none mentions the Cyber Resilience Act. We searched every page’s source for “SBOM”, “software bill of materials” and “Cyber Resilience Act”.[19] Vendors document what buyers ask about; for a product company, SBOM generation and storage is a question to put to its build and application-security vendors directly.

Our view

Our view: the 24 hours test whether a company knows what it ships. A maker that waits until December 2027 to build its parts lists will spend the next 15 months answering a one-day deadline by hand.

If you build software or devices in India and sell them in Europe

The CRA’s “manufacturer” is whoever develops or manufactures a product, or has it designed or made, “and markets them under its name or trademark”, paid or free.[5] An Indian firm that sells its own software, firmware or device in the EU is a manufacturer and has owed the 24-hour report since 11 September. An IT services firm that builds a product to a client’s specification, sold under the client’s name, is usually not; the client is. Expect the duty to arrive by contract instead, as the law firms are advising makers to require supplier notice.[8] We found no official count of Indian firms selling products with digital elements into the EU, so we give none.

At home the six-hour CERT-In rule of 28 April 2022 still applies to the same incident if it touches the company’s systems, with logs kept for a rolling 180 days “within the Indian jurisdiction”.[13] CERT-In’s technical guidelines on bills of materials (version 2.0, 9 July 2025) name software exporters among their audience, list 21 minimum SBOM fields and recommend SPDX or CycloneDX; they are not mandatory.[17] One SBOM built to those fields can serve both the CERT-In guidance and the CRA’s December 2027 duty. The DPDP breach rule follows on 13 May 2027, and the Act’s penalty for failing to take reasonable security safeguards reaches ₹250 crore.[14][18]

Three actions this quarter: confirm whether any product you sell under your own name reaches an EU customer; name the person who files and the CSIRT they file to; and write the one incident log, with one clock, that every regulator above can be answered from.

How we did this

Figures as of 15 September 2026

The CRA provisions (Articles 3, 13, 14, 64, 69 and 71, Annex I Part II and recital 12) are quoted from reuschlaw’s reproduction of Regulation (EU) 2024/2847, because EUR-Lex returned empty pages; the start date and the platform are confirmed by the European Commission’s reporting page (updated 11 September 2026) and ENISA. The clock chart shows, for each regime, the first deadline that carries a number of hours, counted from that regime’s own trigger; CERT-In, NIS2 and GDPR are read from the legal texts, DORA from Delegated Regulation (EU) 2025/301 as reproduced by Springlex, and DPDP Rule 7 from a reproduction of the Gazette text. Excluded: the US CIRCIA rule (not in force), US SEC disclosure rules (a listed-company regime, not a product one), sector rules such as the RBI’s, and the UK. The catalogue count is a text search of TechBag’s 779 intel pages at the 7 September 2026 state of the estate. The incident in Section 2 is a constructed example, not a reported case.

Spotted an error? Write to us; corrections are published at the foot of the piece.

Sources

1. [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14: reporting obligations of manufacturers (reuschlaw reproduction)](https://www.cyber-resilience-act.com/cra/chapter-2/article-14/) — 23 October 2024
2. [Regulation (EU) 2024/2847, Article 69 (transitional provisions) and Article 71 (entry into force and application)](https://www.cyber-resilience-act.com/cra/chapter-8/article-71/) — 23 October 2024
3. [Regulation (EU) 2024/2847, Annex I Part II (vulnerability handling, SBOM) and Article 13(8) (support period)](https://cyber-resilience-act.com/annexes/annex-i/) — 23 October 2024
4. [Regulation (EU) 2024/2847, Article 64 (penalties)](https://www.cyber-resilience-act.com/cra/chapter-7/article-64/) — 23 October 2024
5. [Regulation (EU) 2024/2847, Article 3 (definitions: manufacturer, remote data processing, actively exploited vulnerability) and recital 12 (SaaS under NIS2)](https://cyber-resilience-act.com/recital-12/) — 23 October 2024
6. [European Commission, Cyber Resilience Act: reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) — updated 11 September 2026
7. [ENISA, CRA Single Reporting Platform (launched 11 September 2026; representative registration and notification guidance)](https://www.enisa.europa.eu/cra-srp/) — 11 September 2026 Guidance documents dated 9 and 10 September 2026.
8. [Crowell & Moring: It's live: the Cyber Resilience Act reporting is mandatory as of today](https://www.crowell.com/en/insights/client-alerts/its-live-the-cyber-resilience-act-reporting-is-mandatory-as-of-today-11-september-2026) — 11 September 2026
9. [Directive (EU) 2022/2555 (NIS2), Article 23 (reporting) and Article 26 (jurisdiction, representatives)](https://www.nis-2-directive.com/NIS_2_Directive_Article_23.html) — 14 December 2022
10. [Regulation (EU) 2016/679 (GDPR), Article 33: notification of a personal data breach to the supervisory authority](https://gdpr-info.eu/art-33-gdpr/) — 27 April 2016
11. [Commission Delegated Regulation (EU) 2025/301 (DORA incident reporting RTS), Article 5: time limits](https://www.springlex.eu/en/packages/dora/rts-ir-regulation/article-5/) — 23 October 2024 Published in the Official Journal on 20 February 2025.
12. [Regulation (EU) 2022/2554 (DORA), Article 30: key contractual provisions](https://www.digital-operational-resilience-act.com/Article_30.html) — 14 December 2022
13. [CERT-In, Directions under sub-section (6) of section 70B of the IT Act, 2000 (No. 20(3)/2022-CERT-In), directions (i), (ii), (iv) and Annexure I](https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf) — 28 April 2022
14. [Digital Personal Data Protection Rules, 2025, Rule 7 (intimation of personal data breach), text of G.S.R. 846(E)](https://dpdpa.com/dpdparules/rule7.html) — 13 November 2025 Reproduction of the Gazette text.
15. [Legismith: DPDP Rules 2025 commencement timeline (Rule 4 on 13 Nov 2026; substantive rules on 13 May 2027)](https://legismith.com/dpdp-rules-2025-timeline/) — notified 13 November 2025
16. [Hunton Andrews Kurth: CISA plans to finalize cyber incident reporting regulations in September 2026](https://www.hunton.com/privacy-and-cybersecurity-law-blog/cisa-plans-to-finalize-cyber-incident-reporting-regulations-in-september-2026) — 17 July 2026
17. [AZB & Partners: CERT-In's technical guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM (version 2.0 of 9 July 2025)](https://www.azbpartners.com/bank/cert-ins-technical-guidelines-on-sbom-qbom-and-cbom-aibom-and-hbom/) — 30 September 2025
18. [TechBag, DSPM guide: DPDP commencement and the ₹250 crore security-safeguards penalty](https://www.thetechbag.com/browse/data-security-privacy/dspm) — September 2026
19. [TechBag catalogue: 120 vendor hubs and 659 product intel pages, text search for SBOM and the Cyber Resilience Act](https://www.thetechbag.com/gitlab/gitlab-devsecops-platform) — 7 September 2026

Related on TechBag: the [vulnerability management guide](https://www.thetechbag.com/browse/security/vulnerability-management) compares 13 products that find and rank flaws; the [GitLab DevSecOps Platform](https://www.thetechbag.com/gitlab/gitlab-devsecops-platform) page covers dependency scanning and SBOMs in the pipeline; the [BFSI obligations register](https://www.thetechbag.com/industries/bfsi/obligations) tracks the CERT-In and RBI reporting duties.

**Disclosure.** TechBag is a software reseller: it earns a margin when a reader buys through it, including from vendors named here. The analysis is TechBag’s own; no vendor paid for or saw this piece before publication. Facts are labelled reported, TechBag count or our view.

Go deeper on TechBag

- [Vulnerability management guide](https://www.thetechbag.com/browse/security/vulnerability-management) — 13 products that find and rank flaws, with the CERT-In report line
- [GitLab DevSecOps Platform](https://www.thetechbag.com/gitlab/gitlab-devsecops-platform) — dependency scanning and SBOMs in the build pipeline
- [BFSI obligations: RBI, SEBI and CERT-In duties, dated](https://www.thetechbag.com/industries/bfsi/obligations) — the CERT-In six-hour reporting duty in context