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

01Since 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.¹ “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.⁵

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.² 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.¹ 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.⁵

02One 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”.¹³ 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.⁹ GDPR gives a controller 72 hours to tell its data protection authority; a processor must tell its controller “without undue delay”.¹⁰

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.¹¹ 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.¹² 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.¹⁴¹⁵ 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.¹⁶

03Reporting 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.³ 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.³ Open-source stewards, the foundations that maintain code others ship, start reporting on the same December date.⁶

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.¹ The law makes the parts list compulsory 15 months after it makes the report compulsory.

04What 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.⁸ 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.⁸ In our sequence, that becomes six things to have working before the next exploited flaw.