Privileged Access Management on Azure: Beyond Just-In-Time with PIM and PAM

Privileged accounts are the skeleton key to your Azure environment. A compromised Global Administrator can disable every security control, exfiltrate all data, and destroy your entire infrastructure in minutes. Privileged access management is not a feature to enable — it is an architecture to build.

This guide covers the full privileged access management stack on Azure: from Entra PIM configuration through tiered administration to privileged access workstations.

The Privileged Access Problem

Most Azure environments we audit have the same issues:

• Too many permanent admins. We routinely find 10-20 users with standing Global Administrator access. The recommended number is zero (apart from break-glass accounts).
• No activation workflow. Admins use their privileged accounts for daily work, meaning their elevated access is always active and always at risk.
• No session boundaries. Once activated, privileges remain active indefinitely or until the session expires hours later.
• Shared admin accounts. Multiple people use a single admin account, destroying accountability.
• Admin work on standard workstations. Privileged tasks are performed from the same device used for email and web browsing.

Each of these issues dramatically increases the blast radius of a compromise.

Entra PIM: The Foundation

Converting Standing Assignments to Eligible

The first step is converting all permanent (active) role assignments to eligible assignments. Eligible assignments require explicit activation before the role becomes usable.

Roles to convert (minimum):

• Global Administrator
• Security Administrator
• Privileged Role Administrator
• Exchange Administrator
• SharePoint Administrator
• Intune Administrator
• Azure Subscription Owner
• Azure Subscription Contributor (for production subscriptions)

Process:

1. Inventory all current permanent assignments: Entra ID > Roles and administrators > Filter by "Permanently assigned"
2. For each user with a permanent assignment, create an eligible assignment
3. Remove the permanent assignment
4. Communicate the change and provide activation instructions

Exception: Break-glass accounts (exactly 2) retain permanent Global Administrator. These are your emergency access mechanism.

PIM Role Settings Configuration

Configure each role with appropriate controls. Here is a recommended configuration for Global Administrator:

For less sensitive roles (e.g., Intune Administrator), reduce friction while maintaining accountability:

PIM Activation Workflow

When an administrator needs elevated access:

1. Navigate to Entra ID > Privileged Identity Management > My roles
2. Select the required role and click "Activate"
3. Provide a justification explaining the task requiring elevated access
4. If approval is required, the request routes to designated approvers
5. Once approved (or immediately if no approval is required), MFA is enforced
6. The role becomes active for the configured duration
7. After the duration expires, the role is automatically deactivated

All activation events are logged in the PIM audit log and can be forwarded to Sentinel for monitoring and alerting.

PIM for Groups

PIM for Groups extends just-in-time access to Azure AD group memberships. This is powerful for scenarios where access is granted through group membership rather than direct role assignment.

Common use cases:

• A security group grants Contributor access to a production subscription. Rather than making users permanent members, they activate membership through PIM when needed.
• A group controls access to a sensitive application. Members must activate group membership to access the application.
• Break-glass group: A group with elevated permissions that requires PIM activation, providing an alternative to permanent role assignments for operational scenarios.

Configuration:

1. Enable the group for PIM: Groups > [Group name] > Privileged access > Enable
2. Add members as "Eligible" rather than "Active"
3. Configure activation settings (duration, MFA, justification, approval)

Access Reviews

Access reviews ensure that eligible assignments remain appropriate over time. Configure quarterly access reviews for all privileged roles:

Access review settings:

• Frequency: Quarterly
• Scope: All eligible and active assignments for each privileged role
• Reviewers: Role holders review their own access + manager review
• If reviewer does not respond: Remove access
• Auto-apply results: Yes (after a 7-day grace period)

Critical insight: The "If reviewer does not respond: Remove access" setting is what makes access reviews effective. Without it, reviews become a checkbox exercise with no consequences.

Emergency Access Accounts

Emergency access (break-glass) accounts are your safety net when all other access mechanisms fail. Configure them correctly or they will fail when you need them most.

Configuration

Account 1:

• Cloud-only account (no federation dependency)
• Username: Non-descriptive (e.g., opsaccount1@domain.onmicrosoft.com)
• Password: 128+ character randomly generated string
• Permanent Global Administrator role
• Excluded from ALL Conditional Access policies
• No MFA configured (to avoid MFA system dependency)
• Password stored in a physical safe, split between two locations

Account 2:

• Same configuration as Account 1
• Different password, different physical storage location
• Ideally uses a different authentication method (e.g., FIDO2 key stored in safe)

Monitoring

Create a Sentinel analytics rule that triggers on any sign-in by a break-glass account:

SigninLogs
| where UserPrincipalName in ("opsaccount1@domain.onmicrosoft.com", "opsaccount2@domain.onmicrosoft.com")
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, Status

Set the alert to trigger immediately with high severity. Any break-glass sign-in outside of a scheduled test is a critical security event.

Testing

Test each break-glass account quarterly:

