1.1. The Shift from Perimeter to Zero Trust
💡 First Principle: Trust used to be a location — inside the corporate network meant trusted, outside meant untrusted. That assumption breaks the moment a single workload spans an Azure region, a SaaS app, a partner's API, and a personal device, because "inside the network" stops describing anything real. Zero Trust replaces location-based trust with per-request verification: every access attempt is evaluated on its own evidence, regardless of where it originates.
Without this shift, a compromised laptop on the corporate VPN would still be treated as fully trusted simply because of where it's plugged in — which is exactly how many real breaches spread. Zero Trust removes that free pass: identity, device health, and context all have to check out on every request, not just the first one.
The Zero Trust model rests on three working principles that show up constantly across the rest of this guide:
| Principle | What It Means in Practice |
|---|---|
| Verify explicitly | Authenticate and authorize based on all available signals — user identity, device, location, workload — every time, not once per session |
| Use least privilege | Grant only the access needed for the task, time-bound where possible (this is the whole idea behind PIM in 2.1.1) |
| Assume breach | Design as if an attacker is already inside — segment access, encrypt everything, and monitor for lateral movement rather than trusting the perimeter to keep them out |
⚠️ Exam Trap: Zero Trust is not a single product you enable — it's an architecture expressed through many individual controls (Conditional Access, managed identities, network segmentation, encryption). Exam scenarios that ask "which service implements Zero Trust" are usually testing whether you can name the specific control that fits the described gap, not a generic "Zero Trust" checkbox.
