Zero Trust Architecture Cheat Sheet
Explains zero trust principles, core architectural components, and practical steps for shifting from perimeter-based to identity-based security.
2 PagesAdvancedFeb 15, 2026
Core Zero Trust Principles
The foundational tenets defined by NIST SP 800-207.
- Never trust, always verify- No implicit trust based on network location (inside vs. outside the perimeter)
- Least-privilege access- Grant minimum necessary access per request, not broad standing access
- Assume breach- Design controls as if an attacker is already inside the network
- Continuous verification- Re-authenticate and re-authorize based on ongoing signals, not one-time login
- Micro-segmentation- Enforce granular access boundaries between individual workloads, not just network zones
Key Architectural Components
Building blocks of a zero trust deployment (per NIST SP 800-207).
- Policy Decision Point (PDP)- Evaluates access requests against policy and current context
- Policy Enforcement Point (PEP)- Enforces the PDP's decision, allowing or blocking the connection
- Identity provider (IdP)- Authenticates users/devices and supplies identity attributes for policy decisions
- Device posture assessment- Verifies device health/compliance (patched OS, EDR running) before granting access
- ZTNA- Zero Trust Network Access; replaces traditional VPN with per-app, identity-aware access
Signals Used in Access Decisions
Contextual factors evaluated on every access request.
- User identity & role- Who is requesting access and what's their authorization level
- Device trust/posture- Is the device managed, patched, and free of known compromise indicators
- Location & network- Anomalous geography or IP reputation can trigger step-up authentication
- Behavioral analytics- Deviation from a user's normal access patterns
- Resource sensitivity- Higher-value resources require stronger verification
Policy-as-Code with OPA/Rego
Expressing a PDP access decision as a declarative Rego policy evaluated by Open Policy Agent.
rego
package ztna.authzdefault allow = false# Allow only if identity, device posture, and resource sensitivity all check outallow { input.user.mfa_verified == true input.device.compliant == true input.device.disk_encrypted == true trust_score >= required_score}trust_score = score { base := 50 mfa_bonus := 30 * to_number(input.user.mfa_verified) posture_bonus := 20 * to_number(input.device.compliant) score := base + mfa_bonus + posture_bonus}required_score = 90 { input.resource.sensitivity == "high"} else = 60
SPIFFE/SPIRE Workload Identity
Fetching a short-lived X.509 SVID for service-to-service mTLS without static credentials.
bash
# Register a workload with SPIRE server (identity = SPIFFE ID, not IP/hostname)spire-server entry create \ -spiffeID spiffe://example.org/ns/prod/sa/payments-api \ -parentID spiffe://example.org/ns/prod/node \ -selector k8s:ns:prod \ -selector k8s:sa:payments-api# Workload fetches its SVID via the SPIRE agent's Workload API (Unix socket)spire-agent api fetch x509 \ -socketPath /run/spire/sockets/agent.sock# SVIDs auto-rotate (default TTL ~1h); services present them for mTLS# instead of long-lived API keys or shared certs
Per-Application ZTNA Access Policy
A resource-scoped policy replacing broad VPN network access with per-app, context-aware rules.
yaml
policies: - name: allow-finance-app resource: app://finance-portal conditions: identity_group: ["finance-team", "finance-admins"] device_posture: "compliant" mfa: "required" network_risk: "low" time_window: "business-hours" action: allow session: max_duration_minutes: 60 reauth_on_risk_change: true - name: deny-default resource: "*" action: deny
CISA Zero Trust Maturity Model — Pillars
The five pillars organizations progress through from traditional to optimal zero trust.
- Identity- Move from password-only auth to phishing-resistant MFA and continuous risk-based validation
- Devices- Move from unmanaged assets to real-time posture attestation with automated compliance response
- Networks- Move from macro-segmentation (VLANs) to fully micro-segmented, encrypted-by-default traffic
- Applications & workloads- Move from perimeter-protected apps to per-request authorization integrated into CI/CD
- Data- Move from static classification to automated, attribute-driven access and dynamic DLP
- Visibility & analytics- Move from siloed logs to automated, cross-pillar telemetry feeding the PDP in real time
Zero Trust Migration Pitfalls
Mistakes that stall or undermine zero trust rollouts in practice.
- Treating ZTNA as a VPN swap- Deploying a ZTNA gateway without per-app policy work just relocates the perimeter, it doesn't remove it
- One-time trust evaluation- Granting a long-lived session after login defeats continuous verification; sessions must re-evaluate on signal change
- Ignoring machine-to-machine traffic- Zero trust must cover service/workload identity (mTLS, SPIFFE), not just human users
- No fallback for PDP outages- A centralized PDP is a single point of failure; define fail-closed vs fail-open behavior explicitly per resource
- Segmenting without observability- Micro-segmentation without flow logging makes legitimate traffic breaks nearly impossible to diagnose
Pro Tip
Start a zero trust migration with your highest-value assets and identity/device posture signals first, not a wholesale network overhaul — trying to zero-trust everything at once typically stalls the project entirely.
Was this cheat sheet helpful?
Explore Topics
#ZeroTrustArchitecture#ZeroTrustArchitectureCheatSheet#Cybersecurity#Advanced#CoreZeroTrustPrinciples#KeyArchitecturalComponents#SignalsUsedInAccessDecisions#Policy#Security#CheatSheet#SkillVeris
