← Back to all questions
StaffSecurityIdentity
Design a Zero-Trust Security Architecture for an Enterprise
A Staff-level walkthrough of a zero-trust enterprise architecture that replaces perimeter trust with continuous verification of every access request — built on a conditional-access policy engine, Continuous Access Evaluation, device-compliance tiers, network micro-segmentation, and an automated SecOps loop across 100K+ employees and 5,000+ apps. It trades authentication latency and user friction against breach blast-radius and least-privilege enforcement. Follow it top to bottom, or jump to any step.
100% free · No login required
WHAT THIS QUESTION TESTS
·Conditional access as the Policy Decision Point — most-restrictive-wins over identity, device, location, and risk
·Continuous Access Evaluation: backchannel session revocation under 60 seconds
·Device-compliance tiers gating access (fully managed / BYOD / unmanaged / privileged)
·SIEM + XDR multi-stage correlation with automated SOAR containment
★ STAFF-LEVEL SIGNALS
★Treats identity as the 99.999% control plane, with failure-domain analysis and dual-custody break-glass fallback
★Phases an 18-month, six-team rollout in report-only-before-enforce mode
★Quantifies the per-signal latency budget on the policy-evaluation hot path (~35ms p50)
★Eliminates standing privilege via JIT/PIM, a tiered admin model, and PAW workstations
0
Scope & ambiguity
“Zero trust is not a product — it’s an architecture paradigm. The core challenge is moving from a perimeter-based ’castle and moat’ model to a model where every access request is continuously verified across identity, device, network, application, and data layers — at enterprise scale with 100K+ employees, thousands of applications, and a hybrid multi-cloud footprint. I’ll focus on the policy engine design, identity-centric access architecture, and the security operations automation that ties it all together.”
Phases:
Phase
Timeline
Scope
Phase 1
0-4 months
Identity foundation: Entra ID as central IdP, MFA everywhere, conditional access policies for top-50 critical apps, basic device compliance via Intune
Phase 2
4-10 months
Network micro-segmentation (eliminate flat VPN), Purview data classification on sensitive repos, Sentinel SIEM ingestion from all sources, passwordless rollout
Phase 3
10-18 months
Continuous Access Evaluation (CAE) for all apps, PIM/PAM for privileged access, automated incident response (SOAR playbooks), AI-driven threat detection
Teams:
Team
Ownership
Identity Platform Team
Entra ID, conditional access engine, authentication protocols, SSO
Endpoint Security Team
Intune MDM/MAM, device compliance, Defender for Endpoint
Network Security Team
Azure Firewall, NSGs, Private Link, micro-segmentation, DNS security
Data Protection Team
Purview classification, DLP policies, encryption, sensitivity labels
Security Operations (SecOps) Team
Sentinel SIEM, Defender XDR, SOAR playbooks, incident response
Privileged Access Team
PIM/PAM, tiered admin model, just-in-time access, emergency break-glass
1
Requirements
Functional
- FR1: Every access request authenticated and authorized regardless of network location (no implicit trust from VPN/corporate network)
- FR2: Conditional access policies evaluated in real-time using signals: user identity, device compliance, location, risk level, application sensitivity
- FR3: Continuous Access Evaluation — revoke sessions in near-real-time on security events (password change, account disable, location change)
- FR4: Device health attestation required before granting access to sensitive resources
- FR5: Privileged access managed via just-in-time elevation with approval workflows and time-bound sessions
- FR6: All data classified by sensitivity level with DLP policies enforced at rest, in transit, and in use
- FR7: Centralized SIEM with automated threat detection and response (SOAR) across all security signals
- FR8: Network micro-segmentation — each application/service individually authenticated, no lateral movement
Non-Functional
Requirement
Target
Authentication latency (SSO + MFA)
p50 < 200ms, p99 < 800ms
Conditional access policy evaluation
p50 < 50ms, p99 < 150ms
Session revocation (CAE)
< 60 seconds from security event to enforcement
Device compliance check
< 2 seconds at sign-in, background re-evaluation every 4 hours
SIEM alert-to-detection
< 5 minutes for known threats, < 30 minutes for anomaly-based
Automated response (SOAR)
< 2 minutes from detection to containment action
Availability (identity platform)
99.999% (identity is the control plane for everything)
Scale
100K+ employees, 500K+ devices, 5,000+ applications, 50M+ sign-ins/day
2
Back-of-envelope estimation
Scale Metrics
Metric
Value
Total employees
100,000+
Managed devices (corporate + BYOD)
500,000+
Applications (SaaS + internal + legacy)
5,000+
Sign-in events per day
50M+ (tokens, app launches, re-auth)
Conditional access policy evaluations/sec
~600 (50M/day sustained, 3x peak = 1,800/sec)
Security events ingested by SIEM/day
~10B (endpoint telemetry, network flows, auth logs, app audit)
Privileged access requests/day
~5,000 (admin operations requiring JIT elevation)
DLP policy evaluations/day
~100M (email, file operations, chat, endpoint activity)
Cost Breakdown
Resource
Monthly Cost
Entra ID P2 licenses (100K users × $9/user)
~$900K
Intune device management (500K devices × $8/device)
~$4M
Microsoft Sentinel (10B events/day, ~300TB/month ingested)
~$1.5M
Defender for Endpoint + XDR (100K users)
~$500K
Microsoft Purview (DLP + Information Protection)
~$300K
Azure networking (Firewall, Private Link, NSGs)
~$400K
PIM/PAM infrastructure + HSMs
~$100K
Security team headcount (50 FTE × $15K/month loaded)
~$750K
Total
~$8.5M/month
Key insight: The $8.5M/month seems high but represents ~$85/employee/month for comprehensive zero-trust security. Industry average cost of a data breach for a 100K-employee enterprise is $150M+. The security investment pays for itself if it prevents even a fraction of one major breach per year. The largest cost driver is Intune device management — BYOD policies and tiered device requirements can reduce this by 30-40%.
3
API design
External API (Admin & Policy Management)
# Conditional Access Policy Management
POST /api/v1/policies/conditional-access -- Create policy
GET /api/v1/policies/conditional-access/{policy_id} -- Get policy details
PUT /api/v1/policies/conditional-access/{policy_id} -- Update policy
DELETE /api/v1/policies/conditional-access/{policy_id} -- Delete policy
POST /api/v1/policies/conditional-access/{policy_id}/simulate -- What-if simulation
# Device Compliance
GET /api/v1/devices/{device_id}/compliance -- Check device compliance status
POST /api/v1/devices/{device_id}/wipe -- Remote wipe (emergency)
GET /api/v1/devices?compliance_status=noncompliant -- List non-compliant devices
# Privileged Access (PIM)
POST /api/v1/pim/activate -- Request JIT role activation
GET /api/v1/pim/activations?status=pending -- List pending approvals
POST /api/v1/pim/activations/{id}/approve -- Approve role activation
GET /api/v1/pim/audit-log?role={role}&days=30 -- Audit trail
# Incident Response
GET /api/v1/incidents?severity=high&status=active -- List active incidents
POST /api/v1/incidents/{id}/contain -- Trigger containment playbook
POST /api/v1/incidents/{id}/investigate -- Trigger investigation playbook
# Security Posture
GET /api/v1/secure-score -- Microsoft Secure Score
GET /api/v1/secure-score/recommendations -- Improvement recommendations
Inter-Service Events (Azure Event Hub / Service Bus)
SERVICE: PolicyEngine (Conditional Access)
OWNER: Identity Platform Team
PROTOCOL: gRPC (internal), REST (Microsoft Graph API external)
Events Published:
Topic: security.policy-evaluation
Events: POLICY_EVALUATED, ACCESS_GRANTED, ACCESS_DENIED, MFA_REQUIRED
Schema: PolicyEvaluationEvent (Protobuf)
Partition key: user_id
Retention: 90 days
Throughput: ~1,800 events/sec peak
SERVICE: ContinuousAccessEvaluation
OWNER: Identity Platform Team
Events Published:
Topic: security.cae-events
Events: SESSION_REVOKED, TOKEN_INVALIDATED, RISK_LEVEL_CHANGED
Schema: CAEEvent (Protobuf)
Partition key: user_id
Latency SLA: < 60 seconds from trigger to enforcement
SERVICE: ThreatDetection (Sentinel + Defender XDR)
OWNER: SecOps Team
Events Consumed:
Topics: security.endpoint-telemetry, security.network-flows,
security.auth-logs, security.app-audit
Aggregate ingest: ~10B events/day (~115K events/sec)
Events Published:
Topic: security.alerts
Events: THREAT_DETECTED, ANOMALY_DETECTED, INCIDENT_CREATED
Schema: SecurityAlert (Protobuf)
Partition key: tenant_id + alert_severity
SERVICE: DeviceCompliance
OWNER: Endpoint Security Team
Events Published:
Topic: security.device-compliance
Events: COMPLIANCE_CHANGED, DEVICE_ENROLLED, DEVICE_WIPED
Schema: DeviceComplianceEvent (Protobuf)
Partition key: device_id
API Governance
- Versioning: Microsoft Graph API v1.0 (stable) + beta (preview) for external; gRPC with Protobuf for internal
- Rate limiting: 10,000 requests/min per admin, 100 requests/min for policy simulation (compute-intensive)
- Authentication: All admin APIs require Entra ID token with appropriate admin role + PIM activation for write operations
4
Data model
Data
Storage
Rationale
User identities + attributes
Entra ID (Azure AD) — distributed directory
Global replication, sub-100ms lookups, SCIM provisioning from HR systems, supports 100K+ objects with complex group nesting
Conditional access policies
Azure Cosmos DB (multi-region)
Low-latency reads during policy evaluation (p99 < 10ms), strong consistency for policy updates, JSON document model fits policy schema flexibility
Authentication logs + sign-in events
Azure Data Explorer (ADX)
Columnar store optimized for time-series security analytics, 50M+ events/day with fast aggregation queries, 90-day hot retention
Device compliance state
SQL Database (Azure SQL)
Relational model for device ↔ user ↔ compliance-policy joins, transactional consistency for compliance state changes
Security events (SIEM)
Azure Data Explorer (Sentinel backend)
Handles 10B events/day ingestion, KQL query language for threat hunting, hot/warm/cold tiering (hot: 30 days, warm: 90 days, cold: 2 years in blob storage)
DLP policy matches + incidents
Azure Cosmos DB
Low-latency writes from distributed DLP enforcement points (endpoint, Exchange, SharePoint, Teams), geo-distributed
Privileged access audit log
Azure Immutable Blob Storage
Append-only, tamper-proof audit trail for compliance (SOX, ISO 27001), WORM policy prevents deletion
Encryption keys (DEK/KEK)
Azure Key Vault + HSM
FIPS 140-2 Level 3 certified HSMs, automatic key rotation, envelope encryption pattern
Network flow logs
Azure Blob Storage (tiered)
High-volume network telemetry, compressed Parquet format, batch-queried by Sentinel analytics rules
Threat intelligence feeds
Azure Cosmos DB
Low-latency lookups during real-time threat matching (IP, domain, file hash IOCs), TTL-based expiration for stale indicators
5
High-level architecture
Architecture Diagram
[Users + Devices]
|
+-----------+-----------+
| |
[Corporate Network] [Internet / Remote]
| |
+----------+------------+
|
[Azure Front Door / Global LB]
|
+--------------+--------------+
| |
[Entra ID / Conditional Access] [Azure AD App Proxy]
(Identity Platform Team) (for legacy on-prem apps)
| |
+----+----+----+----+ |
| | | | | |
[MFA] [CAE] [Risk] [Device] |
Engine Engine Engine Check |
| |
+----------+------ -----------+
|
[Policy Decision Point (PDP)]
Evaluates: identity + device + location +
risk + app sensitivity → ALLOW/DENY/MFA
|
+-------+-------+-------+-------+
| | | | |
[M365 Apps] [Azure] [SaaS] [Internal] [On-Prem]
(Exchange, Resources (Salesforce, Apps Legacy
Teams, (VMs, Workday, (LOB) Apps
SharePoint) Storage) ServiceNow)
| | | | |
+-------+-------+-------+-------+
|
[Microsoft Defender XDR]
(SecOps Team)
Endpoint + Identity + Office + Cloud
|
[Microsoft Sentinel SIEM]
(SecOps Team)
| |
[Analytics Rules] [SOAR Playbooks]
(KQL detections) (Logic Apps)
| |
[Incident Queue] → [SOC Analysts]
|
[Microsoft Purview]
(Data Protection Team)
Classification + DLP + Encryption
Failure Domain Analysis
FAILURE DOMAIN 1: Identity Platform (Entra ID + Conditional Access)
Impact: CRITICAL — no authentication possible, all access blocked
Mitigation: Entra ID is 99.999% SLA with global geo-redundancy.
Fallback: cached tokens continue to work (CAE extends to 28hr).
Emergency: break-glass accounts with hardware FIDO2 keys bypass
conditional access (stored in physical safe, dual-custody).
Recovery: Entra ID auto-failover across Azure regions (< 5 min)
FAILURE DOMAIN 2: Device Compliance (Intune)
Impact: MEDIUM — new device compliance checks fail, existing
compliant devices continue with cached compliance state (4hr TTL)
Mitigation: Conditional access policies can be configured to
"allow access with warning" when compliance service unavailable
Recovery: Intune auto-recovery, compliance re-evaluated on next check-in
FAILURE DOMAIN 3: SIEM / Threat Detection (Sentinel)
Impact: LOW (short-term) — security monitoring blind spot, but
access control continues to function independently
Mitigation: Defender XDR has local detection independent of Sentinel.
Events buffered in Event Hub (24hr retention) for replay on recovery.
Recovery: ADX cluster auto-healing, buffered events replayed
FAILURE DOMAIN 4: Network Security (Azure Firewall / NSGs)
Impact: HIGH — network segmentation fails, potential lateral movement
Mitigation: Defense in depth — even if network layer fails, identity
layer still requires authentication per app. Azure Firewall is
zone-redundant within region.
Recovery: NSG rules are declarative and re-applied on infrastructure recovery
FAILURE DOMAIN 5: Data Protection (Purview DLP)
Impact: MEDIUM — DLP enforcement pauses, data exfiltration risk
Mitigation: Endpoint DLP operates locally (offline-capable).
Exchange/SharePoint DLP is inline and fails-closed (blocks on error).
Recovery: Purview service auto-recovery, queued evaluations processed
6
Deep dives
WHERE STAFF IS WON6.1 Zero-Trust Principles and Pillars
Core paradigm: "Never trust, always verify. Assume breach."
Three principles (per NIST SP 800-207):
1. VERIFY EXPLICITLY: Authenticate and authorize every request using all
available signals (identity, device, location, behavior, data sensitivity)
2. LEAST-PRIVILEGE ACCESS: Limit access to just-enough, just-in-time.
No standing privileges. Time-bound elevated access.
3. ASSUME BREACH: Design as if the attacker is already inside.
Minimize blast radius. Segment access. Encrypt everything.
Detect anomalies. Automate response.
Six pillars of zero trust (Microsoft framework):
┌──────────────────────────────────────────────────┐
│ ZERO TRUST PILLARS │
├──────────┬──────────┬──────────┬────────────────┤
│ IDENTITY │ DEVICES │ NETWORK │ APPLICATIONS │
│ Entra ID │ Intune │ Azure FW │ App Proxy │
│ MFA/CAE │ Defender │ NSGs │ Defender Cloud │
├──────────┴──────────┼──────────┴────────────────┤
│ DATA │ INFRASTRUCTURE │
│ Purview / DLP │ Azure Policy / Sentinel │
│ Sensitivity Labels │ Defender for Cloud │
└─────────────────────┴──────────────────────────-┘
Each pillar must enforce:
- Strong authentication (who are you?)
- Authorization (are you allowed?)
- Encryption (in transit + at rest)
- Monitoring (what are you doing?)
- Anomaly detection (is this normal?)
6.2 Conditional Access Policy Engine — The Heart of Zero Trust
The Conditional Access (CA) engine is the central Policy Decision Point (PDP) — every access request flows through it.
Policy Evaluation Flow (per sign-in):
┌─────────────────────────────────────────────┐
│ SIGNAL COLLECTION │
│ │
│ User identity ──┐ │
│ Group membership ┤ │
│ Device compliance ┤ │
│ Device platform ┤ ┌──────────────────┐ │
│ Location (IP/GPS) ┤──→│ POLICY ENGINE │ │
│ Client app ┤ │ │ │
│ Sign-in risk ┤ │ Evaluate all │ │
│ User risk ┤ │ matching policies│ │
│ App sensitivity ┘ │ │ │
│ │ Most restrictive │ │
│ │ policy wins │ │
│ └────────┬─────────┘ │
│ │ │
│ ┌───────────┼──────────┐ │
│ │ │ │ │
│ [BLOCK] [ALLOW] [ALLOW │
│ │ WITH │
│ │ GRANT │
│ │ CONTROLS│
│ │ │ │
│ │ [Require ││
│ │ MFA] ││
│ │ [Require ││
│ │ compliant││
│ │ device] ││
│ │ [Require ││
│ │ approved ││
│ │ app] ││
└──────────────────────────────┴──────────────-┘
Policy Evaluation Algorithm:
function evaluateConditionalAccess(signInContext):
matchingPolicies = []
for policy in allActivePolicies:
if matchesConditions(policy, signInContext):
matchingPolicies.append(policy)
if any(policy.action == BLOCK for policy in matchingPolicies):
return BLOCK // Block takes precedence over everything
requiredControls = set()
for policy in matchingPolicies:
requiredControls.addAll(policy.grantControls)
// e.g., {REQUIRE_MFA, REQUIRE_COMPLIANT_DEVICE, REQUIRE_APPROVED_APP}
if requiredControls.isEmpty():
return ALLOW // No policies matched or no controls required
// Check if user satisfies all required controls
satisfiedControls = evaluateGrantControls(signInContext, requiredControls)
if satisfiedControls == requiredControls:
return ALLOW
else:
return CHALLENGE(unsatisfied controls)
// e.g., prompt for MFA, redirect to Intune enrollment
Latency budget:
Signal collection: ~20ms (parallel fan-out to risk engine, device service)
Policy matching: ~5ms (in-memory policy set, typically < 100 policies)
Grant control check: ~10ms (cached compliance state, risk scores)
Total: ~35ms p50, ~120ms p99 (including risk engine cold path)
Example Conditional Access Policies for 100K Enterprise:
Policy Name
Condition
Grant Controls
Rationale
Baseline MFA
All users, all cloud apps
Require MFA
Eliminate password-only attacks
High-risk sign-in block
Sign-in risk = High
Block
Prevent compromised credential use
Executive protection
C-suite group, any location
Require phishing-resistant MFA (FIDO2 only) + compliant device
High-value targets get strongest protection
Unmanaged device restriction
Non-compliant device, sensitive apps
Allow with app-enforced restrictions (no download, view-only)
Enable BYOD without data exfiltration
Legacy auth block
Authentication using legacy protocols (IMAP, SMTP basic)
Block
Legacy protocols bypass MFA
Country block
Sign-in from embargoed countries
Block
Regulatory compliance, reduce attack surface
Admin access
Directory roles (Global Admin, etc.)
Require MFA + PIM activation + compliant device
Protect privileged access
6.3 Continuous Access Evaluation (CAE)
Traditional token model vs. CAE:
Dimension
Traditional
Continuous Access Evaluation
Token lifetime
1 hour (default), then refresh
Extended to 28 hours (reduced refresh overhead)
Revocation latency
Up to 1 hour (wait for token expiry)
Near-real-time (< 60 seconds)
Location enforcement
Only at sign-in time
Continuous (IP change triggers re-evaluation)
Risk evaluation
At token issuance
Continuous (risk change triggers re-evaluation)
Architecture
Stateless tokens, no backchannel
Event-driven backchannel between IdP and resource provider
CAE Architecture:
[Entra ID] ←──── critical event ────→ [Resource Provider]
(Identity Provider) (Exchange, SharePoint, Teams)
│ │
│ 1. User signs in, gets token │
│ ────────── token ──────────────→ │
│ │
│ 2. Security event occurs: │
│ - Password changed │
│ - Account disabled │
│ - MFA fraud reported │
│ - User risk elevated to High │
│ - Admin revokes all sessions │
│ │
│ 3. Entra ID pushes event to RP │
│ ────── SESSION_REVOKED event ──────→ │
│ │
│ 4. RP rejects next API call with │
│ 401 + claims challenge │
│ │
│ 5. Client receives claims challenge, │
│ must re-authenticate │
│ ←───── re-auth required ──────── │
│ │
│ 6. User re-authenticates (if still │
│ valid) or is blocked │
Latency characteristics:
- Critical event to RP notification: < 15 seconds (event propagation)
- RP enforcement on next API call: immediate (< 1 second)
- End-to-end worst case: < 60 seconds (user between API calls)
- IP location enforcement: instant (RP checks IP on every request)
- Token lifetime benefit: 28hr tokens reduce Entra ID load by ~95%
compared to 1hr tokens (fewer refresh calls)
6.4 Identity & Authentication Architecture
Passwordless Authentication Strategy:
Method
Security Level
User Experience
Deployment Complexity
Best For
FIDO2 security keys (YubiKey)
Highest (phishing-resistant)
Tap key + PIN/biometric
Medium (key distribution)
Admins, executives, shared devices
Windows Hello for Business
Highest (phishing-resistant)
Face/fingerprint/PIN → TPM-bound
Low (auto-provision on Entra-joined device)
Primary method for managed Windows devices
Microsoft Authenticator (passkey)
High (phishing-resistant with number matching)
Phone notification + biometric
Low
Mobile-first users, BYOD
Certificate-based auth (CBA)
Highest
Smart card / virtual smart card
High (PKI infrastructure)
Government, regulated industries
Why passwordless matters — attack surface reduction:
Password-based attacks eliminated by passwordless:
- Phishing: FIDO2/passkeys are origin-bound, cannot be phished
- Credential stuffing: no password to stuff
- Brute force: no password to guess
- Password spray: no password to spray
- MitM relay: FIDO2 challenge-response is channel-bound
Remaining attack vectors (require separate mitigation):
- Token theft (mitigated by CAE + token binding)
- Device compromise (mitigated by device health attestation)
- Social engineering of help desk (mitigated by verified identity proofing)
- Insider threats (mitigated by PIM + DLP + monitoring)
Authentication Architecture:
Sign-in flow (passwordless + conditional access):
1. User opens app → redirected to Entra ID sign-in
2. Entra ID identifies user (email/UPN)
3. Entra ID checks authentication methods registered:
→ FIDO2 key? Windows Hello? Authenticator passkey?
4. User authenticates with strongest available method:
a. Windows Hello: biometric → TPM releases key → signed assertion
b. FIDO2 key: tap key → key signs challenge → assertion sent
c. Authenticator: push notification → number matching → biometric
5. Entra ID verifies assertion
6. Conditional access evaluation (Step 6.2 above)
7. If granted: issue tokens (access token + refresh token)
- Access token: JWT with claims (user, roles, device, risk)
- Token lifetime: 28 hours with CAE (vs 1hr without)
8. Token bound to device via session key (prevents token export)
Protocol: OpenID Connect (OIDC) + OAuth 2.0
- Authorization code flow with PKCE for web apps
- Device authorization flow for IoT/headless devices
- On-behalf-of flow for API-to-API delegation
6.5 Device Trust & Compliance
Device Trust Tiers:
Tier
Device Type
Management Level
Access Level
Example
Tier 1: Fully managed
Corporate-issued, Entra-joined
Full MDM (Intune)
All resources including sensitive
Corporate laptops, desktops
Tier 2: Compliant BYOD
Personal, Entra-registered
MAM only (app-level)
General apps, no download on sensitive
Employee personal phones
Tier 3: Unmanaged
Unknown device
None
Web-only, read-only, watermarked
Contractor on personal laptop
Tier 0: Privileged
Secure Admin Workstation (SAW)
Hardened, dedicated
Admin portals, production systems
IT admin PAW stations
Device Compliance Policy Evaluation:
Compliance check signals (Intune → Entra ID):
{
"device_id": "d-abc123",
"compliance_state": "compliant | noncompliant | unknown",
"checks": {
"os_version": { "required": ">=22H2", "actual": "23H2", "pass": true },
"disk_encryption": { "required": true, "actual": "BitLocker on", "pass": true },
"antivirus": { "required": true, "actual": "Defender active", "pass": true },
"firewall": { "required": true, "actual": "enabled", "pass": true },
"jailbreak_detected": { "required": false, "actual": false, "pass": true },
"min_password_length": { "required": 6, "actual": 8, "pass": true },
"threat_level": { "required": "<=medium", "actual": "low", "pass": true },
"last_sync": { "required": "<4hr", "actual": "2hr ago", "pass": true }
},
"risk_score": 12, // 0-100, Defender for Endpoint
"evaluated_at": "2026-04-02T10:00:00Z"
}
Non-compliant remediation flow:
1. Device fails compliance check (e.g., OS not updated)
2. Intune marks device as non-compliant
3. User attempts to access conditional-access-protected app
4. Conditional access evaluates device state → DENY
5. User redirected to Company Portal with remediation steps
6. User updates OS → Intune re-evaluates → compliant
7. Next access attempt succeeds
Grace period: 24 hours for non-critical compliance failures
Immediate block: jailbreak, critical threat level, disabled encryption
6.6 Network Micro-Segmentation
Traditional VPN vs. Zero-Trust Network:
Dimension
Traditional VPN
Zero-Trust Network
Trust boundary
Network perimeter (inside VPN = trusted)
No network trust, every request verified
Lateral movement
Once inside, access to entire subnet
Each app requires individual authentication
Remote access
VPN tunnel to corporate network
Direct-to-app access via identity proxy
Scalability
VPN concentrator bottleneck
Cloud-native, horizontally scalable
User experience
Slow (all traffic through VPN), split-tunnel risks
Fast (direct routing to cloud apps)
Attack surface
VPN endpoint is high-value target
No single entry point to attack
Implementation Architecture:
Network segmentation layers:
LAYER 1: Identity-based application access (replace VPN)
┌─────────────────────────────────────────────────┐
│ [User] → [Entra ID auth] → [App Proxy / ZTNA] → [App] │
│ │
│ No VPN required. User authenticates to app │
│ directly. App Proxy publishes internal apps │
│ to internet with Entra ID pre-authentication. │
│ │
│ Alternative: Microsoft Entra Private Access │
│ (ZTNA for any TCP/UDP app, not just HTTP) │
└─────────────────────────────────────────────────┘
LAYER 2: Azure network segmentation
┌─────────────────────────────────────────────────┐
│ VNet topology: │
│ Hub VNet ──── Azure Firewall (inspect all traffic)│
│ ├── Spoke VNet: Production apps │
│ │ ├── Subnet: Web tier (NSG: allow 443 in) │
│ │ ├── Subnet: App tier (NSG: allow from web)│
│ │ └── Subnet: Data tier (NSG: allow from app)│
│ ├── Spoke VNet: Dev/Test (isolated) │
│ └── Spoke VNet: Management (restricted) │
│ │
│ Private Link: database, storage, key vault │
│ accessed only via private endpoints (no public IP)│
│ │
│ Service endpoints: restrict Azure PaaS to VNet only │
└─────────────────────────────────────────────────-┘
LAYER 3: Service mesh for microservices (east-west)
┌─────────────────────────────────────────────────┐
│ Within AKS clusters: │
│ - mTLS between all pods (Istio / OSM) │
│ - Network policies: pod A can only talk to pod B │
│ - Service identity: managed identity per service │
│ - No pod-to-pod communication without mTLS cert │
└─────────────────────────────────────────────────-┘
DNS security:
- Azure DNS Private Zones: internal name resolution stays private
- Protective DNS: block known malicious domains
- DNS logging: detect C2 beaconing via DNS query patterns
6.7 Data Classification & Protection (Microsoft Purview)
Classification Framework:
Sensitivity Level
Label
Protection
Examples
Public
General
None
Marketing materials, public docs
Internal
Internal
Encrypt in transit
Internal memos, non-sensitive email
Confidential
Confidential
Encrypt at rest + in transit, no external sharing
Financial reports, HR records
Highly Confidential
Highly Confidential
Encrypt + restrict to named users, watermark, no copy/print
M&A docs, source code, PII databases
Regulated
Regulated - [type]
Encrypt + DLP + audit + geo-fence
HIPAA data, PCI cardholder data, GDPR personal data
DLP Architecture:
DLP enforcement points:
[Endpoint] [Exchange] [SharePoint] [Teams] [Network]
Defender DLP Transport Online DLP Chat DLP Purview NDS
(local agent) Rules + DLP (upload scan) (message (SASE
│ │ │ scan) integration)
│ │ │ │ │
└───────────┬───┴─────────────┴────────────┴────────────┘
│
[Unified DLP Policy Engine]
(Microsoft Purview backend)
│
┌────────┴────────┐
│ │
[Classification] [Action]
- Sensitive info - Block
types (SIT): - Encrypt
SSN, credit - Notify user
card, etc. - Alert admin
- Trainable - Quarantine
classifiers - Audit log
- Exact data - Override with
match (EDM) justification
Sensitivity label metadata (embedded in file):
Written as: msip_labels custom property in Office documents
Format: plaintext metadata readable without decryption
Persistence: travels with the file even outside M365
Enforcement: Azure Information Protection SDK reads label
→ applies protection (encryption, permissions) based on label policy
Data at rest encryption:
Layer 1: Service-level encryption (BitLocker for disk, TDE for SQL)
Layer 2: Per-tenant key (Microsoft-managed or customer-managed in Key Vault)
Layer 3: Per-file encryption for Highly Confidential (Azure RMS / MIP)
Key hierarchy: file DEK → tenant KEK → HSM master key
6.8 SIEM & XDR — Security Operations Architecture
Signal Flow Architecture:
DATA SOURCES (10B events/day):
[Entra ID] → sign-in logs, audit logs, risk detections (~500M/day)
[Defender Endpoint]→ process, network, file, registry events (~5B/day)
[Defender Identity]→ Active Directory signals, lateral movement (~200M/day)
[Defender O365] → email, collaboration threats (~1B/day)
[Defender Cloud] → cloud resource misconfig, runtime threats (~500M/day)
[Azure Activity] → resource CRUD, RBAC changes (~100M/day)
[Network flows] → NSG flow logs, firewall logs (~2B/day)
[Custom apps] → application audit logs via diagnostic settings (~500M/day)
│
▼
[Microsoft Sentinel] ← unified data lake (ADX/Azure Data Explorer)
│
├── [Analytics Rules] (600+ built-in, custom KQL rules)
│ │
│ ├── Scheduled rules: run every 5min, query last 5min of data
│ ├── NRT (near-real-time) rules: run every 1min
│ ├── ML-based rules: anomaly detection (UEBA)
│ └── Fusion rules: multi-stage attack correlation
│
├── [Incidents] ← auto-created when rules trigger
│ │
│ ├── Severity: High/Medium/Low/Informational
│ ├── Auto-assigned to SOC tier based on severity
│ └── Investigation graph: entity timeline + relationships
│
└── [SOAR Playbooks] (Azure Logic Apps)
│
├── Automated containment:
│ - Block user: disable account in Entra ID
│ - Isolate device: Defender for Endpoint network isolation
│ - Block IP: add to Azure Firewall deny list
│ - Revoke sessions: revoke all refresh tokens
│
├── Enrichment:
│ - Lookup IP in threat intelligence
│ - Lookup user in HR system (termination check)
│ - Check VirusTotal for file hash
│
└── Notification:
- Page SOC on-call (PagerDuty/ServiceNow)
- Escalate to CISO for severity > Critical
- Create incident ticket in ServiceNow
Defender XDR Correlation — Multi-Stage Attack Detection:
Example: Business Email Compromise (BEC) attack chain
Stage 1: Phishing email delivered
Signal: Defender for Office 365 detects phishing URL
Action: Email quarantined (but user may have clicked before quarantine)
Stage 2: Credential harvested
Signal: Entra ID detects sign-in from anomalous location (impossible travel)
Risk level: elevated to HIGH
Stage 3: Inbox rule created
Signal: Defender for O365 detects suspicious inbox rule
(forwarding all email to external address)
Action: Auto-disable inbox rule
Stage 4: Lateral movement
Signal: Defender for Identity detects pass-the-hash or
abnormal Active Directory reconnaissance
Action: Alert + auto-contain source device
XDR Fusion: correlate stages 1-4 into single incident
→ Auto-disable user account
→ Revoke all sessions (CAE)
→ Isolate all devices the user authenticated from
→ Alert SOC with full attack timeline
→ Time from stage 1 to full containment: < 5 minutes (automated)
SOC Tier Model:
Tier
Role
Handles
Automation Level
Tier 0
Fully automated
Known attack patterns with high confidence
100% automated (SOAR playbooks)
Tier 1
SOC Analyst (L1)
Medium-confidence alerts, validate automated actions
70% automated, 30% human review
Tier 2
SOC Analyst (L2)
Complex investigations, threat hunting, new attack patterns
30% automated, 70% human analysis
Tier 3
Incident Commander
Major incidents, breach response, executive communication
Manual coordination, automated data collection
6.9 Privileged Access Management (PIM/PAM)
Tiered Administrative Model:
TIER 0: Domain Controllers, Entra ID, PKI, Identity infrastructure
- Access: Privileged Access Workstation (PAW) only
- MFA: FIDO2 hardware key required (no Authenticator app)
- JIT: 1-hour max activation, dual-approval required
- Monitoring: all keystrokes recorded, session recorded
- Personnel: < 10 people in organization
- Break-glass: 2 emergency accounts, sealed hardware tokens, dual custody
TIER 1: Server infrastructure, databases, Azure subscriptions
- Access: SAW or compliant corporate device
- MFA: Phishing-resistant MFA required
- JIT: 4-hour max activation, manager approval
- Monitoring: all commands audited
- Personnel: ~100 people (server admins, DBAs, cloud engineers)
TIER 2: User workstations, help desk, standard admin tools
- Access: Compliant corporate device
- MFA: Any strong MFA
- JIT: 8-hour max activation, auto-approved with justification
- Monitoring: actions logged
- Personnel: ~500 people (help desk, desktop support)
PIM Activation Flow:
Just-in-time privilege elevation:
1. Admin needs to perform privileged action
(e.g., modify Azure AD conditional access policy)
2. Admin opens PIM portal, requests activation of
"Conditional Access Administrator" role
3. PIM requires:
a. Justification text (tied to change ticket)
b. Phishing-resistant MFA (FIDO2 re-authentication)
c. Duration (max 4 hours for Tier 1 roles)
4. Approval workflow:
- Tier 2 roles: auto-approved with justification
- Tier 1 roles: manager approval (SLA: 30 minutes)
- Tier 0 roles: dual approval (security team + manager)
5. Upon approval:
- Role activated for requested duration
- Activation event logged to immutable audit log
- Alert sent to security monitoring
- Sentinel analytics rule watches for anomalous admin activity
6. Duration expires:
- Role automatically deactivated
- Any active admin sessions continue but lose elevated permissions
- Post-action review triggered for sensitive operations
Standing access (always-on): ZERO for admin roles
Exception: break-glass accounts (2 accounts, reviewed quarterly,
usage triggers immediate high-priority alert)
6.10 Policy Engine Design — Signal Collection & Evaluation Architecture
Signal collection architecture for conditional access:
┌────────────────────────────────────────────────────────┐
│ SIGNAL SOURCES │
│ │
│ [Identity Signals] [Device Signals] │
│ - User ID, UPN - Device ID, compliance state │
│ - Group memberships - OS version, encryption │
│ - Directory roles - Defender risk score │
│ - Auth method used - Managed vs BYOD │
│ │
│ [Context Signals] [Risk Signals] │
│ - Client IP address - Sign-in risk (ML model) │
│ - Named location match - User risk (accumulated) │
│ - Client app type - Impossible travel │
│ - Device platform - Anomalous token usage │
│ - Authentication flow - Password spray detection │
└────────────────┬───────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────┐
│ RISK SCORING ENGINE │
│ │
│ Input: all signals above │
│ Output: sign_in_risk ∈ {none, low, medium, high} │
│ user_risk ∈ {none, low, medium, high} │
│ │
│ ML model features: │
│ - Login location vs historical pattern │
│ - Device fingerprint familiarity │
│ - Time-of-day anomaly score │
│ - IP reputation (threat intelligence feed) │
│ - Authentication method strength │
│ - Session behavior patterns (from Defender XDR) │
│ │
│ Decision thresholds: │
│ Risk Score 0-20: NONE → no additional controls │
│ Risk Score 21-50: LOW → may require MFA │
│ Risk Score 51-80: MEDIUM → require MFA + compliant │
│ Risk Score 81-100: HIGH → block access │
│ │
│ Latency: p50 ~15ms, p99 ~80ms (ML inference) │
└────────────────────────────────────────────────────────┘
6.11 Incident Response Automation
Automated Response Decision Framework:
Trigger
Confidence
Action
Human Approval
Impossible travel (2 locations > 500mi in < 1hr)
High
Revoke sessions + require re-auth with MFA
No (auto)
Malware detected on endpoint
High
Isolate device from network
No (auto)
Anomalous mass file download (> 500 files in 10min)
Medium
Block further downloads + alert SOC
Alert only
Suspicious inbox forwarding rule
High
Disable rule + revoke sessions
No (auto)
Brute force / password spray (> 50 failed attempts)
High
Block source IP + lock account 30min
No (auto)
Unusual admin activity from new location
Medium
Require re-auth + alert security team
Human review within 15min
Data exfiltration via USB (DLP match)
Medium-High
Block USB + alert manager
No (auto for block), human for escalation
Compromised service account
High
Rotate credentials + isolate workload
No (auto) + human review
Incident Response Playbook — Compromised User Account:
SOAR Playbook: "User Account Compromise" (fully automated, < 2 min)
Trigger: Sentinel incident with ≥ 2 of:
- Impossible travel sign-in
- Suspicious inbox rule
- High user risk from Entra ID Protection
- Mass file access anomaly
Step 1 (T+0s): Containment
→ API call: Entra ID → disable user account
→ API call: Entra ID → revoke all refresh tokens
→ API call: Defender for Endpoint → isolate user's devices
Step 2 (T+10s): Evidence Collection
→ Query: Sentinel → all sign-in logs for user (last 7 days)
→ Query: Defender → all endpoint activity (last 48hr)
→ Query: Defender O365 → all email activity (last 48hr)
→ Query: Purview → all file access activity (last 48hr)
→ Compile into investigation package
Step 3 (T+30s): Impact Assessment
→ Query: Entra ID → all apps the user accessed during attack window
→ Query: SharePoint → all files accessed/modified during attack window
→ Query: Entra ID → any privilege escalation or role assignment changes
→ Generate impact report
Step 4 (T+60s): Notification
→ Create ServiceNow incident (P1)
→ Page SOC on-call
→ Email user's manager: "Account suspended due to security incident"
→ If user is admin: page CISO
Step 5 (T+120s): Remediation Prep
→ Generate remediation checklist:
□ Reset password
□ Revoke all OAuth app consents
□ Remove suspicious inbox rules
□ Review and revert any unauthorized changes
□ Re-enroll MFA methods
□ Re-enable account with enhanced monitoring
7
Multi-Team Rollout
1. Identity Foundation (Weeks 1-8): Deploy Entra ID as sole IdP for all apps. Enforce MFA on all users (start with Authenticator push, target passwordless). Implement baseline conditional access policies (block legacy auth, require MFA, block high-risk sign-ins). Migrate top-50 apps to Entra ID SSO. Identity Platform Team leads, all teams adopt.
1. Device Compliance (Weeks 5-14): Enroll all corporate devices in Intune. Define compliance baselines per OS (Windows, macOS, iOS, Android). Conditional access: require compliant device for sensitive apps (start in report-only mode for 4 weeks, then enforce). Establish BYOD MAM policies. Endpoint Security Team leads.
1. Network Segmentation (Weeks 10-20): Deploy Azure Firewall in hub VNet. Implement spoke VNet isolation for production, dev, management. Convert top-20 internal apps from VPN access to Entra Application Proxy / Private Access. Retire VPN for cloud-app access. Network Security Team leads.
1. Data Protection (Weeks 14-24): Deploy sensitivity labels and DLP policies in monitor-only mode. Classify top data repositories. Enable DLP enforcement (Exchange first, then SharePoint, then endpoint). Deploy Purview for data discovery and classification. Data Protection Team leads.
1. Security Operations (Weeks 8-24): Connect all log sources to Sentinel. Deploy Defender XDR suite (Endpoint + Identity + O365 + Cloud). Enable top-50 analytics rules. Build initial SOAR playbooks (account compromise, malware detection, data exfiltration). Train SOC team. SecOps Team leads.
1. Privileged Access (Weeks 16-28): Implement PIM for all admin roles. Eliminate standing admin access (move to JIT). Deploy PAW stations for Tier 0 admins. Implement break-glass account procedures. Privileged Access Team leads.
1. Continuous Evaluation & Passwordless (Weeks 20-32): Enable CAE for all Entra-integrated apps. Roll out FIDO2 keys to all admins and executives. Windows Hello for Business deployment to all managed devices. Target: 80% passwordless adoption within 6 months. Identity Platform Team leads.
8
Bottlenecks & evolution
Bottleneck
Mitigation
Conditional access policy complexity (100+ policies, conflicting rules)
Policy simulation ("What If" tool) before deployment, mandatory report-only period, policy naming convention with review cadence
Legacy application integration (apps that don't support modern auth)
Azure AD Application Proxy for HTTP apps, Entra Private Access for TCP/UDP apps, SCIM-based provisioning, gradual deprecation plan
BYOD friction (users resist Intune enrollment on personal devices)
MAM-only policies (protect apps, not manage device), clear communication about what IT can/cannot see, Tier 2 access without enrollment
SIEM alert fatigue (10B events/day → thousands of alerts)
Sentinel Fusion for cross-signal correlation, UEBA baseline per user, tuning false-positive rules weekly, Tier 0 automation reduces SOC workload by 60%
Passwordless adoption (users comfortable with passwords)
Executive mandate + phased rollout, self-service FIDO2 key enrollment, Windows Hello auto-provisioned on device enrollment, password expiry policy as nudge
Break-glass account risk (emergency accounts bypass all controls)
Physical FIDO2 keys in safe, dual-custody access, automated alert on any break-glass usage, quarterly testing of break-glass procedure
Multi-cloud complexity (AWS, GCP workloads alongside Azure)
Entra ID as universal IdP (SAML/OIDC federation to AWS IAM Identity Center, GCP Workforce Identity), Defender for Cloud multi-cloud posture management
2-3 Year Evolution
Year 1: Foundation and Enforcement
Deploy the complete zero-trust stack: Entra ID as the universal identity plane, conditional access as the policy engine, Intune for device compliance, network segmentation replacing VPN, and Sentinel for centralized security monitoring. Achieve 100% MFA coverage, 80%+ passwordless adoption among knowledge workers, and elimination of standing admin privileges. All critical applications integrated with conditional access. SOC operating with automated Tier 0 response for top-10 attack patterns. Retire legacy VPN concentrators for cloud application access. Establish security posture baseline via Microsoft Secure Score (target: 75+/100).
Year 2: Intelligence and Automation
Shift from rule-based to ML-driven security operations. Deploy advanced UEBA (User and Entity Behavior Analytics) to establish per-user behavioral baselines — anomaly detection moves beyond impossible-travel to detecting subtle changes in data access patterns, working hours, and collaboration behavior. Expand SOAR automation to cover 80% of incident types with fully automated containment. Implement Adaptive Protection (dynamic DLP policy adjustment based on insider risk score — higher risk users get stricter DLP controls automatically). Deploy decentralized identity for B2B collaboration (verifiable credentials for external partner onboarding without guest accounts). Expand zero-trust to OT/IoT devices (manufacturing, building systems) via Defender for IoT. Achieve Secure Score 85+/100.
Year 3: Autonomous Security and Zero Standing Access
Target fully autonomous security operations where AI agents handle 95% of incidents without human intervention. Deploy security copilot agents that perform investigation, triage, and response with human oversight only for novel attack patterns. Implement zero standing access across the entire organization — every privileged action requires JIT elevation with full session recording. Adopt confidential computing for processing sensitive workloads (data encrypted even during processing via Azure Confidential VMs / secure enclaves). Implement cross-organization zero-trust mesh for supply chain security (verifiable attestations from vendors and partners). Adopt post-quantum cryptographic algorithms for long-term data protection (NIST PQC standards). Target: zero successful account compromises leading to data breach, mean time to contain < 60 seconds for all automated scenarios.
★
Rubric — Senior vs Staff
Dimension
Senior signal
Staff signal
Access model
Authenticate and authorize every request; no trust from network location.
Maps NIST verify-explicitly / least-privilege / assume-breach onto six enforced pillars with measurable SLAs.
Policy engine
Evaluate conditional access on identity, device, and risk signals.
Specifies parallel signal fan-out, most-restrictive-wins resolution, and a defended ~35ms p50 latency budget.
Session control
Short-lived tokens with periodic re-auth.
Adds a CAE backchannel for sub-60s revocation while extending token life to cut IdP refresh load ~95%.
Privileged access
Require MFA and approval for admin actions.
Zero standing access via JIT/PIM, a tiered admin model, and PAW plus dual-custody break-glass.
Detection & response
Centralize logs in a SIEM with alerting.
Correlates multi-stage attacks across XDR and auto-contains via SOAR in under two minutes.
★ MORE WALKTHROUGHS
Want more breakdowns like this?
Join free early access for upcoming RAG, LLM eval, agents, and AI infrastructure walkthroughs.