security.txt Under RFC 9116: Implementing a Vulnerability Disclosure Policy

1. The problem: no clear channel for reporting a vulnerability

Security researchers who stumble across a vulnerability during an audit, a bug bounty engagement, or just while browsing need a clear, fast way to report it responsibly. Without that channel, the remaining options are all mediocre: an email to a generic info@ address that disappears into a marketing inbox, a ticket in a public support system anyone can read, or, in the worst case, a tweet with vulnerability details because no other channel responded.

That uncertainty costs both sides time and trust. Operators often learn about critical flaws too late, or never through an official channel, while well-meaning researchers give up in frustration or default to going public for lack of an alternative. RFC 9116 closes exactly this gap with a convention simple enough to implement in a few minutes, yet impactful enough in practice to noticeably change how fast a company hears about a vulnerability.

# /.well-known/security.txt -- minimal example under RFC 9116
Contact: mailto:security@example-shop.com
Contact: https://example-shop.com/report-security-issue
Expires: 2026-12-31T23:59:59.000Z
Encryption: https://example-shop.com/.well-known/pgp-key.txt
Preferred-Languages: en, de
Canonical: https://example-shop.com/.well-known/security.txt
Policy: https://example-shop.com/security-policy
Acknowledgments: https://example-shop.com/security-hall-of-fame

2. The core idea behind RFC 9116

RFC 9116 was published as an official IETF standard in April 2022, replacing the earlier draft status the convention had been used under informally for years. The core idea is intentionally simple: a web application publishes a plain text file at the fixed, discoverable path /.well-known/security.txt, using a clearly defined field-value format to bundle the most important information for anyone reporting a security issue.

The /.well-known/ path is itself standardized under RFC 8615 and serves as a generic namespace for machine-readable website metadata, hosting other well-known resources besides security.txt, such as ACME challenges or OAuth metadata. Automated tools, security scanners, and human researchers now routinely check this path as a first step before reporting a vulnerability, because it is treated as a reliable, standardized source.

3. Required fields: Contact and Expires in detail

RFC 9116 mandates at least one Contact field and exactly one Expires field; every other field is optional. The Contact field states how researchers can reach an organization, and multiple contact lines are allowed and should be listed in order of priority. Valid values include email addresses using the mailto: scheme, phone numbers using the tel: scheme, and any HTTPS URL, for example a dedicated report form or a bug bounty program on a platform like HackerOne or Intigriti.

The Expires field states, in ISO 8601 format, how long the file should be considered valid, forcing operators to review and renew the contents on a regular basis. An expired security.txt file signals to tools and researchers alike that the listed contact details might be stale, which in practice is an effective mechanism against orphaned entries left unmaintained for years. A reasonable rhythm is an expiration date six to twelve months out, paired with a recurring calendar reminder to renew it.

4. Optional fields for a complete policy

Beyond the two required fields, RFC 9116 defines several optional fields that make a security.txt file considerably more useful. The Policy field links to a detailed vulnerability disclosure policy that spells out scope, permitted testing methods, exclusions, and how discovered data is handled. The Acknowledgments field links to a page where researchers are publicly credited after a successful, responsibly disclosed report, which is a meaningful non-monetary incentive for many security researchers.

The Preferred-Languages field states which languages reports are preferably submitted in, the Canonical field names the authoritative URL of the file itself and guards against tampered copies on mirror servers, and the Hiring field can point to open roles on the security team. All fields can be repeated, so multiple contact channels or multiple policy documents for different product areas can coexist side by side.

5. Signing with PGP: protecting the integrity of the file

Without additional protection, an attacker with server access could plant a forged security.txt file to intercept reports of genuine vulnerabilities or steer researchers toward a false trail. RFC 9116 therefore allows the file to be signed as an OpenPGP cleartext signature, so any tampering with the content becomes immediately detectable once someone verifies the signature against the public key.

In practice, the public PGP key itself is referenced through the Encryption field and also published under a well-known path, so researchers can both verify the security.txt file's signature and communicate encrypted with the security team. This combination of signing and encryption ensures sensitive vulnerability details never travel in plaintext over insecure channels, and that the contact information itself stays trustworthy.

6. Common mistakes in practical implementation

The most common mistake is a security.txt file created once and never maintained again, until the expiration date sits far in the past and the listed contact addresses no longer work. A second common mistake is placing the file outside /.well-known/, for example directly at the domain root, which some tools still accept as a fallback but which contradicts the RFC standard and is frequently missed by automated scanners.

A third mistake is a security.txt file with no clear link to an actual disclosure policy, leaving researchers with a contact address but no clarity on which testing methods are allowed or how long a response typically takes. Without an accompanying policy, the file remains a pure formality rather than a working reporting channel, and security researchers become more hesitant to reach out in the first place.

7. Defining the internal response process for incoming reports

A security.txt file is only as effective as the internal process that follows an incoming report. A sensible workflow includes clear deadlines: an automated acknowledgment within a few hours, an initial technical assessment within a few business days, and transparent communication about the remediation timeline going forward. These deadlines ideally live directly in the linked policy, so reporters have a realistic expectation from the start.

Equally important is clear internal ownership: who reads incoming reports, who assesses severity, and who decides on priority and remediation timeline? Without defined responsibilities, reports easily fall between multiple teams and get handled with delay, which undermines the reporter's trust in the whole process and makes future voluntary reports less likely.

8. Automated maintenance instead of a one-time manual setup

Because the Expires field requires regular renewal, an automated solution beats manual upkeep tracked in a calendar. Many projects therefore generate the security.txt file from a central configuration source as part of the deployment process, automatically setting the expiration date a fixed interval into the future and regenerating the signature on every build whenever the content has changed.

Teams running multiple domains or subdomains also benefit from centralized monitoring that regularly checks whether the file is reachable, syntactically valid, and not expired across every relevant host. A simple automated check that runs daily as a cron job, compares the Expires date against the current date, and triggers an internal warning once a lead time threshold is reached reliably prevents the file from going stale unnoticed.

9. Conclusion: small effort, noticeable security benefit

security.txt under RFC 9116 is one of the best effort-to-impact security measures available. A single text file, created in a few minutes, gives security researchers a clear, reliable channel to report discovered vulnerabilities responsibly instead of going public for lack of an alternative or staying silent altogether.

The real value, however, only emerges through the surrounding processes: a clear policy, defined response deadlines, an accountable internal owner, and automated upkeep of the expiration date. Teams that implement these pieces together noticeably reduce the odds that a discovered vulnerability finds its way to the public before a fix was even possible.

10. Summary

11. FAQ: security.txt under RFC 9116 at a glance