2026-04-16
Secure SharingTTL — Time To Live — is the expiry window on a secure message. Setting it wrong in either direction has real security consequences.
An expired link is an inaccessible link. TTL turns time itself into a security boundary.
TTL — Time To Live — is the duration after which a secure link becomes permanently inaccessible, regardless of whether it was ever opened. It is not just a convenience feature; it is a hard security boundary. An expired link cannot be opened, forwarded, or replayed — even if the URL is intact.
Short TTL (5–30 minutes) is the right choice for one-time credentials: temporary passwords, two-factor recovery codes, or API keys being handed off during a deployment call. The window is long enough for a real recipient in the same conversation, short enough to be useless if intercepted minutes later.
Medium TTL (24–72 hours) suits asynchronous workflows where the recipient may be in a different timezone or needs time to act: a contract draft to review, a salary figure shared with HR, or access credentials for a staging environment.
Long TTL (30–90 days) is appropriate for slower processes — legal document review, a new hire onboarding package, or a shared secret that a small team needs to access once during a project quarter.
The main mistake teams make is choosing TTL based on habit instead of exposure. If a secret is useful for 15 minutes but remains retrievable for 30 days, the real access policy is 30 days, not 15 minutes. TTL should mirror the operational lifetime of the information, not the convenience of the sender.
For any credential being actively used: combine TTL with burn-after-reading. Two independent destruction paths — time and first open — mean the secret cannot survive longer than necessary under either scenario.
Use cases
The main TTL mistake is not failing to use it. It is choosing it automatically, without mapping it to the actual lifetime of the information being shared.
If the recipient is waiting in the same conversation, choose minutes, not days. The secret is only useful for a brief step, so the access window should end as soon as that step is realistically complete.
For contract drafts, salary details, or onboarding files, hours or 1–3 days usually make more sense. The recipient needs working time, but there is rarely a good reason for the link to remain live for weeks.
If several people genuinely need the same secret during a project phase, let the TTL cover only that phase. Long-lived access without context quickly turns secure sharing into an accidental password archive.
Short-lived messages (≤24h) are stored in Redis with a native TTL — Redis deletes them automatically at expiry. Long-lived messages are stored in PostgreSQL and a cleanup job runs every hour to delete records where expires_at has passed.
No. The TTL is set at creation and cannot be modified. If the recipient needs more time, create a new secure link with a longer window.
Shortest-possible is the safest default, but only if it is realistic for your recipient. A link that expires before your recipient checks their messages defeats the purpose. Match TTL to your real-world communication pattern.
No. TTL limits how long a secret remains accessible. Encryption controls who can read it while it exists. Good secure sharing uses both: encryption for confidentiality and TTL for exposure reduction.
Keep reading
2026-04-24
WeTransfer and similar services can read every file you upload. Here's who that affects, why it matters, and how zero-knowledge file sharing works differently.
2026-03-28
Email was designed in 1971 to move text between terminals. It was never built for confidentiality — and these five scenarios make that painfully clear.
2026-03-20
A message that deletes itself after being read sounds like a spy film trope. Here's the technical reality — and why it's more reliable than you might think.