The PAW, PIM and the Conditional Access setup and some Entra ID attack vectors

Table of Contents

My previous post was about Microsoft Enterprise Access Model (EAM) and the last section handled the two tenant model with bridge controls PIM and CA policies. 

I will shortly continue this. What is idea of PAW, PIM and CA setup.

This got little longer than I first thought because I added some MITRE ATT&CK Tactics & Techniques. Anyway I hope this some insight for someone.

A Privileged Access Workstation, PAW (Inside the Red Tenant box) is a hardened, dedicated device used only for administrative work, deliberately separated from the user’s everyday machine that browses the web and reads email, the two biggest infection vectors. It follows the “clean source” principle:
 
you should administer a secure system only from a system that is at least as secure, so PAWs are tightly locked down with application allowlisting, no general internet access, and strict managed baselines.
 
Privileged Identity Management (PIM) attacks the problem of standing privilege. Rather than an account permanently holding an admin role, the role is made eligible and must be activated just-in-time for a limited window, typically requiring justification, MFA, and sometimes approval, with everything logged. That shrinks the amount of always-on privilege an attacker could steal. 
 
Conditional Access is the policy engine that ties it together by gating access on signals:
*device compliance,
*user or sign-in risk,
*location,
*role,
so you can enforce, for example, that a privileged role can only be activated from a compliant PAW using phishing-resistant MFA.
 
Putting together, the pattern is:
*just-in-time privilege (PIM),
*exercised from a hardened origin device (PAW) and
*gated by policy (Conditional Access).
 

What does this mean?

This setup is designed to make administrator access safer by combining:

  • PAW = Privileged Access Workstation
  • PIM = Privileged Identity Management
  • Conditional Access = policies that control how and when sign-in is allowed

The idea is simple:

An admin should only perform privileged work from a secure device, under strict sign-in controls, and only receive admin rights temporarily when needed.

The administrator starts with a dedicated admin account

The admin has a privileged identity in Microsoft Entra ID.

Best practice is usually:

  • a normal user account for email and daily work
  • a separate admin account for privileged tasks

This reduces the chance that a compromise of the normal account gives away admin privileges.

The admin signs in from a PAW

 A PAW (Privileged Access Workstation) is a dedicated, hardened device used only for admin work.

Typical PAW characteristics:

  • managed and secured by IT
  • not used for casual browsing or email
  • restricted software
  • strong endpoint protection
  • monitored closely

Why this matters:
If admins use their everyday laptop for privileged work, malware or phishing on that laptop could capture admin credentials.

 Conditional Access checks whether sign-in is allowed

Before access is granted, Conditional Access evaluates the sign-in.

Typical checks include:

  • MFA is required
  • the device must be compliant and trusted
  • the device should be the approved PAW
  • optional checks for sign-in risk, location, or network
  • block access from unmanaged or non-admin devices

So Conditional Access acts like a security gate:

  • if the admin is on the right device and completes MFA, access can continue
  • if not, access is blocked

Entra ID authenticates the admin

Once the sign-in passes Conditional Access, Microsoft Entra ID authenticates the user.

At this point, the admin is signed in, but they may still not yet have active admin rights.

That’s where PIM comes in.

PIM gives admin rights only when needed

With Privileged Identity Management (PIM), the admin does not permanently hold powerful roles.

Instead, the admin is made eligible for a role, such as:

  • Global Administrator
  • Privileged Role Administrator
  • Azure Subscription Contributor
  • Exchange Administrator
  • another privileged role

When the admin needs to do a task, they activate the role.

Activation often requires:

  • MFA again
  • justification
  • ticket number
  • approval
  • limited activation time

This is called just-in-time elevation.

So instead of having permanent access all day, the admin only gets elevated rights:

  • for a specific reason
  • for a limited period
  • under audit

The admin accesses protected targets

After the privileged role is activated, the admin can work on protected systems such as:

  • Azure Portal / Azure subscriptions
  • Microsoft 365 admin centers
  • Entra admin center
  • privileged apps
  • servers or management platforms

The key point is:

Access to these admin targets happens only after the person used a secure PAW, passed Conditional Access, and activated the role through PIM.

End-to-end flow in one sentence

A privileged user signs in from a hardened PAW, passes Conditional Access checks like MFA and device compliance, then uses PIM to temporarily activate an admin role, and only then accesses sensitive admin resources.

Why this is secure

PAW reduces credential theft

