Setting Up security.txt for CRA Compliance: A 10-Minute Guide
A quick, practical guide to implementing security.txt for your products. Includes templates, hosting options, and common mistakes to avoid.
In this article
- Summary
- What Is security.txt?
- The Minimum Viable security.txt
- The Recommended security.txt
- Field-by-Field Explanation
- Step-by-Step Setup
- For Products Without Web Interfaces
- Security Vulnerability Reporting
- Common Mistakes
- Validation Checklist
- Maintenance Schedule
- Integration with CRA Compliance
- Complete Example
- How CRA Evidence Helps
The CRA requires a publicly available contact point for vulnerability reports. The simplest way to comply? A security.txt file.
This 10-minute guide gets you from zero to compliant.
Summary
- security.txt is a standardized file (RFC 9116) telling researchers how to report vulnerabilities
- Place it at
/.well-known/security.txton your web presence - Minimum required fields: Contact, Expires
- Recommended: Also include Preferred-Languages, Policy, Canonical
- For products without web interfaces, include the URL in documentation
What Is security.txt?
security.txt is an RFC standard (RFC 9116) that provides a machine-readable and human-readable way to publish security contact information.
Why it matters for CRA:
- CRA requires vulnerability reporting contact points
- security.txt is the industry-standard method
- Automated tools and researchers check for it
- Shows regulators you've implemented proper disclosure channels
The Minimum Viable security.txt
Here's the simplest compliant file:
Contact: mailto:security@yourcompany.com
Expires: 2027-12-31T23:59:59.000Z
That's it. Two lines. You're technically compliant.
But let's do better.
The Recommended security.txt
A complete, professional security.txt:
# Security Contact Information for [Your Company]
# https://www.yourcompany.com/.well-known/security.txt
Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://yourcompany.com/.well-known/pgp-key.txt
Preferred-Languages: en, de, fr
Canonical: https://yourcompany.com/.well-known/security.txt
Policy: https://yourcompany.com/security/disclosure-policy
Hiring: https://yourcompany.com/careers/security
Acknowledgments: https://yourcompany.com/security/thanks
Field-by-Field Explanation
Contact (Required)
How researchers should reach you.
Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report
Best practices:
- Include both email AND web form
- Use a team alias, not personal email
- Web forms provide structured intake
- Multiple Contact lines are allowed
Expires (Required)
When this file should be considered stale.
Expires: 2027-01-01T00:00:00.000Z
Best practices:
- Set 6-12 months in the future
- Use ISO 8601 format with timezone
- Put a calendar reminder to update before expiry
- Stale files make you look unmaintained
Encryption (Recommended)
PGP key for encrypted reports.
Encryption: https://yourcompany.com/.well-known/pgp-key.txt
Best practices:
- Host your public key at the specified URL
- Use a team key, not individual key
- Include key fingerprint in comments
- Keep private key secure (HSM if possible)
Preferred-Languages (Recommended)
Languages your team can handle reports in.
Preferred-Languages: en, de, fr
Best practices:
- List languages your security team actually speaks
- English should usually be included
- Order by preference
- Don't list languages you can't actually respond in
Canonical (Recommended)
The authoritative location of this file.
Canonical: https://yourcompany.com/.well-known/security.txt
Why it matters:
- Prevents spoofing
- Clarifies if file is mirrored
- Helps researchers verify authenticity
Policy (Recommended)
Link to your full vulnerability disclosure policy.
Policy: https://yourcompany.com/security/disclosure-policy
Best practices:
- Link to your complete CVD policy
- Ensure the page exists and is accessible
- Keep policy and security.txt in sync
Acknowledgments (Optional)
Link to your security Hall of Fame.
Acknowledgments: https://yourcompany.com/security/thanks
Why include it:
- Shows you value researchers
- Encourages reports (recognition is motivating)
- Demonstrates mature security program
Hiring (Optional)
Link to security job postings.
Hiring: https://yourcompany.com/careers/security
Why include it:
- Researchers often make good hires
- Shows investment in security
- Community goodwill
Step-by-Step Setup
Step 1: Create the File
Create a plain text file with your information:
# Create the file
cat > security.txt << 'EOF'
# Security Contact Information for YourCompany
# Last Updated: 2026-01-15
Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report
Expires: 2027-01-15T00:00:00.000Z
Preferred-Languages: en
Canonical: https://yourcompany.com/.well-known/security.txt
Policy: https://yourcompany.com/security/policy
EOF
Step 2: Choose Hosting Location
The file must be at /.well-known/security.txt
For websites:
https://yourcompany.com/.well-known/security.txt
For products with web interfaces:
https://product.local/.well-known/security.txt
https://192.168.1.1/.well-known/security.txt
Step 3: Configure Your Web Server
Nginx:
location /.well-known/security.txt {
alias /var/www/security.txt;
default_type text/plain;
}
Apache:
Alias /.well-known/security.txt /var/www/security.txt
<Files "security.txt">
ForceType text/plain
</Files>
Express.js:
const express = require('express');
const app = express();
app.get('/.well-known/security.txt', (req, res) => {
res.type('text/plain');
res.sendFile(__dirname + '/security.txt');
});
Static hosting (S3, GitHub Pages, etc.):
Just place the file in the .well-known directory.
Step 4: Verify
Check that your file is accessible:
curl https://yourcompany.com/.well-known/security.txt
Use an online validator:
Step 5: Sign (Optional but Recommended)
Digitally sign your security.txt for authenticity:
# Sign with GPG
gpg --clearsign security.txt
# This creates security.txt.asc
# Rename and deploy
mv security.txt.asc security.txt
Signed file looks like:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Contact: mailto:security@yourcompany.com
Expires: 2027-01-01T00:00:00.000Z
...
-----BEGIN PGP SIGNATURE-----
[signature data]
-----END PGP SIGNATURE-----
For Products Without Web Interfaces
Not all products have web servers. Here's how to handle security.txt:
Embedded Devices
Option 1: If the device has any web interface (config page, status page):
- Host security.txt on that interface
http://device-ip/.well-known/security.txt
Option 2: If no web interface:
- Include the URL in product documentation
- Reference your corporate security.txt
- Add to Quick Start Guide: "Report security issues at: https://company.com/security"
Desktop Software
- Include security contact in Help > About
- Add to README/documentation
- Reference corporate security.txt URL
Mobile Apps
- Include in app Settings > About > Security
- Link to corporate security.txt
- Add to app store description
Documentation Reference
Add to your product documentation:
## Security Vulnerability Reporting
To report security vulnerabilities in this product:
- Email: security@yourcompany.com
- Web: https://yourcompany.com/security/report
- Policy: https://yourcompany.com/security/policy
Our security.txt file: https://yourcompany.com/.well-known/security.txt
Common Mistakes
Expired File
Problem: Expires date is in the past.
Expires: 2024-01-01T00:00:00.000Z # EXPIRED!
Fix: Set a future date. Add calendar reminder.
Wrong Location
Problem: File at wrong path.
/security.txt # Wrong
/security/security.txt # Wrong
/.well-known/security.txt # Correct
Fix: Use the standard location.
Invalid Format
Problem: Wrong date format, missing fields.
Expires: January 1, 2027 # Wrong format
Contact: security team # Not a valid URI
Fix: Use ISO 8601 dates, mailto: or https: URIs.
Dead Links
Problem: Policy or Acknowledgments URLs return 404.
Fix: Verify all links work. Check after deployments.
Personal Email
Problem: Using individual's email instead of team alias.
Contact: mailto:john.smith@yourcompany.com # Bad
Fix: Use team alias that survives personnel changes.
No HTTPS
Problem: Using HTTP instead of HTTPS for Canonical/Policy links.
Fix: Always use HTTPS for security-related URLs.
Validation Checklist
SECURITY.TXT VALIDATION CHECKLIST
REQUIRED FIELDS:
[ ] Contact field present (mailto: or https:)
[ ] Expires field present (future date, ISO 8601)
RECOMMENDED FIELDS:
[ ] Preferred-Languages included
[ ] Canonical URL matches actual location
[ ] Policy link works and points to CVD policy
[ ] Encryption key link works (if included)
HOSTING:
[ ] File at /.well-known/security.txt
[ ] HTTPS accessible
[ ] Content-Type: text/plain
[ ] No authentication required
VERIFICATION:
[ ] curl test successful
[ ] Online validator passes
[ ] Links all resolve (no 404s)
[ ] PGP signature valid (if signed)
MAINTENANCE:
[ ] Calendar reminder set for before Expires date
[ ] Update process documented
[ ] Monitoring for accessibility
Maintenance Schedule
| Task | Frequency |
|---|---|
| Check expiry date | Monthly |
| Verify links work | Monthly |
| Update PGP key (if expiring) | As needed |
| Review contact addresses | Quarterly |
| Full validation check | Before expiry |
Integration with CRA Compliance
Your security.txt supports CRA compliance by:
- Providing discoverable contact: Regulators and researchers can find you
- Demonstrating process: Shows you have vulnerability handling
- Enabling CVD: Links to your disclosure policy
- Supporting documentation: Reference in technical file
Include in your technical documentation:
Vulnerability Reporting Contact Points:
- security.txt: https://company.com/.well-known/security.txt
- Email: security@company.com
- Web Form: https://company.com/security/report
- Policy: https://company.com/security/policy
Complete Example
Here's a production-ready security.txt:
# ============================================================
# SECURITY.TXT for AcmeTech Products
# https://acmetech.eu/.well-known/security.txt
# ============================================================
#
# If you've found a security vulnerability in any AcmeTech
# product, please report it using the contact methods below.
#
# We appreciate responsible disclosure and will acknowledge
# your contribution if desired.
#
# ============================================================
# Primary contact methods (preferred order)
Contact: https://acmetech.eu/security/report
Contact: mailto:security@acmetech.eu
# This file expires (update before this date)
Expires: 2027-06-01T00:00:00.000Z
# For encrypted communications
Encryption: https://acmetech.eu/.well-known/pgp-key.txt
# Languages our security team handles
Preferred-Languages: en, de, es
# Authoritative location of this file
Canonical: https://acmetech.eu/.well-known/security.txt
# Our vulnerability disclosure policy
Policy: https://acmetech.eu/security/disclosure-policy
# Security researchers who've helped us
Acknowledgments: https://acmetech.eu/security/hall-of-fame
# Join our security team
Hiring: https://acmetech.eu/careers#security
# ============================================================
# Last Updated: 2026-01-15
# Contact security@acmetech.eu with questions about this file
# ============================================================
Tip: Setting up security.txt takes 10 minutes and satisfies a key CRA requirement for published vulnerability contact. Do it today.
Important: Your security.txt must include a contact method, a preferred language, and an expiry date. It should be at /.well-known/security.txt on your domain.
Related Guides
- Coordinated Vulnerability Disclosure Under CRA: Policy Template and Setup
- ENISA Vulnerability Reporting: The 24-Hour Requirement
- CRA Technical File (Annex VII) Guide
How CRA Evidence Helps
CRA Evidence can:
- Generate security.txt: Pre-filled with your organization details
- Monitor expiry: Alert before your file expires
- Validate format: Check for common errors
- Track updates: Audit trail of changes
Set up your security.txt with app.craevidence.com.
This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.
Topics covered in this article
Related Articles
Are Smart Cameras Important Products Under the EU Cyber...
Smart security cameras are classified as Important Products (Class I) under...
9 minEU Cybersecurity Act 2: Supply Chain Bans, Certification...
On January 20, 2026, the EU proposed replacing the Cybersecurity Act...
10 minCRA Product Classification: Is Your Product Default,...
A practical guide to determining your product's CRA category. Includes...
11 minDoes the CRA apply to your product?
Answer 6 simple questions to find out if your product falls under the EU Cyber Resilience Act scope. Get your result in under 2 minutes.
Ready to achieve CRA compliance?
Start managing your SBOMs and compliance documentation with CRA Evidence.