✅
Phase 1 — Pre-Reactivation Checks
As soon as rehire is confirmed
1
Confirm HR Authorisation & Verify Start Date
ServiceNow
▼
💡 Why is this step needed?
Reactivating an account grants access to all the data and systems the employee had before they left — mailbox history, OneDrive files, group memberships, and application access. Doing this without formal HR authorisation creates a serious data governance and security risk. The ServiceNow New Joiner form is the official record that ties the IT action to an approved HR decision, ensuring there is an auditable paper trail if the rehire is later disputed or if data access is questioned.
| # | Action | Notes |
|---|---|---|
| 1 | Confirm the employee has been officially rehired by HR | Do not proceed on a verbal request alone |
| 2 | Locate the ServiceNow New Joiner form or HR request ticket | This must exist before any account changes are made |
| 3 | Note the confirmed start date | This governs when sign-in is re-enabled in Phase 4 |
| 4 | Record the approved job title, department, manager, and office location | Required for attribute updates in Phase 2 |
🛑 No HR Form — No Action
If a valid ServiceNow request does not exist, do not proceed. Return to the requestor and ask them to raise a formal ticket. Reactivating an account without authorisation is a potential data protection incident.
🔓
Phase 2 — Restore & Update the Account
After HR confirmation
2
Remove from "Disabled Mailboxes" Group & Enable Account
Intune + Entra ID
▼
💡 Why is this step needed?
When an employee leaves R&R, their account is placed in the "Disabled Mailboxes" Intune group, which applies termination-specific policies — typically restricting mailbox access, blocking mobile sync, and suppressing notifications. If the account is re-enabled without first being removed from this group, those termination policies will continue to apply and will conflict with the normal user experience. The Intune group removal must happen before the account is enabled to avoid a race condition between conflicting policies.
2.1 — Remove from Disabled Mailboxes group (Intune)
| # | Action | Notes |
|---|---|---|
| 1 | Open Microsoft Intune Admin Center | intune.microsoft.com |
| 2 | Navigate to Groups | |
| 3 | Locate the Disabled Mailboxes group | Search by group name |
| 4 | Remove the user from the group | Members tab → select user → Remove |
2.2 — Enable the user account (Entra ID)
| # | Action | Notes |
|---|---|---|
| 1 | Open Entra ID Admin Center | entra.microsoft.com |
| 2 | Search for the user account | Search by name, UPN, or employee ID |
| 3 | Open the user record and set Account Enabled = Yes | Properties tab → Edit → Account enabled toggle |
2.3 — Clear old authentication data
💡 Why clear MFA methods?
MFA methods registered by the user before they left — authenticator apps, phone numbers, FIDO keys — may be on devices the user no longer has access to, or may have been decommissioned. Leaving stale MFA methods causes sign-in failures during the Autopilot build process and forces the user to recover from an unknown MFA state on their first day. Clearing all methods gives the user a clean slate for re-registration.
| # | Action | Notes |
|---|---|---|
| 1 | In Entra ID, open the user record and navigate to Security → Authentication Methods | |
| 2 | Remove all existing MFA methods | Delete each registered method (Authenticator app, phone, email, etc.) |
ℹ Soft-Deleted Mailbox
If the user's mailbox was soft-deleted during the leaver process, it must be recovered before enabling sign-in. Navigate to Exchange Admin Center → Deleted mailboxes and restore it to the account. Attempting to re-enable an account with a soft-deleted mailbox can result in a new, empty mailbox being provisioned, losing all historical mail data.
3
Update User Attributes from the HR New Joiner Form
Entra ID / M365
▼
💡 Why is this step needed?
A rehired employee's role, department, or reporting line may have changed significantly since they left. Using stale attribute data causes problems across the entire Microsoft 365 estate — the Global Address List shows incorrect information, dynamic group memberships (which drive licence assignments, Conditional Access, and app access) may not update correctly, and Conditional Access policies that target specific departments or job titles may grant inappropriate access. All attributes must reflect the current, HR-approved role before the account goes live.
Job Title
From ServiceNow form
Department
From ServiceNow form
Manager
From ServiceNow form
Office Location
From ServiceNow form
Usage Location
Required for licence
Licence Assignment
Per role — if applicable
ℹ Allow Replication Time
After making major attribute changes, allow 20–30 minutes for backend replication across Microsoft 365 services before checking whether dynamic groups and licence assignments have updated correctly.
💻
Phase 3 — Lock & Build Before Start Date
Days before start date
4
Block Sign-In & Remove from MFA Enforcement Groups
M365 Admin Center
▼
💡 Why block sign-in before the start date?
The account has now been enabled and configured, but the employee's start date may still be days away. Blocking sign-in prevents premature access — the account should not be usable until the user physically collects their laptop and completes onboarding. This also prevents the account from being compromised in the window between restoration and day one, when no active monitoring or device posture is yet in place.
| # | Action | Notes |
|---|---|---|
| 1 | In Microsoft 365 Admin Center, open the user profile | admin.microsoft.com → Users → Active Users |
| 2 | Toggle Block sign-in: ON | The account is configured but inaccessible |
💡 Why remove from MFA enforcement groups?
During the Autopilot build in Step 5, an IT admin needs to sign in as the user using a temporary password to complete the Out-of-Box Experience (OOBE). If the account is in an MFA enforcement group, Conditional Access will require MFA during this sign-in — but no MFA methods have been registered yet (they were cleared in Step 2.3). Removing the user from MFA groups temporarily allows the Autopilot build to complete without an MFA prompt that cannot be satisfied.
| # | Action | Notes |
|---|---|---|
| 3 | In Entra ID, remove the user from any MFA enforcement groups | e.g. CA-MFA-AllUsers or similar Security Group–based MFA groups |
| 4 | Confirm the user is not targeted by any active MFA Conditional Access policies | Check Entra ID → Security → Conditional Access |
5
Generate Temporary Password & Build Device via Autopilot
Entra ID + Device
▼
💡 Why build the device before day one?
Autopilot provisioning — enrolling the device, applying baseline policies, installing applications, and loading the user profile — can take 30–90 minutes or more depending on the number of required applications. Completing this process in advance means the user receives a ready-to-use device on day one rather than sitting waiting for their laptop to build while policies and apps download. A good first-day experience significantly improves onboarding satisfaction and productivity.
5.1 — Generate temporary password for build
| # | Action | Notes |
|---|---|---|
| 1 | In Entra ID or M365 Admin Center, generate a temporary password for the account | |
| 2 | Ensure "Require password change at next sign-in" is UNCHECKED | If checked, Autopilot will fail at OOBE — the forced change prompt cannot be completed during the build |
5.2 — Build the laptop via Autopilot
| # | Action | Notes |
|---|---|---|
| 1 | Power on the device and proceed through the Out-of-Box Experience (OOBE) | Autopilot will intercept and redirect to the R&R deployment profile |
| 2 | Sign in with the user's UPN and temporary password | No MFA prompt should appear (MFA groups removed in Step 4) |
| 3 | Allow Autopilot to complete — loading user profile, baseline apps, and Intune configurations | Do not interrupt the build process |
| 4 | Once the build completes, do not allow further sign-in to the device | The device is now ready for the user — no additional IT sign-in needed |
⚠ Autopilot Profile Must Exist
The device must have a valid Autopilot deployment profile assigned before beginning the build. If the device is new or was not previously Autopilot-registered, register it first via the Intune Admin Center → Enrolment → Autopilot → Devices → Import.
6
Secure the Account After Build Completion
M365 Admin Center
▼
💡 Why re-lock the account after the build?
The temporary password used during Autopilot is known to IT and was used to sign in to the device. Once the build is complete, the account must be immediately re-secured to prevent any unauthorised sign-in using that temporary password before the user collects their device. This window — between build completion and day one — is a potential vulnerability if not closed.
| # | Action | Notes |
|---|---|---|
| 1 | Return to Microsoft 365 Admin Center → Block sign-in: ON | Re-block immediately after build completes |
| 2 | Enable "Require password change at next sign-in" | User will be forced to set their own password when they first log in on day one |
| 3 | Do NOT add the user back to MFA groups yet | MFA re-registration happens at device collection — not before |
ℹ Why not add MFA yet?
MFA registration requires the user to be physically present with their device and phone. Adding them to MFA groups before device collection means any sign-in attempt between now and day one would be blocked by an unsatisfiable MFA prompt. MFA is added in Step 7 — at the point of handover.
🎉
Phase 4 — Start Date & Device Handover
On the user's first day
7
Unlock Account, Issue Password & Complete MFA Registration
M365 + Handover
▼
💡 Why do all three sub-steps happen together?
The sign-in unblock, MFA group addition, and password handover must happen in sequence during the device collection meeting. Unblocking sign-in without adding the user to MFA groups means they can log in without MFA — a security gap. Adding to MFA groups before unblocking means if the user tries to sign in early, they will be blocked by an unsatisfied MFA prompt. Doing all three steps at the moment of physical handover ensures the user has everything they need to complete sign-in, set their password, and register MFA in one sitting.
7.1 — Issue a new temporary password
| # | Action | Notes |
|---|---|---|
| 1 | Generate a new temporary password in M365 Admin Center | Different from the Autopilot build password |
| 2 | Provide this password to the user in person during the handover meeting | Do not send via email to an external address |
7.2 — Unblock sign-in & add to MFA groups
| # | Action | Notes |
|---|---|---|
| 1 | In M365 Admin Center, toggle Block sign-in: OFF | Do this immediately before handing over the device |
| 2 | In Entra ID, add the user back to MFA enforcement group(s) | The same groups they were removed from in Step 4 |
7.3 — User logs in and completes setup
| # | Action | Notes |
|---|---|---|
| 1 | User signs in with the temporary password | |
| 2 | User is prompted to change their password | Enforced by the setting applied in Step 6 |
| 3 | User is prompted to register MFA | Triggered by Conditional Access targeting the MFA group |
| 4 | Device becomes fully operational | Compliance and CA policies will apply on next sync |
🔍
Phase 5 — Post-Activation Validation
After handover
8
IT Verification Checks
All portals
▼
💡 Why is post-activation verification needed?
Reactivating an account touches multiple interconnected systems — Entra ID, Exchange, Intune, SharePoint, Teams. A successful sign-in does not guarantee all services are correctly provisioned. Licence propagation delays, stale group memberships, or residual termination policies can leave individual services unavailable even when the account appears healthy. Running through the verification checklist ensures the account is fully functional across every platform before the user raises a support ticket.
Mailbox accessible — user can send and receive email in Outlook
Licences applied — correct M365 licences showing in Entra ID
Device in Intune — appears under Devices with correct user and compliance state
Conditional Access policies applied — no legacy termination CA rules blocking access
MFA registered — user's MFA methods confirmed in Entra ID → Authentication Methods
Teams sign-in successful — user can access Teams, channels, and meetings
SharePoint & OneDrive accessible — prior files are visible and accessible
✔ All Checks Passed
Once all seven verification items are confirmed, update the ServiceNow ticket with completion timestamps and close the request. The reactivation is complete.
Notes & Best Practices
9
Best Practices & Common Pitfalls
Reference
▼
Soft-deleted mailbox — If the mailbox was soft-deleted during offboarding, recover it from Exchange Admin Center → Deleted Mailboxes before enabling the account. Otherwise a new empty mailbox is created and historical data is lost.
Conflicting CA rules — Check for any residual Conditional Access rules targeting terminated or inactive accounts (e.g. a "Block leaver" named location or device state policy). These may still apply and block the user post-reactivation.
Autopilot profile — Ensure a valid Autopilot deployment profile exists and is assigned to the device or the user's group before starting the build. A missing profile causes OOBE to proceed as a standard Windows setup, bypassing Intune enrolment.
Replication delay — Allow 20–30 minutes after major attribute changes (department, licences, group memberships) before verifying downstream effects in Teams, SharePoint, and dynamic groups.