A one-time link is intended to have a limited lifetime, but there is no single expiration period that fits every situation. The right choice depends on how sensitive the information is, how quickly the recipient is expected to act, and what happens if the link is discovered before the intended recipient opens it.
Shorter expiration reduces the exposure window
An unopened link is still potentially useful to anyone who obtains it. A shorter expiration reduces the time available for accidental forwarding, mailbox compromise, leaked browser history, or other unintended access. For high-value information, the shortest practical lifetime is usually preferable.
Match expiration to the workflow
If you are sending a temporary password to a colleague who is waiting for it, an expiration of an hour may be enough. If the recipient is in another time zone or will not be available until the next day, a longer period may be necessary. The goal is not to choose the smallest number possible; it is to avoid leaving unused secrets active longer than the task requires.
Consider the value of the secret
A recovery code for an administrative account deserves a tighter window than a low-risk temporary note. The possible impact of unauthorized access should influence the lifetime of the link. Highly privileged information may also justify an additional passphrase or a separate verification step.
Expiration is different from one-time access
One-time access and time-based expiration protect against different scenarios. One-time access makes the secret unavailable after it is retrieved. Expiration makes it unavailable after a deadline even if nobody retrieves it. A secure implementation benefits from both controls.
Do not use long expiration as a substitute for convenience
It may be tempting to choose a very long lifetime so the recipient never encounters an expired link. That convenience increases the period during which the link remains valuable. If the recipient misses a short window, it is often safer to generate a new link than to keep every link active for days or weeks.
Account for operational delays
Support teams and global organizations should consider realistic delays. A recipient may be offline, traveling, or working in a different region. Define a small set of expiration options that correspond to common workflows, such as immediate transfer, same-day transfer, and next-day transfer.
What if the link expires before it is used?
Create a new secret or new one-time link rather than attempting to reactivate an old one. If the underlying credential has its own expiration or rotation policy, make sure the replacement remains valid long enough for the recipient to complete the intended task.
Use policy for consistency
Organizations can reduce guesswork by defining standard expiration windows for different data classes. For example, administrator credentials may require a shorter window than ordinary temporary access. Consistent rules make secure behavior easier and reduce the chance that users choose unnecessarily long lifetimes.