V1
Back to handbooks index
FIELD MANUAL
Zero Trust Architecture
DOC-ZTA-2024
LIVE
ZTA
Architecture Field Handbook

Zero
Trust

// "Never trust, always verify. Assume breach. Verify explicitly."

The definitive operational guide to eliminating implicit trust from your network. Covers identity-based access, micro-segmentation, ZTNA, device posture, and a phased migration path from legacy perimeter defenses.

Post-VPN Identity-First Micro-Segmentation ZTNA NIST SP 800-207
01

Overview & Core Principles

// FOUNDATIONAL DOCTRINE

Zero Trust Architecture (ZTA) is a security model, not a product. It eliminates the concept of a trusted internal network — the assumption that everything inside the corporate perimeter is safe. Coined by John Kindervag at Forrester in 2010 and formalized by NIST in SP 800-207, ZTA mandates continuous verification of every request, regardless of origin.

Assume Breach

Design and operate as if adversaries are already inside your network. Every segment, every workload, every user is a potential lateral movement vector.

Verify Explicitly

Authenticate and authorize every request using all available signals: identity, device health, location, service, data classification, and behavioral anomalies.

Least Privilege Access

Grant the minimum access required, just-in-time, for the exact resource needed. No standing privileges. Time-bound sessions. Continuous re-evaluation.

NIST SP 800-207 defines seven ZTA tenets: all data sources are resources; all communication is secured; access is granted per-session; access policy is dynamic; the enterprise monitors asset integrity; authentication/authorization is dynamic and strictly enforced; and the enterprise collects information to improve its security posture.
02

The End of the Perimeter

// WHY CASTLE-AND-MOAT FAILED

The traditional perimeter model assumed a trusted interior separated from an untrusted exterior by firewalls and VPNs. This model has fundamentally collapsed. The attack surface now spans cloud workloads, remote users, SaaS applications, and third-party supply chains — none of which sit inside a definable perimeter.

✕ Legacy Perimeter Model
  • Trust everything inside the network boundary
  • VPN grants broad access to internal subnets
  • Flat network — lateral movement is trivial
  • Authentication happens once at the edge
  • No visibility into east-west traffic
  • Single breach = full internal exposure
  • Implicit trust based on IP address
✓ Zero Trust Model
  • Trust nothing — verify every request
  • Access granted per-application, per-session
  • Segmented — blast radius is contained
  • Continuous authentication & re-authorization
  • Full visibility: north-south and east-west
  • Breach impact limited to smallest unit
  • Explicit trust based on identity + context

The Forces That Killed the Perimeter

Cloud & SaaS Adoption Critical

Applications no longer live in the data center. AWS, Azure, GCP, M365, Salesforce, Workday — corporate data now lives outside any traditional perimeter. Routing all traffic through a VPN creates catastrophic latency and a single choke point.

Remote & Hybrid Work Structural

The workforce operates from home networks, coffee shops, mobile hotspots. The endpoint is no longer on a corporate LAN. The device itself may be BYOD, unmanaged, or compromised.

Supply Chain Attacks Growing

SolarWinds, Log4Shell, MOVEit. Adversaries compromise trusted third-party software or vendors to gain implicit access to victim networks. Perimeter firewalls provide zero defense against trusted-insider threat vectors.

Credential Compromise Pervasive

81% of breaches involve stolen credentials (Verizon DBIR). VPN + password = complete network access for any attacker with a phished credential. Perimeter defenses collapse at the authentication layer.

03

The Five Pillars

// CISA ZTA FRAMEWORK

CISA's Zero Trust Maturity Model organizes ZTA across five interdependent pillars. Progress in each pillar compounds — strong identity makes micro-segmentation policies more precise; device health data enriches authentication decisions; visibility across all pillars enables automation.

