[2.2.2] Privileged Identity Management: Architecture and Build Guide

This guide documents the architecture, configuration, and deployment of Privileged Identity Management across a Microsoft Entra tenant. It is an internal methodology document covering break glass account setup, authentication context design, Conditional Access policy construction, PIM group structure, and role activation settings.

A note on where this sits. This article remains the Intune-context entry point to Privileged Identity Management and is still accurate for what it covers. The canonical, current treatment now lives in the Governance guide, which goes considerably deeper and is up to date on the April 2026 arrival of Conditional Access enforcement on activation, a change that makes the on-activation controls described here materially stronger than they were when this was written. Start at [PIM 1] Privileged Identity Management: The End of Standing Privilege, or browse the whole wave from the Governance guide.

Section 1 – Design Principles and Scope

This guide does not replace tenant-specific review. Every environment has existing CA policies, group structures, and identity configurations that must be assessed before any of the following steps are applied. The engineer following it is expected to have working familiarity with Entra ID, Conditional Access, and basic PIM concepts.

Cloud-Only Admin Identities

Admin roles in Entra ID must be assigned to cloud-only accounts. This is a security boundary, not a preference.

A synced account originates in on-premises Active Directory. Its lifecycle, credential, and security posture are controlled by the on-premises environment. If that environment is compromised – through credential theft, a ransomware event, or a directory services attack – any synced account holding an active Entra admin role becomes a direct path into the cloud tenant. Global Administrator authority should never be reachable through an on-premises attack vector.

Domain Admins do not become Global Admins. Engineers who hold both on-premises and cloud responsibilities maintain separate identities for each plane.

The cloud admin account is created directly in Entra ID, never synced from AD, and has no on-premises counterpart. Its credentials, MFA registration, and authentication methods are entirely cloud-managed. This applies consistently across all roles in this guide. Where an organisation already has synced accounts holding admin roles, that is a remediation item to track and resolve – not a configuration to work around.

Standing Roles for Cloud Admin Accounts

Admin accounts created for this guide should have one standing active role at rest – Global Reader. This gives the account read-only visibility across the tenant for routine investigative and review work without requiring a PIM activation just to look at a user, a policy, or a sign-in log. The blast radius of a compromised Global Reader account is near zero – it cannot make changes to anything.

For admins who work regularly in Defender or Purview, Security Reader is also acceptable as a standing role. Read-only access to security data and alerts does not warrant an activation gate.

A cloud admin account at rest should look like this: Global Reader active and permanent, everything else eligible. If an engineer finds themselves activating so frequently that it becomes friction, the answer is to review whether the activation window duration is appropriate – not to convert a role to a permanent assignment.

Licensing

Every cloud admin account in this guide requires a Microsoft Entra ID P2 license. P2 is required for PIM eligibility and activation, authentication context enforcement, Identity Protection, and Access Reviews. It applies only to the admin accounts themselves – not to end users.

P2 is included in Microsoft 365 E5, but we recommend against repurposing E5 licenses from your user pool to cover admin accounts. Admin accounts do not need Exchange, Teams, SharePoint, or any of the other workloads bundled into E5. Assigning a full E5 to an account that only needs identity security controls adds unnecessary cost and licensing complexity. The cleaner approach is a small number of standalone Entra ID P2 licenses assigned specifically to the admin accounts.

Role Tiers

This guide implements two tiers of privileged access.

Standard Elevated covers Intune Administrator and Exchange Administrator. Activation requires re-authentication with any compliant MFA method. Maximum activation duration is 8 hours. Justification required.

Protected covers Global Administrator, Compliance Administrator, and Security Administrator. Activation requires re-authentication with a phishing-resistant method – FIDO2 hardware key or Windows Hello for Business. Maximum activation duration is 2 hours. Justification required.

Section 10 covers how to extend this model to additional roles.

Section 2 – Break Glass Accounts

Break glass accounts exist outside every control documented in this guide. They are permanent, always-active Global Administrators that bypass PIM, Conditional Access, and MFA enforcement. They exist for one reason: if a misconfigured CA policy, a broken PIM configuration, or a lost authentication method locks every other admin out of the tenant, these accounts get you back in.

Break glass accounts are not used for day-to-day administration under any circumstances.

2.1 – Verify Licensing

Before creating any objects, confirm that Microsoft Entra ID P2 licensing is available in the tenant and that there are enough available seats to cover all admin accounts that will be created in this guide.

Navigate to Entra admin center > Billing > Licenses > All products and confirm that Entra ID P2 or an equivalent SKU (M365 E5, Business Premium, or Entra ID Governance) is present with available seats.

📸 [Screenshot: License overview showing Entra ID P2 available seats]

If P2 is not present, stop here. Nothing in this guide can be implemented without it. Every account that will hold eligible role membership – including all admin accounts created in this guide – must have a P2 license assigned before being added to any PIM group.

2.2 – Create the Break Glass Accounts

Create both accounts using the tenant’s .onmicrosoft.com domain. Do not use a custom domain. Custom domains depend on DNS and federation configuration – the .onmicrosoft.com domain is always available regardless of what else breaks in the tenant.

Suggested naming:

[email protected]
[email protected]

Navigate to Entra admin center > Users > All users > New user > Create new user. Configure each account as follows:

