What expiry time to choose for a secret link?
Why expiry time matters
A one-time link that never expires is only slightly better than a permanent record. The whole point of a one-time link is that the secret exists for as short a time as possible. If the recipient doesn't open the link for a week, the credential has been sitting on a server — encrypted, yes, but still waiting to be retrieved — for seven days longer than necessary.
Choosing the right expiry time balances two competing concerns: giving the recipient enough time to act, and minimising the window during which the secret could theoretically be intercepted and used.
The general principle: as short as possible, as long as necessary
The expiry time should match the urgency and nature of the transfer. There is no universal answer, but there are clear patterns for different scenarios.
Common scenarios and recommended expiry times
Active handover — 1 to 2 hours If you're sending a credential to someone who is online and expecting it right now — a colleague on the same call, a client during a project handover meeting — a 1-2 hour window is plenty. You know they'll act on it immediately, and a short window means minimal exposure if something goes wrong.
Same-day delivery — 4 to 8 hours Sending credentials to someone who will use them during their working day but isn't in an active meeting with you. They'll open it when they get to their desk, during a natural break in their work.
Next business day — 24 hours The most common scenario: you're sending credentials to someone who may not check their messages for several hours, perhaps across time zones. A 24-hour window gives them a full working day to retrieve the link while keeping the exposure window reasonable.
End of the week — 48 to 72 hours For non-urgent transfers where the recipient might not be immediately available. Only use this when necessary — a three-day window is a long time for a credential to exist unnecessarily.
Longer than 72 hours — reconsider If you feel you need a link to stay valid for more than three days, it's worth asking whether this is really the right tool for the job. Perhaps the credential needs to be stored in a shared password manager rather than transferred via a one-time link.
What happens when a link expires unused?
A well-implemented one-time link service — including PassTransfer — automatically deletes the encrypted credential when the link expires. There is no lingering record on the server. This is the safety net that makes expiry time so valuable: even if the recipient never opens the link, the secret doesn't accumulate indefinitely on the server.
Communicating the expiry to the recipient
Tell the recipient when the link will expire. A message like "I've sent you a secure link — it's valid for 24 hours, so please open it before tomorrow at 3pm" sets clear expectations and prompts prompt action. It also means that if the recipient hasn't opened it by the deadline, you know to investigate rather than assume everything is fine.
If the link expires before retrieval
If a recipient tells you they missed the link, generate a new one. Don't extend expiry times on expired links — they shouldn't exist anymore at that point. Simply create a fresh link with a new expiry window. This is quick and has the benefit of giving you another clean handover event.
Conclusion
Expiry time is a small but meaningful security decision. Match it to the real-world urgency of the transfer, err on the shorter side, and communicate the deadline clearly to the recipient. These small habits significantly reduce the window of exposure for every credential you share.
