What We Found
security.txt (defined in RFC 9116) is the plain text file at /.well-known/security.txt that tells a security researcher who to contact when they find a bug in your site. It costs almost nothing to add. We expected most large sites to have one. They do not.
Only 182 of the top 500 sites (36%) publish a security.txt file with real fields in it. Of those 182, nearly half are already expired or are missing the mandatory Expires field, which means only 95 sites across the entire top 500 (19%) have a file that is both complete and current. Just 13% sign their file with a PGP key so a researcher can confirm it has not been tampered with.
You can browse every result yourself in our live security.txt Index, which is sortable, filterable by status, and refreshed on a schedule. This article walks through what the numbers mean and why the gap is wider than it first looks.
Why So Few Publish It
The surprising part is not that small sites skip security.txt. It is that companies with large, well funded security teams skip it too. The file is trivial to write, so its absence rarely reflects a deliberate decision. It usually reflects one of a few structural reasons.
Bug bounty platforms feel like a substitute
Many large organizations run their disclosure through HackerOne or Bugcrowd and assume that covers them. A researcher who does not already know which platform you use still has no starting point, which is exactly the gap security.txt closes. A single Contact line pointing at your bounty page solves this in seconds.
Nobody owns the file
The file sits at the awkward boundary between the security team, the web platform team, and whoever controls DNS and deploys. When no single person owns it, it is never created, or it is created once and then forgotten until the Expires date silently passes.
A big team feels like enough
The assumption that a mature security program does not need a public contact file gets it backwards. The file is not for your team, it is for the outsider who found something and is deciding, in the next thirty seconds, whether to report it responsibly or post it publicly.
Whatever the cause, the outcome is the same. A researcher who finds a real vulnerability and cannot find a way to reach you will often walk away, or disclose in public before you can patch. For a deeper explanation of what the file is and why it matters, see our security.txt setup guide.
The Expiry Problem
Adoption is only half the story. The bigger surprise is how many sites that do publish a file have let it fall out of compliance. Of the 182 sites with a security.txt, 87 (nearly half) are either expired or missing the Expires field entirely.
This matters because RFC 9116 makes Expires a MUST, not a nice to have. The field exists precisely so a researcher can tell whether the contact information is still maintained. A file with no Expires, or one whose Expires date is in the past, gives the researcher no way to know if anyone still watches that inbox. In our scan this broke down into two groups.
An expired file can be worse than none
A stale security.txt points researchers at a contact that may no longer be monitored. It projects a security program that once cared and then stopped, which erodes exactly the trust the file is meant to build. Keeping the Expires date fresh is the single most neglected part of the standard.
Who Is Missing, and Who Let It Lapse
The names are what make the numbers concrete. These are not obscure sites. They are some of the most visited destinations on the internet, and you can verify every one of them yourself by opening the relevant /.well-known/security.txt path in a browser.
No security.txt at all
Among the top 500, these major sites serve nothing at the standard path: LinkedIn, Instagram, TikTok, iCloud, Pinterest, Bing, Baidu, and Samsung. A researcher who finds an issue on any of these has no file to guide them.
Published, but expired
twitter.com and x.com both carry an Expires date stuck in 2024. Intel's file expired back in 2022. Dell and Booking.com also publish files whose Expires date has already passed. The file exists, but by the spec it should no longer be trusted.
Published, but missing Expires
Cloudflare, Amazon, and Spotify all publish a security.txt with a valid contact, yet none of them include the mandatory Expires field. These are files that are useful in practice but not compliant with the standard as written, which is the exact ambiguity the next section addresses.
What a Valid security.txt Requires
To count a file as valid, we followed RFC 9116 rather than inventing our own bar. Four requirements matter most.
/.well-known/security.txt. A top-level /security.txt is allowed only for legacy compatibility, and if both exist the one under /.well-known/ wins.A minimal compliant file is just two lines plus a comment. Everything beyond this, such as Encryption, Policy, Acknowledgments, and Preferred-Languages, is optional but recommended.
# Minimal compliant security.txt Contact: mailto:security@example.com Expires: 2027-08-04T00:00:00.000Z
You can generate a complete file in under a minute with our free security.txt generator, or check an existing one against the spec with the validator.
How We Measured This
The dataset covers the top 500 sites by traffic, and the method is deliberately simple so the results are easy to reproduce.
/.well-known/security.txt first, then fall back to the legacy /security.txt, matching the priority the spec defines.text/html, so a soft 404 is never counted as a real file.One honest note on strictness
RFC 9116 asks for a Content-Type of text/plain. We reject clearly HTML responses but do not fail an otherwise valid file purely on a mislabeled content type, to avoid marking real files as missing. We also count a file with a Contact but no Expires as not fully valid, because the spec lists Expires as a MUST. Reasonable people can draw that line slightly differently, which would move the compliant number by a few points.
The numbers in this article reflect the scan as of August 2026. The live index is rescanned on a schedule, so the current figures there may differ slightly as sites add, fix, or let their files lapse.
How to Get Yours Right
If your site is in the missing column, or your file has quietly expired, fixing it is a short task with a long payoff. Three steps cover it.
/.well-known/security.txt. Our setup guide has copy ready steps for Nginx, Apache, Express, Vercel, and Netlify.Is your security.txt in the missing column?
Scan your site to see whether you have a valid security.txt, then keep it from quietly expiring with continuous monitoring across 100+ security signals.