First-Day Passwords Are Still IAM's Soft Underbelly

Key points

• Temporary onboarding passwords are routinely delivered over SMS or corporate email, channels that are either unauthenticated or not yet secured for the new hire.
• Helpdesks under load tend to recycle predictable patterns, making starter credentials easy to guess once an attacker learns one.
• Binding a first login to a second factor before any session token is issued stops a leaked starter password being useful on its own.
• Temporary Access Pass flows in Microsoft Entra and Okta let new hires bootstrap a passwordless credential without a shared secret surviving the first session.

Why does onboarding keep showing up in breach forensics?

Onboarding is when IAM hygiene quietly collapses. A new hire needs a laptop, an email account, SSO (single sign-on) enrollment, a VPN profile, and access to whatever SaaS apps their manager remembered to request, all before 9 a.m. On day one. So IT does what IT has always done: provisions an account, sets a temporary password, and sends it over email or SMS.

That's where the attack surface opens up.

The credential itself is rarely the problem. The delivery channel is a different matter. SMS is unauthenticated by design, and corporate email at the point of onboarding is often the very mailbox the password is meant to open. If the new hire forwards it to a personal Gmail to read on their phone, and they do, the secret now lives in a consumer inbox protected by whatever password they picked years ago.

Then there's reuse. Helpdesks under load tend to recycle a pattern: Welcome2024!, Company@123, the office Wi-Fi name plus a symbol. Once one new starter learns the formula, so does every attacker who phishes one new starter. Pentest reports have recorded initial access vectors that came down to guessing the onboarding template.

Should you worry about passwordless alternatives?

The fix isn't exotic. Most identity teams already own the controls and don't enforce them together.

Force credential rotation on first authentication and make the temporary password single-use. Bind the first login to a second factor before granting any session token: a TOTP (time-based one-time password) enrollment or FIDO2 passkey registration during the initial flow stops a leaked starter password being useful on its own.

Better yet, skip the password entirely. Microsoft Entra and Okta both support Temporary Access Pass flows that issue a time-boxed, single-use code specifically for bootstrapping a passwordless credential. The new hire uses it once to register a passkey or Windows Hello, and the code dies. No shared secret survives the first session.

We've tracked the passkey space closely since June, and the tooling to do this without friction has genuinely matured. The blocker isn't technology.

The attacks that started with a leaked onboarding credential almost always relied on the temporary password still being valid weeks later, with no second factor attached, because nobody finished the enrollment flow and nobody chased it. As we reported on 3 June in "Identity Dark Matter", enterprise identity has fragmented badly enough that a growing slice of account activity sits outside what centralised IAM can even see, and orphaned onboarding credentials are exactly the kind of thing that falls into that blind spot.

That's an authentication problem dressed up as an HR problem.

If your onboarding runbook still ends at "send password to personal phone," it's not an onboarding process. It's a credential-leak pipeline with a calendar invite.