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 vulnerability. It takes a few minutes to publish and costs nothing to maintain. We expected it to be close to universal among the largest sites on the web. It is not.
Only 187 of the 500 sites we scanned carry a security.txt with real content, so adoption is thin to begin with. Among those that do publish one, outright expiry is rarer than the raw counts suggest. Just 17 files carry an Expires date that has actually passed. What is common is the opposite habit, with 73 sites omitting the Expires field entirely. RFC 9116 lists Expires as required, so by the strict letter of the spec only 97 of the 500 are fully compliant, but much of that gap is deliberate. Large operators sometimes drop Expires on purpose so they never have to touch the file again, which is a defensible tradeoff rather than neglect. Only 13 percent sign their file with a PGP key so a researcher can confirm it has not been altered.
Every figure here is browsable in our live security.txt Index, which is sortable, filterable by status, and rescanned on a schedule.
Why adoption is low
The surprising part is not that small sites skip security.txt. It is that companies with large, well funded security teams skip it too. Because the file is trivial to write, its absence rarely reflects a deliberate decision. It reflects structure.
The most common pattern we see is a team that runs disclosure through a bug bounty platform and assumes that is enough. It is not, because a researcher who does not already know which platform a company uses still has no starting point, and that is the exact gap security.txt closes. A single Contact line pointing at the bounty page would solve it in seconds.
The second pattern is ownership. The file sits at the boundary between the security team, the web platform team, and whoever controls DNS and deployments. When no one owns it, it is either never created or created once and then forgotten until its Expires date silently passes. The third pattern is the belief that a mature program does not need a public contact file, which gets it backwards. The file is not for the internal team. It is for the outsider who just found something and is deciding, in the next thirty seconds, whether to report it responsibly or post it in public.
Expiry and the Expires field
Adoption is only half the story. The other half is how the sites that do publish a file handle the Expires field, and the picture there is more nuanced than a single number suggests.
Genuine expiry is the smaller problem. Only 17 of the 187 files carry an Expires date that has already passed. Those are the ones to worry about, because an expired file points researchers at contact details the spec itself calls no longer valid, and a stale file can be worse than none at all.
Far more common is omitting Expires altogether, which 73 sites do. RFC 9116 makes Expires a MUST, so a file without it is technically non-compliant, and strict validators flag it as an error. In practice, though, several large operators appear to drop the field on purpose so they never have to renew the file. That is a reasonable engineering choice as long as the contact behind it stays current, and it is a different thing from letting a dated file expire. We count those files as present and usable, noting that the required field is missing, rather than lumping them in with the genuinely expired.
The names
The specifics are what make the numbers land. These are not obscure sites, and every one is verifiable by opening the relevant /.well-known/security.txt path in a browser.
Among the top 500, several of the most visited destinations on the web serve nothing at the standard path, including Instagram, TikTok, iCloud, Pinterest, Bing, Baidu, and Samsung. A researcher who finds an issue on any of them has no file to work from.
Others publish a file that has expired. twitter.com and x.com both carry an Expires date stuck in 2024, Intel's expired back in 2022, and Dell and Booking.com are past their dates as well. A third group publishes a working contact but omits Expires entirely, including Cloudflare, Amazon, and Spotify. Those files are useful in practice but not compliant with the standard as written, which is the exact ambiguity the next section addresses.
What counts as valid
To decide what counts, we followed RFC 9116 rather than inventing our own bar. Four requirements carry the weight. The file must be served at /.well-known/security.txt, with a top-level /security.txt allowed only for legacy compatibility and the well-known path winning if both exist. It must include at least one Contact field, which can be an email, a URL, or a phone number. It must include exactly one Expires field with a date in the future, kept no more than a year out. And it must be retrieved over HTTPS.
A minimal compliant file is two lines. Everything beyond it, such as Encryption, Policy, Acknowledgments, and Preferred-Languages, is optional but useful.
# Minimal compliant security.txt Contact: mailto:security@example.com Expires: 2027-08-05T00:00:00.000Z
You can produce a complete file in under a minute with our free security.txt generator, or check an existing one against the spec with the validator. The setup guide covers every field in depth.
Methodology
The dataset covers the top 500 sites by traffic, and the method is deliberately simple so the results are easy to reproduce. Domains come from the Tranco list, a research grade ranking that blends several sources for stability. We remove pure infrastructure, CDN, and DNS domains so the index reflects sites people actually visit, then take the top 500 that remain.
For each domain we request /.well-known/security.txt first and fall back to the legacy /security.txt, matching the priority the spec defines. Many sites answer a missing path with a styled 200 error page, so we discard responses that look like HTML, which keeps a soft 404 from being counted as a real file. A file that is served but contains no parseable Contact or Expires is not a machine readable security.txt, so we treat it the same as having none.
Two judgment calls are worth stating plainly, since reasonable people draw them differently. RFC 9116 asks for a text/plain content type, and 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. On Expires, we treat a file that omits the field as present and usable rather than expired, and flag the missing field with a note, because many sites drop it deliberately. We still measure against the strict letter of the spec, where Expires is a MUST, so the fully compliant count of 97 reflects that stricter bar.
These figures reflect the scan as of August 2026. The live index is rescanned on a schedule, so the current numbers there may differ slightly as sites add, fix, or let their files lapse.
Getting 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. Generate a compliant file with a real Contact and an Expires date within the next year. Host it over HTTPS at /.well-known/security.txt. Then set a reminder to refresh it before that date, or monitor it so you are alerted the day it lapses. The Expires numbers in this data show how easily that last step slips.
Do not end up in next year's expired column
Files expire, contacts change, and headers drift, usually with no one watching. SiteSecurityScore rescans your security.txt, TLS, DNS, email, and security headers every day and alerts you the moment one breaks or expires.
Already have an account?