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.

CRA Evidence Team
Author
February 6, 2026
Updated February 25, 2026, 12:00:00 AM UTC
8 min read
Setting Up security.txt for CRA Compliance: A 10-Minute Guide
In this article

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

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:

  1. Providing discoverable contact: Regulators and researchers can find you
  2. Demonstrating process: Shows you have vulnerability handling
  3. Enabling CVD: Links to your disclosure policy
  4. 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

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.

Share this article

Related Articles

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