Security

The EU started a 24-hour vulnerability clock. Indonesia counts from a different trigger.

September 21, 2026 · 7 min read

On 11 September 2026, the EU's Cyber Resilience Act reporting rules went live. Sell a connected product into the EU, and you now have 24 hours to file an early warning once you know a vulnerability in your product is being actively exploited.

The deadline that matters is not when the CVE was published, but when you knew and how fast you could tell the vulnerable component was yours.

If you work in Indonesia, add another clock. Depending on what you run, the trigger is a personal data breach, a banking incident, or a payment disruption, and each one points to a different regulator.

What actually started on 11 September

Per the European Commission's CRA reporting page: "as of 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements."

The deadlines, from the same page:

  • Early warning: within 24 hours of becoming aware.
  • Full notification: within 72 hours.
  • Final report for a vulnerability: no later than 14 days after a corrective measure is available.
  • Final report for a severe incident: within one month of the 72-hour notification.

You report once, through ENISA's Single Reporting Platform. It reaches the CSIRT in your main establishment's country and ENISA at the same time.

Three scope points are easy to get wrong. Products already on the EU market are in scope, not only new releases. The duty covers actively exploited vulnerabilities, not every CVE. And the rest of the CRA, including obligations for open-source stewards, applies from 11 December 2027.

One nuance matters. Travers Smith, summarizing the Commission's guidance, notes the 24-hour window opens not when a suspicious event is reported, but once an initial assessment gives the manufacturer reasonable certainty that a reportable event occurred.

"Becoming aware" is an engineering problem

Nobody in legal can tell you within 24 hours whether your product ships a vulnerable transitive dependency. Your build pipeline can, if you built it for that.

A vulnerability is confirmed as exploited in the wild. Someone has to answer three questions fast:

  1. Do we ship this component, in which version, in which product?
  2. Is the vulnerable code path reachable?
  3. Who owns the product and can sign off on a report to a regulator?

If question 1 takes a week of grepping lockfiles, the clock is already gone.

Indonesia runs on different triggers

Indonesia has no single incident reporting law that maps onto the CRA. The obligations split by sector and by what is being protected.

Personal data (UU PDP No. 27/2022, Article 46). When protection of personal data fails, the data controller must notify affected data subjects and the institution in writing within 3 x 24 hours, so 72 hours. The notice must say what data was exposed, when and how, and what recovery steps are underway. The trigger is a data breach, not an exploited vulnerability.

Banking (POJK 11/2022, Article 60). A bank must send an initial notification to OJK within 24 hours of learning of an IT incident that could cause significant loss or disrupt operations, then a fuller report within 5 working days. The number looks like the CRA's, but the trigger is an operational incident and the recipient is the banking supervisor, not a national CSIRT.

Payments. For payment system operators, one secondary summary says PBI 2/2024 requires an initial notification within 1 hour, which would compress the effective OJK deadline to the same hour. I have not read the regulation, so treat that as a lead, not a fact.

Still pending. Indonesia's own cybersecurity law, the RUU KKS, was still in DPR discussion in mid-2026 (Kompas, 30 June 2026), and I found no evidence it has passed. There is no single platform equivalent to ENISA's SRP here; reports go to different regulators, in different formats.

A team that ships to the EU and holds Indonesian personal data answers to both regimes, on different clocks, with different people to notify.

Where this bites: dependencies

One compliance vendor, HeroDevs, argues that end-of-life components become your problem: "The obligation doesn't vanish. It transfers entirely to the manufacturer: your organization." They name AngularJS, Vue 2, Spring Framework 5.x, and Node.js 18. Treat this as a vendor claim: HeroDevs sells extended support for exactly those components. That direction is plausible, since a manufacturer reports on its own product regardless of where the code came from, but confirm it with counsel, not a vendor blog.

Supply chain is the same problem from the other direction. Public write-ups of the TanStack compromise in May 2026, part of a campaign reported as Mini Shai-Hulud, say it hit more than 170 npm packages; OpenAI's response said two devices on its corporate network were affected. I have not verified either figure directly, so treat them as secondary. A compromised package is exactly the kind of event where you need to know, within hours, what you ship.