Admin credentials are only used on a hardened device, which lowers the risk of them being stolen by malware or phishing.

Conditional Access enforces policy

Only approved devices, trusted conditions, and MFA-backed sign-ins are allowed.

PIM enforces least privilege

Admins do not have permanent high privilege. They only elevate when necessary.

Time-limited admin access reduces exposure

Even if an attacker got access later, the privileged role may already be gone.

Auditing is improved

PIM activations and sign-ins are logged, making it easier to review:

  • who elevated
  • when they elevated
  • why they elevated
  • what approvals were used

A practical example

Imagine an Azure admin needs to change access on a production subscription.

Without this model

They may log in from their normal laptop and keep permanent admin rights all day.

With this model

  1. They use their PAW
  2. They sign in with MFA
  3. Conditional Access confirms the PAW is compliant
  4. They open PIM
  5. They activate the needed Azure admin role for, say, 1 hour
  6. They make the change
  7. The privileged role expires automatically

That is much safer.

In short

This setup works by combining three layers:

  • PAW → secure device for admin activity
  • Conditional Access → allows admin sign-in only under approved conditions
  • PIM → gives admin rights only temporarily and only when needed

Together, they help:

  • reduce credential exposure
  • block risky admin sign-ins
  • enforce least privilege
  • improve auditability

Insecurities without these

Without PAW, PIM, and Conditional Access, the main problem is that privileged access becomes easier to steal, easier to reuse, and harder to contain. The attacker does not necessarily need to “hack M356/Azure” directly, they can compromise an administrator, their device, or their session and inherit the administrator’s access.

A useful way to think about it is:

Missing controlSecurity weaknessTypical attacker opportunity
No PAWAdmin credentials are used on ordinary endpointsPhishing, malware, credential dumping, token/session theft
No PIMPowerful roles remain permanently assignedCompromised account immediately has admin privileges
No Conditional AccessSign-ins are not sufficiently constrained by device, MFA, risk, location, etc.Stolen credentials can be used from attacker-controlled devices

 

Without PAW the administrator's workstation becomes an attack path

If an administrator performs privileged work from the same laptop used for email, web browsing, Teams, downloads, and normal office work, the attack surface is much larger.

An attacker may use phishing or malicious attachments to compromise the workstation. Once they have code running on that endpoint, they can potentially target cached credentials, browser sessions, authentication tokens, management tools, PowerShell sessions, or administrator activity.

A common attack chain looks roughly like:

Phishing → user workstation compromise → wait for admin login → steal credential/session → use privileged access

This is one of the reasons privileged workstations exist: they try to prevent a low-trust activity such as reading email from sharing the same security boundary as high-trust administrative activity.

Potential attack vectors include:

  • credential-stealing malware
  • browser/session-token theft
  • malicious browser extensions
  • credential dumping from a compromised endpoint
  • keylogging
  • adversary-in-the-middle phishing
  • malicious Office documents
  • drive-by downloads
  • remote-access malware
  • abuse of cached administrative credentials

The important architectural issue is credential exposure. A Tier 0 / control-plane credential should not appear on a workstation that attackers can reasonably compromise through normal user activity.

Without PIM compromise can immediately become privileged compromise

Suppose an account has permanent Global Administrator, Privileged Role Administrator, or Azure Owner rights.

If the attacker obtains that account or its active session, there is no additional privilege boundary to cross. The attacker already possesses the administrative authority.

This creates what is often called standing privilege.

For example:

Admin account compromised → account already has Global Admin → attacker immediately controls Entra ID

With PIM, the same account can instead be merely eligible. An attacker who steals the account may still have to overcome another set of controls before privilege can be activated.

Without PIM, attackers may exploit permanently assigned permissions to:

  • create new privileged accounts
  • add themselves to administrative roles
  • change authentication methods
  • alter Conditional Access policies
  • create credentials for applications or service principals
  • modify subscriptions and resource permissions
  • disable security controls
  • interfere with logging
  • establish persistence

The danger increases significantly if many administrators have permanent roles.

Without Conditional Access stolen credentials become portable

Conditional Access answers an important question:

Even if the username and password are correct, should this sign-in be allowed under these circumstances?

Without those policies, a stolen credential may be usable from almost anywhere.

For example:

Password stolen in Finland → attacker signs in from an unmanaged machine elsewhere → Azure accepts the authentication

Proper Conditional Access can add requirements such as a compliant device, phishing-resistant MFA, approved client, acceptable sign-in risk, or specific administrative access conditions.

