New employee passwords: a day-one handover checklist

The cleanest way to handle onboarding passwords for a new employee is to give them one credential, not a stack of them. That’s a temporary password for their identity provider account (Entra ID, Google Workspace, Okta), unique to them, which must be changed at first sign-in. Or better, a Temporary Access Pass that lets them set up a passkey or authenticator app and never have a password to forget. Everything else they need follows from that account: single sign-on for apps, and group membership for the password manager vaults that hold shared logins.

Deliver that one credential on the morning they start, by a route that leaves no copy behind, and enrol MFA before they do anything else. The rest of this page is the detail, then a checklist you can paste into your onboarding ticket.

Why one credential, delivered once

Every password sent separately to a new starter is another copy in another place: the welcome email, the Teams message from their manager, the spreadsheet HR keeps “just for the first week”. Each one is something to rotate if it leaks. With single sign-on and a password manager, the new starter needs exactly one secret from you. Everything else is access granted to their account, which you can also remove in one place when they leave.

Before day one

• HR confirms the details IT needs: start date, role, manager, and a verified personal phone number or email to use for identity checks on day one. Get these from the contract paperwork, not from a new email that claims to be from the starter.
• Create the account with sign-in blocked until the start date. An enabled account with a known temporary password, sitting idle for a week, is an easy target.
• Add them to role-based groups. Groups should grant the SSO apps and the password manager vaults or collections for their team, so nobody has to send them shared logins one by one.
• Prepare the device. Enrol it in Intune, Jamf or your MDM before it ships, so the first sign-in happens on a managed machine.
• Don’t generate the temporary credential yet. Create it on the morning, close to when it’s used.

Temporary passwords done properly

If you’re issuing a temporary password, it should be:

• Unique and random. Generated by the identity provider or your password manager, never a pattern like Welcome2026! or the company name plus the start date. Once one person knows the pattern, they know everyone’s, and NIST SP 800-63B’s advice to check passwords against lists of commonly used and expected values exists precisely to catch this.
• Changed at first sign-in. In the Microsoft 365 admin centre, tick “Require this user to change their password when they first sign in” (through Microsoft Graph, set forceChangePasswordNextSignIn). In Google Workspace, tick “Ask for a password change at the next sign-in”. Okta can send an activation email instead, which avoids the temporary password altogether.
• Delivered close to use. A temporary password created a week before the start date has a week to leak.

This is also what the guidance for control 5.17 (authentication information) in ISO/IEC 27002:2022 describes: temporary credentials unique to the person, delivered securely, changed on first use, and acknowledged by the person who receives them. If you’re working towards ISO/IEC 27001:2022, your onboarding ticket is the evidence.

Better: a Temporary Access Pass

If you use Entra ID, a Temporary Access Pass (TAP) is a time-limited passcode that lets the new starter sign in once and register a passkey, Windows Hello or Microsoft Authenticator. You can set it to expire within hours and to work only once. They never need a password to get started, and the thing you send is useless by lunchtime.

Google Workspace doesn’t have a direct equivalent. Use a temporary password with a forced change, and set a short new-user enrolment period for 2-Step Verification so the account isn’t left on password-only for long.

Delivering it on the day

For the remote case, set the link to one view and an expiry of a few hours. Choosing a link expiry explains why the shortest workable window is the right one. In ShareShield, you can email the link to the starter’s address and make it recipients-only, so whoever opens it has to confirm a code sent to that inbox, and an organisation policy can require a passcode on every secret.

The help desk is the weak point

A caller claiming to be a new starter who “never got their password” is one of the oldest routes into a company, and it still works: the widely reported 2023 attack on MGM Resorts began with a call to the IT help desk. Decide in advance how the help desk verifies a new starter (a call back to the number HR has on file, or the manager confirming on a video call), and never reset a credential on the strength of the caller knowing a name and a start date.

MFA in the first hour

Enrol MFA during the first sign-in, with someone available to help, not “some time in the first fortnight”.

• Require it from the first sign-in. Entra ID’s security defaults give users 14 days to register MFA. A Conditional Access policy or a TAP-based first sign-in closes that window.
• Prefer phishing-resistant methods. Passkeys and Windows Hello for Business, then an authenticator app with number matching. SMS codes only as a fallback.
• Register a second method, and store any backup codes in their password manager, so a lost phone doesn’t become a help desk reset.
• Let them set up the password manager themselves. They choose their own master password, which nobody else should ever know, and keep the recovery kit (1Password’s Emergency Kit, Bitwarden’s recovery code) somewhere safe.

Shared team logins

The new starter will need some shared credentials: the social media account, the supplier portal, the test login for the staging site. Grant them through password manager groups, so they appear in the starter’s vault. If there’s no password manager, send each credential as its own one-time link, and plan to replace the shared login with named accounts where the service allows it.

Never a “welcome pack” document with every password in it. It gets forwarded, printed and saved to the desktop, and it outlives the passwords’ owners. How to send a password securely covers the one-time link method in detail.

The checklist

Before day one:

• Start date, role, manager and verified contact details confirmed by HR
• Account created with sign-in blocked until the start date (and an end date for contractors)
• Role-based groups assigned: SSO apps and password manager vaults
• Device enrolled in MDM
• Help desk knows how to verify this person

On the morning:

• Sign-in unblocked
• Temporary Access Pass or unique random temporary password created
• Forced change at first sign-in set (for a password)
• Delivered in person, or by one-time link with the passcode by a second channel
• Starter confirms receipt

In the first hour:

• MFA enrolled, with a second method or backup codes
• Password manager set up with their own master password
• Shared logins visible through group access, none sent by email or chat
• Temporary credential confirmed expired or changed

When they eventually leave, the same structure makes offboarding shared credentials much shorter.