# security.txt Generator

> 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.

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/.

Source: https://zyberum.com/tools/security-txt-generator · Updated: 2026-10-07

## 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

**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

- [RFC 9116: A File Format to Aid in Security Vulnerability Disclosure](https://www.rfc-editor.org/rfc/rfc9116)
- [securitytxt.org](https://securitytxt.org/)

## Related

- [Responsible Disclosure](https://zyberum.com/glossary/responsible-disclosure)
- [Cyber Resilience Act (CRA)](https://zyberum.com/glossary/cyber-resilience-act)
- [Make your products CRA-compliant, without slowing development.](https://zyberum.com/cyber-resilience-act)

---
Zyberum GmbH. Canonical page: https://zyberum.com/tools/security-txt-generator