Free toolVulnerability handling

security.txt Generator

Create a valid security.txt in a minute: contact, expiry date and the optional fields of RFC 9116, with validation. Copy or download and publish it at /.well-known/.

Updated October 7, 2026This page as Markdown

In short

This generator builds a security.txt file according to RFC 9116, the standard that tells security researchers how to report a vulnerability to you. You enter at least one contact and an expiry date; the optional fields Encryption, Policy, Acknowledgments, Hiring, Canonical and Preferred-Languages are checked for the right format. The file goes to /.well-known/security.txt on your web server.

Contact (required)

One per line or comma-separated: mailto:, tel: or an https:// URL. The first one is preferred.

Expires (required)

Must be in the future. RFC 9116 recommends less than a year.

Optional fields

Encryption

https:// URL of your PGP key.

Policy

Acknowledgments

Hiring

Canonical

The https:// URL where this file will live.

Preferred-Languages

Language tags, comma-separated.

Your security.txt

Contact: mailto:security@example.com
Expires: 2027-10-08T00:00:00Z
Preferred-Languages: en, de

Publish it over HTTPS at /.well-known/security.txt

If you publish an Encryption key, consider signing the file with PGP (cleartext signature) as RFC 9116 describes.

How it works

The tool writes the fields exactly as RFC 9116 defines them: one Contact line per address, one Expires line with an ISO 8601 timestamp, and the optional fields only when you fill them in. Contacts that look like email addresses get the mailto: prefix. Every URL field must use HTTPS, and Expires must be in the future, otherwise the tool shows the error and disables copy and download.

How to read the result

The file is only useful if researchers find it. Publish it at https://your-domain/.well-known/security.txt (the legacy location /security.txt may redirect there). The contact address should reach people who can act, not a general inbox. Say in your Policy page what reporters can expect: acknowledgment time, whether you pay bounties, and that good-faith research will not be met with legal threats.

Limits

The generator checks the format, not your process. A security.txt without someone reading the mailbox is worse than none, because it promises a response. For manufacturers under the Cyber Resilience Act, the file is one piece of the coordinated vulnerability disclosure policy the regulation requires; the policy itself, the handling process and the reporting obligations to ENISA and the national CSIRT are separate work.

FAQ

Frequently asked questions

Is a security.txt required by law?

Not by name. The Cyber Resilience Act requires manufacturers of products with digital elements to have a coordinated vulnerability disclosure policy and a contact address for reporting vulnerabilities (Annex I, Part II). A security.txt is the simplest way to publish that address in a place researchers look first.

Why does the file need an expiry date?

RFC 9116 makes Expires mandatory so stale contacts do not linger for years. Researchers treat an expired file as unreliable. Pick a date within a year and put a reminder in your calendar.

Should I sign the file?

If you publish an Encryption key, a PGP signature proves the file was not tampered with. It is optional. Most organisations start without a signature and add it when they have a key management process.

Sources

← Free tools