Zero Trust
A security model built on the principle “never trust, always verify”. Instead of one large “secure network”, every access is checked individually. Zero Trust matters particularly in DaaS environments — because the resources sit outside the classic perimeter by definition.
What is Zero Trust?
Zero Trust is a Security model built on one simple premise: A network is never safe, not even your own. Every access to every resource has to be verified explicitly — even when the person accessing it is already “inside”.
The term was coined in 2010 by John Kindervag at Forrester. He was responding to a historical pattern: classic security rested on the Castle-and-moat model — a tall castle with a deep moat around it. Whoever is inside is trusted.
That model fails in the modern world: mobile users, SaaS applications, BYOD, cloud services, supply chain attacks. There is no clear inside any more.
The three Zero Trust principles
| Principle | What it means | In practice |
|---|---|---|
| Verify Explicitly | Every access is checked (user plus device plus context) | MFA, Conditional Access, Device Compliance |
| Use Least Privilege Access | The minimum necessary rights, just in time, just enough | Privileged Identity Management (PIM), RBAC |
| Assume Breach | Assume an attacker is already inside the system | Segmentation, Encryption, Monitoring, Threat Detection |
What that means in practice
- Even an authenticated user may not reach everything (least privilege)
- Coming from the “internal network” grants no blanket trust either (assume breach)
- Every session is assessed — not only at the first sign-in (verify explicitly)
The 6 Zero Trust pillars (Microsoft)
Microsoft structures Zero Trust into six pillars — protective columns that together make a complete strategy:
| Pillar | Focus | Microsoft tools |
|---|---|---|
| 1. Identities | Who is accessing? | Entra ID, MFA, PIM, Conditional Access |
| 2. Endpoints | Which device? | Intune, MDE, Defender for IoT |
| 3. Applications | Which application? | Defender for Cloud Apps, App Protection Policies |
| 4. Data | Which data? | Purview, Sensitivity Labels, DLP |
| 5. Infrastructure | Where do the services run? | Defender for Cloud, Azure Policy |
| 6. Network | How is the connection made? | Azure Firewall, Private Endpoints, Entra Private Access |
Why DaaS and Zero Trust fit each other so well
DaaS environments are practically predestined for Zero Trust. The reason: there is no classic perimeter left to cling to.
Why the fit is so good
- Users sit everywhere: home, a café, a hotel — not in the “secure company network”
- Cloud PCs are external by definition as far as traditional IT is concerned — Zero Trust is the right approach
- Session context matters more than network location — who, on which device, in which session?
- Several levels of trust: internal desktop sessions ≠ guest access via browser ≠ admin session
A typical Zero Trust DaaS pattern
- Sign-in requirement — Windows Hello for Business or FIDO2 (phishing-resistant)
- Device verification — only on Intune-compliant devices
- Location check — Conditional Access checks country and network
- Risk evaluation — P2 Identity Protection assesses sign-in risk
- Continuous Re-Eval — during the session (continuous access evaluation)
- Session scope — browser session vs. desktop vs. admin scope
- App-level policies — separate rules per app
- Data protection — sensitivity labels prevent data export
How to put Zero Trust into practice
Zero Trust is not a single technology but a process of maturing. Microsoft’s Zero Trust Maturity Model distinguishes four stages:
| Stage | Description | Typical measures |
|---|---|---|
| 0. Traditional | Perimeter-based, static | VPN, firewall, passwords |
| 1. Initial | First Zero Trust steps | MFA, Basic Conditional Access |
| 2. Advanced | Zero Trust in core processes | Intune compliance, device-based CA |
| 3. Optimal | Zero Trust everywhere, automated | Identity Protection, MDE XDR, CAE |
Starter roadmap (heavily simplified)
- Enable MFA for everyone (months 1 to 2)
- Block legacy authentication, baseline Conditional Access (months 2 to 3)
- Enrol every device in Intune, with compliance policies (months 3 to 6)
- Enable device-based Conditional Access (months 4 to 6)
- Introduce PIM for administrator roles (months 5 to 7)
- Defender for Endpoint + Identity Protection (months 6 to 9)
- App Protection Policies + Data Classification (months 9 to 12)
- Continuous Access Evaluation, Advanced Hunting (from month 12 onwards)
Zero Trust is never finished — it is a journey of continuous improvement.
Zero-Trust-Patterns in DaaS Maps
DaaS Maps shows Zero Trust architecture patterns for the different DaaS platforms. For strategic discussion of Zero Trust rollouts and maturity assessments, you will find me on LinkedIn.