🪪
Identity
Users, services, and devices as the primary perimeter
💻
Devices
Posture, health, and compliance of every endpoint
🌐
Networks
Segmentation, encryption, and traffic inspection
📁
Data
Classification, labeling, and access control
⚙️
Applications
Workload identity, app-layer authorization
Cross-cutting capabilities: Visibility & Analytics, Automation & Orchestration, and Governance thread through all five pillars. No pillar operates in isolation — access decisions at the policy enforcement point draw from signals across all of them simultaneously.
04

Identity as the New Perimeter

// IDENTITY PROVIDER ARCHITECTURE

In a Zero Trust model, identity is the control plane. Every access decision — user to app, service to service, workload to data store — flows through an identity provider (IdP). The IdP becomes the authoritative source of truth for who (or what) is requesting access, enriched by contextual signals from device, network, and behavioral analytics.

Identity Provider Architecture

Request
User / Device / Workload
IdP
Authentication & MFA
Policy Engine
Context Evaluation
PEP
Enforce Decision
Resource
App / Data / Service
Federated Identity Standard

Consolidate authentication to a single IdP (Okta, Azure AD, Ping Identity). Use SAML 2.0 or OIDC for all application integrations. Eliminate local accounts. Every identity must have an authoritative source.

Continuous Access Evaluation Advanced

CAE (OpenID CAEP) allows resource servers to receive real-time revocation signals from the IdP — token invalidation in under 15 minutes drops to near-instant when a policy change or credential compromise is detected.

Contextual Access Policy Signals

Signal CategoryData PointsRisk Weight
Identity Strength Authentication method, MFA type, credential age, compromised credential check HIGH
Device Posture MDM enrollment, OS patch level, disk encryption, EDR presence, jailbreak status HIGH
Network Context Source IP, ASN reputation, geolocation, VPN/TOR exit node detection MEDIUM
Behavioral Baseline Typical access time, typical resource patterns, velocity anomalies MEDIUM
Resource Sensitivity Data classification label, regulatory scope (PCI, HIPAA), blast radius HIGH
Session Risk Score Composite risk score computed in real-time; triggers step-up auth or deny HIGH
05

MFA & Phishing Resistance

// NOT ALL MFA IS EQUAL

Multi-factor authentication is necessary but not sufficient. SMS OTP and TOTP codes are vulnerable to real-time phishing (AiTM — Adversary-in-the-Middle attacks). Evilginx, Modlishka, and similar proxy frameworks can intercept and relay valid MFA codes in real time. Zero Trust requires phishing-resistant MFA as the baseline for privileged access.

SMS OTP
WEAK
TOTP App
BETTER
Push Auth
GOOD
Number Match Push
STRONG
FIDO2 / Passkeys
PHISHING-RESISTANT
Vulnerable to AiTM Phishing Avoid
  • SMS one-time passwords (SIM-swappable)
  • Standard TOTP codes (relayed by proxy)
  • Plain push approval notifications
  • Email magic links (if email is compromised)
Phishing-Resistant MFA Target
  • FIDO2 / WebAuthn — hardware or platform authenticator, origin-bound
  • Passkeys — FIDO2 with synced credentials, consumer-friendly
  • PIV / Smart Cards — certificate-based, required for U.S. federal (M-22-09)
  • Windows Hello for Business — TPM-backed, Kerberos/FIDO2
MFA Fatigue / Push Bombing: Attackers flood users with push notifications at odd hours hoping for an accidental approval. Mitigations: number matching (user must enter a code displayed on the login screen into the push), additional context (show app name + location), and maximum push frequency limits per session.
Policy Example — Conditional Access
# Azure AD / Entra ID Conditional Access Policy (conceptual) # Target: All Users → All Cloud Apps → Require phishing-resistant MFA Policy: "Require Phishing-Resistant MFA - Privileged Resources" Assignments: Users: All users (excluding break-glass accounts) Apps: - All cloud apps - On-prem apps via App Proxy Conditions: SignInRisk: Medium, High # Identity Protection signal DevicePlatform: Any Locations: Any (including trusted) Access Controls: Grant: - Require: Authentication Strength = Phishing-Resistant MFA # Phishing-Resistant = FIDO2 or Certificate-Based Auth only - Require: Compliant Device # MDM enrolled + policy compliant - Operator: AND Session Controls: SignInFrequency: 4 hours (persistent browser: disabled) ContinuousAccess: Enabled # CAE for real-time revocation CloudAppSecurity: Monitor session (DLP integration)
06

