Skip to content

security.txt: the two-minute change that gets you warned first.

When a researcher finds a hole in your site, the difference between a quiet heads-up and a public surprise is often whether they can find your inbox. RFC 9116, in practice.

Beacon slot light on a dark panel
A clearly marked way to reach you.

The scenario

Somewhere, a researcher just found a vulnerability in your site. Not a criminal - one of the thousands of people who scan, poke, and report for reputation, bounties, or sport. They want to tell you. They spend ninety seconds looking for a security contact, find a generic contact form that routes to sales, and give up.

What happens next is out of your hands: maybe a public disclosure, maybe a tweet, maybe nothing until someone less friendly finds the same hole. The entire branch point was whether you were reachable.

What security.txt is

A plain-text file at a standardized path - /.well-known/security.txt - defined by RFC 9116. Researchers and their tooling check it first. Two fields are required:

Contact: mailto:security@yourdomain.example
Expires: 2027-07-01T00:00:00Z

Expires exists so stale files are visibly stale - keep it under a year out and refresh it when it passes. Useful optional fields: Policy (link to your disclosure policy), Preferred-Languages, Canonical (the file's own authoritative URL), and Encryption (a PGP key - only publish one if you will actually decrypt mail sent to it).

What to put in it

  1. A monitored address. A shared mailbox like security@ beats a personal one - people leave; the file should not know that.
  2. An Expires date about a year out, with a calendar reminder to bump it.
  3. A one-page policy if you can: what is in scope, what you promise (acknowledgment time, no legal threats for good-faith research), how credit works. Even three sentences beats silence.

Serve it over HTTPS, content type text/plain. That is the whole deployment. It is genuinely a two-minute change - the file, not the habit.

The real work: answering

The file is a promise, and the promise is operational: someone reads that mailbox and replies. Set an internal service level - acknowledge within two business days, even if the answer is "we are looking." A researcher who gets a human reply becomes an ally through the whole coordinated-disclosure path, advisory and CVE included if it comes to that. A researcher who gets silence becomes a deadline.

This is the cheapest item in your entire security program, and it decides which version of a bad day you get.

Two required fields. One monitored inbox. You get warned first.

Update log (1)

2026-07-08Initial publication.

Sources + verification

Format and fields follow RFC 9116 ("A File Format to Aid in Security Vulnerability Disclosure", 2022): the well-known path, the required Contact and Expires fields, and the optional fields listed. Verify your own file by fetching /.well-known/security.txt over HTTPS - ours is live at the address below.

Keep reading

Tooling HSTS in plain English 2026-06-10 · 4 min Tooling The five headers that fix most of a failed scan 2026-05-06 · 6 min Compliance NIS2 for small teams, in plain terms 2026-04-28 · 6 min
reading as
consumerpro