What I would do this quarter

I would test whether the basics work before buying a platform.

Run a fire drill. Pick a recent CVE in a popular library and ask one engineer: "Are we affected, in which products, which versions?" Time it. If the answer takes more than a few hours, that is your gap.

Generate an SBOM at build time, per release. Not once a quarter, and not from a laptop scanner. Store it with the artifact so you can query what version X shipped with months later.

# example: generate an SBOM for a container image at build time
syft <image> -o cyclonedx-json > sbom-<version>.json

Use whatever your pipeline supports; the point is that it runs on every release.

Assign an owner per product. The person who decides "this is exploited and we are affected" has to be named before the incident.

List your end-of-life components. Not to migrate them all now. To know which ones you would have to patch yourselves.

Write the runbook for both regimes. One page per clock: who declares awareness, who files, what goes in an early warning, who talks to OJK or the data subjects. Then practice it.

Quick checklist

  • Can you list every version of a given library you ship, per product, in under an hour?
  • Is an SBOM produced on every release and stored with the artifact?
  • Does each product have a named owner who can decide "actively exploited and affected"?
  • Do you have a written runbook for each clock: the CRA's 24h / 72h / 14 days, UU PDP's 3 x 24 hours, and OJK's 24 hours and 5 working days if you are a bank?
  • Have you run one fire drill and timed it?
  • Has legal confirmed whether you are a "manufacturer" under the CRA?

Sources

  1. Cyber Resilience Act, Reporting obligations, European Commission (Shaping Europe's digital future), accessed 2026-09-21: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
  2. EU Cyber Resilience Act: First Reporting Obligations Take Effect Today, Slaughter and May (The Lens), 2026-09-11: https://thelens.slaughterandmay.com/post/102o0xa/eu-cyber-resilience-act-first-reporting-obligations-take-effect-today
  3. The EU Cyber Resilience Act's vulnerability and incident reporting requirements are now live, Travers Smith, 2026-09-11: https://www.traverssmith.com/knowledge/knowledge-container/the-eu-cyber-resilience-acts-vulnerability-and-incident-reporting-requirements-are-now-live/
  4. EU's Cyber Resilience Act starts the 24-hour vulnerability clock, The Register, 2026-09-11: https://www.theregister.com/security/2026/09/11/eus-cyber-resilience-act-starts-the-24-hour-vulnerability-clock/5295821
  5. POJK No. 11/POJK.03/2022, Article 60, Otoritas Jasa Keuangan, 2022: https://ojk.go.id/id/regulasi/Documents/Pages/Penyelenggaraan-Teknologi-Informasi-Oleh-Bank-Umum/POJK%2011%20-%2003%20-%202022.pdf
  6. SEOJK No. 29/SEOJK.03/2022, Ketahanan dan Keamanan Siber bagi Bank Umum, Otoritas Jasa Keuangan, 2022-12-27: https://www.ojk.go.id/id/regulasi/Documents/Pages/Ketahanan-dan-Keamanan-Siber-Bagi-Bank-Umum/SEOJK%2029%20SEOJK.03%202022.pdf
  7. UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi, Article 46, JDIH Komdigi, 2022: https://jdih.komdigi.go.id/produk_hukum/view/id/832/t/undangundang+nomor+27+tahun+2022
  8. CRA Reporting Obligations Start September 2026: What EOL Dependencies Mean for Your Compliance, HeroDevs, 2026-03-11 (vendor): https://www.herodevs.com/blog-posts/cra-reporting-obligations-start-september-2026-what-eol-dependencies-mean-for-your-compliance
  9. Ketahanan dan Keamanan Siber bagi Bank Umum: Aturan OJK, Alpha Code, 2026-04-16 (secondary): https://alphacode.tech/id/blog/ojk-cybersecurity-requirements-indonesian-banks
  10. TanStack Supply Chain Attack Hits Two OpenAI Employee Devices, The Hacker News, May 2026 (secondary): https://thehackernews.com/2026/05/tanstack-supply-chain-attack-hits-two.html