Microsoft Entra ID & Conditional Access: — The Identity Firewall for the Cloud

① Identity is the perimeter — the cloud control plane

Picture Sneha, an L1 cloud-support engineer at Infosys. Ten years ago, "secure the company" meant guarding the network perimeter — a hardware firewall around the office, a VPN to get inside, and the rule "if you're on the inside network, you're trusted." But Sneha's company now runs on Microsoft 365, Azure and a dozen SaaS apps. Those apps don't live behind her firewall anymore — they live on the public internet, and every employee logs into them from home, a cafe, or a phone.

So where is the wall now? There isn't a network one. When the apps and the users are both on the internet, the only thing standing between an attacker and the data is the login. That is the shift this whole lesson rests on: identity is the new perimeter, and the control plane — the place security decisions get made — moved from the network edge to the identity layer.

The system that owns that identity layer for Microsoft is Microsoft Entra ID — which you will still hear called by its old name, Azure Active Directory (Azure AD). Entra ID is the identity provider (IdP) that sits in front of M365, Azure and SaaS: when you sign in to Outlook or the Azure portal, you are really signing in to Entra ID, which then issues a token the app trusts.

Entra ID doesn't just hold human users. Learn this cast — interviews and the exam test it: Users (people like Sneha) and Groups (bundles you assign access to, so you manage 5,000 people as 12 groups). App registrations let your own or third-party apps use Entra ID to sign people in. A service principal is the "user account for an app." And a managed identity is a passwordless identity Azure gives a resource (like a VM) so it can call other services without a secret in code — the cure for hard-coded keys.

The four identity types in Entra ID

Tap each card — these are the objects you will create, assign and troubleshoot every day, and they show up across SC-300 and AZ-500.

② Conditional Access — the if-then policy engine

Here is the one sentence that unlocks Conditional Access: a CA policy is an if-then statement. IF these signals are true, THEN apply these controls. That's it. Everything else is detail. Microsoft's own docs describe it as combining signals to make a decision and enforce a policy.

The signals (the IF side, called Assignments and Conditions in the portal) include: user or group (who), device state (managed/compliant or not), location (the IP and country the sign-in comes from), the app being accessed, the client app, and the sign-in risk. The controls (the THEN side) include: require MFA, require a compliant device, require a hybrid-joined device, block access, or session limits.

Two rules about how they combine, both exam-favourites. First, all assignments combine with AND — if a policy targets "admins" and "the Azure portal," the user must be an admin and hitting the Azure portal for it to fire. Second, when several policies apply, all of them must be satisfied, and if any matching policy says block, block wins. Enforcement runs in two phases: phase 1 collects the signals (this also happens for report-only policies), and phase 2 enforces — block stops first, otherwise the user is prompted for the missing controls in a fixed order (MFA, then compliant device, then hybrid join…).

You can also drive Conditional Access as code — useful for review, version control and the exam's automation angle. Here is the same "require MFA for admins" idea expressed as a Microsoft Graph policy body, the shape the portal saves behind the scenes.

# Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$params = @{
  displayName = "CA002 - Require MFA for admins"
  state       = "enabledForReportingButNotEnforced"   # report-only
  conditions  = @{
    users        = @{ includeRoles = @("62e90394-69f5-4237-9190-012177145e10") }  # Global Admin
    applications = @{ includeApplications = @("All") }
  }
  grantControls = @{ operator = "OR"; builtInControls = @("mfa") }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Id                                   DisplayName                    State
--                                   -----------                    -----
8f3c1a92-...-4d2e-bb7a-19c0e7f2a6b1  CA002 - Require MFA for admins enabledForReportingButNotEnforced

③ Risk-based access & Zero Trust

So far the signals were static facts (who, what device, where). The most powerful signal is dynamic: how risky does this sign-in look right now? That comes from Microsoft Entra ID Protection, which runs machine-learning models over Microsoft's sign-in telemetry and produces two scores.

Sign-in risk rates a single login attempt: is this an impossible-travel case, an anonymous/Tor IP, an unfamiliar device, a token-replay? User risk rates the account itself over time: did this user's credentials show up in a leaked-credentials dump, or is there a pattern of risky activity? Each is scored low / medium / high.

Now the clever part: risk-based Conditional Access uses those scores as the IF. A common pair: IF sign-in risk is high → require MFA (prove it's really you), and IF user risk is high → require a secure password change (the credential may be in attackers' hands, so rotate it). Microsoft is moving the legacy Identity-Protection risk policies into Conditional Access — the standalone risk policies retire on 1 October 2026, so build new ones in CA where you get report-only mode and Graph APIs.

This is Zero Trust in practice. Zero Trust has three rules, and Conditional Access implements each one directly. Verify explicitly — check identity, device, location and risk on every request (that's the signals). Use least privilege — grant only what's needed, with session limits and just-in-time access. Assume breach — treat a risky sign-in as already compromised and demand more proof or block. In NIST SP 800-207 terms, the CA engine is the Policy Engine (it decides) and Entra ID is the Policy Enforcement Point (it acts).

④ Building safe policies — baselines, break-glass & gotchas

Now you build. A sane starting estate is a small set of baseline policies that every Microsoft identity guide recommends. (1) Block legacy authentication for all users. (2) Require MFA for admins (all the privileged directory roles). (3) Require MFA for all users. (4) Risky sign-in → require MFA (and risky user → password change). Many tenants now also get Microsoft-managed policies rolled out automatically in report-only — review and adopt those too.

Why is block legacy authentication rule number one? Old protocols — IMAP, POP3, SMTP AUTH, the Office 2010-era clients — cannot perform MFA. So if you require MFA for users but leave legacy auth open, an attacker just connects over IMAP with the phished password and skips MFA entirely. Microsoft's own data attributes more than 99% of password-spray attacks to legacy authentication. Leaving it on turns your MFA into a front door with the back door propped open.

The single most important safety step before you enforce anything: the break-glass (emergency access) account. Microsoft recommends two cloud-only Global Admin accounts that you exclude from every blocking CA policy, protect with phishing-resistant MFA (FIDO2), and alert on for every single use. Without this, one typo in a block policy can lock out all your admins — a real, common disaster.

Two more building blocks. Named locations let you define your office IP ranges or specific countries once and use them as a signal (e.g. "block sign-ins from countries we never operate in"). But location is a weak signal — IPs can be spoofed or proxied — so use it to reduce friction, never as the only gate. And remember the legacy-auth backdoor: if any policy or app still allows basic auth, your strongest MFA policy can be sidestepped, so the block-legacy-auth policy underpins all the others.

az ad signed-in-user show --query userPrincipalName -o tsv
# review last 24h of legacy-auth sign-ins (clientAppUsed = IMAP/POP/SMTP/Other)
az monitor activity-log list --offset 24h \
  --query "[?contains(operationName.value,'Sign-in')].{user:caller, app:properties.clientAppUsed, result:status.value}" \
  -o table

UserPrincipalName
sneha.k@infosys-tenant.onmicrosoft.com

User                              App                    Result
--------------------------------  ---------------------  -------
rahul.m@infosys-tenant...         Browser                Success
svc-backup@infosys-tenant...      Other clients (legacy) Failure  <- blocked by CA001