What is a security.txt file and what is it for?

A security.txt is a text file that an organization publishes on its own site at /.well-known/security.txt to state, in a form a program can also read, where to report vulnerabilities found in its systems. It is described by RFC 9116, published in April 2022 by Edwin Foudil and Yakov Shafranovich. How you cite it matters: the document is Informational and states that it is not an Internet Standards Track specification, so it is not a binding technical norm, yet it went through IETF community consensus and IESG approval, and today it is the de facto standard. The minimum content is two lines. The Contact field says where to write, an email address, a form or a phone number. The Expires field says how long that information stays reliable, and the RFC requires it to always be present.

See also: Cyber Resilience Act (CRA) · EU regulation imposing mandatory cybersecurity requirements on products with digital elements: SBOM, vulnerability notification, CE marking.

What it contains, and why it expires

The other six fields are optional: Policy, the page with the coordinated disclosure rules; Encryption, the public key for an encrypted report; Acknowledgments, where researchers are credited; Preferred-Languages; Canonical; and Hiring. The least intuitive rule is expiry: the RFC recommends an Expires under one year, and section 5.3 warns that not having a security.txt file may be preferable to having stale information in it. A contact that bounces wastes the time of someone trying to help, and that person will not try again. The problem is measured: the analysis by Hilbig, Geras, Kupris and Schreck published in ACM Digital Threats: Research and Practice in October 2023 finds the file on 1.0% of the top one million domains in January 2023, against 0.7% at the end of 2021, on roughly 3.1% of the top hundred thousand, and with one file in ten already expired.

An enterprise example

A company selling connected machinery gets a report from a researcher: the telemetry portal lets a logged-in customer read data from plants that are not theirs. With no declared contact the report goes to the website's sales address, reads as technical spam and sits for weeks, while whoever found it starts wondering whether to publish it. With four lines in /.well-known/security.txt the same message reaches the right inbox, with the policy page beside it saying what happens next. The file does not make the product safer: it shortens the time between an outsider finding a problem and the right person reading about it.

Why it matters for decision makers

The Cyber Resilience Act asks manufacturers of products with digital elements for a coordinated vulnerability disclosure policy and a contact address for reports (Annex I, Part II, points 5 and 6), plus a single point of contact that is easy to identify (Article 13(17)) but must let users choose their preferred means of communication, so a file on its own is never enough. The regulation prescribes no format and never names security.txt; the only foothold is recital 76, which is not binding and merely invites considering publishing security policies in a machine readable format. Under NIS2 there is no obligation to publish a contact at all: vulnerability handling and disclosure appears among the minimum measures of Article 21(2)(e), carried into Article 24 of Italian Legislative Decree 138/2024, with no form or direction specified, so the link to security.txt is a reasonable reading and not a prescription. The decision is not about compliance but cost: four lines and a yearly reminder to make findable a channel that today exists only in the head of whoever runs it. A security test is bought once a year; reports from outside arrive whenever they arrive, and only if they know where to land.

This entry is informational and does not constitute legal advice: to establish which obligations apply to your product, involve your legal counsel.