“Drop the credentials in the work chat. We'll delete them later.” A complete .env lands in Slack, an admin password goes into Telegram, and a database connection string ends up in Jira or email. The task is finished. The secret isn't.
Six months later, a contractor loses an email account or messenger session. Conversation history becomes a searchable archive: password, api_key, root, .env, or the equivalent in another language. That history can help an intruder locate old credentials.
A one-time link reduces that archive; it doesn't replace access management. Where possible, give each person an individual account with the minimum necessary permissions. Encryption doesn't justify sharing a root password. For a one-off handoff, use a password-protected link and deliver the password separately. If you set the temporary password yourself, use the local password generator rather than a name-and-date pattern.
The golden rule: separate context from the secret
The context message might say: “Staging environment: staging.example.com, user: deploy_user.” The encrypted note contains only a random password, such as xK9#mP2$vL.... Don't reuse that example. Don't put the service address, username and secret together in one unprotected message.
There's a catch, though. Put the context beside a complete decryption link in the same chat, and someone with that history can reconnect them. Removing context from the note merely reduces clues; a token's format may reveal its provider anyway.
Split-channel delivery uses genuinely different communication paths. Split-link separates the ciphertext URL from its decryption key. Send the link through Telegram and deliver the key through another agreed channel after verifying the recipient. Two consecutive messages in the same conversation don't provide that separation.
Internal hostnames and usernames can be sensitive too.
A six-step checklist before sharing access
- 1Remove unnecessary context. Include only the password, token or required variables. A full
.envmay containDATABASE_URL, usernames, hosts and unrelated secrets. It isn't context-free just because it's a configuration file. Prepare the smallest useful subset and check comments before sending. Secure Link accepts text: paste the required lines rather than sending a project archive. - 2Choose one view: a digital seal. This limits retrieval and can reveal unexpected consumption. If the intended recipient finds an empty note, pause and investigate. Expiration, an accidental visit or a scanner may explain it; an empty link isn't proof an attacker read the secret. Treat unexplained access as potential exposure: revoke or replace the credential, then generate another link.
- 3Set a task-sized TTL. If the recipient is online, 15–60 minutes is often enough; use a custom lifetime rather than a week “just in case.” Agree on timing first. Expiring the link removes the note, not the credential from the destination system. If the recipient misses the window, issuing another link is preferable to leaving a longer window by default.
- 4Split the key or add a separate password. For sensitive server credentials, use independent channels. Deliver any additional passphrase separately too. Burn-on-Failure consumes remaining views after failed attempts in the standard client. This isn't automatically two-factor authentication, nor a substitute for a strong passphrase: two knowledge-based secrets don't become different authentication factors simply because there are two of them.
- 5Enable screen clearing after 30–60 seconds. Secure Link offers 30-, 60- and 120-second timers; the shorter options suit a brief password handoff. Clearing the display reduces the chance of leaving a secret visible during screen sharing or on an unattended laptop. It cannot undo screenshots, recordings or copies already made. Tell the recipient how quickly the text will disappear.
- 6Finish with a change or revocation plan. Use a temporary password with a forced change at first login where supported. Scope API keys to the required permissions and task lifetime; rotate or revoke them through your agreed process, accounting for applications that depend on them. Don't break an integration with an unannounced key change. Deleting the note doesn't complete the credential's lifecycle.
Four everyday handoffs
Confirm unexpected requests through an established contact. A familiar name or avatar—or “I'm on a new account”—isn't sufficient verification.
| What you're sharing | A practical delivery pattern |
|---|---|
| Admin / CMS password for a client | Send the username and instructions to agreed email, then a one-view password link through a messenger. Use a 24-hour TTL only when delayed opening is necessary; otherwise shorten it. |
.env variables or a developer API key | Share the minimum text, add a separately delivered password and Burn-on-Failure, and use one view with roughly a one-hour TTL. Don't attach the whole project. |
| Root access, a private key or a recovery phrase | Prefer an individual server account and a public SSH key. Don't submit recovery phrases to web forms. For a justified handoff of another server secret, use Split-link through independent channels and a 30-second display timer. |
| A handoff involving device-inspection risk | Decoy Mode provides a real password and a harmless decoy password. It's an additional option, not a guarantee of safety under coercion. |
Keep private SSH keys on their owner's device; public keys are normally used to grant access. A recovery phrase restores control of a wallet, so a self-destructing link doesn't make sharing it with “support” or a contractor appropriate. Follow the manufacturer's recovery procedure instead.
Three mistakes that undermine the handoff
- Sending a screenshot. It can remain in the photo library and sync to iCloud Photos or Google Photos if syncing is enabled. OCR can extract the text. A password image isn't encryption, and deleting the chat message may leave other copies intact.
- Sending an archive and its password in the same chat. Someone with that conversation gets both. The archive may be properly encrypted; the delivery channels still aren't separated.
- Trusting the self-destruct label alone. Check when a view is consumed and what third-party scripts run. Secure Link preserves notes during ordinary HTML previews, but JavaScript-capable clients may initiate reading. A password form alone doesn't guarantee deferred retrieval.
Keep the permissions and expiry agreement, not the secrets. For ongoing team access, use managed secrets storage: a one-time note is a handoff tool.