Start with impact, not job title
Before buying or configuring devices, I would ask a simpler question: which accounts could cause the most damage if they were compromised? A role belongs on a PAW when it can take over an identity system, change security controls, or reach a large set of important workloads. Microsoft’s privileged security level includes Microsoft Entra administrators, identity synchronization and federation administrators, and high-impact on-premises Active Directory roles. Owners of other critical control planes may need the same treatment.
Inventory what each role can actually change. A narrow workload role may have less reach than a role that can create applications, grant consent, change authentication methods, or alter Conditional Access. Review custom roles and inherited privileges, including Azure resource roles, because a reassuring title can hide a powerful permission set.
Prioritize the control plane
Imagine someone who can change who receives an admin role or which devices are allowed to sign in. That person can affect the security of many other users. Start with Global Administrator and Privileged Role Administrator, then examine roles that alter Conditional Access, authentication methods, device management, and application permissions. A Global Administrator can administer Microsoft Entra broadly and may elevate access to Azure subscriptions. A Privileged Role Administrator can manage Entra role assignments and PIM. A Conditional Access Administrator can change sign-in policy.
These examples are a starting point, not a complete universal list. Rank roles by the systems they control and the potential blast radius in your tenant. Use Microsoft’s current role reference during review because built-in permissions and products evolve.
Separate identities and duties
Give administrators a normal account for email and collaboration and a separate account for privileged tasks. Assign the least-privileged role that performs the task, at the narrowest scope that works. Avoid standing assignments where eligible, time-limited activation is practical. The PAW should host privileged sessions; normal productivity activity should stay off it.
Microsoft Entra Privileged Identity Management can require activation duration, justification, authentication, and approval for eligible roles. These checks improve accountability and reduce the time a high-impact permission is active. They complement device isolation rather than replacing it.
Design for emergency access
Emergency access accounts need a different operating rule. Microsoft recommends at least two cloud-only emergency accounts with permanent active Global Administrator assignments, phishing-resistant authentication, monitoring, and regular validation. They should be excluded from Conditional Access policies that could block recovery during an outage, while their use remains tightly controlled and audited.
A PAW is still the designated secure workstation for using those accounts. Document who can access the credentials, where the devices are held, how the accounts are tested, and what alert fires when one signs in. Test the complete recovery path before an emergency.
A small role review I would run with the team
I would start with a spreadsheet of real assignments, not a generic list of job titles. For each assignment I record the permission, its scope, whether it is standing or eligible, who approves activation, and which interface is used. Then I ask: can this role change identities, grant other people access, disable a security control, or reach many workloads? A yes moves it toward the strongest device and sign-in profile.
Suppose an engineer needs to read sign-in logs and occasionally change Conditional Access. I would keep routine investigation in a read-only role and put the policy-changing role behind separate activation. The engineer may be the same person, but the two tasks should not inherit the same permissions and risk. I would test this with actual task walkthroughs before removing broad assignments.
The output is a decision table that operations can maintain: role, protected task, required device, authentication, activation rule, and exception owner. It should be reviewed when a new product or integration adds another way to administer the environment.
Sources and further reading
This article is based on Microsoft’s published documentation. Review the linked guidance for current product requirements and detailed deployment steps.