security.txt Template (RFC 9116)
A ready-to-use security.txt file template following RFC 9116. The security.txt standard provides a standardised machine-readable location for vulnerability disclosure contact information, satisfying part of the CRA Article 13 requirement for a publicly accessible single point of contact for security researchers.
security.txt File Content
Article 13(1)Security contact information for [COMPANY NAME]
Following RFC 9116 (https://www.rfc-editor.org/rfc/rfc9116)
Place this file at: https://[YOURDOMAIN.COM]/.well-known/security.txt
Required fields
Contact: mailto:[[email protected]] Expires: [YYYY-MM-DDTHH:MM:SS+00:00]
Recommended fields
Policy: https://[YOURDOMAIN.COM]/security Acknowledgments: https://[YOURDOMAIN.COM]/security/acknowledgments
Optional but useful fields
Preferred-Languages: en, [de/fr/nl - add your supported languages] Canonical: https://[YOURDOMAIN.COM]/.well-known/security.txt
If you support encrypted reports
Encryption: https://[YOURDOMAIN.COM]/security-pgp.txt
If you have a bug bounty programme
Hiring: https://[YOURDOMAIN.COM]/careers/security
Place this file at `/.well-known/security.txt` on your web server. The `Expires` field is required by RFC 9116 - set it to no more than 12 months from today and update it annually. If you do not update it before expiry, researchers and automated tools will treat your security.txt as stale. The `Policy` URL should link to your full CVD policy page.
Where to Place Your security.txt
Article 13(1)Your security.txt file must be accessible at:
Primary location (required by RFC 9116): https://[YOURDOMAIN.COM]/.well-known/security.txt
Legacy fallback (also supported by many tools): https://[YOURDOMAIN.COM]/security.txt
For multiple domains:
Create a security.txt at each domain root, or redirect all to a canonical location using the Canonical field.
Subdomains: You do not need a separate security.txt for each subdomain. Researchers typically check the root domain. However, for major products with separate domains, consider adding security.txt to each.
Verification: After deployment, verify your security.txt at https://securitytxt.org/ or using the command:
curl https://[YOURDOMAIN.COM]/.well-known/security.txt
The `.well-known/security.txt` location is the canonical RFC 9116 path. Most vulnerability disclosure tools, scanners, and researcher workflows check this path first. Deploy here first, and optionally redirect from `/security.txt` for backwards compatibility.
Signed security.txt (Recommended)
Article 13(1)For additional authenticity, sign your security.txt with PGP using your security team's key. A signed file provides assurance that the contact information has not been tampered with.
How to sign:
- Create your security.txt content (unsigned version above)
- Sign with GPG:
gpg --clearsign --armor security.txt - This produces a
security.txt.ascfile with the signature embedded - Rename to
security.txtand deploy
Example signed file structure:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
[YOUR SECURITY.TXT CONTENT HERE]
-----BEGIN PGP SIGNATURE-----
[SIGNATURE BLOCK]
-----END PGP SIGNATURE-----
PGP public key: Make your signing key available at the URL specified in the Encryption field, or at a well-known key server.
Signing your security.txt is not mandatory but is a best practice, particularly for organisations where researchers need confidence they are reaching the legitimate security team and not a spoofed page. It is especially recommended for high-profile targets.
Nginx Configuration
Add to your Nginx server block:
location /.well-known/security.txt { alias /var/www/[YOURDOMAIN]/.well-known/security.txt; default_type text/plain; add_header Content-Type 'text/plain; charset=utf-8'; }
Optional: redirect /security.txt to canonical location
location = /security.txt { return 301 /.well-known/security.txt; }
Serving security.txt with the correct `Content-Type: text/plain` header is important - some tools fail to parse it if served as HTML or with no content type. The `.well-known/` directory should already exist if you use other well-known resources (e.g. ACME challenges).
Apache Configuration
Add to your Apache VirtualHost or .htaccess:
Ensure .well-known directory is accessible
<Directory "/var/www/[YOURDOMAIN]/.well-known"> Options None AllowOverride None Require all granted </Directory>
Serve security.txt with correct content type
<Files "security.txt"> Header set Content-Type "text/plain; charset=utf-8" </Files>
Optional: redirect from legacy path
Redirect 301 /security.txt /.well-known/security.txt
Apache may block `.well-known` directory access depending on your server configuration. Ensure the directory is explicitly allowed. Some shared hosting environments require the `.htaccess` approach rather than VirtualHost configuration.
Annual Maintenance Checklist
Article 13(1)security.txt requires regular maintenance. Add these tasks to your annual security calendar:
Before Expires date (update annually):
- [ ] Update the
Expiresfield to a new date 12 months ahead - [ ] Verify
Contactemail address is still monitored - [ ] Verify
PolicyURL resolves to your current CVD policy - [ ] Verify
AcknowledgmentsURL is current - [ ] Re-sign the file if you use PGP signing
- [ ] Test the file is accessible at
/.well-known/security.txt - [ ] Verify with https://securitytxt.org/
When staff change:
- [ ] Update
Contactif the security alias changes - [ ] Update
Encryptionif the PGP signing key changes - [ ] Notify researchers who may have the old key cached
When adding new domains:
- [ ] Deploy security.txt to all new domains within 30 days of launch
An expired security.txt is worse than none - it signals neglect. Add renewal as a calendar event 1 month before the Expires date. Many organisations set Expires to exactly 12 months and renew annually alongside their CVD policy review.
Use this template automatically in CVD Portal
CVD Portal generates your CVD policy, tracks acknowledgments, and creates an audit trail — free for Article 14 compliance.
Set up your free portal