User principal name: [email protected]
Display name: Break Glass Account 1
Password: Auto-generate. Copy and store immediately as described in 2.5.
Account enabled: Yes

Repeat for breakglass2.

📸 [Screenshot: New user creation form with breakglass1 populated]

2.3 – Assign Permanent Global Administrator

Both accounts require a permanent, always-active Global Administrator assignment. This is not an eligible assignment via PIM – it is a direct, active role assignment with no expiry.

Navigate to Entra admin center > Roles and administrators > Global Administrator > Add assignments. Select breakglass1, set assignment type to Active, and set duration to Permanently active. Repeat for breakglass2.

📸 [Screenshot: PIM assignment screen with Active and Permanently active selected]

Confirm both accounts appear in the Global Administrator role with type listed as Active and no expiry date.

2.4 – Create the Break Glass Exclusion Group

This group is the exclusion target for every Conditional Access policy in this guide and in the VCIO CA Framework. Any CA policy that does not exclude this group is a liability – if it misfires, break glass is also blocked.

Navigate to Entra admin center > Groups > New group. Configure as follows:

Group type: Security
Group name: CA-BreakGlassAccounts - Exclude
Membership type: Assigned

Add both break glass accounts as members.

📸 [Screenshot: Group creation with both breakglass accounts as members]

2.5 – Password Storage

Generate a strong password for each account – 40+ characters, fully random. Store each password in two offline locations. Printed and sealed in separate physical envelopes is the standard recommendation. One copy on-site with the appropriate custodian, one off-site or in a secured physical safe.

Do not store break glass passwords in a password manager, Key Vault, or any system that requires cloud authentication to retrieve. If the reason you need break glass is that cloud auth is broken, a cloud-stored password is inaccessible.

Document the custodian name and storage location in your internal CMDB or security register – not in this document.

2.6 – FIDO2 Key Registration (Break Glass)

Register a FIDO2 hardware key on each break glass account as a secondary authentication method. This is defence-in-depth, not a hard requirement – because both accounts are excluded from all CA policies, either the password or the FIDO2 key is sufficient to authenticate. No policy will enforce a specific method against these accounts.

To register the key, sign in as the break glass account, navigate to https://mysignins.microsoft.com/security-info, select Add sign-in method, choose Security key, and follow the FIDO2 registration flow. Store the physical YubiKey in the same sealed envelope as the password for each respective account. Whoever retrieves the envelope in an emergency has both methods available.

📸 [Screenshot: Security info page showing password + FIDO2 key as registered methods]

# PowerShell - Confirm FIDO2 method registered
Get-MgUserAuthenticationFido2Method -UserId "[email protected]"

2.7 – Monitoring

Break glass accounts must be monitored for any sign-in activity. Any authentication event against either account should trigger an immediate alert. Alert configuration is covered in the Azure Monitor and Entra diagnostic settings build guide. At minimum, a sign-in alert scoped to both break glass UPNs should be in place before the CA policies in Section 4 are enabled.

Section 3 – Authentication Contexts

Authentication contexts are named markers that a Conditional Access policy listens for. When a supporting application or workflow – such as PIM role activation – triggers a specific context, any CA policy scoped to that context fires and enforces its conditions against the authenticating user. The context itself enforces nothing. It is a signal. The CA policy attached to it does the actual work.

This guide creates two authentication contexts – one per role tier. Keeping them separate means each CA policy has a single, unambiguous trigger. There is no scenario where a standard elevated activation could accidentally fire the protected tier enforcement, or vice versa.

3.1 – Create the Standard Elevated Authentication Context

Navigate to Entra admin center > Protection > Conditional Access > Authentication contexts > New authentication context. Configure as follows:

Name: Re-Authentication - Standard Elevated
Description: Requires re-authentication at PIM activation for standard elevated roles. Any compliant MFA method accepted.
Publish to apps: Enabled

📸 [Screenshot: Authentication context creation form populated for standard elevated]

# PowerShell - Create standard elevated context
New-MgIdentityConditionalAccessAuthenticationContextClassReference `
  -Id "c1" `
  -DisplayName "Re-Authentication - Standard Elevated" `
  -Description "Requires re-authentication at PIM activation for standard elevated roles. Any compliant MFA method accepted." `
  -IsAvailable $true

3.2 – Create the Protected Role Authentication Context

Navigate to Entra admin center > Protection > Conditional Access > Authentication contexts > New authentication context. Configure as follows:

Name: Re-Authentication - Protected Roles
Description: Requires re-authentication at PIM activation for protected roles. Phishing-resistant MFA required – FIDO2 or Windows Hello for Business only.
Publish to apps: Enabled

📸 [Screenshot: Authentication context creation form populated for protected roles]

# PowerShell - Create protected role context
New-MgIdentityConditionalAccessAuthenticationContextClassReference `
  -Id "c2" `
  -DisplayName "Re-Authentication - Protected Roles" `
  -Description "Requires re-authentication at PIM activation for protected roles. Phishing-resistant MFA required - FIDO2 or Windows Hello for Business only." `
  -IsAvailable $true

📸 [Screenshot: Authentication contexts list showing both contexts created and published]

3.3 – Additional Contexts for Future Use

The following contexts are not part of this guide but represent logical extensions of this architecture as the environment matures: Phishing-Resistant MFA, Compliant Device variants, Passkey (FIDO2), Privileged Access Workstation, and Windows Hello for Business. These can be created using the same process above when needed.

