security.txt
security.txt is a standardised plain-text file placed at `/.well-known/security.txt` on a web domain that tells security researchers how to report vulnerabilities. Defined in RFC 9116, it is the recommended machine-readable disclosure of a manufacturer's CVD contact and policy.
security.txt is a standardised plain-text file placed at `/.well-known/security.txt` on a web domain that tells security researchers how to report vulnerabilities. Defined in RFC 9116, it is the recommended machine-readable disclosure of a manufacturer's CVD contact and policy.
CVD & Vulnerability ManagementWhat Is security.txt?
security.txt is a plain-text file published at https://example.com/.well-known/security.txt that standardises how organisations communicate their vulnerability disclosure contact details. Defined in RFC 9116 (published May 2022), the file uses key-value fields including Contact, Policy, Expires, Encryption (PGP key URL), Preferred-Languages, and Canonical. Security researchers — and automated scanners — can retrieve this file without navigating a website. The Expires field is mandatory; once a security.txt file expires, it should not be trusted. The file is typically signed with a PGP key to prevent tampering.
Why security.txt Supports CRA Compliance
The CRA requires manufacturers to make their CVD contact channel accessible. A security.txt file satisfies this requirement by providing a machine-readable, standardised location that researchers check before reporting. ENISA's CVD Good Practice Guide specifically recommends security.txt as part of a compliant disclosure infrastructure. Without a security.txt file (or equivalent published contact), researchers cannot easily find the correct reporting channel — vulnerability reports end up on social media or in full-public-disclosure, which harms the manufacturer and EU consumers. Maintaining an up-to-date security.txt also demonstrates to market surveillance authorities that the disclosure channel is actively managed.
Creating a CRA-Compliant security.txt
A minimal CRA-compliant security.txt file for an EU manufacturer:
Contact: mailto:[email protected]
Contact: https://example.com/security/report
Encryption: https://example.com/.well-known/pgp-key.txt
Policy: https://example.com/security/cvd-policy
Preferred-Languages: en, de, fr
Expires: 2027-01-01T00:00:00.000Z
Canonical: https://example.com/.well-known/security.txt
- Sign the file with the same PGP key referenced in
Encryption. - Refresh
Expiresannually — expired files warn researchers the programme is inactive. - If you operate multiple product domains, publish a security.txt on each.
CVD Portal makes security.txt compliance straightforward.
Public CVD submission portal, acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Free forever for EU manufacturers.
Start your free portalFrequently asked
Is a security.txt file legally required under the CRA?+
The CRA does not name security.txt specifically, but Article 13(6) requires an accessible, published CVD contact. security.txt (RFC 9116) is the de facto standard for meeting this requirement. ENISA endorses it in its CVD Good Practice Guide. Regulators will look for a discoverable contact method; security.txt is the most auditable way to demonstrate compliance.
What happens if our security.txt file expires?+
RFC 9116 states that an expired security.txt MUST NOT be relied upon. Security researchers and automated tools will treat it as if it does not exist and may report vulnerabilities through other channels — or publicly. An expired file signals to regulators that the vulnerability disclosure programme is not actively maintained, which weakens a manufacturer's CRA compliance posture.
Do we need a separate security.txt for each product domain?+
You need a security.txt on every domain from which your products serve content or receive researcher contact. If all your products share a single corporate domain, one file suffices. If individual products have dedicated domains or subdomains (e.g. firmware update servers, cloud backends), each should carry its own security.txt or a `Canonical` redirect to the primary one.
Related terms
Browse the full CRA Compliance Checklist
See how security.txt fits into your complete CRA compliance programme.