While Microsoft Entra Privileged Identity Management (PIM) is a powerful tool for enhancing identity security and streamlining the implementation of your identity management strategies, there’s a good chance that it’s not delivering the exact security protection that you think it is.
During tenant assessments as Microsoft Ireland’s Security Partner of the Year, we’ve noticed common mistakes both within PIM configurations themselves and in the expectations customers have of their setup’s effectiveness, which can undermine the defence that – when properly configured and understood – Microsoft Entra PIM can offer.
Common Privileged Identity Management Mistakes
Mistake #1 - A Reliance on One-Time Authentication
One of the most pervasive PIM misconceptions that we see is a misunderstanding of the protection delivered by the “On Activation Require Azure MFA” checkbox. While this setting may appear to enforce MFA when activating a privileged role, its practical impact may be limited in the case of certain attacks.
For example, if an active session has already satisfied MFA requirements, with this checkbox ticked, PIM will not prompt for MFA again during role activation. Unfortunately, this can allow an adversary with a stolen token (e.g., via Adversary In The Middle attacks) to activate roles without necessary reauthentication.
Leverage Authentication Context within Conditional Access policies to enforce reauthentication explicitly, and don’t leave it up to chance. This ensures that users prove their identity again before activating high-privilege roles.
Mistake #2 - Failing to Leverage Authentication Context
Authentication Contexts can provide an additional layer of security by reinforcing Conditional Access during application use. Rather than relying on existing sessions and authentication, users are required to once again prove that they are who they say they are, placing an extra barrier between would-be attackers and privileged roles within your organisation.
To implement this control, link an Authentication Context to a Conditional Access policy that specifies stricter session requirements, such as “Sign-in Frequency = Every Time.” This approach helps to mitigate token theft risks and ensure that even authorised users must continuously validate their identity for sensitive role activations.
Mistake #3 - Misusing "Require Approval to Activate"
In our experience, the “Require Approval to Activate” feature within Microsoft Entra PIM is often either overused or underused, creating either inefficiencies or security gaps. It’s essential to strike a meaningful balance.
Overuse might look like requiring approval for roles with lower security access, such as helpdesk administrators. While this can be beneficial in terms of keeping potential adversaries out, with proper Conditional Access policies in place, it may prove an ineffective measure, and even overkill – users are likely to become frustrated and experience delays in their workflows without actually adding meaningful security benefits.
Conversely, in the case of underuse for critical roles like Global Administrator, skipping this step leaves the organisation vulnerable to token theft and compromised accounts. For best practice, and bolstered defence in depth, use approvals selectively for high-privilege roles, balancing usability with security by implementing robust validation processes for requests to prevent unauthorised access elevations.
Mistake #4 - Not Having Mitigations Against Role Lockouts
If your PIM activation process requires approval from multiple high-ranking admins (a two-keyed lock system is common), it’s worth considering how this process would work should the admin accounts in question no longer be accessible when they’re needed. When it comes to security, time is of the essence, and when activation is required quickly, an administrator that’s uncontactable – on annual leave, for example – can seriously impact processes.
For reliable, continuous access, organisations should consider establishing stringently monitored emergency access accounts. An emergency access account (also known as a “break glass” account) is a highly privileged account, typically a Global Admin, that sits outside of Conditional Access policies, to be used in the case of a cyber attack. Once a threat has been contained and remediated, emergency access accounts are utilised to restore access for users.
A static emergency access account, locked down and monitored with tools such as Microsoft Sentinel or Azure Monitor, can allow access to PIM activation, even when Global Admins aren’t available.
Mistake #5 - Misunderstanding PIM for Groups
PIM for Groups enables users to activate the ownership or membership of a Microsoft Entra security group or other Microsoft 365 group. It’s a useful tool, and an effective way of enforcing permissions, such as those for Microsoft Purview, Intune or Exchange. However, we commonly encounter an underutilisation, or lack of understanding around PIM for Groups’ capabilities, and while it may be worth exploring as a means of privilege management, misuse can inadvertently weaken security.
For example, there’s potential for group membership to grant eligible users a Global Admin role, bypassing the security of typical protective measures and leading to an unintended privilege escalation. We recommend organisations take time to fully understand the use cases for PIM for Groups and proceed judiciously, even potentially avoiding it entirely for highly privileged roles.
Threatscape’s award-winning Microsoft Security Practice provides a range of managed and professional services across identity protection, messaging, endpoint protection, cloud security and more. Threatscape’s complimentary Microsoft Entra ID Advisory Service helps you understand the identity threats we see lodged against organisations every day, and the associated security protections available within your Microsoft 365 licence.
During your no-obligation consultation with one of our Microsoft security experts, you’ll gain insight and recommendations on how Entra ID and other capabilities within Microsoft 365 help defend cloud identities against a wealth of threats.