Section 4 – Conditional Access Policies

This section creates two CA policies. CA150 enforces re-authentication with standard MFA at activation for standard elevated roles. CA151 enforces re-authentication with phishing-resistant MFA at activation for protected roles. Both policies are scoped to authentication contexts – meaning they fire only when PIM triggers the relevant context during role activation, not during general sign-in. Both policies must be set to On – not Report-only.

Both policies exclude the CA-BreakGlassAccounts - Exclude group. These policies sit in the 150 block, extending the VCIO CA Framework’s Admins (Privileged) persona range without conflicting with its 100-series baseline.

4.1 – CA150: Standard Elevated Re-Authentication

Navigate to Entra admin center > Protection > Conditional Access > New policy.

Name: CA150-VCIO-Privileged-PIMActivation-ReAuthentication

Users: Include: All users – Exclude: CA-BreakGlassAccounts - Exclude

Target resources: Select Authentication context – Choose Re-Authentication - Standard Elevated

📸 [Screenshot: Target resources scoped to Re-Authentication – Standard Elevated]

Grant: Grant access – Require Authentication strength – Choose Multifactor authentication

Session: Sign-in frequency: Every time

Enable policy: On – not Report-only. Save.

📸 [Screenshot: CA150 policy summary view showing all configured conditions]

4.2 – CA151: Protected Role Re-Authentication with Phishing-Resistant MFA

Navigate to Entra admin center > Protection > Conditional Access > New policy.

Name: CA151-VCIO-Privileged-PIMActivation-PhishingResistantMFA

Users: Include: All users – Exclude: CA-BreakGlassAccounts - Exclude

Target resources: Select Authentication context – Choose Re-Authentication - Protected Roles

📸 [Screenshot: Target resources scoped to Re-Authentication – Protected Roles]

Grant: Grant access – Require Authentication strength – Choose Phishing-resistant MFA

Session: Sign-in frequency: Every time

Enable policy: On – not Report-only. Save.

📸 [Screenshot: CA151 policy summary view showing all configured conditions]

4.3 – Confirm Both Policies Are Active

Navigate to Entra admin center > Protection > Conditional Access > Policies and confirm both CA150 and CA151 are listed with state On. A policy in Report-only mode is being evaluated but not enforced – it will not challenge users during PIM activation.

📸 [Screenshot: CA policies list showing CA150 and CA151 both enabled and set to On]

# PowerShell - Confirm CA policy states
Get-MgIdentityConditionalAccessPolicy | 
  Select-Object DisplayName, State | 
  Where-Object DisplayName -like "CA15*"

4.4 – Relationship to Existing Baseline Policies

CA150 and CA151 layer on top of the VCIO CA Framework’s 100-series Privileged policies – they do not replace them. Those policies – particularly CA100, which requires phishing-resistant MFA for admin roles, and CA101, which requires a compliant device – target users who currently hold an active admin role and enforce controls during general sign-in and app access. They fire based on role membership during normal sign-in.

CA150 and CA151 fire only at the moment of PIM activation, triggered by the authentication context that PIM sends. They do not affect general sign-in at all. For a standard elevated admin, the framework’s 100-series – CA100 phishing-resistant MFA and CA101 compliant device – applies to their general app access, and CA150 additionally fires at activation. For a protected role admin, the same baseline applies, and CA151 fires on top requiring fresh phishing-resistant authentication at activation.

Because this model uses PIM groups rather than direct role assignment, most admins hold no active role outside of an activation window. Outside that window they are regular users from the framework’s perspective – which reduces the attack surface the 100-series policies have to cover continuously.

Section 5 – YubiKey Onboarding

FIDO2 hardware keys are required for all accounts that will hold eligible membership in protected tier roles – Global Administrator, Compliance Administrator, Security Administrator, and any role added to the protected tier in the future. CA151 requires phishing-resistant authentication at activation, and a YubiKey or Windows Hello for Business is what satisfies that requirement. An account without a registered FIDO2 key or WHfB will fail activation for any protected role.

Standard elevated role accounts do not require a hardware key. Any compliant MFA method satisfies CA150.

5.1 – Prerequisites

Navigate to Entra admin center > Protection > Authentication methods > Policies, select FIDO2 security key, and confirm it is enabled with target admin accounts in scope. Confirm the admin account being enrolled is cloud-only. A YubiKey 5 series key is the standard recommendation – confirm the key model matches the connection type on the admin’s device.

📸 [Screenshot: FIDO2 security key policy enabled in authentication methods]

5.2 – Register the YubiKey

The admin account holder performs this step themselves – the registration flow requires authenticating as the account owner. Sign in at https://mysignins.microsoft.com/security-info, select Add sign-in method, choose Security key, and select USB device. Insert the key, allow browser access, touch the key when the light flashes, and set a PIN. Name the key recognisably – for example YubiKey5C-[AdminName].

📸 [Screenshot: Security info page showing registered FIDO2 key with display name]

# PowerShell - Confirm FIDO2 key registered
Get-MgUserAuthenticationFido2Method -UserId "[email protected]" | 
  Select-Object DisplayName, CreatedDateTime, AaGuid

5.3 – Register a Backup Key

