Privileged Identity Management reduces risk by making administrative roles something you activate rather than something you hold. It only works if the roles are actually eligible instead of permanent, and in most tenants we review, several are still permanent. The NCSC’s guidance on secure system administration makes the underlying point: administrative rights should be available when needed and absent the rest of the time.
Count your standing administrators first
Start with a simple number: how many accounts hold a permanent assignment to a privileged role. Global Administrator is the obvious one, and Privileged Role Administrator, Application Administrator and Security Administrator all deserve the same scrutiny because each provides a route to the others. Microsoft’s own guidance suggests keeping the number of permanent global administrators very small, typically two break-glass accounts, with everyone else eligible. If your count runs into double figures, the roles are permanent for a reason worth understanding, usually an automation account or a service that could not be made to work with activation.
Activation settings that are switched off
Eligibility alone is not the control. Check whether activation requires multi-factor authentication, whether a justification is mandatory, whether approval is needed for the highest roles, and what the maximum activation duration is set to. A role that anyone eligible can activate for twelve hours with a single click and no approval gives you an audit trail and very little else. Approval workflows create friction, so apply them to the roles where friction is warranted rather than everywhere, or people will build workarounds.
“The gap I find most often is on the Azure resource side. The directory roles are beautifully configured with approvals and short activations, and then somebody holds permanent Owner on the production subscription because that was never brought into the same process. Attackers do not care which portal the privilege lives in.”
William Fieldhouse, Director, Aardwolf Security Ltd
Groups, service principals and the paths around it
Role assignable groups are convenient and they create an indirect route to privilege that reviews often miss. If a group holds an administrative role and somebody can add members to that group, then that person effectively holds the role. Service principals are the same story with less visibility, since an application granted a directory role does not appear in a list of privileged users. Enumerate both, and check who can consent to new applications, because an attacker who can grant an app permission to read directory data has no need for a role at all.
Reviewing it properly, and proving it works
Run access reviews on a schedule and treat the output as work rather than a report. Quarterly suits most organisations, with a shorter cycle for the highest roles. Alert on activations outside working hours, on any use of break-glass accounts, and on changes to the PIM configuration itself. Then test it: Azure identity penetration testing checks whether the paths to privilege you have closed are genuinely closed, including the group and application routes. Where administrators also hold on-premises rights, pair that with internal security testing, because a hybrid account compromised on a workstation reaches the cloud role from a different direction.
Frequently asked questions about PIM
These questions come up whenever privileged access is being tightened.
Do break-glass accounts belong in PIM?
No. They need permanent access precisely because they exist for the moment when other systems fail. Protect them with hardware keys, exclude them from Conditional Access policies that could lock them out, and alert on every single use.
Does PIM licensing make this hard for smaller firms?
It sits in the higher tiers, which is a real constraint. Where licensing is not available, the fallback is separate administrative accounts with strong authentication and a documented review, which is less elegant and still much better than daily accounts holding admin rights.