Privileged Access Management

// NO STANDING PRIVILEGE

Privileged accounts are the crown jewels. Domain admins, root accounts, service principals with broad permissions — these are the accounts attackers pivot to after initial compromise. Zero Trust mandates eliminating standing privileged access entirely and replacing it with just-in-time (JIT) and just-enough-access (JEA) models.

Just-In-Time Access

Privileged access is elevated on-demand for a bounded time window (e.g., 1 hour). No permanent admin role assignments. Every elevation is logged, requires approval workflow, and auto-expires.

Just-Enough Access

Scope privileges to the minimum required for the specific task. Instead of Domain Admin, use a custom role scoped to a single OU or resource group. Role definitions are task-specific, not broad.

Privileged Access Workstations

Administrative tasks performed only from hardened, dedicated PAWs. Isolated from the internet and standard user activity. No email, no browsing. Separate device or VM for privileged sessions.

JIT Workflow — PIM / CyberArk Pattern
## JIT Access Lifecycle 1. REQUEST User submits elevation request: - Role: "SQL Server Admin — Production DB Cluster" - Scope: /subscriptions/prod/resourceGroups/db-rg - Duration: 60 minutes - Justification: "Incident INC-4891 — DB deadlock investigation" - Ticket: Required (INC-4891 validated against ITSM) 2. APPROVAL - Auto-approved if: risk score LOW + ticket verified + within hours - Manager approval: risk score MEDIUM or off-hours access - CISO approval: Sensitive tier resources or duration > 4h 3. ELEVATION - Role activated, credential vaulted in PAM (CyberArk / Delinea) - Session proxy initiated — all keystrokes recorded - Alert: SOC notified of elevation event 4. SESSION - Time-bound credential, rotates every elevation - Full session recording in PAM vault - Network access limited to target resource only (micro-segmentation) 5. EXPIRY / REVOCATION - Auto-revoked at T+60m or on ticket close - Credential rotated immediately post-session - Session recording retained per policy (90 days minimum)
07

Micro-Segmentation

// CONTAIN THE BLAST RADIUS

Micro-segmentation replaces flat network architecture with granular, policy-enforced zones — down to individual workload or process level. Even if an attacker compromises one workload, east-west (lateral) movement to other workloads is blocked. The goal: a breach in web tier cannot reach the database tier without explicit policy permission.

Segmentation Tiers

TierGranularityTechnologyZT Alignment
Network Segmentation VLANs, subnets Firewall ACLs, router policy PARTIAL — coarse, IP-based
Perimeter Micro-seg DMZ zones, app tiers NGFWs, NSGs, Security Groups PARTIAL — better, still coarse
Workload Micro-seg Per VM / container Illumio, Guardicore, NSX-T, Calico STRONG — identity-aware policy
Process Micro-seg Per process / port eBPF-based (Cilium, Tetragon) OPTIMAL — kernel-level enforcement

Policy Model: Allowlist, Not Denylist

Legacy firewalls operate on denylist logic — block known bad, allow everything else. Micro-segmentation inverts this: deny all by default, allow only explicitly declared flows. Every permitted communication path is intentional and documented.