Every protected role account holder must have a second YubiKey registered as a backup. Repeat 5.2, naming it YubiKey5C-[AdminName]-Backup. Store the backup separately from the primary – never co-located.

5.4 – Lost Key Procedure

Navigate to Entra admin center > Users > [affected account] > Authentication methods. Locate the lost key by display name and delete it immediately. The backup key remains active while a replacement is sourced. Document lost key events in your internal security register.

# PowerShell - Remove a specific FIDO2 key
$keyId = (Get-MgUserAuthenticationFido2Method -UserId "[email protected]" | 
  Where-Object DisplayName -eq "YubiKey5C-AdminName").Id

Remove-MgUserAuthenticationFido2Method `
  -UserId "[email protected]" `
  -Fido2AuthenticationMethodId $keyId

5.5 – WHfB as an Alternative

Windows Hello for Business satisfies the phishing-resistant MFA requirement in CA151. The limitation is device dependency – WHfB is bound to a specific device. A YubiKey travels with the person. For protected roles, a registered FIDO2 key should always be present regardless of whether WHfB is also enrolled.

Section 6 – PIM Group Naming and Creation

PIM for Groups is the mechanism that connects a user’s eligible access to an Entra role without assigning the role directly to the user. The group is permanently assigned to the Entra role as an active member. The user holds eligible membership in the group via PIM. When the user activates, they gain group membership, which grants the role. When activation expires, membership is removed and the role is gone. Every role in this guide gets its own dedicated PIM group – groups are never shared across roles.

6.1 – Naming Convention

All PIM groups follow this naming pattern: pimGroup.RoleAssigned.[EntraRoleName]

Entra Role	PIM Group Name
Intune Administrator	`pimGroup.RoleAssigned.IntuneAdministrator`
Exchange Administrator	`pimGroup.RoleAssigned.ExchangeAdministrator`
Global Administrator	`pimGroup.RoleAssigned.GlobalAdministrator`
Compliance Administrator	`pimGroup.RoleAssigned.ComplianceAdministrator`
Security Administrator	`pimGroup.RoleAssigned.SecurityAdministrator`

6.2 – Create the PIM Groups

Each group must be created as a role-assignable security group. This setting cannot be changed after creation – the group must be created correctly the first time. Create one group per role.

Navigate to Entra admin center > Groups > New group. Configure as follows:

Group type: Security
Group name: pimGroup.RoleAssigned.[RoleName]
Microsoft Entra roles can be assigned to the group: Yes – this must be enabled at creation and cannot be changed later
Membership type: Assigned
Owners: Assign at least one owner
Members: None at creation

📸 [Screenshot: New group creation form with role-assignable toggle enabled]

# PowerShell - Create a role-assignable PIM group
New-MgGroup `
  -DisplayName "pimGroup.RoleAssigned.GlobalAdministrator" `
  -Description "PIM activation group for Global Administrator. Members hold eligible role access via PIM." `
  -SecurityEnabled $true `
  -MailEnabled $false `
  -MailNickname "pimGroup-RoleAssigned-GlobalAdministrator" `
  -IsAssignableToRole $true

Repeat for all five groups before proceeding.

6.3 – Assign Each Group to Its Entra Role

Navigate to Entra admin center > Roles and administrators > [Role Name] > Add assignments.

Select member: The corresponding PIM group
Assignment type: Active
Duration: Permanently active

📸 [Screenshot: Role assignment screen with PIM group as permanent active member]

Role	Group
Global Administrator	`pimGroup.RoleAssigned.GlobalAdministrator`
Compliance Administrator	`pimGroup.RoleAssigned.ComplianceAdministrator`
Security Administrator	`pimGroup.RoleAssigned.SecurityAdministrator`
Intune Administrator	`pimGroup.RoleAssigned.IntuneAdministrator`
Exchange Administrator	`pimGroup.RoleAssigned.ExchangeAdministrator`

6.4 – Confirm Group Role Assignments

Navigate to Entra admin center > Roles and administrators and verify each role shows its corresponding PIM group as a permanent active member. No users should be directly assigned to any of these roles – the group is the only member. If any users hold direct permanent active assignments, refer to Section 11 – Remediating Existing Direct Role Assignments.

📸 [Screenshot: Role members view showing only the PIM group as permanent active member]

6.5 – Onboard Groups to PIM

Creating a role-assignable group and assigning it to an Entra role does not automatically place it under PIM management. Each group must be explicitly discovered and onboarded before activation settings can be configured and eligible members can be added. Without this step the groups will not appear in PIM > Groups at all.

Navigate to Entra admin center > Identity Governance > Privileged Identity Management > Groups > Discover groups.

The discovery view lists all role-assignable groups in the tenant that are not yet under PIM management. Select all five PIM groups in a single operation and choose Manage groups. There is no reason to onboard them one at a time.

📸 [Screenshot: PIM Discover groups view with all five pimGroup entries selected]

Once onboarded, all five groups will appear in PIM > Groups and are ready for settings configuration in Section 7.

📸 [Screenshot: PIM Groups list showing all five pimGroup entries after onboarding]

Section 7 – PIM Role Settings

This section configures the activation rules for each role tier and adds eligible members to the PIM groups. The authentication contexts from Section 3 are bound here, the time limits are set here, and the users who need access are made eligible here. Settings are configured at the group level – navigate to PIM > Groups > [Group] > Settings > Member for each group.