Without it, common attack vectors include:

  • password spraying
  • credential stuffing
  • phishing
  • adversary-in-the-middle attacks
  • stolen session cookies
  • sign-in from unmanaged devices
  • sign-in from attacker-controlled virtual machines
  • legacy authentication, where still available
  • repeated authentication attempts from unusual locations

MFA alone does not solve everything

A frequent mistake is to assume:

“We have MFA, therefore the admin accounts are safe.”

MFA is important, but attackers have developed ways of attacking the authentication flow rather than simply guessing passwords.

Examples include phishing pages that proxy the real authentication session and steal the resulting session token. An attacker may also exploit already authenticated endpoints or stolen browser sessions.

That is why the stronger model combines controls:

PAW + phishing-resistant authentication + Conditional Access + PIM

rather than relying on MFA alone.

Session/token theft becomes particularly important

Modern cloud attacks increasingly involve tokens rather than passwords.

If an attacker obtains an authenticated session token, they may sometimes use the existing session without needing to know the password.

Consider this scenario:

Admin signs into Azure from normal laptop

↓

Laptop compromised

↓

Attacker steals browser/session token

↓

Attacker inherits authenticated Azure session

↓

If the account has standing privilege, attacker inherits privileged access

The combination of no PAW + no PIM therefore compounds the risk.

MITRE ATT&CK techniques for Entra ID session/token theft

Privilege escalation becomes much easier

An attacker rarely begins with the most privileged account. They may initially compromise an ordinary user and then search for a path upward.

Without strong privileged-access separation, they can potentially move through:

User → Helpdesk → Server admin → Identity admin → Global control

Examples of pathways they might abuse include overly broad group memberships, permanently assigned roles, exposed admin credentials, compromised management servers, service accounts, automation credentials, or weak application permissions.

This is the cloud equivalent of the lateral-movement problem that the old Tier 0/1/2 architecture tried to solve.

MITRE ATT&CK techniques for Entra ID privilege escalation & persistence

Persistence becomes easier after the first compromise

Obtaining access once is useful to an attacker. Establishing access that survives password changes is much more valuable.

With sufficient privilege, attackers may try to create alternative access paths such as additional identities, application credentials, authentication methods, role assignments, or other persistent authorization mechanisms.

The architectural concern is:

Initial compromise → privilege → persistence → difficult recovery

PIM and strong control-plane restrictions reduce the opportunity window for this.

MITRE ATT&CK now has an official Enterprise → Identity Provider matrix, and MITRE explicitly states that it covers cloud identity providers including Microsoft Entra ID and Okta. As of September 2026, it maps 9 tactics and 23 unique parent techniques to the Identity Provider platform.  Link

The worst case is an identity control-plane takeover

The most dangerous scenario is not losing one virtual machine. It is losing control of the identity system.

If an attacker obtains sufficiently powerful Entra ID administrative privileges, they may be able to affect access across:

  • Azure
  • Microsoft 365
  • applications using Entra authentication
  • administrative accounts
  • subscriptions
  • security tooling
  • potentially connected on-premises environments

This is why Entra ID privileged administration corresponds conceptually to Tier 0 / Enterprise Control Plane.

The attack can progress something like:

User endpoint compromise

→ admin credential/session theft

→ privileged Entra role

→ identity control-plane takeover

→ access to many downstream systems

That is precisely the type of escalation the privileged-access architecture is intended to prevent.

Comparing the protected and unprotected models

The difference can be summarized very simply:

Weak model

Normal laptop → admin login → permanent admin rights → Azure/M365

A compromise of the laptop or account can potentially expose everything downstream.

Protected model

PAW → Conditional Access → strong MFA/device validation → PIM activation → temporary privilege → Azure/M365

The attacker must cross multiple independent security boundaries.

This is the security principle of defense in depth.

FINALLY and in very short:

PAW protects the credentials.
Conditional Access protects the authentication path.
PIM protects the privilege.

Remove all three, and an attacker only needs to compromise one privileged identity or one privileged endpoint to potentially obtain a direct path toward the control plane.

That’s about it folks! This is the end of this study.

Picture of Jussi Metso
Jussi Metso

Author is a lifelong IT enthusiast, Microsoft Security MVP and interested in Cloud Security, XDR, SIEM and AI. Motto: Learning is the key for your future.

Discover more from Jussi Metso

Subscribe to get the latest posts sent to your email.

IDENTITY_ACCESS

Related Posts