I have just published a vulnerability disclosure policy on the Certi360 website, along with the file that goes with it: /.well-known/security.txt.
While I was writing it, one question stayed with me. This file was designed for researchers who find a flaw and want to warn you. The bots that scan your website at 3 a.m. will never write to you.
So is it still useful? Yes, if you understand what the file is and what it is not.
A short reminder
security.txt is a plain text file published at a fixed address, https://yourdomain.com/.well-known/security.txt. It tells someone who has found a security issue who to contact, and how.
The idea comes from Edwin Foudil, a security researcher, who submitted a first draft to the IETF (the body that publishes Internet standards) in September 2017. The principle followed robots.txt: a predictable location, readable by a human and by a machine. The text became an official standard, RFC 9116, in April 2022, co-authored with Yakov Shafranovich.
The problem it solved was real. A researcher finds a flaw, looks for a contact, and lands on the “Contact us” form. The email gets lost, and the flaw stays open.
What the file contains
Two fields are required:
- Contact, an email address, a phone number, or a web page.
- Expires, an expiration date. The RFC recommends less than one year.
The others are optional, such as Encryption (a link to your public key), Policy (your disclosure policy), Acknowledgments (the thank-you page), Preferred-Languages, Canonical, and Hiring.
The file must be served over HTTPS, as plain text. Ideally, it is signed with a PGP key (the standard for encrypting and signing email). Without a signature, an attacker who has compromised your site can replace your address with theirs and receive the reports instead of you.
A minimal example:
Contact: mailto:security@yourdomain.com
Expires: 2027-06-30T23:59:59Z
Encryption: https://yourdomain.com/pgp-key.txt
Policy: https://yourdomain.com/disclosure/
Preferred-Languages: fr, en
Canonical: https://yourdomain.com/.well-known/security.txtWhat the file is not
It is not a security control. It blocks nothing and detects nothing.
It is not permission to test. The RFC says so plainly: the presence of the file gives no permission to probe your systems. Its absence removes none either.
And it is not a bounty program. You do not have to pay anyone.
The other change: the noise
The bot that finds your vulnerable WordPress plugin will not write to you. It will act. security.txt changes nothing about that. Your updates, your inventory, and your own testing do.
The file is for the other person: someone acting in good faith who finds a problem and wants to tell you. A researcher, a customer, a student, a consultant from another firm. Without a clear channel, that person gives up. Or publishes.
That channel has a cost. The RFC itself warns that a public contact address attracts spam and automated reports.
In 2026, that has become a major problem. The curl project closed its bounty program at the end of January, drowned in AI-generated reports. On October 1, Google suspended submissions to its open-source bounty program, at least until the first quarter of 2027, for the same reason.
A small business will not receive thousands of them. Still, every false report takes time from someone who already has little of it.
Then come the “beg bounties”: unsolicited emails, often from an automated scan, demanding payment for a “critical flaw.” Sophos has documented demands of 150 to 2,000 US dollars per flaw. The most common finding is a missing SPF or DMARC record (two settings that protect your domain against email spoofing). That is not a vulnerability in your website. It is a question of how your email is configured.
When to use it
You have a website, an application, or a customer portal exposed on the Internet. Someone will read the inbox every week. You can sort, reply, and fix issues within a reasonable time.
When not to use it
Nobody will watch the address. A file that points to a dead inbox is worse than no file. The RFC recognizes this: stale information causes reports to be lost.
You are not ready to renew the expiration date. An expired file tells the world that nobody is at the helm.
You want to put an employee’s personal address in it. Use an alias. Employees leave. Aliases stay.
In practice
- Create a
security@alias that reaches two people, not one. - Write a short policy that covers scope, exclusions, the time you ask for before public disclosure, and a commitment not to bring a lawsuit or file a complaint if the person follows the policy.
- Set an expiration date less than a year out, and a calendar reminder one month before.
- Sign the file with your PGP key, on your own computer or in your encrypted email client, never on an online signing website. Then publish the public key on keys.openpgp.org and confirm the email address. A researcher then has a second source to check it, outside your site.
- Publish one file per exposed domain. An application subdomain deserves its own.
- Prepare two template replies: the acknowledgment, and “this is not a vulnerability.”
- Never pay a beg bounty. Validate the report yourself or with your managed service provider, then fix it if it is real.
What to expect
Few useful reports. A lot of noise. From time to time, a real report that saves you an incident.
A single valid report received before an attacker finds the same flaw is worth the time spent sorting spam.
Measure it. How many reports, how many valid ones, how long it takes to fix them. After a year, you will know whether your channel works.
At Certi360
I put it in place. The file is here: /.well-known/security.txt. It points to security@certi360.com, our PGP key, the disclosure policy, and the acknowledgments.
About 90 days before a public disclosure. If you follow this policy, we will not bring any lawsuit and will not file any complaint in connection with the report. No bounties. A public acknowledgment for those who want one.
I recommend it to my clients. It is hard to require of others what you do not do yourself.
Want a look at yours? Let’s talk.
References