Zero Trust and Identity

What Zero Trust means in practice

Zero Trust is not a product you buy, a compliance checkbox, or a marketing label. It is an architectural approach that replaces implicit trust with explicit verification on every access request. The phrase was coined by Forrester Research in 2010, but the principles are older than the name: never trust, always verify.

In identity security, Zero Trust means that a user being inside the corporate network does not grant trusted status. A user having authenticated yesterday does not mean they should be trusted today. A user having a legitimate job role does not mean they should access every resource that role could theoretically need. Every access request is evaluated independently based on available signals — who is requesting, what they're accessing, from which device, from which location, at what risk level — and the minimum access necessary is granted for the minimum time necessary.

The kill chain from Section 0.5 demonstrates why this matters. Every stage of a successful identity attack exploits implicit trust — the initial access exploits trust in MFA completion, persistence exploits trust in legitimate API permissions, escalation exploits trust in standing privilege assignments, and lateral movement exploits trust in accumulated access rights. Zero Trust systematically eliminates each of these trust assumptions with explicit verification, time-limited access, and continuous monitoring.

The Entra ID features in this course are the implementation layer for Zero Trust identity. Conditional Access is the enforcement engine. Identity Protection provides real-time risk signals. Authentication methods determine verification strength. PIM enforces just-in-time privilege. Token protection ensures tokens can't be separated from the devices that earned them. Every configuration decision in this course maps to one of three principles.

Verify explicitly: every signal matters

The first principle is verify explicitly — authenticate and authorize based on all available data points. In traditional security, a user inside the VPN was implicitly trusted. In Zero Trust, every access request is evaluated regardless of where it originates.

Conditional Access is the implementation. Every sign-in to every cloud application is evaluated against all applicable policies. The signals Conditional Access evaluates include: user identity and group membership, which application is being accessed, the device platform and compliance state, the network location (trusted IP ranges, named locations, country), the sign-in risk level from Identity Protection (anomalous location, unfamiliar device, impossible travel), the user risk level (compromised credentials, anomalous behavior patterns), and the client application type (browser, mobile app, desktop app, legacy protocol).

A Conditional Access policy that requires MFA is a weak implementation of verify explicitly — it considers only one signal. A policy that requires phishing-resistant MFA from a compliant device within a trusted location for a user with no elevated risk is a strong implementation — it evaluates five signals simultaneously and blocks the request if any one fails.

The practical difference is measurable. A policy that requires "MFA" grants access to an attacker who completed MFA through an AiTM proxy. A policy that requires "phishing-resistant authentication from a compliant device" blocks that same attacker because phishing-resistant authentication rejects the proxy domain and the attacker's unmanaged device fails the compliance check. The same principle, different specificity, completely different security outcomes.

This is what a strong verify-explicitly policy looks like as a Graph API object — the structure you'll learn to design in EI4 and deploy in EI8:

{
  "displayName": "CA-002: Require phishing-resistant MFA + compliant device for admins",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": { "includeRoles": ["62e90394-69f5-4237-9190-012177145e10"] },
    "applications": { "includeApplications": ["All"] },
    "platforms": { "includePlatforms": ["all"] },
    "signInRiskLevels": [],
    "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": ["compliantDevice"],
    "authenticationStrength": {
      "displayName": "Phishing-resistant MFA"
    }
  }
}

This policy evaluates five signals (user role, application, platform, client type, device compliance) and requires two controls (phishing-resistant authentication AND a compliant device). The operator: "AND" is critical — it means both controls must be satisfied, not either. The policy is in report-only mode (enabledForReportingButNotEnforced) because you deploy in report-only first, verify the impact, then enforce. EI8 covers this deployment methodology.

Identity Protection adds real-time risk as a dynamic signal. Rather than making static decisions based on policies written months ago, risk-based Conditional Access adapts to what's happening right now. A user who normally signs in from London at 9 AM gets seamless access. The same user signing in from Lagos at 3 AM with an unfamiliar device and a medium-risk detection gets challenged for additional verification or blocked entirely. The policy didn't change — the signals changed, and the evaluation adapted. EI5 covers configuring and tuning these risk policies.

Authentication strength is the verification quality control. Entra ID's authentication strength feature lets you define named policies that require specific authentication methods — FIDO2, passkey, or certificate-based authentication — rather than generic "MFA." You can create an "Admin authentication strength" that requires only phishing-resistant methods, then apply it to Conditional Access policies targeting administrative roles. This ensures the verification meets the security requirement, not just the compliance checkbox. EI4 covers authentication strength design.

Use least privilege: limit the blast radius

The second principle is use least privilege — limit access to what's needed for the task, for the minimum time necessary. In the kill chain from Section 0.5, stages 3 through 5 succeed because the compromised identity has more access than it needs. Least privilege directly reduces the blast radius of any compromise.

PIM is the most direct implementation. A user who needs Global Administrator access once a month for a specific maintenance task has standing access 30 days out of 30 — and standing exposure for all 30 days. With PIM, the same user has eligible access, activates the role for a 2-hour window when needed, provides a justification, and has zero standing exposure for the remaining 29 days and 22 hours. If their account is compromised during the 29.9 days when the role isn't active, the attacker gets a standard user account, not Global Administrator. PIM also adds an activation requirement — the user must complete phishing-resistant MFA and provide a business justification — which creates an additional barrier and an audit trail.

Access reviews implement least privilege over time. Permissions accumulate as users change roles, join projects, and receive temporary access grants that become permanent by neglect. Without regular review, a 5-year employee may have permissions from 4 previous roles — none of which they still need. A compromised account with accumulated permissions gives the attacker access to resources across multiple departments and functions. EI12 covers designing access review campaigns that systematically identify and remove stale permissions on a recurring schedule.