1. Retrieve the credentials from physical storage
2. Sign in from a clean device
3. Verify Global Administrator access is functional
4. Verify that the Sentinel alert fires
5. Sign out and re-secure the credentials
6. Document the test with date, tester, and results

Privileged Access Workstations (PAW)

A privileged access workstation is a hardened device used exclusively for administrative tasks. It reduces the attack surface by isolating privileged sessions from daily computing activities.

PAW Architecture

Tier 0 PAW (for identity and security admins):

• Dedicated physical hardware — not a VM on a shared host
• Windows 11 Enterprise with Secured-core PC features
• Managed by a dedicated Intune policy set (separate from standard device policies)
• No email client, no web browser (except for admin portals on allowlist)
• No personal software installation
• Application control via Windows Defender Application Control (WDAC)
• Network access restricted to Azure management endpoints only

Tier 1 PAW (for server and application admins):

• Same physical isolation requirements
• Slightly relaxed application control to include necessary management tools
• Network access to server management endpoints

Implementation with Intune:

Create a dedicated device configuration profile:

• Disable USB storage devices
• Enforce BitLocker encryption
• Configure Windows Defender Credential Guard
• Block all applications except an explicit allowlist
• Configure Windows Firewall to allow only outbound HTTPS to Azure management URLs
• Disable Windows Store access
• Configure Microsoft Defender for Endpoint with maximum protection level

PAW Enrollment Process

1. Procure dedicated hardware (separate from standard fleet)
2. Enroll in Intune with the PAW device configuration profile
3. Assign to the specific admin user
4. Verify WDAC policy enforcement and network restrictions
5. Admin uses this device only for privileged operations

The key discipline: admins must never use their PAW for email, web browsing, or personal tasks. One compromised activity on the device defeats the entire purpose.

Tiered Administration Model

The tiered model segments your environment into tiers of decreasing sensitivity, preventing credential exposure across tiers.

Tiered Administration Overview

Tier Definition

Tier 0 — Identity and security infrastructure:

• Entra ID, Active Directory Domain Controllers
• ADFS/PingFederate servers
• Certificate authorities
• Security monitoring infrastructure (Sentinel, Defender for Cloud)
• Backup infrastructure

Tier 1 — Servers and applications:

• Application servers
• Database servers
• File servers
• Azure subscriptions hosting business applications

Tier 2 — End-user devices and workstations:

• User workstations and laptops
• Mobile devices
• Printers and peripherals

Tiered Access Rules

The core rule: Credentials from a higher tier must never be exposed on a lower tier.

• A Tier 0 admin account must never sign in to a Tier 1 or Tier 2 device
• A Tier 1 admin account must never sign in to a Tier 2 device
• Each admin has a separate account per tier they administer

Enforce with Conditional Access:

Create policies that restrict where each tier's admin accounts can authenticate:

• Tier 0 admin accounts: Only allow sign-in from PAW devices (use device filter: device.extensionAttribute1 -eq "PAW-T0")
• Tier 1 admin accounts: Only allow sign-in from PAW or designated management servers
• Tier 2 admin accounts: Allow from compliant corporate devices

Practical Implementation

Most organisations adopt the tiered model incrementally:

1. Phase 1: Separate admin accounts from daily-use accounts (no admin work with your regular account)
2. Phase 2: Implement PIM for all privileged roles with just-in-time activation
3. Phase 3: Deploy PAW devices for Tier 0 administrators
4. Phase 4: Enforce Conditional Access restrictions per tier
5. Phase 5: Extend PAW to Tier 1 administrators

Each phase delivers measurable risk reduction. You do not need to implement everything at once.

Monitoring Privileged Access

Build a Sentinel workbook that provides a unified view of privileged access across your environment:

Metrics to track:

• Number of permanent vs. eligible role assignments (trend over time)
• PIM activation frequency by role and user
• Average activation duration
• Denied activation requests
• Access review completion rates
• Break-glass account sign-in events
• Admin sign-ins from non-PAW devices (should be zero for Tier 0)

Create alerts for:

• Any new permanent role assignment (should trigger a review)
• PIM activation outside business hours (may be legitimate, but worth investigating)
• Admin sign-in from an unmanaged device
• Multiple failed activation attempts (possible compromise attempt)

Conclusion

Privileged access management is not a single product configuration — it is a layered architecture. PIM provides the just-in-time foundation. Access reviews maintain hygiene over time. PAW devices isolate privileged sessions. The tiered model prevents credential leakage. Together, they reduce the blast radius of a compromise from "entire environment" to "single session, limited scope, limited duration."

Start with PIM. Convert standing assignments to eligible. Then build outward: access reviews, PAW for Tier 0, tiered Conditional Access. Each step measurably reduces your risk.

If you need help designing and implementing a privileged access architecture for your Azure environment, contact us at mbrahim@conceptualise.de. We specialise in building PAM programmes that are both secure and operationally sustainable.