Network Policy — Kubernetes / Cilium
apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: payments-service-policy namespace: production spec: # Identity selector — target workload endpointSelector: matchLabels: app: payments-api tier: backend # INGRESS: only allow from these sources ingress: - fromEndpoints: - matchLabels: app: api-gateway # Frontend gateway only toPorts: - ports: [{ port: "8080", protocol: TCP }] rules: http: - method: POST path: /v1/charge # Exact path, exact method - fromEndpoints: - matchLabels: app: fraud-detection # Internal service toPorts: - ports: [{ port: "8080", protocol: TCP }] # EGRESS: only allow to these destinations egress: - toEndpoints: - matchLabels: app: postgres-primary # DB only toPorts: - ports: [{ port: "5432", protocol: TCP }] - toFQDNs: - matchPattern: "api.stripe.com" # External payment gateway toPorts: - ports: [{ port: "443", protocol: TCP }] # All other traffic: DENY (implicit default)
Discover before deny: Begin micro-segmentation in observe mode to map actual traffic flows before enforcing policy. Blind enforcement breaks applications. Tools like Illumio Explorer or NSX Traffic Analysis visualize east-west flows from day 1, allowing you to build accurate allowlists from reality, not assumptions.
08

ZTNA vs VPN

// APPLICATION-LEVEL ACCESS BROKERS

Zero Trust Network Access (ZTNA) replaces VPN tunnels with identity-aware, application-level access brokers. Instead of granting network access, ZTNA grants application access — only after verifying identity, device posture, and policy, and only to the specific application requested.

DimensionTraditional VPNZTNA
Access Scope Full network segment / subnet Single application, per session
Trust Basis Authenticated = trusted Authenticated + device + risk score
Visibility Encrypted tunnel, limited inspection Full session logging, app-layer visibility
Lateral Movement Unrestricted once inside Blocked — no network access granted
Performance Hairpin traffic through data center Direct-to-app or cloud-proxied, low latency
Application Discovery IP/port scanning possible Dark — apps invisible without auth
Unmanaged Devices VPN client required Clientless browser access option

ZTNA Deployment Models

Agent-Based ZTNA Managed Devices

Lightweight agent on managed endpoints continuously reports device posture to the ZTNA service. Access decisions incorporate real-time device health. Agent intercepts application traffic and routes through ZTNA broker.

Products: Zscaler Private Access, Cloudflare Access, Palo Alto Prisma Access, Cisco Duo SSE

Agentless ZTNA Third Parties / BYOD

Browser-based access through reverse proxy. No agent required — ideal for contractors, partners, BYOD. Device posture limited to browser-observable signals. Session isolation via browser rendering.

Products: Cloudflare Browser Isolation, Zscaler Cloud Browser Isolation, Axis Security

09

Software-Defined Perimeter

// DARK CLOUD — INVISIBLE UNTIL AUTHORIZED

A Software-Defined Perimeter (SDP) implements the "need to know" principle at the network layer. Applications and infrastructure are invisible — they do not respond to unauthenticated connection attempts. Only after mutual authentication through a controller does the infrastructure reveal itself and allow connectivity.

Client
SDP Client + Identity
Controller
AuthN + Policy Check
Decision
ALLOW / DENY
Gateway
Dynamic Tunnel
Service
Dark / Hidden
Single Packet Authorization (SPA): The gateway listens for a cryptographically signed UDP packet before opening any TCP port. Port scanners and unauthenticated probes receive no response — the service is completely dark to attackers. fwknop is the reference open-source SPA implementation. Commercial implementations include Appgate SDP and Zscaler.
10

Data Classification & Protection

// PROTECT WHAT MATTERS

Zero Trust protects data, not networks. You cannot apply appropriate controls without knowing what data you have, where it lives, and how sensitive it is. Data classification is the prerequisite to data-aware access policy.

ClassificationExamplesControls RequiredRegulatory Scope
RESTRICTED PII, PHI, PCI cardholder data, credentials, trade secrets Encryption at rest + in transit, MFA required, DLP block, PAM-controlled, audit all access GDPR, HIPAA, PCI-DSS, CCPA
CONFIDENTIAL Internal financials, HR data, unreleased product plans, M&A details Encryption, authenticated access, DLP monitor, access review quarterly SOX, various
INTERNAL Internal wikis, process docs, non-sensitive code Authenticated access, encryption in transit General data protection
PUBLIC Marketing, press releases, public docs Integrity controls, no confidentiality requirement N/A

Data-Loss Prevention Integration

