1
One-time passwords and recovery codes
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.
2026-03-25
sharingWhat Is Message TTL and How to Set It Wisely
Message TTL is the expiry window on a secure link or encrypted message. Set it too short and work breaks; set it too long and sensitive data stays available far beyond its real usefulness.
Message TTL is a security decision, not a cosmetic setting
An expired link cannot be reopened, forwarded later, or rediscovered in an old thread. That makes TTL one of the simplest ways to reduce exposure.
What message TTL actually controls
Message TTL defines how long a secure link or encrypted message stays accessible before it expires permanently. In practice, that means TTL is not just a UX setting in a form. It is part of the access policy. Once the TTL window ends, the link should be useless even if someone still has the URL in email, chat history, or browser bookmarks.
That matters because many teams treat expiry as an afterthought. A password, payroll file, contract draft, or onboarding package gets sent through a secure link, but the expiry is left at a default chosen for convenience. The sender feels they used a secure tool, yet the real exposure window may still be far longer than the business need. If the recipient only needs the file today, a 30-day link is not a neutral default. It is a decision to keep that information available for 30 days.
The easiest way to think about message TTL is this: how long should a normal, legitimate recipient still be able to open the link if nothing unusual happens? That answer should come from the workflow, not from habit. A two-factor recovery code needed during a live call should have a very short TTL. A contract draft being reviewed across time zones needs longer. A board document that should only be available during one approval cycle needs a window aligned to that cycle and no more.
TTL is especially valuable because it limits the afterlife of a message. Old inboxes, forwarded threads, screenshots of links, copied chat history, and stale bookmarks are all common sources of accidental exposure. Encryption protects who can read the content while the link is alive. Message TTL reduces how long that opportunity exists at all.
If you want the broader exposure model, compare TTL with why email is often the wrong channel for sensitive data and why password-protected attachments fail in practice. In both cases, the hidden issue is usually not only who can access the material, but how long that access survives by default.
Rule of thumb
If the information is only useful for one meeting, one review cycle, or one handoff, the TTL should usually match that window rather than outlive it by weeks.
Most secure-sharing mistakes come from leaving sensitive links alive far longer than the legitimate workflow actually requires.
How to set message TTL for real workflows
The right message TTL depends on the tempo of the work, not on the abstract sensitivity label. A short-lived operational secret should expire quickly because the useful moment passes quickly. A slower review process can justify more time, but only if that time is genuinely needed. The common error is choosing one TTL for everything because it is administratively easy.
Minutes, not days. Use very short TTL windows for temporary passwords, recovery codes, deployment secrets, one-time payment approvals, or credentials handed over during a live conversation. If the recipient is already waiting, a long-lived link only creates unnecessary replay risk.
Hours or one to three days. This is often the sensible range for HR messages, salary discussions, contract markup, short review loops, and client-side document approval. People may need time to respond asynchronously, but they rarely need indefinite access after the task is complete.
Several days or a few weeks. Longer TTL windows can make sense for slower legal review, onboarding packets, or project documentation accessed once during a specific phase. Even here, the safer question is not whether a longer link is convenient, but whether the recipient still needs it after the phase ends.
A useful operational test is to ask what would happen if the link resurfaced in an old thread next month. If the answer is, “that would be fine,” then the information may not be especially sensitive or may belong in a different collaboration tool. If the answer is, “that would create confusion, overexposure, or a real incident,” then the TTL should be tightened now rather than after the fact.
For the most sensitive cases, TTL should be paired with burn-after-reading. Time-based expiry and first-open destruction solve two different problems. Burn-after-reading handles the case where the recipient opens the message quickly and no one should ever reopen it. TTL handles the case where nobody opens it, but the link should still die on its own. Together they create a much tighter exposure window than either control alone.
That is why message TTL is best treated as a workflow setting with security consequences. The goal is not simply to make links expire eventually. The goal is to make access disappear as soon as the legitimate business need ends.
Praktyczne scenariusze
How to match TTL to the real workflow
The biggest TTL mistake is not forgetting expiry. It is setting the same expiry for every kind of message regardless of how the information is actually used.
2
Async document review and HR workflows
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.
3
Small-team shared secrets
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.
4
Old links in inboxes and chats
Ask whether the link should still work if someone finds it in a thread next week or next month. If not, the TTL is too generous for the sensitivity of the material.
Najczęstsze pytania
Questions about TTL
- What happens to the message data when TTL expires?
-
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.
- Can I extend a TTL after sending the link?
-
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.
- Should I always set the shortest possible TTL?
-
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.
- Is TTL a substitute for encryption?
-
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.
Czytaj dalej
Więcej z kategorii sharing
sharing
Bezpieczny transfer plików: prywatna alternatywa dla WeTransfer
WeTransfer i podobne usługi mogą odczytać każdy plik, który wgrywasz. Oto kogo to dotyczy, dlaczego ma znaczenie i jak działa udostępnianie plików zero-knowledge.
Czytaj dalej
sharing
Co to jest TTL wiadomości i jak mądrze ustawić wygasanie linku
TTL wiadomości określa, jak długo bezpieczny link pozostaje aktywny. Zbyt krótki utrudnia odbiór, a zbyt długi niepotrzebnie wydłuża ekspozycję sekretu.
Czytaj dalej
sharing
5 sytuacji, kiedy e-mail to zły wybór dla poufnych danych
E-mail to zły wybór dla poufnych danych, bo przechowuje wiadomości i załączniki w obu skrzynkach bez realnej kontroli czasu dostępu. Te pięć scenariuszy pokazuje to najboleśniej.
Czytaj dalej