Zero Trust security — what vendors won't tell you. Implementation pain, legacy nightmares, identity sprawl, and the massive gap between marketing slides and production reality.
Zero Trust is the right direction. Getting there is the problem nobody talks about.
- Zero Trust Is a Journey, Not a Product
- Identity Is Harder Than Network
- Legacy Systems Break Everything
- The User Experience Tax
- Microsegmentation Myths
- Vendor Lock-In and Tool Sprawl
- The Operational Nightmare
- Compliance Theater
- What Actually Works
- Related Repos
- Contributing
What vendors tell you: "Deploy our Zero Trust platform and you're secure."
What actually happens: Zero Trust is an architecture philosophy (NIST SP 800-207), not a product. No single vendor covers identity, device trust, network segmentation, application security, and data protection. You'll need 5-10 tools that supposedly integrate but don't.
The Zero Trust stack reality:
| Pillar | What You Need | Typical Vendor | Actually Integrates? |
|---|---|---|---|
| Identity | SSO + MFA + RBAC | Okta, Entra ID, Ping | Mostly |
| Device Trust | MDM + posture checks | Intune, Jamf, CrowdStrike | Partially |
| Network | Microsegmentation + ZTNA | Zscaler, Cloudflare, Palo Alto | Partially |
| Application | CASB + WAF + API security | Netskope, Cloudflare, Akamai | Barely |
| Data | DLP + encryption + classification | Varonis, Microsoft Purview | Barely |
| Monitoring | SIEM + UEBA + XDR | Splunk, Sentinel, CrowdStrike | It depends |
Realistic timeline to "Zero Trust":
| Organization Size | Time to Basic ZT | Time to Mature ZT | Budget |
|---|---|---|---|
| Startup (< 100) | 3-6 months | 1-2 years | $50K-200K/year |
| Mid-size (100-1000) | 6-12 months | 2-3 years | $200K-1M/year |
| Enterprise (1000+) | 1-2 years | 3-5 years | $1M-10M+/year |
What vendors tell you: "Replace your VPN with our ZTNA solution and you have Zero Trust."
What actually happens: ZTNA replaces VPN for remote access — that's one pillar of many. You still have lateral movement inside your network, over-privileged service accounts, shared credentials in config files, and legacy apps that can't do modern auth.
What actually matters (in order):
- Strong identity — MFA everywhere, no shared accounts, no password-only auth
- Least privilege — Role-based access, just-in-time elevation, regular access reviews
- Device trust — Verify device health before granting access
- Microsegmentation — Limit blast radius of compromised systems
- Continuous monitoring — Detect anomalies, not just block known threats
What vendors tell you: "Centralize identity with our Identity Provider."
What actually happens: Your organization has:
- Active Directory (on-prem)
- Entra ID / Azure AD (cloud)
- Okta (SaaS apps)
- Local accounts on 47 legacy systems
- Service accounts nobody owns
- Shared credentials in Vault/env vars
- API keys scattered across CI/CD pipelines
- SSH keys on developer laptops from 3 years ago
Centralizing human identity is achievable. Centralizing machine identity (service accounts, API keys, certificates, secrets) is where organizations get stuck for years.
The identity sprawl numbers:
| Identity Type | Typical Count (500-person org) | Who Manages Them |
|---|---|---|
| Human accounts | 500-700 | IT / IAM team |
| Service accounts | 2,000-5,000 | Nobody (seriously) |
| API keys | 5,000-20,000 | Developers |
| Certificates | 1,000-10,000 | Sometimes PKI team |
| SSH keys | 500-5,000 | Developers |
| Database credentials | 200-1,000 | Devs + DBAs |
How to deal with it:
- Start with human identity (SSO + MFA) — highest ROI
- Inventory machine identities before trying to manage them
- Use workload identity federation (no long-lived credentials)
- Implement secret scanning in CI/CD (GitGuardian, Gitleaks, TruffleHog)
- Accept that 100% centralization takes years — prioritize by risk
What vendors tell you: "Deploy MFA and you've eliminated 99% of credential attacks."
What actually happens: MFA blocks password spraying and credential stuffing. It does NOT prevent:
- MFA fatigue attacks — bombard users with push notifications until they approve
- AiTM (Adversary-in-the-Middle) phishing — proxy captures both password and MFA token in real-time
- Session hijacking — steal session cookies after authentication
- SIM swapping — intercept SMS-based MFA codes
- Help desk social engineering — call IT, impersonate user, reset MFA
What actually helps:
- Use phishing-resistant MFA (FIDO2 keys, passkeys) — not SMS, not push notifications
- Implement continuous authentication (re-verify on sensitive actions)
- Monitor for impossible travel and suspicious session behavior
- Train help desk to verify identity before MFA resets
What vendors tell you: "Set policies like 'block unmanaged devices from sensitive apps.'"
What actually happens: You create 50 Conditional Access policies. They conflict. Marketing can't access Salesforce from their personal phones during a conference. The CEO is locked out during a board meeting. You create exceptions. Exceptions multiply. Two years later, nobody understands the full policy set.
How to deal with it:
- Start with 5-10 core policies, not 50
- Use "report-only" mode for 2 weeks before enforcing
- Document every policy and its business justification
- Review policies quarterly — remove or consolidate
- Name policies clearly:
CA001-Block-Legacy-Auth, notPolicy 47
What vendors tell you: "Zero Trust works for all applications."
What actually happens: Your 15-year-old ERP system:
- Only supports basic authentication (username + password)
- Can't integrate with your IdP (no SAML, no OIDC)
- Requires direct database connections (no API layer)
- Runs on Windows Server 2012 (can't install modern agents)
- Has 500 active users who will revolt if you change their workflow
Percentage of enterprise apps that can do modern auth:
| App Category | Modern Auth Support |
|---|---|
| Modern SaaS (Salesforce, etc.) | 95%+ |
| Recent commercial software | 70-80% |
| Custom web apps (< 5 years) | 60-80% |
| Custom web apps (> 10 years) | 20-40% |
| Mainframe / AS400 | 0-5% |
| Industrial / OT systems | 0-10% |
| Vendor appliances | 10-30% |
How to deal with it:
- Wrap legacy apps with an identity-aware proxy (Azure AD App Proxy, Cloudflare Access)
- Isolate systems that can't be protected in their own network segment
- Monitor heavily — compensating controls for systems that can't do ZT natively
- Accept that some systems need VPN-like access patterns until they're replaced
- Build a migration roadmap — ZT is the forcing function to modernize
What vendors tell you: "Our platform covers IT and OT environments."
What actually happens: Industrial control systems, medical devices, building management systems, and IoT devices:
- Can't run agents
- Can't do TLS (some run on 20-year-old firmware)
- Have default credentials that can't be changed
- Are managed by facilities/engineering teams, not IT/security
- A firmware update might require a maintenance window — in 6 months
How to deal with it:
- Network segmentation is your primary control (isolate OT from IT)
- Deploy passive monitoring (network tap + anomaly detection) — don't install agents
- Maintain a separate asset inventory for OT/IoT
- Accept that OT Zero Trust is 5-10 years behind IT Zero Trust
What vendors tell you: "Zero Trust is transparent to users."
What actually happens:
A user's morning with Zero Trust:
- Boot laptop → device compliance check (30 seconds)
- Open email → MFA prompt (15 seconds)
- Open Jira → SSO redirect → MFA again (different app, new session)
- SSH to server → certificate-based auth → 2FA → just-in-time access request → wait for approval
- Access database → step-up authentication → explain why in ticket
- User gives up, shares credentials with colleague to skip steps 4-5
How to deal with it:
- Implement SSO properly (one login, access to everything appropriate)
- Use passwordless authentication (FIDO2 keys → one tap, no typing)
- Risk-based authentication: MFA for sensitive actions, silent for low-risk
- Session duration should be hours, not minutes (balance security vs friction)
- Measure authentication friction as a KPI — if users hate it, they'll bypass it
What vendors tell you: "Modern developers expect Zero Trust."
What actually happens: Developers who used to ssh root@server now need to:
- Request access through a portal
- Wait for just-in-time approval (5-30 minutes)
- Use a bastion host with short-lived certificates
- Their scripts break because hardcoded IPs/credentials no longer work
- CI/CD pipelines fail because service accounts were rotated
Developer impact:
| Change | Productivity Impact | Recovery Time |
|---|---|---|
| SSH key → certificate auth | 1-2 days setup | 1 week |
| Static credentials → vault | 2-3 days migration per app | 2 weeks |
| Direct DB access → proxy | 1-2 days | 1 week |
| VPN → ZTNA | 1 day | 3 days |
| All at once | 2-4 weeks | Never (they'll quit) |
How to deal with it:
- Roll out changes incrementally — one system at a time
- Provide self-service access portals (don't make devs file tickets for everything)
- Automate credential rotation in CI/CD pipelines first
- Give developers 2-4 weeks notice before changes, with migration guides
What vendors tell you: "Deploy our agent and segment your network in weeks."
What actually happens:
- Discovery phase (2-4 months): Map all application flows. You'll find 3x more east-west traffic than expected.
- Policy design (1-3 months): Define which apps can talk to which. Every exception requires a meeting.
- Testing (2-4 months): Enable policies in "monitor" mode. Fix the 500 flows you missed.
- Enforcement (3-6 months): Slowly enable enforcement, service by service. Something breaks every week.
- Maintenance (forever): Every new app, migration, or deployment needs policy updates.
Total: 8-17 months, not the "weeks" the vendor promised.
What vendors tell you: "We'll show you all application flows."
What actually happens: Most organizations have no visibility into which services talk to which. The "application dependency map" is either outdated, incomplete, or doesn't exist. You can't segment what you can't see.
Why it's hard:
- Applications communicate on dynamic ports
- Microservices create thousands of ephemeral connections
- Database replication, backup systems, and monitoring add noise
- Cloud-native apps use service mesh, which obscures actual flows
- Nobody documented the app architecture when it was built 8 years ago
How to deal with it:
- Run a traffic discovery tool for 30+ days before writing any segmentation policies
- Focus on crown jewels first (databases, payment systems, PII stores)
- Accept 80% coverage — chasing the last 20% takes 80% of the effort
What vendors tell you: "Consolidate with our platform."
What actually happens: You buy the "platform." It doesn't replace your existing SIEM, EDR, or firewall. Now you have 76 tools. The new tool has its own console, its own alerts, its own agent, and its own API. Your security team spends more time switching between dashboards than investigating threats.
The tool sprawl problem:
| Category | Typical Tool Count | Integration Reality |
|---|---|---|
| Identity & Access | 3-5 tools | Moderate — SCIM/SAML help |
| Endpoint | 2-4 tools | Poor — agents compete for resources |
| Network | 3-5 tools | Poor — different vendors, different consoles |
| Cloud Security | 3-6 tools | Getting better (CNAPP consolidation) |
| SIEM / Analytics | 1-3 tools | The data lake everything feeds into |
| Email Security | 1-2 tools | Generally good |
How to deal with it:
- Map your current tools to NIST ZT pillars — identify gaps AND overlaps
- Consolidate where possible (SASE = network + cloud access in one)
- Prioritize tools with open APIs and standard formats (STIX/TAXII, CEF, OCSF)
- Kill tools that provide overlapping capability — vendor contracts are the blocker, not technology
What vendors tell you: "SASE is Zero Trust for the network."
What actually happens: SASE (Secure Access Service Edge) combines SD-WAN + Cloud Security (CASB, SWG, ZTNA, FWaaS). It's a networking product with security features. It handles network access well but doesn't address identity governance, device trust, data classification, or application-level security.
SASE covers:
- ✅ Remote access (ZTNA replaces VPN)
- ✅ Web filtering (SWG)
- ✅ Cloud app visibility (CASB)
- ✅ Network-level segmentation
SASE doesn't cover:
- ❌ Identity governance and lifecycle
- ❌ Privileged access management
- ❌ Application-level authorization (RBAC/ABAC)
- ❌ Data classification and protection
- ❌ Workload identity and service mesh
- ❌ Endpoint detection and response
What vendors tell you: "Zero Trust gives you complete visibility into all access."
What actually happens: You now see every authentication, every authorization decision, every denied request. Your SIEM ingests 10x more events. Your SOC gets 500 new alerts/day. 95% are false positives from legitimate users hitting Conditional Access policies. The real threats get buried.
Alert volumes before vs after ZT:
| Source | Before ZT | After ZT |
|---|---|---|
| Authentication events | 10K/day | 100K/day |
| Authorization decisions | Not logged | 500K/day |
| Network flow logs | 1M/day | 10M/day (microsegmentation) |
| Device compliance events | None | 50K/day |
| Actionable alerts | 50/day | 500/day (but mostly false positives) |
How to deal with it:
- Tune alert thresholds BEFORE enabling enforcement
- Implement tiered alerting: P1 (block + alert), P2 (alert only), P3 (log only)
- Use SOAR automation for known-good patterns (auto-close false positives)
- Focus SOC on behavioral anomalies, not policy violations
- Budget 1-2 FTEs just for alert tuning in the first year
What vendors tell you: "Use certificates for mutual TLS — it's more secure than passwords."
What actually happens: mTLS is more secure. But now you manage:
- Certificate authority infrastructure (root CA, intermediate CAs)
- Certificate lifecycle (issuance, renewal, revocation)
- Short-lived certificates (better security, more rotation)
- Certificate distribution to every workload
- Debugging "certificate expired" at 3 AM on a Saturday
Certificate failure modes:
| Failure | Impact | How Common |
|---|---|---|
| Cert expiration | Complete service outage | Very common |
| CA compromise | Everything is compromised | Rare but catastrophic |
| Clock skew | "Certificate not yet valid" | Surprisingly common in containers |
| Cert chain incomplete | Intermittent TLS failures | Common with custom CAs |
| CRL/OCSP unavailable | Can't validate revocation | Common under load |
How to deal with it:
- Use cert-manager (K8s) or Vault PKI for automated certificate lifecycle
- Monitor certificate expiration with 30/14/7/1 day alerts
- Use short-lived certificates (hours, not years) with automated rotation
- Test certificate renewal in staging before production
- Document your CA chain and keep offline root CA backups
What vendors tell you: (Nothing — they don't mention this.)
What actually happens: Your Zero Trust policies work perfectly. Then your IdP goes down. Nobody can authenticate. Or ransomware encrypts your PAM solution. Or a critical production incident requires immediate access that takes 30 minutes to approve through normal channels.
Scenarios that need break-glass:
- Identity provider outage (Okta, Entra ID down)
- PAM system compromised
- Critical incident requiring immediate root access
- Microsegmentation policy blocking emergency traffic
- Security tool false positive blocking legitimate operations
How to deal with it:
- Create documented break-glass procedures for each ZT control
- Store emergency credentials in physically secure location (hardware tokens, printed codes)
- Test break-glass procedures quarterly (don't assume they work)
- Log all break-glass usage and review within 24 hours
- Ensure break-glass access auto-expires (don't leave emergency access open)
What vendors tell you: "Our product is Zero Trust compliant / Zero Trust certified."
What actually happens: There is no Zero Trust certification body. No compliance standard says "you must have Zero Trust." NIST SP 800-207 defines the architecture but has no certification program. When a vendor says "Zero Trust certified," they made that up.
Compliance frameworks that reference Zero Trust concepts:
| Framework | What It Actually Says |
|---|---|
| NIST SP 800-207 | Architecture guidelines, not requirements |
| CISA Zero Trust Maturity Model | Maturity levels, not pass/fail |
| DoD Zero Trust Strategy | Federal agencies only, phased approach |
| ISO 27001 | Doesn't mention Zero Trust |
| SOC 2 | Doesn't mention Zero Trust |
| PCI DSS 4.0 | Stronger access controls, but not "Zero Trust" |
How to deal with it:
- Map your ZT implementation to CISA Maturity Model levels (concrete, measurable)
- Use ZT to improve compliance posture, not as a compliance checkbox
- Don't let auditors demand "Zero Trust" without defining what they mean
- Document your architecture decisions and justify them against NIST 800-207
What vendors tell you: "Our dashboard gives you a Zero Trust score."
What actually happens: The CISO presents a "Zero Trust maturity score of 3.2 out of 5" to the board. Nobody knows what that means. The score combines identity (mature), network (moderate), and OT (nonexistent) into one meaningless average. The board either panics or ignores it.
What the board actually needs to know:
- What are our top 5 security risks?
- How would an attacker move laterally after initial compromise?
- What's the blast radius of a compromised credential?
- How long does it take to detect and respond to a breach?
- What are we spending, and is it reducing risk?
Phase 1: Foundation (Months 1-6)
- Deploy SSO for all SaaS applications
- Enable MFA for all users (phishing-resistant for admins)
- Eliminate shared accounts and default credentials
- Implement privileged access management (PAM) for admin accounts
- Block legacy authentication protocols (NTLM, basic auth where possible)
- Deploy EDR on all endpoints
Phase 2: Visibility (Months 6-12)
- Map all application flows (east-west traffic)
- Inventory all machine identities (service accounts, API keys, certificates)
- Centralize logging (authentication, authorization, network flows)
- Implement Conditional Access policies (start with report-only mode)
- Deploy ZTNA for remote access (replace VPN for new use cases)
Phase 3: Enforcement (Months 12-24)
- Enforce Conditional Access policies (managed devices, compliant status)
- Implement just-in-time access for privileged operations
- Begin microsegmentation (start with crown jewels — databases, PII stores)
- Automate certificate lifecycle management
- Implement break-glass procedures and test them
Phase 4: Maturity (Months 24-36+)
- Continuous authentication and risk-based access
- Full microsegmentation across production environments
- Automated response to identity-based threats
- Zero standing privileges for all admin access
- Regular adversary simulation / red team exercises
If you do nothing else, do these three things:
- SSO + MFA everywhere — eliminates 80% of credential-based attacks
- Eliminate shared accounts — enables accountability and forensics
- Conditional Access — block unmanaged devices from sensitive data
These three controls are cheaper and more effective than any microsegmentation project.
Good Zero Trust metrics:
| Metric | What It Tells You | Target |
|---|---|---|
| % of apps behind SSO | Identity coverage | > 95% |
| % of users with phishing-resistant MFA | Credential protection | > 90% for admins, > 50% all users |
| Mean time to revoke access | Offboarding risk | < 4 hours |
| % of admin access that's just-in-time | Standing privilege reduction | > 80% |
| Lateral movement paths (BloodHound) | Attack surface | Decreasing quarter over quarter |
| Break-glass procedure test pass rate | Emergency readiness | 100% (test quarterly) |
Bad Zero Trust metrics:
- ❌ "Zero Trust maturity score" (too abstract)
- ❌ Number of policies deployed (more ≠ better)
- ❌ Number of tools purchased (tool sprawl)
- ❌ Vendor compliance checkbox count
| Repo | Description |
|---|---|
| what-they-dont-tell-you-about-kubernetes | K8s security defaults section covers container security |
| aws-hidden-costs | Security service costs (GuardDuty, WAF, Secrets Manager) |
| terraform-gotchas | IaC security gotchas (state secrets, hardcoded credentials) |
| what-they-dont-tell-you-about-llms | AI security and privacy landmines |
| devops-learning-path | DevSecOps phase covers security in CI/CD |
| production-ready-snippets | Secure configs for Nginx, Docker, K8s |
Got a Zero Trust implementation war story? See CONTRIBUTING.md to share it.
MIT — Share freely, attribute kindly.
⭐ If this saved you from a Zero Trust vendor pitch, star this repo.