DLP policies enforce data classification at the enforcement point — intercepting uploads, emails, and clipboard operations that attempt to move RESTRICTED data to unauthorized destinations. In a ZT model, DLP is a session control layer integrated with the ZTNA/SSE platform.

DLP Policy — Inline Inspection (CASB / SSE)
# DLP Rule: Block PCI Data Upload to Unsanctioned Cloud Storage Rule: "PCI Data Exfiltration Prevention" Priority: 10 (highest) Direction: UPLOAD to INTERNET Content Inspection: Patterns: - type: PCI_CCN # Credit card number regex + Luhn check threshold: 1 # Single instance triggers - type: CUSTOM_REGEX pattern: "4[0-9]{12}(?:[0-9]{3})?" # Visa pattern Destinations (Unsanctioned): Categories: PersonalStorage, FileSharing Apps: Dropbox, Google Drive (personal), WeTransfer, Pastebin # Note: sanctioned apps (e.g., corporate SharePoint) are excluded Actions: Primary: BLOCK Alert: SOC (P2 — 30 min SLA) Notify: User (explain policy) + Manager Log: Full session context, content fingerprint (no raw data) Quarantine: File flagged for review in DLP console
11

Device Trust & Posture

// ENDPOINTS AS ACCESS SIGNALS

Device health is a critical signal in ZTA access decisions. A compromised endpoint authenticating with valid credentials should be denied access to sensitive resources. Device posture — MDM enrollment status, patch level, EDR presence, disk encryption — is evaluated continuously, not just at login.

Managed Device Requirements Enforced
  • MDM enrolled (Intune / Jamf / SOTI)
  • OS patch level within 14 days of release
  • Full disk encryption enabled (BitLocker / FileVault)
  • EDR agent active and reporting (CrowdStrike / Defender)
  • Compliant screen lock policy
  • Approved certificate from PKI issued
Non-Compliant Device Response Tiered
  • Missing EDR: Block access to Restricted tier, allow Internal only
  • OS out of date: Redirect to remediation portal, 7-day grace
  • No MDM enrollment: Agentless ZTNA only (browser-isolated)
  • Jailbroken/rooted: Full deny, SOC alert, quarantine device
Device Identity via Certificate: Issue unique certificates from your corporate PKI to each managed device. Device certificate authentication (mTLS) at the ZTNA gateway cryptographically binds the session to the specific device. Certificate validity is conditioned on MDM compliance status — non-compliant devices have certificates revoked via OCSP or CRL.
12

Workload Identity

// SERVICE-TO-SERVICE ZERO TRUST

Human users are only half the access problem. Workloads — microservices, functions, pipelines, VMs — communicate constantly, and each communication is an opportunity for lateral movement. Workload identity issues cryptographic identities to every workload and enforces mutual authentication on service-to-service communication.

Service Mesh mTLS — Istio / SPIFFE
# Istio — enforce STRICT mTLS across the mesh apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: production spec: mtls: mode: STRICT # Reject all plaintext. mTLS required for every connection. --- # Authorization Policy — payments-api may ONLY be called by api-gateway apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: payments-authz namespace: production spec: selector: matchLabels: app: payments-api action: ALLOW rules: - from: - source: # SPIFFE identity of the allowed caller principals: - "cluster.local/ns/production/sa/api-gateway" to: - operation: methods: ["POST"] paths: ["/v1/charge", "/v1/refund"] # Default: DENY ALL (no matching ALLOW rule = denied)

Secret Management — No Hardcoded Credentials

Dynamic Secrets (HashiCorp Vault)

Workloads authenticate to Vault using their SPIFFE/SVID identity or cloud IAM role. Vault issues short-lived, scoped credentials (DB passwords, API keys, TLS certs) that expire automatically. No static credentials ever stored in config or environment variables.

Cloud-Native Options

AWS IAM roles for service accounts (IRSA), Azure Managed Identity, GCP Workload Identity Federation. Workloads receive temporary, auto-rotated tokens from the cloud provider's IAM service — no secret management overhead.

13

Visibility & Analytics

