Does having a security.txt make my site more secure?

No, and it is important to be clear about that. It is purely a contact and disclosure file. It helps someone who has already found a vulnerability report it to the right place quickly. The security work itself, patching, updates, strong authentication, HTTPS, is entirely separate and has to be done regardless.

Where exactly does the file go?

At https://yourdomain.co.uk/.well-known/security.txt, served over HTTPS. The .well-known directory is the standard location and the one scanners check first. A copy at the site root is tolerated by the spec, but the .well-known version is the one that takes precedence, so put it there.

What happens when the Expires date passes?

Readers are told by the standard not to trust the file after that date, so it effectively stops doing its job. That is by design, it forces you to review the contents. Set a date you will actually honour, add a calendar reminder, and regenerate and republish before it lapses.

Do I have to sign it with a PGP key?

No. Signing is recommended by RFC 9116 but not required. For most small sites an unsigned file over HTTPS is fine. Sign it only if you already run OpenPGP and can keep the signature current, otherwise you are taking on key management for little practical gain.

What contact should I use?

A monitored one. A dedicated address like security@yourdomain.co.uk that a real person reads is ideal. Avoid pointing it at a mailbox nobody checks, because the whole value of the file is that a report actually reaches someone who can act. You can list more than one method, and the first is treated as preferred.

Free tool

Tell researchers how to report a hole in your site

A security researcher who finds a problem looks for a file at yourdomain.co.uk/.well-known/security.txt. It names who to contact and where your disclosure policy lives, so a finding reaches the right inbox instead of your public contact form or nobody at all. This tool builds a valid file to the RFC 9116 standard. A member of our team is a certified ISO 27001 Lead Auditor and ISO 42001 Auditor, so the field guidance follows the spec, not guesswork.

Contact method (required)

An email, a phone number as tel:+44..., or a reporting page. Add several in order of preference; the first is treated as preferred.

Expires date (required)

Policy page (optional)

Encryption key (optional)

Preferred languages (optional)

Acknowledgments page (optional)

Canonical URL (optional)

Publish at /.well-known/security.txt

# Our security contact details. Please report vulnerabilities responsibly.
Contact: mailto:security@yourdomain.co.uk
Expires: 2027-07-30T23:59:00.000Z

This is a contact file, not a security control. It does not patch, block or defend anything; it only tells someone who has found a problem how to reach you. It also does nothing until you place it at /.well-known/security.txt over HTTPS yourself, and the Expires date means a file you forget will quietly stop being trusted.

Runs in your browser. Nothing you type is sent to us or stored.

It is a contact file, not a security control

This is the honest boundary and it matters. A security.txt file does not make your website more secure by a single degree. It does not patch anything, block anything, or defend anyone. It only tells a person who has already found a problem how to reach you. Publishing one on a site with unpatched software, weak passwords or no HTTPS helps nobody, it just gives an attacker a tidy list of your contact details. The file is the last mile of a disclosure process, useful only if you actually read the inbox it points at and act on what arrives. It also does nothing on its own: this tool writes text, it does not upload the file, and nothing is protected until you place it at /.well-known/security.txt over HTTPS yourself. And because of the Expires field, a file you publish today and forget will quietly become untrusted, so treat it as something you maintain, not something you finish.

What the file is and where it lives

security.txt is a small plain-text file that answers one question: if I find a security problem on your site, who do I tell? It is defined by RFC 9116, an internet standard, and it belongs at a fixed address, yourdomain.co.uk/.well-known/security.txt. Researchers, and increasingly automated scanners, look there first. Without it, a well-meaning finder either gives up or posts the problem publicly, which is the outcome you least want.

The two fields you cannot leave out

The standard requires exactly two fields. Contact is how someone reaches you, an email like mailto:security@yourdomain.co.uk, a phone number, or a reporting page. Expires is a date after which the file should no longer be trusted. Everything else, your disclosure policy, encryption key, preferred languages, acknowledgements page, is optional but useful. This tool makes the two required fields mandatory and offers the rest as clearly labelled extras.

Why Expires exists and why it bites

Every security.txt must carry an expiry date, and the standard recommends less than a year out. The point is to force a review: a file that says contact Jane three years after Jane left is worse than no file. When your file expires, researchers are told not to rely on it. So this is not a set-and-forget artefact. Put a reminder in your calendar to regenerate and republish before the date you set, and update it whenever your security contact changes.

Signing, and when it is worth it

The standard recommends signing the file with an OpenPGP key so a reader can verify it genuinely came from you and was not swapped by an attacker. For most small business sites this is optional and adds real overhead, you have to manage the key and keep the signature current. This tool can add the Encryption and Signature field references for you, but it does not hold keys or sign anything. If you are not running PGP already, an unsigned file served over HTTPS is a perfectly reasonable start.

Check if yours is there

The X-Ray reports whether your site already publishes a security.txt

Questions

Does having a security.txt make my site more secure?: No, and it is important to be clear about that. It is purely a contact and disclosure file. It helps someone who has already found a vulnerability report it to the right place quickly. The security work itself, patching, updates, strong authentication, HTTPS, is entirely separate and has to be done regardless.
Where exactly does the file go?: At https://yourdomain.co.uk/.well-known/security.txt, served over HTTPS. The .well-known directory is the standard location and the one scanners check first. A copy at the site root is tolerated by the spec, but the .well-known version is the one that takes precedence, so put it there.
What happens when the Expires date passes?: Readers are told by the standard not to trust the file after that date, so it effectively stops doing its job. That is by design, it forces you to review the contents. Set a date you will actually honour, add a calendar reminder, and regenerate and republish before it lapses.
Do I have to sign it with a PGP key?: No. Signing is recommended by RFC 9116 but not required. For most small sites an unsigned file over HTTPS is fine. Sign it only if you already run OpenPGP and can keep the signature current, otherwise you are taking on key management for little practical gain.
What contact should I use?: A monitored one. A dedicated address like security@yourdomain.co.uk that a real person reads is ideal. Avoid pointing it at a mailbox nobody checks, because the whole value of the file is that a report actually reaches someone who can act. You can list more than one method, and the first is treated as preferred.