Is security.txt required by the CRA?

The CRA does not mandate security.txt specifically, but Article 13(1) requires manufacturers to 'make publicly accessible a single point of contact to allow third parties to report vulnerabilities'. A security.txt file at the well-known location is the industry standard way to satisfy this requirement for web-accessible organisations. It is machine-readable, indexed by security scanners, and the first place researchers check.

What is the difference between the `Contact` and `Policy` fields?

The Contact field is where researchers submit reports - typically an email address or URL to a vulnerability submission form. The Policy field links to your human-readable CVD policy document explaining your programme rules, timelines, and safe harbour. Both are needed: Contact tells researchers where to go; Policy tells them what to expect.

Do we need security.txt on every domain we own?

You need it on every domain where security researchers might look for vulnerabilities. Your primary product domain is mandatory. Additional product or service domains are recommended. Internal or development domains (not public-facing) do not need it. For subsidiary or regional domains that redirect to a main domain, add a security.txt that uses the Canonical field to point to your main domain's security.txt.

What happens if our security.txt expires?

RFC 9116 specifies that a security.txt with a past Expires date should be treated as invalid. Security scanners and researcher tools will flag your security.txt as expired and may not surface your contact information. Worse, it signals to researchers that your security programme may be unmaintained. Set a calendar reminder to renew it before expiry.

Can we use a vulnerability disclosure platform URL instead of an email address in the `Contact` field?

Yes. The Contact field accepts both mailto: URIs and HTTPS URLs. Using a portal URL (e.g. Contact: https://cvdportal.com/submit/yourcompany) is often preferable to an email address because it provides structure for the report, creates an automatic audit trail, and avoids email deliverability issues. You can list multiple Contact entries in priority order.

Free security.txt Generator & Template (RFC 9116)

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:[SECURITY@YOURCOMPANY.COM]
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

Note

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

Note

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.asc file with the signature embedded
Rename to security.txt and 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.

Note

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;
}

Note

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

Note

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)

Note

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.

security.txt Template (RFC 9116)

User Manual: How to Use This Functionality

1. Purpose and Scope

2. Customisation Instructions

3. Deployment and Maintenance

4. Platform Automation

Unlock security.txt Template (RFC 9116)

Key takeaways

security.txt File Content

Where to Place Your security.txt

Signed security.txt (Recommended)

Nginx Configuration

Apache Configuration

Annual Maintenance Checklist

Use this template automatically in CVD Portal

Frequently asked questions

Related templates