First-Day Passwords Are Still IAM's Soft Underbelly

Onboarding is when IAM hygiene quietly collapses.

A new hire needs a laptop, an email account, SSO enrollment, a VPN profile, and access to whatever SaaS apps their manager remembered to request. All of it has to land 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 to the new starter over email or SMS.

That's where the attack surface opens up.

The credential itself is rarely the problem. The delivery channel is. SMS is unauthenticated by design, and corporate email at the point of onboarding is often the very mailbox the password is meant to unlock. 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 in 2014.

Then there's reuse. Helpdesks under load tend to recycle a pattern: Welcome2024!, Company@123, the office Wi-Fi SSID plus an exclamation point. Once one new starter learns the formula, so does every attacker who phishes one new starter. I've seen pentest reports where the initial access vector was literally guessing the onboarding template.

The fix isn't exotic. It's three controls most identity teams already own and don't enforce together:

• Force credential rotation on first authentication, and make the temporary password single-use. NIST SP 800-63B section 5.1.1.2 has been clear on this for years.
• Bind the first login to a second factor before granting any session token. A TOTP enrollment or FIDO2 passkey registration during the initial flow stops a leaked starter password from being useful on its own.

Better: 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.

Would MFA have helped in the breaches that started with a leaked onboarding credential? Honestly, yes — almost every time. The attacks I've reviewed 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.

That's an authn 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.