Most security statistics come from samples: a vendor scans whatever domains it can reach, weights the result, and publishes a percentage. This one is different. In a paper published this year, independent researcher David Mellafe Z. took the official list of 915 organisations that Chile's National Cybersecurity Agency formally designated as Operadores de Importancia Vital — operators of vital importance — under Ley 21.663, and measured all of them. Not a sample. The full catalogue, with roughly 98.7% coverage.
These are the organisations a national regulator sat down and decided were critical: the electricity companies, hospitals, banks, telecoms carriers, fuel distributors, water utilities, transport operators and government bodies whose failure would hurt. The designation was published in December 2025. Every one of them knows they are on the list.
Two findings from the census, both measured passively from the public internet:
Email-authentication misconfiguration affects 766 of 915 operators — 84%. Broken SPF, DKIM or DMARC, distributed across every single sector. The paper describes this as its most significant operational finding, precisely because there is no sector that gets it right.
Sixteen of 915 operators — 1.7% — publish a verifiable vulnerability-disclosure contact. Among the operators of physical-world infrastructure, fewer than ten do. All four of the country's major banks lack one. So do both incumbent telecoms carriers.
For comparison, the paper reports adherence above 99% in the U.S. federal civilian branch, where none of this is optional. Two CISA directives did that work. Binding Operational Directive 18-01, issued in 2017, required federal agencies to publish valid SPF and DMARC records and reach p=reject within a year. Binding Operational Directive 20-01, issued in 2020, required every agency to publish a vulnerability disclosure policy and a security.txt file on its primary domain. A mandate with a deadline moved both numbers. Appearing on a list of critical operators did not.
None of this is about Chile. The interesting part is the control condition: what happens to an organisation's external configuration when a regulator names it critical infrastructure and nothing else changes. The answer, on this evidence, is nothing.
Somebody found a flaw on your website. How do they tell you?
This is the question the second finding is really about, and it is worth sitting with for a moment.
A researcher, a customer's IT person, or someone who tripped over a misconfiguration while doing something unrelated now has a piece of information you would very much like to have. What do they do with it?
If your site publishes nothing, their options are: the contact form, which routes to sales; info@, which routes to a shared mailbox; LinkedIn; or nothing. In practice, a meaningful share choose nothing, and the finding sits with a stranger indefinitely. Some fraction of the rest end up in a spam folder. This is not a hypothetical failure mode — it is the ordinary outcome, and it is why RFC 9116 exists.
RFC 9116 defines security.txt: a plain text file served at https://yourdomain.com/.well-known/security.txt containing, at minimum, a Contact: line and an Expires: line. That is it. It takes ten minutes, costs nothing, and requires no tooling. A realistic minimum is a contact address or reporting URL, an expiry date within a year, and optionally a Policy: link and the languages you read.
The reason so few organisations have one is not cost or difficulty. It is that nobody owns it. It sits between the web team, who see a file request, and the security function, who may not know the file format exists.
The prerequisite is real, though: publishing a contact means committing to read it. A security.txt pointing at an unmonitored mailbox is worse than none, because it converts "they could not find us" into "they told us and we ignored it" — a materially different position if the finding later becomes an incident.
The email-authentication half
Eighty-four percent is a big number, and it lines up with what we see externally on domains of every size. The patterns behind it are consistent: SPF records that overflow the ten-lookup limit or still carry legacy mechanisms, DKIM that is missing or published with broken syntax, and DMARC records sitting at p=none, which instructs receiving servers to do precisely nothing when a message fails.
We covered the mechanics of this in detail in why your DMARC record does nothing at p=none — the ten-lookup limit, alignment versus authentication, what forwarding breaks, and the shadow senders that keep organisations parked in monitoring mode. That article is the how. This census is the scale.
What the Chilean data adds is the pairing. An organisation whose domain can be spoofed and which has no channel for someone to warn them about it is in a specific and unfortunate position: an attacker can impersonate them convincingly, and the first person to notice has no way to say so. The two gaps compound.
The paper also measured a third layer and estimated that around 23.5% of operators run end-of-life or known-vulnerable stack components, though with a wide confidence interval — the authors give 12% to 38% — so treat that one as directionally useful rather than precise.
Four things to check on your own domain
None of these require a login, a vendor, or permission. All of them are things an attacker can already see.
1. Do you have a security.txt? Open https://yourdomain.com/.well-known/security.txt in a browser. If it 404s, you have no disclosure channel. If it exists, check the Expires: date — an expired file signals an abandoned process, which is arguably worse than absence. Decide who reads the mailbox before you publish the address.
2. Can your domain be spoofed today? Query your DMARC record and read the p= value. If it is p=none, or there is no record at all, a forged message with your exact domain in the From header will be delivered. Check sp= too, for subdomains, and do not skip the domains you do not send from — parked domains, old product names and defensive registrations are the easiest to lock down and the most consistently forgotten.
3. What is actually exposed? The census found what it found because the information was public. Run the same check against yourself: which services answer on your address space, which of them you meant to expose, and which are running versions the vendor stopped supporting. Management interfaces, remote-access services and forgotten staging hosts are the recurring three.
4. Who owns each answer? This is the one that determines whether the other three stay fixed. The Chilean operators did not fail a technical test — a security.txt is not technically hard, and neither is p=reject. They failed an ownership test. If nobody's name is against "our email authentication stays at enforcement" and "somebody reads the disclosure mailbox", both will drift back within a year.
ClickScan runs the first three from the outside — email authentication including a live spoofing test, TLS and certificate state, HTTP security headers, and exposed services — on the same passive basis the researchers used. The fourth one is yours.
The point of a full-universe census
Sampled studies let you argue about methodology. A full-universe census against a regulator's own published list does not leave that room. Every organisation in this dataset had been formally told it was critical to national functioning, and 84% of them still publish an email-authentication stack that does not work.
The operational reading is not that Chilean operators are careless. It is that designation, registration and paperwork do not change DNS records, and any compliance regime that stops at declaration will produce exactly this result. The things measured here are cheap, externally visible, and unambiguous. That is what makes them a fair test — and what makes the numbers uncomfortable.
Sources: The Coverage Gap: Chile's Cyber Disclosure Framework versus the USA, EU and UK (arXiv 2606.05594); RFC 9116 — A File Format to Aid in Security Vulnerability Disclosure; CISA Binding Operational Directive 18-01 (email and web security); CISA Binding Operational Directive 20-01 (vulnerability disclosure policy); RFC 7208 (SPF). The census covers Chilean operators designated under Ley 21.663 and is a single-country dataset; the 84% and 1.7% figures describe that population, not organisations in general. The 23.5% end-of-life estimate carries a 95% confidence interval of 12–38% and should be read as a range.