7.1 – Configure Standard Elevated PIM Group Settings

Applies to pimGroup.RoleAssigned.IntuneAdministrator and pimGroup.RoleAssigned.ExchangeAdministrator.

Navigate to PIM > Groups > [Group] > Settings and click Edit.

📸 [Screenshot: PIM group settings edit view for standard elevated group]

Activation tab:

Activation maximum duration: 8 hours
On activation, require: Microsoft Entra Conditional Access authentication context – select Re-Authentication - Standard Elevated
Require justification on activation: Enabled
Require ticket information on activation: Optional
Require approval to activate: Disabled

📸 [Screenshot: Activation tab with 8 hour duration and Re-Authentication – Standard Elevated context selected]

Assignment tab:

Allow permanent eligible assignment: Enabled – eligible members never lose the ability to activate. All activation controls, auth context, and time limits remain fully enforced regardless. If your organisation prefers an annual review forcing function, disable this and set the maximum to 12 months.
Allow permanent active assignment: Disabled – active group membership grants the role without any PIM activation, bypassing all controls built in this guide. This must stay disabled.

Notification tab: Configure activation alerts to the group owner and a security distribution list. At minimum enable the Role activation alert under the “Send notifications when eligible members activate this role” section and add your security team email in Additional recipients.

📸 [Screenshot: Notification tab showing activation alert configured with additional recipients]

Save. Repeat for pimGroup.RoleAssigned.ExchangeAdministrator.

7.2 – Configure Protected Tier PIM Group Settings

Applies to pimGroup.RoleAssigned.GlobalAdministrator, pimGroup.RoleAssigned.ComplianceAdministrator, and pimGroup.RoleAssigned.SecurityAdministrator.

Activation tab:

Activation maximum duration: 2 hours
On activation, require: Microsoft Entra Conditional Access authentication context – select Re-Authentication - Protected Roles
Require justification on activation: Enabled
Require ticket information on activation: Recommended
Require approval to activate: Disabled – documented as a future option

📸 [Screenshot: Activation tab with 2 hour duration and Re-Authentication – Protected Roles context selected]

Assignment tab:

Allow permanent eligible assignment: Enabled – same reasoning as standard elevated.
Allow permanent active assignment: Disabled – this must stay disabled. The only permanent active Global Administrator assignments in this tenant are the break glass accounts, and those are direct role assignments entirely outside of this group. These group-level settings have no effect on the break glass accounts.

The break glass accounts are assigned directly to the Global Administrator Entra role – not through this group. PIM group settings cannot reach them. Disabling permanent active assignment here does not affect break glass in any way.

Notification tab: For protected roles, add both the group owner and a senior security contact in Additional recipients on the activation alert. A Global Admin activation outside of business hours or without an associated ticket warrants immediate attention.

Save. Repeat for pimGroup.RoleAssigned.ComplianceAdministrator and pimGroup.RoleAssigned.SecurityAdministrator.

7.3 – Add Eligible Members

Eligible members are added per group. You are manually placing specific cloud-only admin accounts into the eligible assignment for each group. Nobody inherits eligibility automatically.

Navigate to PIM > Groups > [Group] > Assignments > Add assignments.

On the Membership tab, the Select role dropdown will show Member and Owner. Always choose Member – Owner gives administrative control over the group itself, not the Entra role. Owner membership does not grant the role.

Select the admin account on the Membership tab, then click the Setting tab.

On the Setting tab, the Assignment type defaults to Active. Change it to Eligible before saving. Active assignment grants the role immediately and permanently without any PIM activation – it bypasses every control built in this guide.

Assignment type: Eligible
Permanently eligible: Checked – the ability to activate never expires. The role itself only lasts for the activation window duration.

📸 [Screenshot: Add assignments Membership tab – Member selected, admin account chosen]

📸 [Screenshot: Add assignments Setting tab – Eligible selected, Permanently eligible checked]

Repeat for each account that requires access to that role, and repeat across all five PIM groups.

# PowerShell - Add eligible member to PIM group
$group = Get-MgGroup `
  -Filter "displayName eq 'pimGroup.RoleAssigned.GlobalAdministrator'"

$user = Get-MgUser `
  -Filter "userPrincipalName eq '[email protected]'"