// YOU CAN'T PROTECT WHAT YOU CAN'T SEE

Zero Trust generates more telemetry than any other security architecture — every access decision, every policy evaluation, every denied request is a data point. This telemetry feeds analytics platforms that detect anomalies, drive policy tuning, and provide the forensic record needed for incident response.

Identity Analytics (UEBA)

User and Entity Behavior Analytics baselines normal access patterns. Detects: off-hours access, impossible travel, privilege escalation chains, data staging/exfil patterns, mass file access.

Network Flow Telemetry

NetFlow / IPFIX / eBPF-sourced telemetry from micro-segmentation layer. Maps east-west traffic, detects scanning, identifies unexpected communication paths, powers blast radius analysis.

Endpoint Telemetry (XDR)

EDR/XDR agents provide process execution, file system, registry, and network events from endpoints. Correlates endpoint activity with network and identity events for full attack chain reconstruction.

Log Sources — Required for ZTA Baseline

SourceKey EventsRetention
Identity ProviderAll auth events, MFA challenges, policy evaluations, token issuance/revocation1 year
ZTNA / Access ProxyEvery access request (allow/deny), session duration, bytes transferred, app accessed1 year
Micro-SegmentationAll connection attempts, policy hits/misses, new/changed flows90 days
Endpoint EDRProcess creation, network connections, file writes, credential access90 days
PAM / VaultElevation requests, credential checkouts, session recordings, secret access2 years
Cloud Control PlaneIAM changes, resource creation/deletion, config changes (CloudTrail, Activity Log)2 years
14

Policy Automation & Orchestration

// HUMAN SPEED IS NOT ENOUGH

ZTA policies must respond to risk signals faster than human operators can act. Automated policy enforcement closes the gap between detection and response — revoking access, quarantining devices, and isolating workloads in seconds, not hours.

SOAR Playbook — Compromised Credential Response
TRIGGER: Identity Protection — High Risk Sign-in Detected Conditions: - RiskLevel: HIGH (score > 90) - Source: Azure AD Identity Protection / Okta ThreatInsight - NOT: known break-glass account AUTOMATED ACTIONS (T+0 seconds): 1. Revoke all active sessions # IdP API: revokeAllSessions(userId) 2. Invalidate all refresh tokens # IdP API: revokeTokens(userId) 3. Disable account # IdP API: disableUser(userId) 4. Quarantine endpoint (if known) # EDR API: isolateDevice(deviceId) 5. Block in ZTNA # ZTNA API: blockUser(userId, reason) 6. Create P1 incident in ITSM # ServiceNow API: createIncident(P1) 7. Page SOC analyst # PagerDuty: trigger(policy=SOC-P1) 8. Notify user's manager # Slack + Email: notifyManager(mgr) ENRICHMENT (T+30 seconds): - Pull: last 24h sign-in history - Pull: all privileged roles / group memberships - Pull: recent file access and email send events - Geo-plot: all recent access locations - Cross-reference: breach credential database (Have I Been Pwned API) SOC REVIEW (T+15 min SLA): - Confirm compromise / false positive - If FP: restore account, document, tune detection - If confirmed: escalate to full IR procedure
Automation blast radius: Automated account disables are powerful but dangerous. Implement confidence thresholds — only automate at risk score >90. Between 60-90, automate step-up MFA and notify SOC. Below 60, log and monitor. Test all playbooks in simulation mode before production activation. Maintain break-glass accounts excluded from all automated policies.
15

CISA Zero Trust Maturity Model

// WHERE ARE YOU TODAY

CISA's ZT Maturity Model defines four stages across all five pillars. Organizations rarely advance all pillars simultaneously — focus on achieving ADVANCED across Identity first, as it provides the most immediate risk reduction and enables higher maturity in other pillars.

Stage 01
Traditional
  • Static perimeter defenses
  • Manual access provisioning
  • No device posture checking
  • Password-only authentication
  • Flat network architecture
  • Minimal telemetry
