Entra Id Defense in Depth for your Most Privileged Roles

The Sum of the Whole is Greater Than the Sum of its Parts

I won’t pretend this is the norm, but I’ve noticed in different circles professionally and on some corners of the internet that imply certain identity controls are redundant or unnecessary because another control is already in place:

• “If we have phishing-resistant MFA, do we really need PIM? This seems like overkill and not a necessary control” ~A SharePoint Administrator for one of my clients.

• “If we use PIM, why can’t admins just use their standard accounts?” ~A Reddit post.

• “If PIM is time-bound and we use PAWs is there a need for session controls like Sign-In Frequency?” ~A LinkedIn post, which is by far the least egregious question of these three examples.

  
  

At a glance, maybe some of these questions sound reasonable. If one control provides strong assurance, why layer on complexity? But this mindset fundamentally misunderstands identity and defense in depth. Identity isn’t static; it’s fluid, context-driven, and subject to decay. Trust changes over time and across conditions.

Controls are not redundant, they are symbiotic. Each one addresses a different point in the identity lifecycle, and the true strength of your identity and access management comes from how they interact, not from any single control working alone. That’s defense in depth.

I could (and I honestly have as a drop the mic moment) just provide you with a link to NIST or CIS as an appeal to authority on why MFA, PIM, and any other controls should be implemented but, in this article, I want to explain the why and how these controls complement each other. This isn’t a lecture, it’s a breakdown.

Why “We Already Have That” Misses the Point

Every layer of identity and access management must assume the previous one could fail. PIM doesn’t replace strong authentication, and phishing-resistant MFA (PRMFA) doesn’t replace session governance. Conditional Access does not remove the need for administrative segmentation. Removing a layer reduces resilience.

Defense in depth for identity is about continuity of assurance. Every layer verifies that the security posture established by the previous control is still valid right now. This aligns with Zero Trust principles: assume breach, verify explicitly, and never grant trust based on a single factor. While this article focuses on defense in depth, applying Zero Trust principles enhances it by ensuring we continuously validate every aspect of a privileged session, from identity to device to network context, never assuming that any single control guarantees security.

How Controls Address Different Threats

Each control protects against a specific class of threat. The strength of your security posture comes from how these protections overlap, not from any single control working alone.

Phishing-Resistant MFA (PRMFA)

Protects against: Credential phishing, password spraying, and authentication based on stolen passwords.

PRMFA ensures the person authenticating possesses a physical authenticator or platform credential that cannot be remotely phished. This stops the most common initial access vector in identity compromise.

What it doesn’t protect against: Token theft post-authentication, privilege misuse by legitimate users, or session hijacking after successful authentication.

Privileged Identity Management (PIM)

Protects against: Standing privileged access, privilege creep, and indefinite role assignments.

PIM ensures that administrative roles are temporary and intentional. Users must explicitly request elevation, providing justification and (optionally) approval. This creates an audit trail and limits the window of exposure.

What it doesn’t protect against: Compromised authentication before elevation, or actions taken during the approved time window. PIM governs authorization duration, not authentication validity.

Dedicated Admin Accounts

Protects against: Credential overlap between productivity and administrative contexts, and inconsistent policy enforcement.

When a user’s email account is compromised, a dedicated admin account ensures that breach doesn’t automatically extend to administrative capabilities. Separate accounts allow you to apply different Conditional Access policies, device requirements, and monitoring to administrative identities.

What it doesn’t protect against: Compromise of the dedicated admin account itself, or poor separation practices (like checking admin email from the same device).

Session Controls (Sign-In Frequency and Non-Persistent Sessions)

Protects against: Stale authentication context and long-lived session tokens.

Session controls ensure that privileged actions are performed using recent authentication proof, not tokens that were signed hours or days ago. Non-persistent sessions prevent browsers from caching privileged session state beyond the active window.

What it doesn’t protect against: Real-time session compromise while the user is actively authenticated, or authorization boundaries (that’s PIM’s role).

Device Ownership and Management

Protects against: Privileged access from personal or unmanaged devices, and administrative operations outside your organization’s control plane.

Device ownership ensures privileged access only originates from corporate-managed endpoints that meet compliance policy. It enforces separation between personal computing and administrative operations, enabling remote wipe, continuous monitoring, and policy enforcement.

What it doesn’t protect against: Compromised users on legitimate devices or local device-level attacks. Device signals establish accountability for the endpoint, not intent. This is core Zero Trust: never trust a device because it’s corporate-owned; validate it continuously, along with identity and session context.

Trusted Locations

Protects against: Privileged access from unexpected or untrusted networks.

By restricting administrative operations to known IP ranges or private endpoints, you prevent stolen credentials or tokens from being used outside your controlled infrastructure. This adds network-level context to identity decisions.

What it doesn’t protect against: Attacks originating from within the trusted network, or compromised devices connecting from approved locations.

Cloud-Only Admin Accounts

Protects against: Privilege synchronization across on-premises and cloud environments, and authentication bypass via weaker on-prem paths.

Cloud-only admin accounts cannot be compromised through on-premises Active Directory attacks, and they ensure that Entra ID Conditional Access policies cannot be bypassed by authenticating through legacy protocols or on-prem federation paths.

What it doesn’t protect against: Cloud-native attacks or compromise of the cloud admin account itself.

Protected Actions

Protects against: Post-compromise tampering with security controls.

Protected Actions restrict modifications to critical configurations (like Conditional Access policies) to specific contexts. This prevents an attacker with elevated privileges from immediately disabling the controls meant to contain them.

What it doesn’t protect against: Actions outside the scope of Protected Actions, or attacks that never attempt to modify security controls.

Why Removing Any Layer Creates Risk

Each of these controls addresses a different point in the attack chain. Removing one doesn’t just reduce your defense; it creates a specific, exploitable gap:

• Without PRMFA, stolen credentials provide direct access.

• Without PIM, that access is permanent.

• Without dedicated accounts, a compromised productivity identity becomes an admin identity.

• Without session controls, authentication from yesterday can authorize actions today.

• Without device ownership requirements, privileged access can occur from personal devices outside organizational control.

• Without trusted locations, stolen tokens work from anywhere.

• Without cloud-only design, on-prem compromise extends to cloud.

• Without Protected Actions, the first compromised admin can disable everything else.

  
  

The goal isn’t perfection in any single control. It’s ensuring that when one layer is bypassed (and it will be) the next layer is already in position.

Final Thoughts

Defense in depth for identity is not about redundancy. It is about resilience.

Every control you remove is an assumption that another will never fail, an assumption that rarely holds up in production. Identity assurance decays over time. Overlapping controls slow that decay by ensuring that every privileged action is both intentional and current. The goal is not one perfect layer; it is multiple imperfect layers that fail in different, predictable ways.

Zero Trust principles reinforce this approach: verify explicitly, use least privilege access, and assume breach. By implementing these controls together, you ensure that the entire system works as designed, keeping privilege temporary, context-aware, and traceable.