The Expires field in security.txt is a required date and time, written in RFC 3339 format, that says when the file should stop being trusted. RFC 9116 recommends setting it less than a year ahead so a forgotten file does not point researchers at an inbox nobody reads.
Definition
security.txt is a small text file, defined in RFC 9116, that tells outside researchers how to reach your security team. Two fields are mandatory: Contact and Expires. Everything else, such as Policy or Encryption, is optional.
Expires answers a customer-trust question: is this contact information still current? A reader who sees a date in the past knows the file may be abandoned and can look for another route.
What RFC 9116 says
The specification states that Expires "MUST always be present and MUST NOT appear more than once." The value is an RFC 3339 date-time. It also says it is recommended that the value be less than a year into the future to avoid staleness.
That recommendation is the practical rule. A date five years out defeats the purpose of the field.
How to choose a value
| Choice | What it signals | Trade-off |
|---|---|---|
| About 12 months or less | Someone reviews this file at least yearly | One more calendar task |
| A few months | Active upkeep | More renewals to remember |
| Many years | Nobody plans to check | Defeats the field |
Pick an interval you will honestly keep. Put the renewal on the same calendar as your annual policy review, so the file is checked when the policy is.
Steps to set and renew it
- Serve the file at /.well-known/security.txt over https as text/plain with UTF-8, as the RFC describes.
- Add Contact with a monitored address or form, and Expires with a date under a year ahead.
- If you sign the file with an OpenPGP cleartext signature, re-sign it every time you change Expires, because the signature covers the content.
- Add a calendar reminder a month before the date.
- Test the reminder by assigning it to a named person, not a shared mailbox.
What happens when it lapses
The RFC defines the field; it does not describe enforcement. In practice, a lapsed date is a signal. Researchers and automated tools may treat the file as stale, and a buyer reviewing your security page may read it as a sign that nobody owns disclosure. None of that is a rule, so treat it as a trust cost rather than a penalty.
The fix is cheap. Update the date, re-sign if you sign, and redeploy.
Common mistakes
- Setting a date and never reviewing the Contact value.
- Pointing Contact at a person who has left.
- Editing the file by hand and forgetting the signature.
- Publishing a date in the wrong format. Use a full RFC 3339 timestamp, for example a date followed by a time and a Z for UTC.
Quick check
Is Expires optional?
No. RFC 9116 says Expires must always be present, along with Contact. Every other field is optional.
How far ahead should I set it?
The RFC recommends less than a year into the future. Choose an interval you will actually renew.
Do I need to sign the file?
Signing with an OpenPGP cleartext signature is recommended, not mandatory. If you sign, include the Canonical field as well.
Safeguard can inventory the dependencies behind your products so advisories you publish rest on current data. You can try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