Consent governance is least privilege for applications. When users can consent to application permissions without admin approval, every user is an attack surface for consent phishing. Blocking user consent and requiring admin approval through a consent workflow ensures that every application permission grant is reviewed by someone who understands the implications of Mail.ReadWrite.All or Directory.ReadWrite.All. EI9 covers consent governance design.

Application permissions are the most neglected least privilege domain. Service principals and application registrations accumulate broad permissions because developers request "everything they might need" during initial setup, and no one reviews them afterward. A service principal with Mail.ReadWrite.All and Directory.ReadWrite.All is a target that provides more access than most human administrators — and it authenticates with a client secret that has no MFA requirement. Workload Identity Premium licensing enables Conditional Access for these non-human identities, and EI10 covers the governance framework.

Assume breach: detect and contain

The third principle is assume breach — design the architecture as if the attacker is already inside. This doesn't mean accepting defeat. It means designing controls that work even after a compromise occurs.

Assume breach means that every defensive control should function even if the attacker has already compromised one account. Token protection works because even a compromised token is useless on a different device. Sign-in frequency forces re-authentication because a stolen session eventually expires — the attacker must re-authenticate, and the re-authentication evaluates current risk signals. Detection rules fire because the attacker's behavior deviates from the user's baseline. Auto-attack disruption in Defender XDR disables compromised accounts because the system treats a risky sign-in followed by inbox rule creation as a breach in progress, not an anomaly to investigate later.

The practical implementation starts with log routing. If your sign-in logs aren't flowing to Sentinel, you have no detection capability for identity attacks — the logs exist in Entra ID for 30 days, but without Sentinel you have no analytics rules, no automated response, and no correlation across signal sources. EI14 covers the log routing architecture that connects Entra ID telemetry to your SIEM.

Detection engineering builds on that foundation. Microsoft's built-in detections are broad but not tailored to your environment's specific risk profile. The detection rules in EI13 target the exact attack patterns from Section 0.4 — anomalous sign-in followed by inbox rule creation (AiTM→BEC), multiple failed sign-ins across many accounts from few IPs (password spray), service principal credential additions by non-owner accounts (workload identity persistence). These correlations between kill chain stages are what distinguish a detection program from a collection of alerts.

Continuous Access Evaluation is assume breach at the token level. Rather than trusting a token for its full lifetime, CAE enables the resource provider to check whether the security context has changed. A password change, user disable, or critical risk event triggers near-real-time token invalidation — even if the token hasn't expired. Incident response actions take effect immediately rather than waiting up to 90 minutes for token expiry, or up to 28 hours for CAE-enabled tokens without critical event evaluation.

// How many of your sign-ins are evaluated by Zero Trust controls?
// Compares sign-ins that hit CA policies vs those that don't
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "0"
| extend CAPoliciesApplied = array_length(ConditionalAccessPolicies)
| extend HasCAEvaluation = CAPoliciesApplied > 0
| summarize
    TotalSuccessful = count(),
    WithCAPolicy = countif(HasCAEvaluation),
    WithoutCAPolicy = countif(not(HasCAEvaluation))
| extend ZeroTrustCoverage = round(100.0 * WithCAPolicy / TotalSuccessful, 1)
// ZeroTrustCoverage should be as close to 100% as possible
// Sign-ins without CA evaluation bypass your Zero Trust controls entirely

This query measures your Zero Trust coverage — the percentage of successful sign-ins that were evaluated by at least one Conditional Access policy. Sign-ins without any CA evaluation bypassed your entire Zero Trust enforcement layer. These are the sign-ins where you're still trusting without verifying.

Common causes of coverage gaps include applications excluded from CA policies (often "Microsoft Azure Management" or custom applications), user groups not targeted by any policy (service accounts, break-glass accounts, guest users), sign-in flows that bypass CA evaluation (device code flow if not explicitly blocked, legacy authentication if not blocked), and service principal sign-ins (which require Workload Identities Premium licensing for CA coverage). Each gap is an implicit trust surface — a path an attacker can use that your Zero Trust controls don't evaluate.

The gap between your current coverage and 100% represents your implicit trust surface. Closing that gap — by adding CA policies for excluded applications, covering all user groups, blocking uncovered sign-in flows, and extending CA to workload identities — is the operational work of Zero Trust implementation. This course teaches you to close each type of gap systematically.

The maturity continuum

Zero Trust isn't binary — you don't flip a switch and become Zero Trust. Microsoft defines three maturity levels for identity Zero Trust: traditional, advanced, and optimal.

Traditional means password-only or password plus basic MFA with Security Defaults, no Conditional Access policies, no risk-based decisions, no PIM, and minimal logging. Most organizations start here. The implicit trust surface is enormous — every sign-in from any device at any location is treated the same.

Advanced means Conditional Access with MFA required for all users and all cloud applications, risk-based policies through Identity Protection, device compliance requirements for sensitive applications, PIM for administrative roles, and sign-in logs routed to a SIEM. This level eliminates the most common attack paths — password spray through legacy protocols, MFA fatigue through generic push, and standing privileged access.

Optimal means phishing-resistant authentication for all users (not just admins), Conditional Access with authentication strength policies, full token protection, continuous access evaluation, workload identity governance with Conditional Access for service principals, comprehensive detection rules correlated across kill chain stages, and automated response through Defender XDR attack disruption. At this level, implicit trust is minimized across human and non-human identities, and the architecture is designed to detect and contain breaches that bypass preventive controls.

This course takes you from wherever you are to optimal. The modules are sequenced along this path — EI2 and EI4 move you from traditional to advanced, and EI7 through EI14 move you from advanced to optimal. The KQL query above measures your progress: Zero Trust coverage percentage is the metric that tracks your position on this continuum.