Setting Up security.txt for CRA Compliance: A 10-Minute Guide

Under the CRA, manufacturers need a publicly reachable way for researchers and customers to report vulnerabilities. The standard is RFC 9116 — a plain text file called security.txt hosted at /.well-known/security.txt. Two required fields, a handful of recommended ones, and about 10 minutes of work.

This guide covers the fields, the hosting, the common mistakes, and what you need to reference in your technical file.

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.

The CRA requires manufacturers to publish a vulnerability reporting contact. security.txt is the industry-standard way to do it. Automated scanning tools and security researchers check for it by default, and having it in place gives regulators a concrete signal that you've set up 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 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

Use a team alias, not a personal email. Include both an email address and a web form if you have one. Multiple Contact lines are allowed and the form gives you structured intake.

Expires (Required)

When this file should be considered stale.

Expires: 2027-01-01T00:00:00.000Z

Set it 6-12 months out in ISO 8601 format with timezone. Put a calendar reminder before it hits. A stale file tells researchers you're not maintaining it.

Encryption (Recommended)

PGP key for encrypted reports.

Encryption: https://yourcompany.com/.well-known/pgp-key.txt

Use a team key rather than an individual key, and keep the private key in an HSM if you can. Include the fingerprint in the comments so researchers can verify it out-of-band.

Preferred-Languages (Recommended)

Languages your team can handle reports in.

Preferred-Languages: en, de, fr

List only languages your security team can actually respond in. Order by preference. If you list German and nobody on the team reads German, you will get reports you cannot triage.

Canonical (Recommended)

The authoritative location of this file.

Canonical: https://yourcompany.com/.well-known/security.txt

Prevents spoofing and clarifies if the file is mirrored. Researchers can verify the canonical URL against what they fetched to confirm authenticity.

Policy (Recommended)

Link to your full vulnerability disclosure policy.

Policy: https://yourcompany.com/security/disclosure-policy

Make sure the page exists and loads without authentication. A dead Policy link during a security review is not a good look.

Acknowledgments (Optional)

Link to your security Hall of Fame.

Acknowledgments: https://yourcompany.com/security/thanks

Researchers who find bugs are often good candidates for your security team. Recognition also encourages more reports. Most researchers will prioritize organizations that acknowledge their work.

Hiring (Optional)

Link to security job postings.

Hiring: https://yourcompany.com/careers/security

Worth including if you have open security roles. Researchers actively looking for work check these links.

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:

• https://securitytxt.org/

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

What Goes in Your Technical File

The CRA requires manufacturers to maintain a technical file (Annex VII) documenting their vulnerability handling process. Your security.txt file and the CVD policy it references are direct inputs to that documentation.

Specifically, your technical file should reference:

• The security.txt URL and what contact methods it exposes
• The disclosure policy URL it links to
• The response SLAs you've committed to in that policy

Regulators reviewing your technical file look for evidence that a working vulnerability intake process exists. A live, non-expired security.txt with a functioning Policy link is a concrete signal. An expired file or dead links work against you.

Add this block to your vulnerability handling 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
# ============================================================

How CRA Evidence Helps

security.txt is one piece of the vulnerability handling picture. The harder part is the full process behind it: policy, triage SLAs, ENISA reporting, and documenting it all in your technical file. That's what CRA Evidence is for.

Start at craevidence.com.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.