Vendors Now Have 24 Hours to Report Exploited Bugs

Vendors Now Have 24 Hours to Report Exploited Bugs

Since 11 September 2026, any company that sells software or a connected device into the European Union must report a security hole that attackers are already using within 24 hours. The rule binds manufacturers wherever they sit, including Asia. You may never sell to Europe — but the vendors of your cameras, door controllers and routers do.

What exactly changed on 11 September?

Article 14 of the EU Cyber Resilience Act became enforceable, and the filing portal opened the same day. The European Commission calls it the Single Reporting Platform, operational as of 11 September 2026. A manufacturer files once; the platform routes the report to ENISA — the EU's cybersecurity agency — and to the national incident response team that handles that company.

Two things trigger the clock: a vulnerability someone is actively exploiting, and a severe incident affecting the security of the product. Both start a three-stage timer.

Three details decide whether this touches your building. First, scope follows the market, not the address: the duty falls on the manufacturer even if the company has no office in Europe. Second, it covers products already sold — the device installed in your rack in 2022 counts, as long as the model is still available in the EU. Third, reporting survives end-of-support: a vendor that stopped shipping firmware for a model still has to report an exploited hole in it.

The rest of the Act — secure-by-design duties, conformity assessment, CE marking — applies from 11 December 2027. The Act itself entered into force on 10 December 2024. Reporting simply came early, because the Commission wanted the pipeline running before the heavy obligations land.

Penalties are not symbolic. Breaching Article 13 or 14 carries administrative fines of up to EUR 15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher. That is the top tier of the regulation.

Why does this matter if you never sell to Europe?

Because you buy from people who do. Three effects reach Jakarta without anyone filing anything here.

Bad news about your devices arrives faster. A vendor that used to sit on an exploited flaw for a quarter now has a legal clock. Expect more advisories, earlier, with dates attached. That is good for defenders and equally good for attackers — which is the whole argument for knowing your firmware versions before the advisory lands, not after.

Support periods become a written number. Under the CRA a manufacturer must handle vulnerabilities for a minimum of five years and state the end date — at least the month and year — at the time of purchase. Vendors are building that disclosure anyway for the EU. Ask for it in Indonesia and most will hand it over, because the document already exists.

The quiet vendors identify themselves. A manufacturer with no European entity, no disclosure policy and no security contact was always a risk. Now that gap is visible from outside: ask who files their reports, and a compliant vendor answers in one line.

Indonesia has nothing equivalent for product vendors. The closest local duty is Article 46 of Law 27/2022 on Personal Data Protection, which gives a data controller 3x24 hours to notify affected people and the regulator after a breach. Different object entirely: that rule chases leaked personal data held by the operator, not exploitable holes shipped by the manufacturer. If your obligations under the PDP law are still fuzzy, start with the 2026 changes to PDP enforcement.

What belongs in your next purchase order?

On 10 September 2026, a day before the rule went live, Genetec published five questions buyers of connected physical security systems should ask suppliers. They translate cleanly into procurement language for an Indonesian project.

• Support period end date, in writing. Month and year, per model, in the quotation — not "supported for the foreseeable future".
• A vulnerability disclosure policy and a security contact. An address that reaches a human, published on the vendor's site.
• A parts list for the software. An SBOM — a software bill of materials, the ingredient label listing every open-source library inside the firmware. We covered how to generate and gate on one; the same file answers "are we affected?" in minutes instead of days.
• How firmware updates are delivered and signed. If an update is a ZIP from a Google Drive link, the update path is the vulnerability.
• What happens at retirement. The date the model stops receiving fixes, and what the vendor recommends replacing it with.

Add one more that Genetec does not list: ask who files the vendor's CRA reports. A manufacturer in scope will name an authorised representative — the EU-based company that acts for them legally. One that stares blankly is either out of scope or unprepared, and both answers are worth knowing before you standardise a hundred units on their platform.

This is the same discipline as pinning down licensing before delivery. Vendor paperwork you did not ask for at quotation time is paperwork you will never get after the purchase order — the pattern behind hardware SDKs that arrive with no license text at all.

Are you a manufacturer without knowing it?

Possibly. The Act hooks on making a product available on the EU market in the course of commercial activity, and "product with digital elements" covers software as well as hardware, including the vendor's own remote processing that the product needs to work.

Practical test for an Indonesian software house or hardware integrator: do you ship or license a product — not a one-off service engagement — to a customer in Europe? If yes, assume you are in scope and check properly. Being custom-built for one client does not automatically exempt you; being sold in the course of business is what matters. Run that question past a lawyer rather than a blog post, including ours.

The mechanics, if you are in: appoint an authorised representative in a member state, register on the Single Reporting Platform, and put a named person on the 24-hour clock. Twenty-four hours is one working day plus a night. Nobody improvises that at 2am.

What happens on the day a vendor actually reports?

The public timeline compresses, and your patch window compresses with it. September gave a clean example. Attackers began hijacking internet-facing MikroTik routers on 2 September 2026 — a day before the fix shipped, and the exposure numbers were public within days. We wrote up the check order for exposed RouterOS units while that was live.

Under the CRA the reporting half of that sequence becomes mandatory rather than optional. So the practical preparation is boring and unchanged:

1. Know what you run. Model, firmware version, and where it sits on the network — one spreadsheet beats zero spreadsheets.
2. Know what faces the internet. Management interfaces on public IPs are the first thing an advisory turns into an incident.
3. Know who can push firmware, and how fast. If the answer is "the vendor comes next month", that is your real exposure window.

None of this is new advice. What changed is the speed at which the trigger arrives.

The short version

Europe wrote a rule for its own market and handed the rest of us a procurement tool. Vendors now maintain the documents — support dates, disclosure policies, software inventories — that buyers everywhere have been asking for and rarely receiving.

Ask for the end-of-support date before you sign. Ask for the security contact before you need it. Ask who files their reports, and listen to how fast the answer comes.