A security.txt file is a plain text file at /.well-known/security.txt that tells researchers how to report a vulnerability. RFC 9116 makes two fields mandatory: Contact and Expires. It is not a legal duty for most vendors, but a missing or expired file is a quick signal when you review one.
What RFC 9116 says
The standard places the file under the /.well-known/ path of a domain, served over HTTPS as plain text in UTF-8. A copy at the top level is allowed for older tooling, but the /.well-known/ version takes precedence if both exist.
Only two fields must be present. Contact gives a way to report, such as an email address or web page, and several can be listed in order of preference. Expires is a date and time after which the data is stale, written in the RFC 3339 profile of ISO 8601. The RFC recommends setting it less than a year ahead and says researchers should not rely on a file past its expiry.
Optional fields include Policy, Encryption, Acknowledgments, Hiring, Preferred-Languages and Canonical.
Why a CTO should care
When you evaluate a company to acquire or integrate, you want to know what happens when someone outside finds a flaw. The file answers three things in thirty seconds:
- Is there a named channel, or does a researcher have to guess?
- Has anyone maintained it? An Expires date in the past suggests nobody looked at it.
- Is there a published policy about what researchers may and may not do?
It does not prove the vendor responds well. It proves that somebody thought about the question.
A 5 minute check
- Open the vendor's domain plus /.well-known/security.txt in a browser.
- Confirm it loads over HTTPS and shows readable text.
- Check the Expires date against today.
- Open the Policy link if there is one, and read what is promised.
- Send a harmless test message to the Contact address only if the vendor's policy invites it, and note whether you get an acknowledgement.
If the file is absent, look for a vulnerability disclosure page on the main site, and ask the vendor directly. Many good teams have the process and have never published the file.
What a good file looks like
A short example, for reference only:
Contact: mailto:security@example.com
Expires: 2027-06-30T23:59:59z
Policy: https://example.com/security/policy
Preferred-Languages: en
Questions to ask in the follow up
- Who reads the Contact mailbox and how fast do they reply?
- What happened the last time a report came in? Ask for a sanitised example.
- How are fixes announced to customers?
Safeguard focuses on the code and dependency side of this problem, with SBOM scanning, zero-day discovery and policy gates. If you publish software yourself, a free scan is a way to check your own house before a researcher does.
Quick check
Is security.txt a certification?
No. It is a contact convention described in an RFC. It does not attest to anything about the vendor's security.
What if the file is expired?
Treat it as a prompt to ask who owns it. The RFC says researchers should not rely on data past its expiry.
Sources
Last reviewed: 19 October 2026.
