Two ways a note can die
When you create a secure note, you usually get two levers: destroy the note after it's read once, or destroy it after a fixed time window — say, 24 hours or 7 days. These sound like minor configuration details. They're not. Each one is a response to a different threat, and picking the wrong one can leave your secret exposed in exactly the situation you were trying to protect against.
What self-destruct actually does
A self-destructing note ceases to exist the moment someone opens it. The server deletes the ciphertext. The link goes dead. Anyone who follows that URL afterward gets nothing — not an error that reveals anything useful, just a gone note.
The security property here is confirmation of access. If you send a one-time link to a new employee with their temporary password, and the link is already dead when you check in with them, you know someone read it. Maybe them, maybe someone else who intercepted the link. Either way, you have a signal. That's more than you get from an email sitting in an inbox.
This is the right choice for anything that should be read once and acted on immediately: a temporary password, an API key being handed to a contractor, a door code, a recovery code. For a deeper look at the threat model around recovery codes specifically, see a practical threat model for sharing recovery codes.
What time-based expiration actually does
A time-limited note survives multiple reads until the clock runs out. After that, same result — the note is gone. But between creation and expiry, the link works as many times as someone follows it.
The security property here is availability within a bounded window. This matters when you're not sure when the recipient will be ready to read, or when you need them to reference the secret more than once during a workflow.
A real example: a sysadmin is provisioning a server over a two-hour window and needs to copy a database connection string to three different config files. A self-destructing note breaks that workflow on the first read. A note that expires in three hours doesn't.
Time-based expiration is also the right call when you're coordinating across time zones and can't predict exactly when the recipient will be online. You set a window that's long enough to be practical but short enough to limit exposure.
The threat each one leaves open
Here's the part most people skip past.
Self-destruct protects against future access — anyone who tries to read the link after the first open gets nothing. But it does nothing to protect against someone who reads it at the same time as the intended recipient, or who intercepts the link before it's opened. If a malicious proxy or a compromised email client fetches the URL to generate a preview, that's your one read gone — and the legitimate recipient gets a dead link with no idea why.
This is worth understanding. Link-preview fetching by mail clients and messaging apps is a real, documented behavior. Some apps follow every URL in a message to generate a thumbnail or check for malware. If your secret is in a self-destructing note and you send the link via a channel that does this, you've lost the note before the human ever sees it. The counter-move is to either use a passcode on the note (so the preview fetch hits an encrypted wall) or deliver the link out-of-band — a quick phone call, a separate message. The passcode-protected notes guide covers both the when and the how.
Time-based expiration, meanwhile, protects against secrets that linger indefinitely — but it leaves the note readable for its entire window. If the link leaks into a chat log or gets forwarded somewhere it shouldn't be, anyone who finds it during the active window can read it. The mitigation there is to set the shortest window that's actually practical, and to combine it with a passcode for anything sensitive.
The case for combining both
Most services let you layer these: a note that self-destructs on first read and expires in 24 hours if nobody reads it. This is usually the right default for one-time secrets. The read-once rule protects against repeated access; the time limit cleans up after a no-show (the contractor who never got the message, the hire whose start date got pushed).
The failure mode to watch for: setting a long expiry as a fallback and forgetting the note exists. A secret that times out in 30 days is a secret that can leak for 30 days. Keep the window tight. If the recipient misses it, you generate a new note — that's a feature, not an inconvenience.
Matching the setting to the scenario
- Temporary password for a new hire: self-destruct, short fallback expiry (24 hours). If they haven't read it by then, IT generates a new one. See the new hire onboarding post for a full breakdown of what secrets actually need this treatment.
- API key for a contractor mid-project: time-based expiry that covers their working window, plus a passcode. Self-destruct would interrupt legitimate repeated access.
- Database credentials for a one-off migration: self-destruct, delivered over a channel that doesn't preview links. Confirm receipt verbally before the migration starts.
- Legal document access code sent to a client: time-based expiry long enough for them to retrieve it at their convenience, passcode delivered by phone.
The pattern is simple: if the secret should be used once, self-destruct. If it needs to be referenced multiple times in a defined window, time-based. When in doubt, add a passcode. And never leave secrets in chat history as a fallback — that's not a plan, it's a future incident.
Try it before you next paste a password into Slack
The next time you're about to drop a credential into a message thread, take thirty seconds and compose a self-destructing note instead. Pick the expiry setting that fits the situation, add a passcode if the channel previews links, and send something that can't sit in a log forever.
