Every company that sells software or a connected device should be legally required to publish where a stranger can report a security bug, and to promise someone will read it. The cheapest form is a plain text file called security.txt, and only 1.25% of the top million domains have one, per a URIports scan on 24 January 2025. On roughly 98 of every 100 big sites, a researcher who spots a hole has nowhere to send it.
TL;DR: a published, monitored channel for security reports should be compulsory, and the rule must demand a reply, not just a file.
- The UK has required device makers to publish a reporting contact and reply timings since 29 April 2024.
- The EU requires a published disclosure policy from 11 December 2027; the US binds only its own agencies.
- A listed address that bounces helps nobody, so test your own channel.
- Write the rule around an answer, not around a file.
Why should security.txt be compulsory?
A security bug report is only useful if the right person receives it, so a public, monitored contact turns a stranger's warning into a fix, while a voluntary one leaves most sites silent.
The format is simple. RFC 9116, the 2022 internet standard for the file, asks for a contact, an expiry date and an optional policy link. The CRA's 24-hour reporting duty assumes a vendor hears about the bug first: before a vendor can tell regulators within a day, someone has to be able to tell the vendor.
Neef, Schlunke (TU Berlin) and Hennig (KIT), in a paper posted to arXiv in June 2026, tracked the 40 largest German listed firms from 2023 to January 2025: adoption of the file or a formal disclosure programme went from half the group to nearly all of it. One country, 40 firms and no proof of cause, but firms plainly move when a deadline is visible.
Voluntary effort is not nothing. By my arithmetic from URIports' two scans, domains with the file rose from 6,816 in April 2024 to 12,510 in January 2025, roughly 84% in nine months. I still disagree that good practice will spread alone: most sites stay silent and attackers do not wait. The UK wrote the duty into law with its default-password ban for connected devices instead of hoping.
Four figures test whether a bare file does the job: the European Commission's CRA page sets the dates, the TU Berlin and KIT paper sampled security mailboxes, and URIports checked the files themselves.
Months between two EU duties
15 months
Vendors report out before listening
Big German firms with a channel
37 of 40
Large firms moved; small unknown
Listed security inboxes that bounced
46%
A listed address may be dead
Files that follow the standard
44%
Most files fail the standard
The bounce figure is the one I would show a regulator. The sample was small, 26 generic security addresses, so it is a warning light rather than a rate. Still, a finder whose email errors out has done everything asked; the failure sits with the company, and only a duty to acknowledge, as UK law now sets, closes it.
An address that bounces is a promise nobody keeps. The law should demand an answer, not just an address.
Is a vulnerability disclosure policy required by law?
It depends on where you sell: UK law already requires consumer-device makers to publish a reporting contact, EU law will require a coordinated disclosure policy from December 2027, and US federal law requires it only of agencies.
Schedule 1, paragraph 2 of SI 2023/1007 makes the UK maker of a relevant connectable product publish a contact plus timings for acknowledgement and status updates, free and in English (as of 2024). The EU's Cyber Resilience Act, Regulation 2024/2847, requires in Annex I, Part II, point 5 a policy on coordinated vulnerability disclosure; the European Commission's CRA page gives the dates (checked 14 October 2026). CISA's Binding Operational Directive 20-01 applies the idea to US federal agencies only (as of 2020).
| Category | Detail | What it means |
|---|---|---|
| ⚖️ UK rule | Live since 29 Apr 2024: contact plus reply timings | ✅ Buyers can demand a reply |
| ⚖️ EU rule | Reporting out from 11 Sep 2026, policy from 11 Dec 2027 | ⚠️ The listening duty comes last |
| ⚖️ US rule | Federal agencies only, since 2 Sep 2020 | ❌ Their suppliers are not bound |
| ⏱ Reply clock | CISA suggests: acknowledge in 3 business days, assess in 7, resolve in 90 | ⚠️ A benchmark, not a legal limit |
| 🔒 Safe harbour | Agencies must not pursue good-faith finders | ✅ Finders can speak without fear |
| 🛠Quick test | Email your own security address | ✅ One email proves it works |
The UK and EU put the duty on the people who profit from the product; the US puts it on its own civil servants and leaves the vendors it buys from to volunteer. My view: that is backwards, because unanswered reports pile up in the market, not in one agency's inbox.
Where you sell decides whether a public reporting channel is already your legal duty. Source: CISA BOD 20-01, SI 2023/1007 and the European Commission's CRA page.
What goes wrong when a file is all you ask for?
A file proves only that someone typed a few lines once: a published, unmaintained one can point to nobody, which is why the rule must demand a working, answered channel rather than a text file.
RFC 9116 makes the expiry date a required field, yet URIports found 45% of files carry no Expires line and another 13% had already expired. Fewer than half follow the standard, so by my arithmetic roughly one top-million domain in 180 publishes a file that does; that is derived from two published rates, not a URIports figure. The objection that a file is cheap theatre is half right. Call it a file, then correct that: the file was never the point, the reply is.
The other objection is that a mandate would bury small firms. The UK text is gentler than critics assume: it asks when a reporter can expect an acknowledgement and updates, not a deadline for the fix. Whether a one-person shop should carry the same duty as a listed company is the real grey area; in my opinion, yes to acknowledging, no to fixing on a clock. Voluntary targets end badly: the CISA and FBI memory-safety roadmap set a 1 January 2026 date that binds nobody. Watch for these in your own setup:
- An empty Expires field or a lapsed date.
- A security address routed into a general support queue.
- No named owner, so the reply is nobody's job.
- A policy that threatens finders into silence.
Check which of these is true for you
- You sell a connected device to UK shoppers and your site never says how to report a flaw.
- Mail to your security address lands in a shared queue someone else triages.
- Your file's expiry date has passed, or nobody owns the renewal.
- A researcher writing to you has no written promise you will not sue.
The decision is whether to wait for the law or run a monitored channel now, and the answer is now. This week, email your own security address from a personal account and time the reply: a bounce or silence tells you what to fix first.
No comments
Post a Comment