New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest `
  -AccessId "member" `
  -GroupId $group.Id `
  -PrincipalId $user.Id `
  -Action "adminAssign" `
  -ScheduleInfo @{
    startDateTime = (Get-Date).ToUniversalTime().ToString("o")
    expiration = @{
      type = "noExpiration"
    }
  }

7.4 – Confirm PIM Configuration

Navigate to PIM > Groups and confirm each group shows the correct activation duration and authentication context under Settings.

Intune and Exchange groups: 8 hours, Re-Authentication - Standard Elevated
Global, Compliance, and Security Administrator groups: 2 hours, Re-Authentication - Protected Roles

📸 [Screenshot: PIM group settings overview showing duration and auth context for each group]

Navigate to Entra admin center > Roles and administrators > Global Administrator and confirm the only permanent active members are the two break glass accounts.

7.5 – Common Scenarios and Edge Cases

Eligible assignment expiry – can you lock yourself out?

With permanent eligible assignment enabled – the default in this guide – eligible members never expire and this scenario cannot occur. If your organisation chose time-limited eligible assignments instead, set calendar reminders 30 days before expiry. The break glass accounts remain the recovery path regardless – they hold permanent active GA outside of PIM entirely and are unaffected by any PIM group configuration.

Permanent eligible does not mean the role is always on.

Permanently eligible means the ability to activate never expires. The role itself is only active during an activation window – 8 hours for standard elevated, 2 hours for protected. When the window expires PIM removes the role automatically. The eligible assignment is untouched and the admin can activate again the next time they need the role.

A user holds both Intune Administrator and Global Administrator eligibility.

Each PIM group activation is entirely independent. Activating Intune Administrator carries no trust into a Global Administrator activation. When the engineer activates the GA group, CA151 fires and demands fresh phishing-resistant authentication regardless of the existing Intune Admin session. The two activations have independent timers. When the GA 2-hour window expires, the Intune Administrator role remains active until its own window closes.

Activation fails with “Role already exists” error.

This means the account already holds the role through a direct active assignment outside of PIM. PIM cannot grant the role through the group because it already exists on the account through another path. Navigate to Entra admin center > Roles and administrators > [Role] > Active assignments, find and remove the direct user assignment, then attempt the activation again. Refer to Section 11 for the full remediation process.

Activation appears to succeed but the workload is inaccessible.

The access token issued at sign-in does not automatically update when PIM grants a new role mid-session. The correct workflow is to activate in PIM first, then navigate to the workload. If you are already in the workload when you activate, sign out and sign back in to get a fresh token that reflects the new group membership. This is expected token-based authentication behaviour, not a configuration problem.

An engineer leaves the organisation.

Disabling the account prevents any new activations immediately. For immediate role revocation, navigate to PIM > Groups, locate each group the account is a member of, and remove the active assignment manually under Active assignments. Deregister any physical YubiKeys from the account immediately per Section 5.4.

Section 8 – Worked Examples

Important: When using PIM for Groups, role activation does not appear under PIM > My roles > Microsoft Entra roles. That section only shows direct role eligibility. Because eligibility in this model is through a group, it will never appear there. All activations happen under PIM > My roles > Groups. If an admin goes to Microsoft Entra roles and sees nothing to activate, they are in the wrong place – not facing a permissions problem.

Example A – Intune Administrator (Standard Elevated Tier)

What has been built: pimGroup.RoleAssigned.IntuneAdministrator is permanently assigned as an active member of the Intune Administrator Entra role. PIM settings specify an 8-hour maximum activation duration, justification required, and Re-Authentication - Standard Elevated bound to activation. CA150 listens for that context and requires fresh re-authentication with any compliant MFA method.

The engineer navigates to PIM > My roles > Groups and finds pimGroup.RoleAssigned.IntuneAdministrator under Eligible assignments. They click Activate. PIM prompts for a justification – mandatory. The CA banner appears indicating a CA policy will require additional verification. The engineer clicks the arrow to continue. CA150 fires and challenges with standard MFA. Once satisfied, Intune Administrator is active for up to 8 hours.

The engineer should activate in PIM first, then navigate to Intune. Navigating to Intune before activating will result in a permissions error – the session token must be refreshed after activation to reflect the new role grant.

📸 [Screenshot: PIM My roles Groups view showing IntuneAdministrator as eligible]

📸 [Screenshot: Activation panel showing CA banner, 8-hour duration, justification field]

📸 [Screenshot: Active assignments showing Intune Administrator active with 8-hour expiry]

Example B – Global Administrator (Protected Tier)

What has been built: pimGroup.RoleAssigned.GlobalAdministrator is permanently assigned as an active member of the Global Administrator role. The only permanent active GA members in the tenant are the two break glass accounts. PIM settings specify a 2-hour maximum activation duration, justification required, and Re-Authentication - Protected Roles bound to activation. CA151 requires phishing-resistant MFA – FIDO2 or WHfB only.

The engineer navigates to PIM > My roles > Groups, finds pimGroup.RoleAssigned.GlobalAdministrator under Eligible assignments, and clicks Activate. They enter a specific, meaningful justification. The CA banner appears. The engineer clicks through. CA151 fires and challenges with phishing-resistant authentication – a standard authenticator push will not satisfy this. The engineer uses their YubiKey or WHfB. Once satisfied, Global Administrator is active for up to 2 hours.

If the engineer does not have a registered FIDO2 key or WHfB credential, the activation fails at the CA challenge. The role is not granted. This is the correct behaviour.

The engineer should manually deactivate when the task is complete – leaving a GA activation running beyond what the task requires is poor practice. Navigate to PIM > My roles > Groups > Active assignments, select the group, and choose Deactivate.

📸 [Screenshot: Phishing-resistant MFA challenge during GA activation]

📸 [Screenshot: Active assignments showing Global Administrator active with 2-hour expiry]

Example B2 – Same Engineer Activates Both Intune Administrator and Global Administrator

The engineer activates Intune Administrator first – CA150 fires, standard MFA satisfied, role active for 8 hours. Later they need Global Administrator. Despite the active Intune Admin session, CA151 fires and demands fresh phishing-resistant authentication. The existing session does not satisfy it. The engineer uses their YubiKey. Both roles are now active with independent timers. When the GA 2-hour window expires, Global Administrator is revoked. Intune Administrator remains active until its own window closes.

📸 [Screenshot: Active assignments showing both roles active with separate expiry times]

Section 9 – Validation

Validation confirms that every component built across Sections 2 through 8 is functioning correctly as an integrated system. Work through each check in order. Perform this immediately after the build is complete and repeat any time a significant change is made to CA policies, PIM settings, or authentication methods.

9.1 – Confirm Break Glass Accounts

Sign in using [email protected] and confirm sign-in succeeds without CA policy interference. If any policy blocks or challenges the sign-in, confirm CA-BreakGlassAccounts - Exclude is present in the exclusions of every CA policy. Sign out immediately after validation.

# PowerShell - Confirm break glass accounts hold permanent active GA
$role = Get-MgRoleManagementDirectoryRoleDefinition `
  -Filter "displayName eq 'Global Administrator'"

