The first day problem
When a new employee starts, someone has to hand them the keys. A Wi-Fi password. A staging environment login. A shared inbox credential. An API key for the internal toolchain. Maybe a recovery code for the company's password manager, in case they get locked out.
In practice, these secrets usually travel by the path of least resistance: a Slack DM, a plain-text email, a sticky note photographed on a phone. The new hire reads them, saves them somewhere, and the originals sit in message history for months or years. If that account is ever compromised — theirs, or the person who sent the message — every secret they received on day one is suddenly in play.
This is not a hypothetical. It is the normal failure mode described in detail in what goes wrong when secrets sit in chat history forever. The fix is not complicated, but it requires a deliberate decision to do things differently.
The ten secrets a new hire typically receives
It helps to name them concretely, because "credentials" is vague enough that people underestimate the surface area:
- Corporate Wi-Fi passphrase (or VPN pre-shared key)
- Initial password for the identity provider (Okta, Google Workspace, Azure AD)
- Shared team inbox credentials, if the company hasn't moved to delegation yet
- Password manager invite plus the emergency recovery code
- Staging or dev environment login
- Internal tool API key (CI pipeline, monitoring dashboard, deployment tool)
- SSH key passphrase, if keys are provisioned centrally
- Shared social media or brand account passwords
- Backup codes for any MFA-protected account handed over on day one
- The master PIN or passphrase for a physical device, if relevant
Some of these will move to individual accounts once the hire is fully provisioned. But in the window between offer-acceptance and full setup — often a week or more — these shared credentials have to travel somehow.
Why a single one-time note per secret is better than a single onboarding document
The tempting approach is to compile everything into one document: a tidy onboarding checklist with all credentials in one place. Convenient to send. Catastrophic if intercepted, forwarded by mistake, or left sitting in a shared folder that the person who made it forgot to restrict.
A better pattern is one secret per note. This matters for a few reasons:
- Blast radius. If one link is forwarded, intercepted, or expires before the hire opens it, only that one credential is exposed. You re-send that one item, not rebuild the entire credential set.
- Auditability. You know exactly which secrets have been delivered and read. A note that has already self-destructed tells you the hire received it. A note that hasn't been opened after 24 hours is a signal to follow up.
- Revocation. If the hire doesn't start — offer rescinded, background check issue, whatever — you haven't already handed them a complete set of keys. Unread notes can be allowed to expire.
One-time notes are particularly well-suited to this compared to a shared password vault entry, because the vault keeps the secret alive indefinitely. The comparison between one-time links and password vaults is worth reading if you manage both — they solve different problems and work best together.
The right channel for the link, and a word about passcodes
A self-destructing, encrypted note is only as strong as the channel you use to deliver the link. Email is convenient but not great: it logs, it forwards, it archives. For most credential handoffs, a direct message in a system where you've verified the hire's identity is fine — the key question is whether you're confident the recipient is who you think they are.
For higher-value secrets, add a passcode to the note and send the passcode through a completely separate channel. The link goes by Slack; the passcode gets said out loud on a call, or sent by SMS to a phone number the hire confirmed in their offer paperwork. Now an attacker needs both — and the note destroys itself after one read anyway.
This same principle applies when sharing things like recovery codes, which carry their own threat model. The post on a practical threat model for sharing recovery codes walks through how to think about those specifically, including what happens after the recipient stores the code.
What to do after delivery
Self-destructing notes handle the transit problem. They don't handle what the new hire does next. A few practical steps that belong in any onboarding checklist:
- Require the hire to change any temporary password immediately after first login, before they do anything else.
- Log which secrets were sent as one-time notes, with timestamps, in your onboarding tracker — not the secret itself, just a record that it was transmitted.
- Rotate any credential the hire doesn't need long-term (like a temporary staging password) once they've set up their own access.
- If anything was shared as a stopgap — shared inbox password, team account credentials — put a calendar reminder to migrate those to proper per-user access within 30 days.
These steps aren't unique to this workflow, but they're easy to skip when onboarding feels like a scramble. The note self-destructs; the rotation often doesn't happen unless someone owns it explicitly.
A note on contractors versus full-time hires
Contractors create additional complexity because their access is scoped and time-limited by design. The secrets they receive on day one should be the minimum needed, and the offboarding checklist should mirror the onboarding one in reverse. The post on sharing API keys with a contractor without leaking them into shared docs covers the credential side of that relationship in more depth.
Try it before your next new hire starts
The next time you're putting together a day-one credential packet, try delivering each secret as a separate one-time note instead of a Slack message or a shared doc. Compose a note at SecureNotes — it takes about thirty seconds, requires no account, and means those credentials stop existing the moment your new hire reads them.
