Zero Trust and Identity

Introduction

Zero Trust is three principles and a maturity scale, and the useful part is that each principle maps to a control you either have or do not. This section is that mapping. You will finish able to place your own tenant on the scale, and to say which principle a given control actually serves.

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.

Each principle names a control rather than a posture.

  Verify explicitly    Conditional Access        ei03
  Use least privilege  PIM and access reviews    ei06, ei12
  Assume breach        detection, revocation     ei13, ei07

Each principle has a failure mode, and knowing the failure mode is what turns it from a slogan into a question you can ask of a tenant.

Verify explicitly means no implicit trust from network position, device ownership or a prior successful sign-in. It fails when no policy matches the sign-in at all, which is silence rather than a denial and appears in no report.

Least privilege means an identity holds what it needs for as long as it needs it. It fails when privilege is standing, because then taking it requires no exploit, per 0.5.

Assume breach means designing for the compromise that succeeds rather than only the one you prevent. It fails when the response is to reset the password, which leaves the session and the consent grant intact, per 0.4.

None of the three is a product. Each is a question about what a specific control in your tenant does today.

The third row is the one organizations skip, and the reason is structural rather than careless. The first two principles are things you deploy and the third is a thing you rehearse, so it produces no artifact anybody can point at until an incident, which is exactly the argument ARC402 11.1 makes about forensic readiness.

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 is not challenged at all. 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 rather than the compliance checkbox. EI4 covers authentication strength design.

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. ARC406 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 ARC406 covers the governance framework.

Bounding the reach is the half of least privilege that survives a compromise. Verification decides whether an identity gets in and least privilege decides how much getting in is worth, so the two principles answer different questions and neither substitutes for the other.

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. ARC406 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 ARC406 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 third principle is the one that changes the design conversation rather than adding to it.

Without it, the question is: how do we stop this happening? Every control gets measured on prevention, so a control that only helps afterwards reads as a cost with no benefit attached.

With it, the question becomes: when this happens, how much do they get and how fast do we know? That makes retention, per ARC402 11.1, and session revocation, per ei07, first-class design decisions rather than contingency.

Three things change concretely. Log retention becomes a design decision rather than a licensing default. Revoking sessions enters the playbook beside resetting passwords. And persistence gets looked for specifically, per 0.5, rather than assumed absent because nobody checked.

Assume breach is not pessimism. It is the only principle that produces controls for the case where the other two did their job and the tenant lost anyway.

The reframing in the second block is what makes the principle operational. A question about how much and how fast has answers you can measure, where a question about prevention only has a yes or a no, and the measurable version is what gets retention and revocation funded.

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 EI9 move you toward optimal. The KQL query above measures your progress: Zero Trust coverage percentage is the metric that tracks your position on this continuum.

The gap that defines the middle level is worth naming, because almost every tenant has it: legacy authentication still open somewhere, so a population is evaluated by nothing at all, per 0.3. A tenant can hold every Advanced control and have a route in that none of them sees.

The scale is not a score. Read it as which questions your tenant can answer, because that is what actually changes between the levels, and it is the thing you can test today without buying anything.

Reading it as questions rather than features is what stops the scale becoming a checklist. The difference between advanced and optimal is not a longer feature list but a shorter list of sign-ins nobody can account for, and that is measurable in a way a maturity label is not.

Placing the tenant takes minutes. Naming which principle is unserved is the part that produces work.

Zero Trust is three principles and each names a control you either have or do not. Verify explicitly is Conditional Access reading method, risk and device state, and it fails as silence when no policy matches a sign-in. Least privilege is PIM and access reviews, and it fails when privilege is standing, because then taking it requires no exploit. Assume breach is the one that gets skipped, and the reason is structural: the first two are things you deploy and the third is a thing you rehearse, so it produces no artifact until an incident. It is also the principle that changes the design question from how do we stop this to how much do they get and how fast do we know, which is the version with measurable answers. Read the maturity scale as which questions your tenant can answer rather than as a score.