Get-MgRoleManagementDirectoryRoleAssignment `
  -Filter "roleDefinitionId eq '$($role.Id)'" | 
  Select-Object PrincipalId, DirectoryScopeId

9.2 – Confirm Authentication Contexts Are Published

Navigate to Entra admin center > Protection > Conditional Access > Authentication contexts. Confirm both Re-Authentication - Standard Elevated and Re-Authentication - Protected Roles are listed and published. An unpublished context will not be available for PIM or CA policy selection.

📸 [Screenshot: Authentication contexts list showing both contexts published]

9.3 – Confirm CA Policies Are Active and Correctly Scoped

Navigate to Entra admin center > Protection > Conditional Access > Policies. Confirm both CA150 and CA151 are set to On – not Report-only. Open each policy and confirm correct auth context scope, authentication strength, sign-in frequency set to Every time, and break glass exclusion group present.

📸 [Screenshot: CA150 detail showing auth context and MFA grant control]

📸 [Screenshot: CA151 detail showing auth context and phishing-resistant MFA grant control]

9.4 – Confirm PIM Groups Are Correctly Configured

Navigate to PIM > Groups. Confirm all five groups appear. For each group open Settings > Member and confirm:

The authentication context field is populated and not blank – a blank field means PIM will not fire the context signal and CA150/CA151 will never trigger regardless of configuration
Correct duration – 8 hours for standard elevated, 2 hours for protected
Justification required is enabled
Allow permanent active assignment is disabled

📸 [Screenshot: PIM group settings showing auth context populated for GlobalAdministrator group]

9.5 – Validate Standard Elevated Activation End to End

Using a test admin account eligible for pimGroup.RoleAssigned.IntuneAdministrator, sign in using standard MFA – authenticator app push, not WHfB or YubiKey. Navigate to PIM > My roles > Groups and activate the group. Confirm the CA banner appears, re-authentication fires, standard MFA satisfies it, and the role appears under Active assignments with an 8-hour expiry.

Check sign-in logs at Entra admin center > Protection > Conditional Access > Sign-in logs and confirm Re-Authentication - Standard Elevated is recorded and CA150 is the applied policy. Manually deactivate after validation.

📸 [Screenshot: Sign-in log showing Re-Authentication – Standard Elevated context and CA150 applied]

9.6 – Validate Protected Role Activation End to End

Using a test admin account eligible for pimGroup.RoleAssigned.GlobalAdministrator with a registered FIDO2 key, sign in using standard MFA – not WHfB or YubiKey. Navigate to PIM > My roles > Groups and activate the GA group. Confirm phishing-resistant challenge fires, a standard push is not accepted, and the YubiKey satisfies it. Confirm 2-hour expiry. Check sign-in logs and confirm Re-Authentication - Protected Roles and CA151 are recorded. Manually deactivate immediately.

📸 [Screenshot: Sign-in log showing Re-Authentication – Protected Roles context and CA151 applied]

9.7 – Validate Failed Activation Behaviour

Using a test account eligible for pimGroup.RoleAssigned.GlobalAdministrator but with no registered FIDO2 key or WHfB, attempt an activation. Confirm the activation fails at the CA challenge and the role is not granted. Document the error message so engineers recognise it as a configuration gap rather than a system fault.

📸 [Screenshot: Failed activation – authentication requirement not met error]

9.8 – Validation Checklist

☐ Break glass accounts sign in without CA policy interference
☐ Both break glass accounts show as permanent active GA with no expiry
☐ Both authentication contexts are published and available
☐ CA150 and CA151 are both set to On – not Report-only
☐ All five PIM groups appear in PIM with correct settings
☐ Auth context field is populated on all five groups – not blank
☐ Standard elevated activation fires CA150 and succeeds with standard MFA
☐ Protected role activation fires CA151 and succeeds only with phishing-resistant MFA
☐ Protected role activation fails correctly when phishing-resistant method is unavailable
☐ Sign-in logs show correct auth context and CA policy for each activation

Section 10 – Expanding to Additional Roles

Every new role follows the same pattern – the only decision that requires judgement is which tier it belongs in.

10.1 – Determine the Role Tier

Standard Elevated is appropriate for roles that grant control over a specific workload with limited ability to affect identity infrastructure or tenant-level controls.

Protected is appropriate for roles that grant broad authority over identity, security policy, compliance data, or tenant-level configuration.

If there is genuine uncertainty about which tier a role belongs in, default to protected. It is easier to relax controls later than to explain why a sensitive role was under-protected.

Standard Elevated	Protected
Helpdesk Administrator	Privileged Role Administrator
User Administrator	Privileged Authentication Administrator
Teams Administrator	Identity Governance Administrator
SharePoint Administrator	Conditional Access Administrator
Groups Administrator	Authentication Policy Administrator
License Administrator	Exchange Administrator (some environments)

10.2 – Create the PIM Group

Follow Section 6.2. Create a role-assignable security group named pimGroup.RoleAssigned.[EntraRoleName] with no members at creation.

10.3 – Assign the Group to the Entra Role

Follow Section 6.3. Assign the new group as a permanent active member of its corresponding Entra role.

10.4 – Onboard the Group to PIM

Follow Section 6.5. Navigate to PIM > Groups > Discover groups, select the new group, and choose Manage groups. The group will not accept configuration until this step is complete.

10.5 – Configure PIM Group Settings

Standard elevated: 8-hour duration, justification required, auth context Re-Authentication - Standard Elevated, permanent active disabled.

Protected: 2-hour duration, justification required, ticket information recommended, auth context Re-Authentication - Protected Roles, permanent active disabled.

10.6 – No CA Policy Changes Required

No changes to CA150 or CA151 are required. The new PIM group’s activation triggers the bound authentication context, which fires the appropriate CA policy automatically. This is one of the architectural advantages of the context-based model – the enforcement layer does not need to be updated every time a new role is onboarded.

10.7 – YubiKey Requirement for Protected Tier

If the new role is protected tier, complete Section 5 for every account that will hold eligible membership before adding them as eligible members. Do not add the eligible assignment first – the first activation attempt will fail at the CA challenge.

10.8 – Add Eligible Members

Follow Section 7.3. Select Member, set to Eligible, check Permanently eligible.

10.9 – Validate the New Role

Follow the pattern in Section 9. Confirm PIM settings are correct, attempt a full activation, and check sign-in logs to confirm the correct CA policy fired. For protected tier, confirm an account without a phishing-resistant method cannot complete activation. Do not skip validation.

10.10 – Keeping a Role Register

Maintain a register documenting each role, its tier, the corresponding PIM group, eligible members, and last review date. Review quarterly.

Role	Tier	PIM Group	Account Holder	Eligible	Last Reviewed
Global Administrator	Protected	pimGroup.RoleAssigned.GlobalAdministrator	[email protected]	Permanent	2026-03-01
Intune Administrator	Standard	pimGroup.RoleAssigned.IntuneAdministrator	[email protected]	Permanent	2026-03-01

Section 11 – Remediating Existing Direct Role Assignments

Most tenants encountered in the field will have admin accounts with direct permanent active role assignments – roles assigned directly to a user account rather than through a PIM group. This is the state that exists before PIM governance is applied and it is what this architecture is designed to replace. This section documents how to move from that state to the PIM group model cleanly.

A common symptom of this misconfiguration is an admin account where high-privilege roles like Global Administrator or Intune Administrator show as Active and Permanent under Assigned roles, while something like Global Reader shows as Eligible. This is the inverse of the correct model.

11.1 – Identify Direct Role Assignments

Navigate to Entra admin center > Users > [Admin account] > Assigned roles. Review the Active assignments tab. Any role showing as Active with Permanent end time and no Group membership indicator is a direct assignment that should be converted.

📸 [Screenshot: Assigned roles showing direct permanent active assignments on an admin account]

11.2 – Add the Account as Eligible in the Corresponding PIM Group

Before removing any direct assignment, confirm the account has been added as an eligible member of the corresponding PIM group per Section 7.3. Do not remove the direct assignment first – if the PIM group eligible assignment is not in place, the account will lose access to the role entirely with no way to recover it through PIM.

For protected tier roles, also confirm a FIDO2 key or WHfB is registered on the account before proceeding. Once the direct assignment is removed, the only way to get the role back is through PIM activation, which requires phishing-resistant authentication.

11.3 – Remove the Direct Role Assignment

Navigate to Entra admin center > Roles and administrators > [Role Name] > Active assignments. Find the direct user assignment – it will show the user’s name directly, not a group name in the Principal name column. Select it and choose Remove.

📸 [Screenshot: Active assignments showing direct user assignment with Remove option]

Repeat for each role that had a direct assignment. Once removed, the account has no active role – only the eligible assignment through the PIM group. The account must now go through PIM activation to use any of those roles.

11.4 – Assign Global Reader as a Standing Role

After removing direct role assignments, assign Global Reader as a permanent active standing role on the account per Section 1. This ensures the account has baseline read-only access for routine work without needing to activate anything.

Navigate to Entra admin center > Roles and administrators > Global Reader > Add assignments. Select the admin account, set assignment type to Active, and set duration to Permanently active.

11.5 – Validate the Account

Sign in as the remediated account and confirm Global Reader is active. Navigate to PIM > My roles > Groups and confirm all previously direct-assigned roles now appear as eligible group activations. Attempt one activation to confirm the full chain works before considering remediation complete.

Internal build guide – virtualcaffeine.io | Not for public distribution in current form.

Intune Deployment Guide · Phase 2: Identity and Tenant Foundation
‹ Previous: [2.2.1] Building Your Group Structure in Practice
Next: [2.3] Designing for Scale: Naming, Structure, and Assignments ›