RFC 9116: how to set up security.txt

Why does RFC 9116 matter for B2B?

Security researchers who find a flaw in your website or product need to know who to tell. Without a clear channel, reports go to a sales inbox, a support queue or nowhere at all. RFC 9116, published by the IETF in April 2022, defines a simple fix: a small text file at a known address that says how to report security issues.^[1]

For B2B companies that hold partner data or sit inside customers' supply chains, the file is a cheap, visible sign that someone is ready to receive and act on reports.

What is security.txt?

The core rules from RFC 9116:^[1]

• Location. For web services the file must sit under the /.well-known/ path. A copy at the top-level path is allowed for legacy compatibility.
• Transport. The file must be fetched over HTTPS.
• Format. It must be served as text/plain with the charset set to UTF-8.
• Contact. Required, and may appear more than once. Values are URIs, so email addresses use mailto: and phone numbers use tel:.
• Expires. Required, and may appear only once. It uses the RFC 3339 date and time format.

Optional fields:^[1]

• Encryption links to your encryption key; the key itself must not be pasted into the field.
• Policy links to your vulnerability disclosure policy.
• Acknowledgments links to a page thanking researchers.
• Canonical lists the URI where the file is meant to live.
• Preferred-Languages lists the languages you accept reports in.
• Hiring links to security job openings.

A minimal file has one Contact line and one Expires line, for example Contact: mailto:security@example.com followed by an Expires date less than a year ahead.

Why move beyond a security@ inbox?

Many companies create a security@ address and stop there. A published file does more:

• It is easy to find. Researchers and scanners check the same path on every site, so nobody has to guess.
• It forces review. Because Expires is mandatory, the file goes stale unless someone renews it, which prompts a check of the contact details.
• It links the rules. A Policy link puts your disclosure terms in front of a researcher before they send anything.

What the file does not do matters too. RFC 9116 says its presence or absence does not by itself grant or deny permission to test your systems.^[1] Scope and safe-harbor terms belong in your written policy.

Is security.txt required by any rule?

Not directly. CISA's Binding Operational Directive 20-01, issued in September 2020, applies to US federal executive branch agencies. It requires them to publish a vulnerability disclosure policy as a public web page and to keep a monitored security contact for each .gov domain. Its FAQ says that security.txt use "is not required under the directive," though it is recommended.^[2]

In the EU, the Cyber Resilience Act sets vulnerability handling requirements for manufacturers of products with digital elements. They include putting "in place and enforce a policy on coordinated vulnerability disclosure" and providing "a contact address for the reporting of the vulnerabilities."^[3] The regulation applies in full from 11 December 2027, and its reporting obligations in Article 14 have applied since 11 September 2026.^[3] security.txt is one clear way to publish that contact address; whether your products fall in scope is a question for your counsel.

How do you implement it well?

1. Publish at the right path. Place the file at /.well-known/security.txt, serve it over HTTPS as plain text and check it loads without a login or a bot challenge.^[1]

2. Choose contacts that are watched. List only addresses or forms that a named team monitors. A web form on https:// works as well as email.

3. Set a realistic Expires date. RFC 9116 recommends a value less than a year into the future to avoid staleness.^[1] Put the renewal in a shared calendar or add an automated check.

4. Sign the file. RFC 9116 recommends signing the file with an OpenPGP cleartext signature, so researchers can check it has not been altered.^[1] The signature sits inside the file itself.

5. Link a clear policy. Your vulnerability disclosure policy should say what is in scope, how you will respond and how you treat good-faith research. For B2B, say how you handle flaws in third-party components.

What are the common mistakes?

• Expired file. An Expires date in the past tells researchers the contact details may be out of date.
• Unwatched contact. An address nobody reads is worse than none, because the reporter assumes you were told.
• Assuming one file covers everything. RFC 9116 says a file applies only to the domain or IP address it was fetched from, not its subdomains or parent domain.^[1] Publish on each domain where you want reports.
• Pasting the key into the file. The Encryption field takes a link to the key, not the key itself.^[1]
• No triage plan. A public contact may bring more reports, including low-quality ones. Decide in advance who reads them and how they are routed.

How does security.txt build trust?

B2B security questionnaires often ask how outsiders can report vulnerabilities. A current security.txt file and a linked policy give a short, checkable answer. They also help you hear about problems such as a subdomain takeover or a phishing page using your name, covered in our guide to brand protection against phishing, before customers do.

Treat the file as part of your domain hygiene, next to corporate DNS security and the executive cybersecurity checklist. Our domain security service covers DNS records, renewals and email authentication as part of our digital asset security work.