Every link carrying a secret should have an expiry. Without one, your "one-time" guarantee silently weakens with every day the link sits unread. This post covers what expiry actually protects, how to pick a window you can defend, the edge cases that bite in practice, and the situations where expiring links are the wrong tool entirely.
What expiry actually buys you
Expiry caps the leakage window. A link that worked for five minutes is worth far less to an attacker than one that worked for a week — even if both were "one-time" links.
Think about where a secret-bearing URL ends up after you hit send: the recipient's inbox, their email provider's storage, possibly a forwarded copy, chat history synced to a phone, a browser history entry. You can't control any of those copies. What you can control is how long any of them remains redeemable. A one-hour expiry means that every stray copy of that URL becomes worthless sixty minutes after creation, no matter where it landed.
Expiry also handles a real human failure mode that burn-after-read cannot: the recipient never opens the link. Burn-after-read only fires on a read. An unread link with no expiry sits in an inbox indefinitely — still live, still searchable, still one forward away from the wrong person.
Expiry and burn-after-read cover different failures
These two controls get conflated constantly. They're orthogonal, and the strongest setup uses both:
| Failure mode | Burn-after-read catches it? | Expiry catches it? |
|---|---|---|
| Recipient reads it, link lingers in inbox afterwards | Yes — already dead | Yes, eventually |
| Recipient never opens it | No — stays live forever | Yes |
| Wrong person opens it first | Partially — burns, and the audit trail shows it | No |
| URL leaks weeks later from an email export | Only if it was read | Yes — long dead |
Note the "wrong person" row: neither control prevents that read — that's what a passphrase delivered out-of-band is for. Expiry bounds time, burn bounds reads, the passphrase bounds who. Three separate dials.
Choosing a window
A working rule of thumb, by scenario:
| Scenario | Window | Why |
|---|---|---|
| Real-time hand-off (chat, call, screen-share) | 5–15 minutes | Recipient is present; any longer window is pure downside |
| Email to a known, active recipient | 1 hour | Covers inbox lag without leaving an overnight window |
| Scheduled hand-off (onboarding tomorrow at 10am) | 24 hours | Survives schedule slips; still dead by the day after |
| Recipient in a distant timezone | 24–48 hours | Their working day may not overlap yours at all |
| Anything needing > 7 days | Stop | The link is the wrong primitive — use a vault |
The pattern behind the table: set the window to the expected hand-off time plus one reasonable delay, not "long enough that I never have to think about it again." Convenience-driven expiry windows converge on infinity.
A timed hand-off, step by step
A new engineer starts tomorrow at 10:00. You need to hand them the production read-only database password.
- 09:55 — create the secret link with a passphrase, burn-after-read on, and expiry at 11:00.
- 09:56 — send the link by email.
- 09:58 — send the passphrase by SMS or a Slack DM — a different channel than the link, so one leaked channel isn't enough.
- 10:05 — recipient opens the link, enters the passphrase, reads the password once. The link burns.
- 10:30 — you check the audit timeline. One view, correct time, plausible location. Done.
- If unread by 10:30 — revoke, ping them, and re-share live. Don't just wait for expiry; an unread live link is an open window.
The window is short enough that a leaked email is worthless an hour later. The passphrase covers interception of the link inside that hour. The burn covers re-reads. Each control catches what the others miss.
Edge cases worth knowing
Email scanners don't consume the clock — or the secret
Corporate email security tools fetch URLs the moment a message
arrives. A well-built secret link treats those fetches as metadata
requests: LinkPilot's reveal endpoint returns only status on a
GET, and a view is recorded only on an explicit POST reveal. So
a scanner hitting your link at 09:56 neither burns it nor tells the
scanner anything useful. What scanners can't be prevented from
doing is observing that a URL was sent — another reason the
passphrase goes in a different channel.
The recipient at minute 59
Expiry is enforced at reveal time, not by a background sweep you
have to hope ran. In LinkPilot, an expired secret flips to expired
status on the next access and the payload is redacted in the same
write. A reveal that starts before the deadline and completes after
it resolves cleanly one way or the other — there is no half-expired
state.
Timezone math
"Expires in 24 hours" is unambiguous; "expires tomorrow evening" is not. Set windows as durations from now, and when you tell the recipient, give them the deadline in their timezone. A surprising number of "the link was dead when I opened it" complaints are timezone arithmetic.
The compliance angle
Expiry is also the practical implementation of two principles that show up in most modern privacy regimes: data minimization and storage limitation (in the GDPR, Articles 5(1)(c) and 5(1)(e)). If you must transmit personal data — an ID document, a customer record, an access credential tied to a person — a link that provably stops existing after a bounded window is a much easier story to tell an auditor than "it's somewhere in the email system." An audit trail showing creation, view, and expiry events for each share turns your retention claim into evidence rather than assertion. None of this makes a tool "GDPR compliant" by itself — compliance is a property of your whole process — but bounded lifetimes and event logs are the raw material.
What expiry doesn't help with
Expiry is not a substitute for:
- Rotation. If the secret itself is compromised, expiry on the link doesn't invalidate the credential. Rotate at the source system. Expiry limits how long the delivery vehicle is hot — it says nothing about the payload once delivered.
- Passphrase protection. Expiry bounds the time; the passphrase bounds the access. They're orthogonal, and cheap to combine.
- Audit logging. Expiry tells you nothing about who saw the secret or when. Use per-link audit events for that — LinkPilot records created, viewed, failed-passphrase, burned, expired, and revoked events with timestamps and hashed IPs.
The "I'll extend it" anti-pattern
Tempting and almost always wrong. The recipient agreed to a window. Silently extending breaks the trust model — they assumed the link was dead and may have treated the secret accordingly, or stopped guarding the inbox it sits in.
The clean pattern: revoke the old link, issue a new one with a new expiry, and tell the recipient. The audit trail stays truthful — one link, one window, one outcome per share. This is why LinkPilot lets you shorten an active window or revoke instantly, but deliberately has no "extend" button.
When expiring links are the wrong tool
An honest boundary list:
- Recurring access. If someone will need the value next week too, put it in a password manager and share the vault item. Re-sending links on a schedule is a vault with extra steps and worse guarantees.
- Machine consumers. CI pipelines and services should pull from a secrets manager (or the platform's native secret store), not fetch one-time URLs.
- Broad distribution. A link that fifteen people need is not a secret hand-off; it's access control, and it belongs in a system that has some.
Expiring links shine at exactly one job: moving a sensitive value from one person to another, once, with a bounded blast radius.