Stage 02
Initial
  • MFA deployed (some users)
  • Basic MDM enrollment
  • VLAN segmentation
  • SSO / IdP introduced
  • SIEM with basic correlation
  • Manual access review (annual)
Stage 03
Advanced
  • Phishing-resistant MFA
  • ZTNA replacing VPN
  • Workload micro-segmentation
  • JIT privileged access (PAM)
  • Automated threat response
  • Quarterly access reviews
Stage 04
Optimal
  • Dynamic, risk-scored policy
  • Continuous re-authorization (CAE)
  • mTLS service mesh everywhere
  • Dynamic secrets, no static creds
  • Real-time SOAR automation
  • Continuous access review (CIEM)
16

Implementation Roadmap

// PHASED MIGRATION FROM PERIMETER

ZTA is a multi-year journey, not a product purchase. Organizations that try to boil the ocean — rearchitecting everything simultaneously — fail. The most successful implementations use a phased approach that delivers quick wins in identity (highest ROI) while progressively modernizing network and data controls.

Recommended Phasing — 18-Month Plan
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PHASE 0 — DISCOVER (Months 1-2) Risk: Map, not mitigate yet ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ✦ Asset inventory — all users, devices, apps, services, data stores ✦ Traffic mapping — east-west flows (Illumio / NSX observe mode) ✦ Identity audit — all accounts, service accounts, privileged roles ✦ Data classification — scan and label data at rest (Varonis / Purview) ✦ Current-state maturity assessment (CISA ZT Maturity Model) ✦ Threat model — identify crown jewels, likely attack paths ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PHASE 1 — IDENTITY FOUNDATION (Months 3-6) ROI: HIGHEST ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ✦ Consolidate IdP — single authoritative identity provider ✦ MFA for all users — start TOTP, roadmap to FIDO2 ✦ Privileged accounts — enroll in PAM (CyberArk / BeyondTrust) ✦ Eliminate shared accounts and service account passwords ✦ Conditional access baseline policies — compliant device + MFA ✦ Access reviews — implement quarterly automated review cycle ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PHASE 2 — NETWORK MODERNIZATION (Months 6-12) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ✦ Deploy ZTNA for remote access — pilot with 20% of users ✦ VPN deprecation plan — sunset legacy VPN per app group ✦ Micro-segmentation pilot — start with highest-value crown jewels ✦ DNS security — block C2 and malicious domains (Cisco Umbrella / PDNS) ✦ TLS inspection — decrypt and inspect encrypted traffic ✦ Expand ZTNA — migrate remaining remote access populations ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PHASE 3 — DATA & WORKLOAD (Months 12-18) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ✦ Deploy CASB / DLP inline — data-aware access controls ✦ Service mesh + mTLS — workload-to-workload identity ✦ Secrets management — eliminate all static credentials ✦ Phishing-resistant MFA — FIDO2 for privileged users first ✦ SOAR automation — automate top 5 response playbooks ✦ Full micro-segmentation — enforce allowlist policy network-wide
Common Failure Modes Avoid
  • Big-bang approach — too much change at once
  • Buying tools before defining policy
  • Ignoring service account identities
  • Skipping observe/audit mode (enforce blindly)
  • No executive sponsorship / budget alignment
  • Siloed teams — network vs. identity vs. security
  • Underestimating change management / user friction
Success Factors Must-Have
  • Identity-first sequencing — highest ROI, lowest disruption
  • Observe before enforce — map reality, then apply policy
  • Executive mandate with clear success metrics
  • Cross-functional tiger team (IAM + Net + Sec + App)
  • User experience investment — poor UX = shadow IT
  • Continuous measurement against CISA maturity model
  • Vendor agnostic architecture (avoid lock-in)
Reference Architectures: NIST SP 800-207 (canonical ZTA definition), CISA Zero Trust Maturity Model v2 (staged roadmap), DoD Zero Trust Strategy (federal implementation), Google BeyondCorp (original corporate ZTA case study), Microsoft Zero Trust Guidance Center (Azure-focused), NSA Embracing a Zero Trust Security Model (network-focused guidance).