Vendors Now Have 24 Hours to Report Exploited Bugs

Since 11 September 2026, manufacturers of products in scope of the EU Cyber Resilience Act have specified reporting duties within 24 hours of becoming aware of actively exploited vulnerabilities or severe security incidents. This does not automatically cover every software seller. Indonesian buyers can use the vendor’s policies as procurement evidence.

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 — Article 69(3) applies Article 14 to in-scope products placed on the EU market before 11 December 2027; assess the particular product rather than relying only on whether its model remains on sale. 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. Check how the vendor notifies users; a regulator reporting deadline does not itself guarantee an immediate public advisory. 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.

Check written support periods. The main support duties apply from 11 December 2027. CRA Article 13 ties the period to expected use, generally at least five years, with an exception for products whose expected use is shorter. Ask for model-specific support dates now as a procurement term; do not present five years as a duty already applying to every device.

The quiet vendors identify themselves. Ask the manufacturer for its disclosure policy, security contact, and reporting responsibilities. A clear answer helps assess readiness, but does not by itself establish compliance or a requirement for every manufacturer to have a European entity.

The Indonesian personal-data breach duty discussed below has a different scope. 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 software components and versions 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, ask how signatures and file origin are verified. The delivery medium alone does not establish safety.
• What happens at retirement. The date the model stops receiving fixes, and what the vendor recommends replacing it with.

Ask who handles CRA reporting where the product is in scope. It may be the manufacturer’s team or a mandated representative. An authorised representative is not automatically mandatory for every non-EU manufacturer. Request contacts and procedures rather than treating a particular job title as proof of compliance.

This is the same discipline as pinning down licensing before delivery. Vendor paperwork you did not ask for at quotation time is paperwork that may be harder to obtain 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.

If the product is in scope, assign an accountable person, confirm the reporting route, and rehearse the clock from awareness. Assess product exclusions and the manufacturer, importer, or distributor role with an adviser familiar with EU rules. Divide those responsibilities before an incident.

What happens on the day a vendor actually reports?

The regulatory reporting clock is short; the timing of public advisories is a separate question. Keep a patch process ready for the advisories you receive. 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. Ask vendors to provide 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.