Skip to main content
AD Academy
Microsoft Entra ID (Azure AD)
Intermediate13 minLast updated: Topic 3 of 6

Protecting access: Conditional Access, MFA and PIM

How cloud identities are protected and what to check when something looks suspicious.

Not read

What you will learn here

  • How a Conditional Access rule is built
  • When to use PIM and why
  • Where to look for suspicious sign-in events

Worth reading first:What Entra ID is and how it differs from AD DS

In the cloud there is no network perimeter — identity is the perimeter. That is why the main control in Entra ID is Conditional Access: a policy that evaluates who signs in, from where and on which device before granting access.

Anatomy of a Conditional Access rule

  • Assignments — who it applies to: users, groups, admin roles.
  • Conditions — from where: location, device platform, sign-in risk level.
  • Access controls — what is required: MFA, a compliant device, or a full block.
  • Report-only — a test mode that shows the impact without blocking real users.

Additional layers

  • MFA — multi-factor authentication; Authenticator or FIDO2 beats SMS.
  • PIM (Privileged Identity Management) — just-in-time admin rights on request and approval instead of standing Global Admin.
  • Identity Protection — detects risky sign-ins: impossible travel, password spray, leaked credentials.
  • Security defaults — a baseline protection set for small organizations without advanced licensing.
# View recent user sign-ins (Microsoft Graph PowerShell)
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'user@contoso.com'" -Top 20 |
  Select-Object createdDateTime, appDisplayName, ipAddress, status

# Who holds administrative roles
Get-MgDirectoryRole | ForEach-Object { $_.DisplayName }
powershell

Signals on the left: user and group, device state, location and IP, sign-in risk, target application. They all feed the Conditional Access policy engine. On the right the possible outcomes: grant with MFA, require a compliant device, or block access outright. The rule is never trust, always verify. The bottom bar covers privileges after sign-in: RBAC by role, PIM for just-in-time admin rights, and managed identities instead of secrets in code.

Short and clear

  • In the cloud identity is the perimeter — every request is re-verified, even from 'inside'.
  • Conditional Access weighs signals: user, device, location, risk and application.
  • Outcome: allow with MFA, require a compliant device, or block.
  • After sign-in, privileges decide: least-privilege RBAC, time-bound PIM and managed identities.

Real-life exampleAn admin signs in to the Azure portal from a personal laptop abroad and is blocked; from the managed device they pass MFA and elevate for 4 hours through PIM.

Check yourself

What is PIM used for in Entra ID?

What should you do before enabling a new Conditional Access policy?

Was this page helpful?