security.txt generator and checker
Build a valid RFC 9116 security.txt so researchers know how to reach you, or paste an existing one to see what is wrong with it. Part of getting ready for the EU Cyber Resilience Act.
Runs entirely in your browser
Generate a security.txt
Check a security.txt
Checks the text against RFC 9116 only. It does not fetch your website (nothing you type leaves this page, so paste the file instead), verify an OpenPGP signature, or test that an address works. A template, not legal advice.
How to make and check a security.txt
- Enter at least one Contact (an email address, a phone number or an https:// page) and check the Expires date. Fill in the optional fields you want, such as Policy and Preferred-Languages.
- Copy the file or download it, and publish it at
/.well-known/security.txton your domain over HTTPS as plain text. - To check an existing file, paste its text into the checker. Fix the errors, then look at the warnings. Add the address you serve it from to test the Canonical field.
- Put a reminder in your calendar to renew Expires before it passes.
What a security.txt is for
When a researcher, a customer or a CERT finds a weakness in your software, the first problem is who to tell. A security.txt is a small text file at a fixed address, /.well-known/security.txt, that answers it: a contact, an expiry date, and optionally a link to your disclosure policy and a public key. RFC 9116 defines the format, and many scanners, bug bounty platforms and national CERTs look for the file before they look anywhere else.
For a software vendor in the EU it also supports duties under the Cyber Resilience Act: Annex I expects a published way for outsiders to report vulnerabilities and a process to handle them. The regulation does not name this format, but it is the usual way to publish the contact. The reporting guide for small vendors sets out the rest of the setup, including the 24-hour clock.
The fields
Contact and Expires are required. Contact may appear several times and must be a URI: mailto:, tel: or https:. Expires appears once, as a date and time such as 2027-12-31T23:59:59Z, and RFC 9116 asks for less than a year ahead. Encryption, Acknowledgments, Policy, Hiring and Canonical are optional links, and every web address must use https. Preferred-Languages appears once and lists language codes. Fields the RFC does not define are ignored by readers, so the checker flags them as warnings: they are usually typos.
Tips
- Use a mailbox that several people read, not one person's address, and test it by writing to it.
- Write a vulnerability disclosure policy and link it with the Policy field.
- Know your deadlines before a report arrives: the CRA 24-hour incident clock turns an awareness time into dated deadlines.
Questions
Does the Cyber Resilience Act require a security.txt?
No. The regulation expects manufacturers to have a coordinated vulnerability disclosure policy and a published way to report vulnerabilities. A security.txt file is the common way to publish that contact, and practitioners recommend it, but the regulation does not name the format. See the guide for small vendors.
Where exactly do I put the file?
At https://your-domain/.well-known/security.txt, served over HTTPS with the content type text/plain; charset=utf-8. RFC 9116 also allows a copy at /security.txt for older setups. Publish it on every domain or subdomain you want covered.
How far ahead should Expires be?
RFC 9116 says it should be less than a year in the future, so that researchers can trust the contact details are kept up to date. The generator defaults to just under a year. When the date passes, readers are told to ignore the file, so renew it in good time.
Do I have to sign the file with PGP?
No, signing is optional but recommended. A signed file is an OpenPGP cleartext-signed message, made with gpg --clearsign security.txt. The checker recognises the signed format and checks its outline, but it cannot verify the signature itself; use gpg --verify for that.
Why can't the checker fetch my site?
To keep the page private: it runs entirely in your browser and makes no requests to other sites. Open your file in a browser tab, copy the text and paste it in. That also checks what visitors actually get.
What is the Canonical field for?
It lists the addresses where the file is meant to be served, so a reader can confirm that a file found at one address really belongs there. If you enter the address you serve the file from, the checker tests that one of your Canonical lines matches it.