security.txt Generator a valid RFC 9116 file in seconds
Generate a security.txt file from a guided form. Pick Contact, Expires, Encryption, Policy, and Canonical fields, validate against RFC 9116, and download a ready-to-publish file. Built for teams running a vulnerability disclosure programme. Runs entirely in your browser.
security.txt is the discovery layer. SecPortal handles intake, triage, researcher communication, and remediation tracking on one engagement record. Start free.
No credit card required. Free plan available forever.
Required: contact and expiry
Use mailto:, https://, or tel: URIs. A role-based mailbox (security@, vdp@) is more durable than a personal address.
Default is 180 days from today. RFC 9116 recommends no more than one year.
Recommended fields
Optional fields
Generated security.txt
1 error
Expires: 2026-11-06T00:00:00Z
Preferred-Languages: en
Save as security.txt and serve it from /.well-known/security.txt over HTTPS with Content-Type: text/plain.
Error: At least one Contact entry is required. RFC 9116 makes Contact the only mandatory field.
Everything runs in your browser. Nothing is sent to a server.
How to publish security.txt safely
security.txt is a static file, but it sits on the discovery layer of your vulnerability disclosure programme. The file points researchers at how to reach you, what to send, and where the policy lives. If any of those break, the rest of the programme stops working. The reliable rollout pattern is to publish, monitor, and rotate the file like any other security control.
Generate the file above with at least one role-based Contact and an Expires no more than one year out.
Save the result as security.txt and serve it from https://your-domain.tld/.well-known/security.txt with a Content-Type: text/plain response header.
Optionally also serve a copy at /security.txt for fallback discovery. RFC 9116 lists it as a permitted secondary location.
Test the live file with curl: curl -I https://your-domain.tld/.well-known/security.txt and confirm a 200 response, the correct content type, and a body that starts with Contact:.
Add a calendar reminder thirty days before the Expires date to rotate the file. An expired security.txt signals that the programme is unmaintained, so researchers stop sending reports.
Treat changes to /.well-known/security.txt as security-relevant content. Code review and commit log the same as any other security control, since an attacker who can rewrite the file can redirect every disclosure report.
security.txt field reference
Field
Status
Purpose
Contact
Required
One or more contact methods (mailto:, https://, tel:). The only field RFC 9116 marks as mandatory. Multiple Contact lines are allowed and recommended.
Expires
Required
ISO 8601 UTC timestamp after which the file should no longer be trusted. RFC 9116 effectively requires it; researchers treat a missing Expires as a sign of neglect.
Encryption
Recommended
https URL pointing to a PGP public key (or an openpgp4fpr: fingerprint URI). Most teams host the key on a stable HTTPS URL.
Acknowledgments
Recommended
https URL to a public hall-of-fame or thank-you page. Recognition is one of the cheapest incentives a programme can offer.
Preferred-Languages
Recommended
Comma-separated BCP 47 tags. Most programmes ship just en; multinational programmes may add additional languages they can triage in.
Canonical
Recommended
https URL of this file (typically the well-known location). Important if the file is signed, otherwise informational.
Policy
Recommended
https URL to the human-readable vulnerability disclosure policy. The policy should cover scope, response SLAs, safe-harbour language, and any reward.
Hiring
Optional
https URL to security-related careers pages. A polite signal to researchers who might want to come work on the programme they just helped.
CSAF
Optional
https URL to a CSAF provider-metadata.json. Used by vendors who publish machine-readable security advisories.
Two starter security.txt files
Minimal (single mailbox)
The smallest publishable file. One role-based mailbox, an explicit Expires, and a link to the policy. Good for a small team running its first disclosure programme.
Contact: mailto:security@example.com
Expires: 2026-12-31T00:00:00Z
Preferred-Languages: en
Policy: https://example.com/security/disclosure-policy
Canonical: https://example.com/.well-known/security.txt
Full programme (with PGP and acknowledgments)
The pattern most mature programmes ship. Multiple contact methods, an encryption key, a hall of fame, the disclosure policy, and an explicit canonical URL. Set Expires to 90 to 180 days and rotate quarterly.
Where security.txt fits in a vulnerability disclosure programme
security.txt is the discovery layer. It tells researchers where to send a report. Everything that happens after the report lands (acknowledgement, triage, communication, remediation, retest, public disclosure) is the operational layer of the programme. The two have to match: there is no value in advertising a fast contact if the inbox behind it is unattended, and there is no value in running a tight triage workflow if no researcher can find the front door. Mature programmes treat the file, the policy page, and the operational workflow as one connected system.
Regulators are increasingly explicit about this. CISA Binding Operational Directive 20-01 requires US federal civilian agencies to publish a vulnerability disclosure policy and a security.txt-style discovery file. NCSC (UK) and ENISA (EU) recommend the same pattern for any organisation operating a disclosure programme. ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (handling) treat discovery as a precondition for a defensible programme. NIS2 and DORA push the operational side: organisations in scope have to handle reports on a deadline, not just receive them.
Common security.txt mistakes
Personal email as the only Contact. The contributor leaves and the alias keeps receiving sensitive vulnerability reports for years. Always use a role-based mailbox.
Missing or expired Expires field. Researchers treat an expired file as a closed programme and stop sending reports. Calendar a quarterly review.
Wrong content type. Some web servers serve the file as text/html or with framework wrapping. Force text/plain at the response level so scanners and humans both parse it cleanly.
Pointing Encryption at an inline key. RFC 9116 allows an inline key, but a stable HTTPS URL to the key file is more durable; rotating the key does not require rewriting security.txt.
Not running it through validation. An invalid file (wrong field name, missing colon, malformed URI) is silently ignored by tools that consume it. Use this generator and test the live file with curl after publishing.
Treating the file as one-and-done. security.txt is a control that decays. Rotate the Expires, review the contacts, and confirm the policy URL still resolves on every quarterly review.
Related tools and resources
security.txt is one component of a coordinated disclosure programme. The rest of the picture lives here.