Your security.txt has an expiry date

A security.txt file tells researchers where to report a vulnerability. The standard requires it to expire, and it's easy to set a date and forget it.

Here's a complete one:

Contact: mailto:security@example.com
Expires: 2026-09-30T23:59:59Z

RFC 9116 requires both lines, and the date on this one has already passed. Past its date, the standard tells readers to treat the file as stale, and nothing on the site breaks to tell you. To a researcher, an expired file says nobody is listening.

The date passes quietly

Teams tend to write the file during a security review, date it a year out, and forget it when the review ends. Netonica's security.txt check reads the file the way a researcher's tools do. Not expired tells you when the date passes, and a warning level tells you while there's still time to renew. Because people renew this file by hand, the default warning comes earlier than the one for certificates.

A new contact can redirect reports

The file is an instruction to strangers: send your findings here. Anyone who can edit it can add an address of their own and read reports about your weaknesses before you do. The file still looks right.

After the first scan, pin the contacts (see how pins work), and No new contacts holds every later scan to them. Removing a contact is usually tidying and doesn't break it. Adding one does.

The rest of the file can change too

• Well-formed: the standard's required rules hold: a contact, one expiry date, plain text, and HTTPS.
• PGP signature present: a signed file stays signed.
• Served by this site: another site doesn't start serving the file after a redirect.
• Canonical matches URL when present: if the file names the addresses its author meant it for, this is one of them. The standard says not to trust it otherwise.