Zero Trust Foundations and the Microsoft Security Stack

Why This Lesson Exists

Every later module in this course — Conditional Access, PIM, Intune and Defender for Endpoint, Purview data governance, Sentinel SIEM/SOAR — is a piece of one architecture. If you learn each product in isolation you become a button-clicker. If you learn the model first, you become an architect who can explain why a control exists and where it fits. That model is Zero Trust, and this lesson is the map you’ll keep returning to.

The old model was a castle-and-moat: a hard network perimeter (firewall, VPN) with a soft, trusted interior. Once you were ‘inside’, you were trusted. That assumption is now fatal: users work from anywhere, apps are SaaS, data lives in the cloud, and a single phished credential drops an attacker straight ‘inside’. Zero Trust replaces implicit trust based on network location with explicit verification on every request.

The Three Zero Trust Principles

Microsoft frames Zero Trust around three principles. Memorize them — they are the lens for every design decision.

1. Verify explicitly. Always authenticate and authorize based on all available signals: identity, location, device health, service or workload, data classification, and anomalies. Never trust something just because it is on the corporate network.
2. Use least-privilege access. Limit users with just-in-time (JIT) and just-enough-access (JEA), risk-based adaptive policies, and data protection. Standing admin rights are the enemy; access should be the minimum needed, for the shortest time needed.
3. Assume breach. Operate as though an attacker is already inside. Segment access (by network, identity, app, and data), minimize blast radius, encrypt end-to-end, and use analytics to detect and respond. Logging and visibility are not optional.

A useful test: for any control you build, ask which principle it serves. Conditional Access requiring MFA = verify explicitly. PIM eligible roles = least privilege. Sentinel detections and segmentation = assume breach.

The Six Zero Trust Pillars

Principles are the philosophy; pillars are where you apply it. Microsoft organizes Zero Trust into six pillars (sometimes shown as a wheel around a central policy engine):

At the center sits a policy engine that takes signals from every pillar and makes an allow/deny/limit decision. In the Microsoft stack, Conditional Access is that engine for identity-centric access — which is exactly why Lesson 2 is dedicated to it.

The Cloud Shared-Responsibility Model

Zero Trust lives inside the shared-responsibility model, which defines who secures what between you and the cloud provider. The split shifts by service type:

• On-premises: you own everything — physical, host, OS, network, apps, data, identity.
• IaaS (e.g., an Azure VM): Microsoft owns the physical host and hypervisor; you still own the OS, applications, network configuration, data, and identities.
• PaaS (e.g., Azure SQL, App Service): Microsoft also takes the OS and runtime; you own data, identities, and access configuration.
• SaaS (e.g., Microsoft 365): Microsoft runs almost the whole stack; you still own your data, your identities/accounts, and the access you grant.

The constant across all models: data and identities are always your responsibility. That single fact is why this course starts with identity. Microsoft running the datacenter does not protect you from an over-privileged admin or an un-reviewed guest account — those are yours to govern.

Mapping the Microsoft Security Stack to the Pillars

Here is the product map you’ll use for the rest of the course:

• Identity → Microsoft Entra ID. Authentication, Conditional Access (the policy engine), Identity Protection (risk), PIM (JIT admin), Identity Governance (access reviews, entitlement management, B2B). This is Module 1.
• Endpoints → Microsoft Intune + Microsoft Defender for Endpoint. Intune sets and reports device compliance (which Conditional Access consumes); Defender for Endpoint provides EDR, attack surface reduction, and threat analytics. Module 2.
• Apps → Microsoft Defender for Cloud Apps / Entra app governance. Discovery, OAuth app risk, session controls.
• Data → Microsoft Purview. Sensitivity labels, data loss prevention (DLP), insider risk, and AI/Copilot data governance. Module 3.
• Infrastructure → Microsoft Defender for Cloud. Cloud security posture management (CSPM) and workload protection. Module 4/5.
• Visibility & automation (cross-pillar) → Microsoft Defender XDR + Microsoft Sentinel. Defender XDR correlates signals across identity, endpoint, email, and apps into unified incidents; Sentinel is the cloud-native SIEM/SOAR that ingests everything, hunts with KQL, and automates response with playbooks. Module 4 and 5.

Notice the flow: each pillar produces signals, Conditional Access acts on identity signals in real time, and Defender XDR/Sentinel observe and respond across all of them — a direct expression of assume breach.

Identity Is the New Perimeter — and Where SC-500 Sits

Because users, apps, and data are scattered beyond any network edge, the identity is the one consistent thing present in every access request. That is what ‘identity is the new perimeter’ means: instead of asking ‘is this packet inside the firewall?’ we ask ‘is this verified identity, on a healthy device, with acceptable risk, allowed to reach this app and this data right now?’ Conditional Access answers that question on every sign-in.

Finally, position your own growth. MD-102 (endpoint admin) and MS-102 (Microsoft 365 admin) certify you to operate services: enroll devices, manage licenses, configure mailboxes. SC-500 (and this course) is the level above — designing and operating the security architecture: how identity, endpoint, data, and SIEM controls combine to enforce Zero Trust, and how you detect and respond when they’re tested. You already know how to administer the parts; this course teaches you to architect the whole.