12.1 The Zero Trust Model
Key Takeaways
- Zero Trust is a security strategy — never trust, always verify — not a single Microsoft product you buy or turn on
- The three official principles are verify explicitly, use least privilege access, and assume breach
- Verify explicitly means every access request is authenticated and authorized using all available signals, not just a one-time sign-in on the office network
- Least privilege gives users and workloads only the access they need for the shortest time required, often with just-in-time and just-enough-access
- Assume breach designs controls as if an attacker might already be inside, so you segment access, encrypt, monitor, and limit blast radius instead of trusting the castle-and-moat perimeter
Quick Answer: Zero Trust is a security strategy, not a SKU. Official Microsoft language is never trust, always verify. The three principles are verify explicitly (authenticate and authorize every request using all available signals), use least privilege access (only the access needed, for the shortest time), and assume breach (design as if an attacker might already be inside). That replaces castle-and-moat / implicit trust, which assumed that being on the corporate network made a user or device safe.
The April 30, 2025 MS-900 outline asks you to describe the Zero Trust Model. This is a vocabulary and contrast skill. You will not be asked to write a Conditional Access JSON, size a hub-and-spoke VNet, or deploy a Zero Trust workshop. You will be asked what the three principles are, how Zero Trust differs from a perimeter firewall, and which Microsoft 365 capability is an example of a principle — not which click path implements the whole strategy.
MS-900 retired on March 31, 2026. The last official skills outline is still the April 30, 2025 list. Zero Trust sits in the Describe security, compliance, privacy, and trust domain (25–30%). Keep this section at fundamentals depth. Chapter 10 already covered Entra ID, multifactor authentication (MFA), and Conditional Access. Chapter 11 covered Defender XDR. This section names those products only as examples of the strategy.
What Zero Trust is — and is not
Official Learn (Zero Trust as a security foundation, updated 2026) opens with a simple idea: never trust, always verify. Access is granted only after you check who is requesting access, what device they are using, their location and behavior, and their risk level. Verification is continuous. A successful sign-in at 9:00 a.m. does not make every later request automatically trusted.
Zero Trust is not a product. You cannot buy “Microsoft Zero Trust” the way you buy Exchange Online. It is an approach for designing and operating security controls. Microsoft 365, Microsoft Entra ID, Intune, Microsoft Purview, and Microsoft Defender XDR are tools you use to apply the strategy. If a question stem says “which Microsoft product is Zero Trust,” the stem is trying to trap you. The answer is that Zero Trust is the model; the products implement pieces of it.
When the strategy is applied consistently, official outcomes replace trust-by-default with trust-by-exception:
- Access is explicitly granted and continuously evaluated.
- Access is conditional and temporary.
- Permissions are tightly scoped.
- Controls apply the same way on-premises, in the cloud, in SaaS apps, and for modern AI workloads.
- Detection and response are built in, not bolted on after a breach report.
Castle-and-moat versus Zero Trust
The older model is often called castle-and-moat, perimeter security, or implicit trust. The idea was simple: build a strong network boundary (the moat). Anyone who got onto the corporate LAN, or who connected through a virtual private network (VPN), was treated as safer than someone on the public internet. Firewalls, on-premises Active Directory, and “you are in the building, so you can open the file share” were the everyday version of that model.
That model worked against older threats such as network scanning from outside the office. It fails against the threats Microsoft calls out as typical today: identity compromise, phishing, and session hijacking. Those attacks do not need to smash the firewall. They steal or trick a valid identity, then walk in through the front door. A stolen password used from a coffee shop, a phishing kit that captures an MFA session, or malware on a home PC that already has a VPN client — none of those look like “outside the castle.”
Official Learn is explicit about the replacement:
- Treat every access request as untrusted regardless of origin.
- Make decisions from real-time context, not from “this IP is on the office subnet.”
- Protection follows the asset — the user, device, app, and data — not the building.
In Microsoft 365 this matters because Exchange Online, SharePoint, Teams, and most SaaS apps already live outside a corporate LAN. Hybrid and flexible work (Chapter 3) made the old perimeter even less useful: the employee, the laptop, and the data are often not on a network you own.
| Older implicit-trust assumption | Zero Trust replacement |
|---|---|
| Inside the office network equals trusted | Every request is untrusted until verified |
| A VPN connection is enough | Identity, device health, location, and risk are evaluated together |
| One successful sign-in lasts the day | Access is re-evaluated as conditions change |
| Broad standing admin rights | Least privilege, often just-in-time |
| Detect after the attacker leaves | Assume they might already be inside; limit lateral movement |
The three official principles
Memorize the official names and the official one-line meanings. Wording on the exam is closer to Learn than to a blog paraphrase.
| Principle | Official implementation idea | Everyday Microsoft 365 example |
|---|---|---|
| Verify explicitly | Every access request is authenticated and authorized using all available signals | Conditional Access looks at user, device compliance, location, and sign-in risk before Exchange Online opens |
| Use least privilege access | Users and workloads get only the access they need, for the shortest time required | A helpdesk account is Helpdesk Administrator, not Global Administrator; privileged roles can be time-bound |
| Assume breach | Controls expect that attackers might be operating inside the environment; limit impact and detect fast | Segment access, encrypt data, watch audit and Defender signals instead of trusting “they are already in” |
Verify explicitly is more than “turn on a password.” Official Azure Zero Trust language: always authenticate and authorize based on all available data points, including user identity, location, device health, and service or workload. In Microsoft 365 the usual engine is Microsoft Entra Conditional Access sitting in front of cloud apps. MFA is one signal. Device compliance from Intune is another. A risky sign-in from an unusual country is another. The principle is use the signals, not trust the network location.
Use least privilege access limits standing rights. Official wording includes just-in-time (JIT) and just-enough-access (JEA), risk-based adaptive policies, and data protection. On MS-900 you already met this idea as admin roles in the Microsoft 365 admin center: Reports Reader to view usage, not Global Administrator. Privileged Identity Management and entitlement management are the deeper Entra features; the exam wants the idea — grant the minimum, for the shortest time — not a PIM activation walkthrough.
Assume breach is the principle people skip. It does not mean “you have already been hacked, so give up.” It means design as if an attacker might already have a foothold. Official language: minimize impact, segment access, verify end-to-end encryption, and use analytics for visibility, threat detection, and better defenses. If one mailbox is compromised, the attacker should not automatically own every SharePoint site and every admin role. Segmentation, encryption, monitoring, and rapid response are the assume-breach toolkit.
Technology pillars — conceptual, not SC-900 depth
Microsoft organizes Zero Trust work into technology pillars — the places you apply the three principles. For MS-900, name the classic six and know one sentence each. Do not turn this into a deployment workshop.
| Pillar | What you protect | Fundamentals example |
|---|---|---|
| Identities | People, admins, and workload identities | Entra ID, MFA, Conditional Access, least-privileged roles |
| Devices / endpoints | PCs, phones, and their health | Intune compliance before a cloud app opens |
| Apps | How data is reached | Modern authentication; session and app controls instead of “any app on the LAN” |
| Data | The file, mail, or record itself | Sensitivity labels, encryption, and data loss prevention (next two sections) |
| Infrastructure | Servers, VMs, cloud services | Harden configuration and access; do not treat a subnet as trusted |
| Network | Connectivity and movement | Segment traffic; a VPN is a path, not a trust stamp |
Current Microsoft adoption guidance also lists security operations (SecOps) — visibility, automation, and orchestration — as a pillar that operationalizes the others. Defender XDR and the unified audit log live there conceptually. MS-900 still tests the six asset pillars plus the three principles. If a question asks for the principles, do not answer with pillar names. Principles are verify / least privilege / assume breach. Pillars are where you apply them.
Identity is the usual control plane. Official Azure Zero Trust text: most journeys start with access control and treat identity as the preferred primary control. Network security still matters, but it is no longer the dominant “you are inside, so you are fine” switch. That is why Chapter 10 sits next to this chapter: Conditional Access is how Microsoft 365 does verify-explicitly for SaaS apps. It is not the entire Zero Trust program.
Realistic exam-style scenarios
VPN is not enough. A company still says “if the laptop is on the corporate VPN, open SharePoint.” That is castle-and-moat. Zero Trust still allows the VPN as a connection, but Entra should evaluate the user, the device’s compliance state, and risk before the library opens.
Name the principle. “Always authenticate and authorize based on user, device, location, and risk” is verify explicitly. “Helpdesk gets password-reset rights for eight hours, not Global Administrator forever” is least privilege. “Encrypt the file and watch for unusual downloads because a stolen token might already exist” is assume breach.
Hybrid work. Employees open Teams from home Wi-Fi, airports, and a branch office. Zero Trust does not require them to be in the headquarters LAN. It requires a verified identity, a healthy device when policy says so, and scoped access to the data they actually need.
Wrong product answer. “Buy Defender and you have implemented Zero Trust” is false. Defender is a threat-protection family (Chapter 11). It supports assume-breach detection. It does not replace identity verification or least privilege.
Exam traps
- Zero Trust is a strategy, not a SKU. Naming Entra, Intune, or Defender is naming implementations, not the model itself.
- Do not confuse principles with pillars. Three principles. Six (plus SecOps) pillars.
- Castle-and-moat is the old model. Implicit trust of the internal network is what Zero Trust replaces.
- Verify explicitly is not “passwords only.” It is all available signals, continuously.
- Least privilege is not “nobody gets access.” It is the minimum access, for the shortest time.
- Assume breach is not fatalism. It is segmentation, encryption, monitoring, and limited blast radius.
- This is not SC-900. You describe the model. You do not design microsegmentation for every subnet.
Official sources
- Zero Trust as a security foundation — never trust, always verify; three principles; trust-by-exception
- Zero Trust deployment for technology pillars — identities, endpoints, data, apps, infrastructure, network, SecOps
- Zero Trust security in Azure — verify explicitly / least privilege / assume breach wording; shift from perimeter to identity
- Study guide for Exam MS-900 — Describe the Zero Trust Model
A security lead says anyone on the corporate LAN or VPN should be treated as trusted, and that extra checks are only for people on the public internet. Which statement correctly describes Microsoft’s Zero Trust model instead?
Which official Zero Trust principle is implemented when users and workloads receive only the access they need, for the shortest time required, often with just-in-time and just-enough-access?
A Conditional Access policy requires a healthy Intune-compliant device, a low-risk Microsoft Entra sign-in, and multifactor authentication before Outlook on the web opens. Which Zero Trust principle is that policy mainly demonstrating?
Why does Microsoft include assume breach as a Zero Trust principle?