Begin with the operating model, not the label
Zero Trust is an architectural approach in which access is not granted solely because of network location. NIST describes it through resource-focused protection, explicit authentication and authorization, and continual evaluation rather than implicit trust in a network segment.[1] That definition matters because many failed programs begin by renaming an existing VPN, identity provider or segmentation project.
The practical goal is to make each access decision using enough current evidence about the subject, device, resource, action and environment, then enforce the decision near the resource. This is a multi-year operating change for most organizations. A credible implementation has a resource inventory, policy decision logic, enforcement points, telemetry, exception handling and a sequence for migration and rollback.
Mistake 1: Buying a product before defining protected resources
A gateway cannot express useful policy when the organization has not identified its important applications, data and machine interfaces. Product-first programs often produce broad groups such as `employees` and `production`, reproducing perimeter trust with new branding.
Correct it by selecting a bounded use case and mapping the resource, users and service identities, devices, transactions, data sensitivity, dependencies and current access paths. Include non-human access: CI runners, backup agents, APIs, scheduled jobs and emergency administration. Define the intended policy in plain language before translating it into vendor syntax. Example: members of the finance operations group may approve payments from managed, compliant devices using phishing-resistant authentication; service accounts may submit files through one API but cannot access the interactive portal.
Measure the outcome at the resource: percentage of access paths under policy, denied unknown identities, unmanaged-device decisions and application availability. Counting purchased licences is not an access-control measure.
Mistake 2: Treating successful login as sufficient authorization
Authentication establishes evidence about identity; authorization determines whether that identity may perform a specific action on a specific resource. A single sign-on rollout can improve identity assurance while leaving excessive application roles untouched.
Correct it by joining identity policy with application entitlements and data-level permissions. Remove standing privilege where practical, separate administrative and daily-use identities, require stronger controls for higher-risk actions and review service-account scopes. The policy engine should receive signals it can evaluate reliably—identity assurance, device state, requested resource, session context and threat indicators—and deny safely when required evidence is unavailable.
Avoid a universal step-up rule that challenges every request. It trains users to approve prompts and can make automation unreliable. Use risk-based controls whose triggers and failure behaviour are documented and testable.
Mistake 3: Trusting device posture as a permanent badge
A device can be healthy at enrolment and compromised later. Posture data can also be delayed, incomplete or wrong. Treating one check as a durable trust grant conflicts with continual evaluation.
Correct it by defining posture freshness, acceptable data sources and what happens when telemetry becomes stale. Evaluate relevant signals such as managed status, supported operating system, encryption, endpoint protection and certificate state, but only where each signal is dependable enough to influence access. Re-evaluate long-lived sessions for sensitive resources and revoke or constrain access when material conditions change.
Design degraded modes deliberately. If the posture service fails, should payroll administration fail closed while the public knowledge base remains available? Test that scenario. Availability and security teams should agree on policy per resource rather than inheriting an opaque vendor default.
Mistake 4: Ignoring workloads and east-west traffic
Human access is visible, so it often receives the first controls. Workload identities and internal service calls remain on broad subnets with shared secrets and long-lived credentials. An attacker who compromises one workload can then traverse the environment without encountering another policy decision.
Correct it by inventorying service-to-service flows, assigning unique workload identities, rotating credentials and enforcing least-privilege policy at suitable gateways, service meshes, host controls or cloud policy points. Segment by application dependency and sensitivity rather than organisational chart alone.
Do not microsegment from a static diagram. Observe actual flows, validate them with application owners, model name resolution and control-plane dependencies, then stage denies. Include DNS, time, certificate validation, identity, monitoring and backup paths; blocking an overlooked infrastructure dependency can create a widespread outage.
Mistake 5: Centralizing enforcement without resilience
Central policy can improve consistency, but it also creates dependencies on identity, device, certificate, DNS and policy services. If every request requires a live round trip to an unavailable decision point, one outage can stop the business.
Correct it by documenting the decision and enforcement topology, cache semantics, policy distribution, high availability and recovery sequence. Decide which policies may use a recent cached decision and which must fail closed. Protect and monitor the control plane as a critical production service. Keep emergency access narrow, time-limited, strongly authenticated and independently logged.
Run dependency-failure exercises. Disconnect the identity provider, expire a device certificate, make posture data stale and isolate a policy node. Confirm that each resource follows its intended degraded mode and that operators can distinguish a policy denial from a platform failure.
Mistake 6: Deploying broad policy in one step
A global cutover combines policy errors, hidden dependencies and unfamiliar support procedures into one high-blast-radius event. Even a correct target design can fail through unsafe migration.
Correct it with a sequence: observe; evaluate policy without enforcement where supported; enforce for a pilot group and low-risk resource; expand by cohort; then remove the old path. Compare intended decisions with observed access and investigate differences. Define success thresholds, stop conditions and rollback for every stage.
Keep the old path only as long as the rollback window requires. A permanent bypass becomes the preferred route around policy. Before removing it, verify external partners, mobile users, automation, disaster-recovery access and after-hours support.
Mistake 7: Measuring controls instead of outcomes
A dashboard that reports MFA adoption and enrolled devices can hide resources that bypass the new enforcement point. CISA's Zero Trust Maturity Model organizes progress across identity, devices, networks, applications and workloads, and data, with visibility, analytics, automation and governance cutting across the pillars.[2] Use that breadth to prevent one strong pillar from masking four weak ones.
Define measures tied to access and recovery: critical resources inventoried; access paths covered by explicit policy; privileged sessions using strong authentication; stale entitlements removed; service identities with scoped credentials; policy decision latency and failure rate; bypass age; mean time to revoke; and successful rollback exercises.
Review denied traffic for both attacks and broken business processes. Zero Trust is not complete when more requests are denied. It is working when approved activity has a narrow, reliable path and unapproved activity does not.
A safer implementation sequence
Choose one valuable but bounded application. Map its users, workloads, data and dependencies. Improve identity assurance and application authorization. Add device evidence where it is trustworthy. Place the enforcement point, run it in observation mode, reconcile policy differences and pilot with real users. Exercise control-plane failure, emergency access and rollback. Only then expand the pattern.
Document policy as code or another version-controlled format where the platform permits it. Require peer review, test representative allow and deny cases, and record the deployed version. After change, read back effective policy and test the live resource from allowed, denied and degraded contexts. A successful configuration push is not proof that access behaves as designed.
Implementation checklist
- Select a bounded resource and name the business outcome.
- Inventory human, service and emergency identities plus every access path.
- Define authorization at the action and resource level, not only login.
- Set posture-signal freshness and per-resource fail-open or fail-closed behaviour.
- Map DNS, PKI, identity, time, logging and control-plane dependencies.
- Include workload identities and east-west flows in the first design.
- Version policy and peer-review each enforcement change.
- Observe and compare decisions before enabling blocking.
- Pilot by resource and cohort with measurable stop conditions.
- Test allowed, denied, stale-posture and unavailable-control-plane scenarios.
- Create narrow, expiring and independently logged emergency access.
- Remove migration bypasses after the verified rollback window.
- Measure access-path coverage, revocation, exceptions and recovery—not licences.