In this module
EI0.7 Zero Trust and Identity
Figure EI0.7 — Operational workflow from input through documented output.
Figure — Zero Trust and Identity.
What Zero Trust means in practice
Zero Trust is not a product you buy. It is not a single technology. It is not a compliance checkbox. Zero Trust is an architectural approach to security 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 the context of identity security, Zero Trust means that a user being inside the corporate network does not grant them trusted status. A user having successfully authenticated yesterday does not mean they should be trusted today. A user having a legitimate job role does not mean they should have access to every resource that role could theoretically need. Every access request is evaluated independently based on the available signals — who is requesting access, what they are accessing, from which device, from which location, at what risk level — and the minimum access necessary is granted for the minimum time necessary.
This is not theoretical. The Entra ID features covered in this course are the implementation layer for Zero Trust identity. Conditional access policies are the enforcement engine. Identity Protection provides the real-time risk signals. Authentication methods determine the strength of identity verification. PIM enforces just-in-time access for privileged roles. Token protection ensures tokens cannot be separated from the devices that earned them.
Verify explicitly: every signal matters
The first Zero Trust principle is verify explicitly — authenticate and authorize based on all available data points, including user identity, location, device health, service or workload, data classification, and anomalies.
In Entra ID, "verify explicitly" means conditional access policies that evaluate multiple signals simultaneously, not just whether the user has a valid credential. A conditional access policy that simply requires MFA for all users is a start, but it is not Zero Trust — it verifies one signal (the user can complete MFA) and ignores everything else.
// KQL: Verify that conditional access policies are evaluating multiple signals
// This query identifies sign-ins where no conditional access policy applied
// — a gap in your Zero Trust enforcement
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0 // Successful sign-ins only
| where ConditionalAccessStatus == "notApplied"
| project TimeGenerated, UserPrincipalName, AppDisplayName,
IPAddress, Location, DeviceDetail, RiskLevelDuringSignIn
| order by TimeGenerated descUse least privilege access: limit the blast radius
The second Zero Trust principle is least privilege — provide just enough access for the user to complete their task, and no more. When combined with just-in-time access, this means privileges exist only when they are actively needed and are automatically removed when the task is complete.
In Entra ID, least privilege manifests in several layers. At the directory role level, PIM (EI6) replaces standing administrator assignments with eligible assignments that require explicit activation. A user who needs Global Administrator access to perform a specific task activates the role through PIM — providing a justification, completing MFA, and receiving the role for a limited duration (typically 1-4 hours). When the activation expires, the role is automatically removed. The user has Global Administrator access for the minimum time necessary, not permanently.
// KQL: Find users with standing (permanent) privileged role assignments
// — violations of the least privilege principle
AuditLogs
| where OperationName == "Add member to role"
| where TargetResources[0].modifiedProperties has "permanent"
| project TimeGenerated,
InitiatedBy.user.userPrincipalName,
TargetResources[0].userPrincipalName,
TargetResources[0].modifiedProperties
| order by TimeGenerated descAssume breach: detect and contain
The third Zero Trust principle is assume breach — minimize blast radius and segment access. Verify end-to-end encryption. Use analytics to get visibility, drive threat detection, and improve defenses.
This principle is the most uncomfortable for organizations to internalize because it requires accepting that the preventive controls will eventually fail. No matter how strong your MFA, how comprehensive your conditional access policies, and how restrictive your consent governance — eventually an attacker will get in. The question is not whether a breach will occur but how quickly you detect it and how much damage the attacker can do before containment.
// KQL: Find accounts flagged as high risk that have not been remediated
// — the assume breach principle requires acting on risk signals
AADRiskyUsers
| where RiskLevel == "high"
| where RiskState == "atRisk" // Not yet remediated
| project RiskLastUpdatedDateTime, UserPrincipalName,
RiskLevel, RiskDetail, RiskState
| order by RiskLastUpdatedDateTime descThe Zero Trust maturity continuum
Zero Trust is not a binary state — you do not wake up one morning with a Zero Trust architecture. It is a maturity continuum where each improvement reduces risk and each module in this course moves you along the path.
The starting point for most organizations is implicit trust: passwords with optional MFA, no conditional access, standing admin assignments, unrestricted application consent, no sign-in log monitoring. Every access request from every user is trusted after a single authentication event. At this level, any of the seven attack techniques described in EI0.5 will succeed. This is where the majority of small and mid-size organizations sit today — and it is the level at which the breaches in EI0.8 occurred.
Try it yourself
Try It — Assess Your Zero Trust Maturity
Exercise: For your environment (production or developer tenant), answer these questions to estimate your current Zero Trust maturity level:
1. Is MFA required for all users on all applications? (Basic verification) 2. Do your conditional access policies evaluate device compliance and network location? (Signal-aware access) 3. Is legacy authentication blocked? (Basic verification) 4. Is Identity Protection enabled with risk-based policies? (Signal-aware access) 5. Are privileged roles managed through PIM with just-in-time activation? (Comprehensive control) 6. Is user consent for applications blocked with admin consent workflow? (Comprehensive control) 7. Are sign-in logs routed to a SIEM with active detection rules? (Comprehensive control) 8. Is phishing-resistant authentication deployed for privileged and high-risk users? (Comprehensive control)
Count your "yes" answers: 0-2 = implicit trust, 3-4 = basic verification, 5-6 = signal-aware access, 7-8 = comprehensive control. This tells you where you are and which modules to prioritize.
The myth: Zero Trust means treating every user as a potential attacker. Our employees will feel surveilled and mistrusted.
The reality: Zero Trust does not mean distrust — it means verified trust. Users who authenticate with strong credentials from compliant devices in expected locations experience seamless access. The additional verification only triggers when something is unusual — a new location, a new device, an elevated risk signal. Done well, Zero Trust is invisible to users in their normal workflow and only introduces friction when the context genuinely warrants it. The goal is to protect users from having their accounts exploited, not to obstruct their work. EI3 covers how to design conditional access policies that balance security enforcement with user productivity.
You are reviewing NE's Entra ID security posture. You find 4 accounts with Global Administrator role, but NE's policy says maximum 2. The extra 2 were added during the AiTM incident for emergency response and never removed. Do you remove them?
Remove them — but through the proper process, not unilaterally. Notify the account owners that their emergency GA assignment is being revoked, confirm they have their standard role assignments restored, and document the removal with the rationale ('emergency assignment during INC-NE-2026-0227-001, no longer required'). Then add a PIR action item: 'Implement PIM time-limited role assignments for future incident response — emergency GA assignments auto-expire after 8 hours rather than persisting indefinitely.' The stale emergency assignment is a governance failure, not a technical failure — the fix is procedural.
You've mapped the identity threat landscape and learned to read sign-in logs.
EI0 established that every cloud attack starts with identity. EI1 took you through the signal that matters most — interactive, non-interactive, service principal, and managed identity sign-ins. Now you engineer the defences.
- 17 engineering modules — authentication methods, conditional access architecture, Identity Protection, PIM, token protection, application governance, and detection rules
- The Defense Design Method — the six-step framework applied to every identity control you'll build
- EI18 Capstone — Identity Security Architecture Design — design complete identity architectures for three realistic organisations (SMB, mid-market, regulated enterprise)
- Identity Security Toolkit lab pack — deployable conditional access policies, PIM configurations, and Identity Protection risk rules
- Cross-domain detection (EI16) — email-to-identity correlation and the full phishing-to-inbox-rule attack chain