You already know that administrator accounts deserve more protection than everyday user accounts. But if a privileged admin signs in from a normal laptop full of email, browser extensions, and random downloads, that admin is still one phishing page away from trouble.
That is where a Privileged Access Workstation (PAW) and Microsoft Entra Privileged Identity Management (PIM) work well together. PIM controls when a privileged role becomes active. A PAW controls where that privileged work happens.
In this tutorial, you will build a practical deployment pattern for PAWs with Microsoft Entra PIM. You will prepare the access model, configure PIM role activation, require admin work from compliant PAWs, and validate that your normal workstation cannot perform the same privileged actions.
[!NOTE]This guide focuses on Microsoft Entra ID, Microsoft Entra PIM, Intune-managed Windows PAWs, and Conditional Access. You can adapt the same model for hybrid Active Directory administration, but do not skip separate admin accounts and device hardening.
Before You Begin
To follow along, you will need:
-
A Microsoft Entra tenant with Microsoft Entra PIM available. Microsoft documents PIM as a Microsoft Entra ID Governance capability for managing, controlling, and monitoring privileged access to Microsoft Entra ID, Azure, and Microsoft Online Services.
-
Permission to configure PIM role settings and Conditional Access policies.
-
Microsoft Intune or another management path that can mark PAW devices as compliant.
-
At least one Windows device dedicated to privileged administration.
-
A separate administrator account for each human administrator.
Microsoft’s privileged access guidance separates normal productivity devices from specialized and privileged access workstations. PAWs should not be used for general web browsing, email, or productivity work because those activities increase the attack surface of the device used for privileged sessions.
Related Microsoft references:
Build the PAW Access Model
Before clicking through portals, decide what you want the system to enforce. A clean PAW deployment has three separate pieces:
-
A separate admin identity — The user signs in to normal productivity apps with a standard account and performs privileged work with a dedicated admin account.
-
A hardened admin device — The admin account signs in only from a managed PAW that meets your security baseline.
-
Just-in-time role activation — PIM grants privileged roles only after activation requirements such as MFA, justification, approval, and time limits.
Think of this as a simple rule:
Privileged roles should activate only for the right identity, from the right device, for the right amount of time.
Do not start by assigning permanent Global Administrator access to your PAW admins. Instead, make those accounts eligible for the least-privileged Microsoft Entra roles they need. Microsoft documents eligible assignments as assignments that require a user to perform one or more actions before using the role.
Create Groups for PAW Devices and PAW Admins
Groups make the rest of the deployment easier to manage. Create one group for PAW devices and one group for privileged admin accounts.
Example group names:
-
SG-PAW-Devices -
SG-PAW-Admins -
SG-PIM-Privileged-Role-Approvers
In the Microsoft Entra admin center:
-
Open Identity —> Groups —> All groups.
-
Create a Security group named
SG-PAW-Devices. -
Add the dedicated PAW devices to the group.
-
Create a second Security group named
SG-PAW-Admins. -
Add the separate administrator accounts to the group.
You can use dynamic device groups if your naming, ownership, or enrollment standards are consistent. For a first pilot, a manually managed security group is easier to audit.
[!TIP]Keep normal user accounts out of PAW admin groups. The goal is to separate daily productivity identity from privileged administration identity.
Enroll and Harden the PAW
A PAW is not just a laptop with a different name. Treat it like an administrative appliance.
At a minimum, configure the PAW with:
-
Full disk encryption.
-
Secure Boot and TPM-backed protections where supported.
-
Microsoft Defender for Endpoint or your organization’s endpoint detection tool.
-
Intune compliance policies.
-
Standard users without local administrator rights.
-
Application control or a tightly managed software allow list.
-
Browser restrictions that limit access to approved administrative portals.
-
No email client, chat client, or general productivity apps.
Microsoft’s privileged access device guidance describes three security levels: enterprise, specialized, and privileged. The privileged level is the strictest and is intended for sensitive administration. That is the model you are building for PAWs.
In Intune, create or assign policies that make the PAW compliant only when it meets your baseline. For example:
-
Open the Microsoft Intune admin center.
-
Go to Devices —> Compliance policies.
-
Create or assign a Windows compliance policy for PAWs.
-
Require encryption, a healthy risk state, minimum OS version, and password requirements that match your standards.
-
Assign the policy to
SG-PAW-Devices.
Compliance matters because Conditional Access can use it later. PIM alone cannot tell whether the admin is sitting at a hardened workstation. Conditional Access bridges that gap.
Configure PIM for Eligible Admin Roles
Next, configure PIM so privileged access is eligible instead of permanently active.
In the Microsoft Entra admin center:
-
Open Identity governance —> Privileged Identity Management.
-
Select Microsoft Entra roles.
-
Open Roles and choose a role to configure, such as Privileged Role Administrator, Global Reader, Exchange Administrator, or another role your admins need.
-
Add the PAW administrator account or admin group as an Eligible assignment.
-
Configure role settings for activation duration, MFA, justification, and approval.
For sensitive roles, require approval and keep activation windows short. A common starting point is one to four hours, but choose a duration that matches your operations process.
PIM can enforce controls such as:
-
Just-in-time privileged access.
-
Time-bound access using start and end dates.
-
Approval for activation.
-
MFA during activation.
-
Justification for why a role is being activated.
-
Notifications when privileged roles are activated.
-
Access reviews for privileged roles.
-
Audit history downloads.
Those controls reduce standing privilege, but they do not replace PAWs. If a compromised normal workstation activates a role, the attacker can still receive the active role token. That is why the Conditional Access step matters.
Require PAWs with Conditional Access
Now create the policy that forces privileged work onto the PAW.
The exact Conditional Access design depends on your tenant and licensing, but the pattern is:
-
Target administrator accounts or directory roles.
-
Target admin portals and Microsoft cloud apps used for administration.
-
Require a compliant device, a device filter, or both.
-
Exclude emergency access accounts.
-
Pilot in report-only mode before enforcing.
A conservative first policy looks like this:
-
Open Protection —> Conditional Access.
-
Create a new policy named
Require PAW for privileged administration. -
Under Users, include
SG-PAW-Adminsor the selected administrator roles. -
Exclude your break-glass accounts.
-
Under Target resources, include the administrative cloud apps you want to protect.
-
Under Conditions, add a device filter that includes your PAW device criteria if you use device filters.
-
Under Grant, require the device to be marked as compliant.
-
Start with Report-only.
-
Review sign-in logs and policy results.
-
Turn the policy On after the pilot results match your expectations.
[!WARNING]Do not lock yourself out. Exclude emergency access accounts, test with report-only mode, and verify access from a known-good PAW before enforcing a blocking policy.
Conditional Access policy design is where many PAW projects either succeed or fail. Requiring MFA is helpful, but MFA alone does not prove the device is hardened. Requiring a compliant PAW device is what ties privileged access to the secure workstation.
Activate a Role from the PAW
After the PAW is enrolled, compliant, and covered by Conditional Access, test the real administrator workflow.
From the PAW:
-
Sign in with the dedicated admin account.
-
Open the Microsoft Entra admin center.
-
Go to Identity governance —> Privileged Identity Management —> My roles.
-
Select the eligible role.
-
Click Activate.
-
Complete MFA, approval, and justification requirements.
-
Confirm that the role becomes active for the configured duration.
Microsoft’s PIM activation guidance states that an eligible administrator must activate the role assignment when privileged actions are needed. That is the behavior you want your admins to learn: privileged access is temporary and intentional.
After activation, perform a low-risk administrative task that proves the role works. For example, a Global Reader activation could read tenant configuration without changing it. Avoid using a destructive permission as your first test.
Prove Normal Workstations Are Blocked
A deployment is not complete until you prove the negative case.
From a normal productivity workstation:
-
Sign in with the same dedicated admin account.
-
Try to open the protected administrative portal.
-
Try to activate the same PIM role.
-
Confirm Conditional Access blocks the sign-in or access attempt.
-
Review the sign-in logs and Conditional Access policy result.
The expected result is simple: the admin can perform privileged work from the PAW, but not from a normal workstation.
Document both results in your operations runbook. Include screenshots of:
-
Successful PAW sign-in and role activation.
-
Blocked normal-workstation access.
-
Conditional Access sign-in log results.
-
PIM activation audit history.
Keep PAWs Operational
PAWs fail when they become inconvenient or when exceptions become permanent. Keep the model usable by building operations around it.
Use these practices:
-
Keep a small spare pool of PAWs for lost, broken, or reimaged devices.
-
Patch PAWs on a predictable schedule.
-
Review PIM eligible assignments regularly.
-
Remove unused roles instead of letting them accumulate.
-
Review activation history for unusual times, unusual justifications, or repeated denied approvals.
-
Keep break-glass accounts separate, cloud-only, monitored, and excluded only where required.
-
Train admins to use normal accounts for normal work and admin accounts only on PAWs.
If an admin complains that a task requires email, chat, or arbitrary web browsing from the PAW, stop and redesign the workflow. The PAW should be the place where privileged actions happen, not a second daily-use laptop.
Troubleshooting Common PAW and PIM Problems
The admin cannot activate the role
Check whether the admin account has an eligible assignment for the role. Then review role settings for approval requirements, activation maximum duration, MFA requirements, and assignment start/end dates.
The PAW is blocked by Conditional Access
Confirm the PAW is enrolled, compliant, and included in the right device group or device filter. Then review the sign-in log to see which Conditional Access control failed.
The normal workstation is not blocked
Check whether the policy targets the right users, roles, and cloud apps. Also verify that the policy is turned on and not still in report-only mode.
Admins keep using privileged accounts for normal work
This is a process failure, not a PIM failure. Remove productivity apps from PAWs, train the workflow, and review sign-in logs for privileged accounts accessing non-admin apps.
Wrapping Up
PIM and PAWs solve different parts of the privileged access problem. PIM gives you just-in-time role activation, approval, MFA, justification, access reviews, and audit history. PAWs reduce the risk that privileged sessions and Microsoft Entra token artifacts such as the Primary Refresh Token are exposed on compromised everyday devices.
Bring them together with Conditional Access and Intune compliance. Once the policy is enforced, your privileged workflow becomes much stronger: admins activate roles only when needed, only from hardened workstations, and only for a limited time.
Start with a pilot, prove both the allowed and blocked paths, and then expand role by role. That approach gives you better protection without surprising your administrators or locking out your tenant.
