Many zero trust programmes buy new products, retire the VPN and still leave the implicit trust that attackers rely on. This list covers the ten mistakes that most often undermine zero trust in practice, why each matters, and what to do instead. Each is mapped to the tenets of NIST SP 800-207, the reference definition of zero trust architecture, and illustrated with incidents from the NHI Mgmt Group breach database where they genuinely fit. It is for security architects, network and identity leads and anyone reviewing a zero trust roadmap.
The Top 10 at a glance
The mistakes are ordered roughly by how often they appear in roadmaps and how much exposure they leave. The NIST SP 800-207 column refers to the seven tenets in section 2.1 of the standard.
| # | Mistake | What it leaves exposed | NIST SP 800-207 tenet |
|---|---|---|---|
| 1 | Ignoring non-human identities | Service accounts, keys and tokens with standing access | 6 |
| 2 | No inventory of assets, identities and flows | Resources nobody protects | 1, 7 |
| 3 | Treating zero trust as a network project | Application and data access decided by location | 2, 4 |
| 4 | Making VPN replacement the goal | Same broad access, delivered differently | 3 |
| 5 | Authenticating once, trusting the session | Stolen session tokens and cookies | 3, 6 |
| 6 | MFA that can be phished or bypassed | Help desk resets, push fatigue, legacy protocols | 6 |
| 7 | Trusting the internal network east-west | Lateral movement between workloads | 2 |
| 8 | Static policies with no device or risk signal | Valid credentials used from any device | 4, 5 |
| 9 | Exempting third parties and legacy systems | Vendor accounts and old appliances outside enforcement | 1, 6 |
| 10 | Not logging policy decisions | No detection, no evidence, no tuning | 7 |
1. Ignoring non-human identities
The mistake: the programme covers employees and their devices, while service accounts, API keys, OAuth applications, workload tokens and AI agents keep permanent, broad access. CISA's Zero Trust Maturity Model v2.0 defines identity to include non-person entities, and NIST CSWP 20 names service accounts in the inventory zero trust needs.
Why it matters: machine credentials are rarely covered by MFA or conditional access, so they become the easiest path. In the Cloudflare Thanksgiving breach, four credentials left unrotated after the Okta breach let a nation-state attacker in.
What to do: inventory NHIs with owners, replace static secrets with short-lived federated credentials, and apply per-request authorisation to services (NIST SP 800-53 IA-9). See the Zero Trust Identity Guide and the Workload Identity Federation Guide.
2. No inventory of assets, identities and flows
The mistake: designing policy before knowing what exists. NIST CSWP 20 says a full inventory of resources, network identities and roles or privileges is necessary for zero trust, and the NCSC's first principle is to know your architecture, including users, devices, services and data.
Why it matters: a forgotten system sits outside every policy. The Microsoft Midnight Blizzard breach began with a forgotten test tenant and an OAuth application nobody was governing.
What to do: build inventories of hardware, software and data flows (NIST CSF 2.0 ID.AM-01, ID.AM-02, ID.AM-03) and reconcile them with discovery. See the Asset Inventory and CMDB Security Guide.
3. Treating zero trust as a network project
The mistake: handing zero trust to the network team as a segmentation or SASE purchase. NIST SP 800-207 describes three approaches, enhanced identity governance, micro-segmentation and software defined perimeters, and most real deployments combine them.
Why it matters: network controls alone cannot decide whether a given subject should reach a given resource. Access must be determined by dynamic policy using identity, device and behaviour (tenet 4).
What to do: make identity, network and application owners joint owners of the policy engine and policy enforcement points. See the NIST SP 800-207 Zero Trust Architecture Guide.
4. Making VPN replacement the goal
The mistake: declaring success once users move from VPN to a ZTNA client, while each user still reaches whole subnets. OMB M-22-09 directs agencies to make applications usable without relying on a VPN, but the aim is per-application access, not a new tunnel.
Why it matters: VPN and edge appliances are a heavily targeted entry point (ATT&CK T1133 External Remote Services). The Colonial Pipeline attack started with one unused VPN account, and the Ivanti Connect Secure exploitation exposed credentials, service accounts and sessions.
What to do: publish applications individually behind a policy enforcement point, remove dormant remote access accounts, and measure access per application. See the ZTNA Guide.
5. Authenticating once, trusting the session
The mistake: strong sign-in followed by long-lived sessions that are never re-evaluated. Tenet 3 says access is granted per session, and tenet 6 says authentication and authorisation are dynamic and strictly enforced.
Why it matters: attackers steal the session rather than the password (ATT&CK T1550.001 Application Access Token). In CitrixBleed, stolen session tokens bypassed MFA.
What to do: shorten session and token lifetimes, bind tokens to devices where supported, and revoke sessions on risk change.
6. MFA that can be phished or bypassed
The mistake: counting SMS, push or OTP as zero trust authentication and leaving help desk resets weak. OMB M-22-09 requires phishing-resistant MFA for agency staff, contractors and partners.
Why it matters: in the MGM Resorts breach, a help desk phone call led to Okta administrator access.
What to do: move privileged and then all users to FIDO2 or certificate-based authentication and verify identity strongly before any reset. See the Top 10 MFA Mistakes.
7. Trusting the internal network east-west
The mistake: enforcing at the edge only, so anything inside the data centre or VPC talks freely. Tenet 2 says all communication is secured regardless of network location, and the NCSC advises not trusting any network, including your own.
Why it matters: once inside, attackers move laterally with valid accounts and remote services (ATT&CK T1078, T1021).
What to do: encrypt internal traffic, segment critical workloads and authorise service-to-service calls by workload identity rather than IP. CISA's microsegmentation guidance (Part One: Introduction and Planning) is a practical start. See the Network Segmentation Guide and the mTLS Guide.
8. Static policies with no device or risk signal
The mistake: access rules that check only username and group. Tenet 5 requires monitoring the integrity and security posture of assets, and tenet 4 includes device state and behavioural attributes.
Why it matters: valid credentials from an infected or unmanaged device get the same access as a managed laptop.
What to do: feed device compliance, EDR status and sign-in risk into the policy engine, starting with report-only mode. See the Device Trust and Posture Guide.
9. Exempting third parties and legacy systems
The mistake: vendor support accounts, partner connections and old appliances are left outside enforcement "until later". CISA ZTMM v2.0 asks agencies to assess how dependencies on external partners and providers affect their architecture.
Why it matters: trusted relationships are a recognised entry route (ATT&CK T1199). In the Okta support system breach, a service account saved in a personal Google profile exposed 134 customers.
What to do: put third-party and legacy access behind a policy enforcement point or compensating gateway, with named owners and exception expiry dates.
10. Not logging policy decisions
The mistake: deploying enforcement without sending policy engine decisions, denials and attributes to monitoring. Tenet 7 says the enterprise collects as much information as possible about assets, infrastructure and communications to improve its posture.
Why it matters: without decision logs there is no detection of misuse, no evidence for auditors and no data to tighten policy.
What to do: log every grant and denial, alert on anomalous use by service principals, and review trends monthly (NIST SP 800-53 SI-4, AU-6). See the ITDR Guide.
Mapping to NIST SP 800-207 and other frameworks
| Mistake | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | MITRE ATT&CK |
|---|---|---|---|
| 1. Ignoring NHIs | PR.AA-01 | IA-9, AC-2 | T1078.004 |
| 2. No inventory | ID.AM-01, ID.AM-03 | CM-8 | - |
| 3. Network-only zero trust | PR.AA-05 | AC-3 | - |
| 4. VPN replacement as goal | PR.IR-01 | AC-17 | T1133 |
| 5. Session trusted after sign-in | PR.AA-03 | IA-2 | T1550.001 |
| 6. Weak MFA | PR.AA-03 | IA-2 | T1078 |
| 7. East-west trust | PR.IR-01 | SC-7, SC-8, AC-4 | T1021 |
| 8. Static policy | PR.AA-05 | AC-6 | T1078 |
| 9. Third-party exemptions | GV.RR-02 | AC-17 | T1199 |
| 10. No decision logging | DE.CM-01, DE.CM-03 | SI-4, AU-6 | - |
Where to start
If you can only do three things this quarter: build an inventory of identities, including service accounts and keys, and the flows of your most critical workflows (mistakes 1 and 2); put those workflows behind per-application policy enforcement with phishing-resistant MFA for privileged users (mistakes 4 and 6); and send every policy decision to your monitoring platform (mistake 10). Track progress with three numbers: the share of NHIs with an owner and expiry, the share of critical applications reachable only through a policy enforcement point, and the share of privileged sign-ins using phishing-resistant MFA. To score the wider programme, see the CISA Zero Trust Maturity Model Guide.
Related NHI Mgmt Group resources: Zero Trust Identity Guide · Zero Trust for AI Agents Guide · SPIFFE and SPIRE Guide · Top 10 Secrets Management Mistakes · Remote Access Identity Guide