The basic lifecycle
The sender enters a secret or selects a file. A well-designed service encrypts it before upload, stores the encrypted payload under a random locator, and produces a link. The recipient opens the link, the service authorizes one retrieval, and the recipient's browser decrypts the result.
Expiry is a second boundary. If nobody retrieves the Relay, the service should remove it after a short, known period. This is different from a normal cloud share, where access may remain until someone remembers to revoke it.
Why one-time links are useful
The biggest benefit is reducing persistence. A password pasted into email can be indexed, backed up, synchronized to multiple devices, exposed in notifications, and retained by corporate archives. A one-time link leaves the communication channel with a locator rather than the plaintext secret.
The model is especially useful for initial passwords, recovery codes, API tokens, private configuration fragments, small sensitive documents, and any information that is valuable briefly but dangerous indefinitely.
What one-time does not mean
It does not mean the recipient cannot copy the information. Once plaintext reaches a trusted recipient's device, they can save or photograph it. It also does not protect a device that is already compromised, and it does not prove who opened the link.
Email protection systems sometimes visit links automatically. A service can reduce scanner risk with a deliberate reveal step, but high-risk transfers should add a passphrase delivered through another channel.
A practical checklist
Before sending a one-time link, make the security decision explicit:
- Verify the recipient and the channel used to reach them.
- Choose the shortest realistic expiry.
- Add a strong, unique passphrase for high-impact secrets.
- Send the passphrase through a different channel.
- Keep a recoverable source copy until receipt is confirmed.
- Rotate credentials if the wrong person opens the link or the channel is compromised.