Zero Trust programmes rarely fail on the architecture diagram. The model is sound: never trust by network location, verify explicitly, grant least privilege, and assume breach. NIST SP 800-207 sets it out clearly, and the CISA Zero Trust Maturity Model breaks the work into five pillars: identity, devices, networks, applications and workloads, and data. What fails first is more mundane. It is the things the diagram assumed would be easy.
These notes are about the order in which a real programme tends to hurt, because knowing the order lets you plan for it rather than discover it in the middle of a rollout.
1. Your inventory
Every Zero Trust decision is a policy about a user, device, application or data set. You cannot write a policy for something you cannot name. The first thing that breaks is the assumption that the organization knows what it has: which applications exist, who uses them, which service accounts talk to which systems, which devices are managed.
Expect the discovery phase to produce an uncomfortable list: forgotten applications, shared accounts, undocumented integrations, and servers nobody owns. That list is not a failure of the programme. It is the programme's first real output.
2. Service accounts and machine identities
Human identity is the part of Zero Trust everyone designs for, with multi-factor authentication, conditional access and device checks. Machine identity is the part that breaks. Service accounts with static passwords, scripts with embedded credentials, and applications that authenticate with old protocols cannot answer an MFA prompt and often cannot be moved without a change to the application itself.
The usual result is a quiet set of exceptions that grows until the exceptions are the real attack surface. Treat non-human identities as a first-class workstream from the beginning: inventory them, assign owners, rotate or replace credentials, and scope their access tightly.
3. Legacy applications and protocols
Older line-of-business applications assume a flat, trusted network. They rely on legacy authentication, broad network access, or fixed IP allow-lists. Putting them behind identity-aware access can work, but each one is a small project, and some cannot be done at all without replacing the system.
Decide early how you will handle the ones that cannot move: isolate them, wrap them in a proxy, restrict who and what can reach them, and put a date on their retirement. Without a date, an exception becomes permanent.
4. The help desk and the user experience
Stronger verification adds friction, and friction lands on the help desk first. Device enrolment problems, MFA resets, blocked access from a new location, and "it worked yesterday" tickets spike during rollout. If support is not prepared, the programme loses the goodwill it needs, and people begin to look for ways around the controls.
- Pilot with a friendly group, then widen in waves.
- Give support a runbook and a clear path to security for edge cases.
- Measure friction as well as coverage: failed sign-ins, tickets per user, and time to resolve.
5. Ownership between teams
Zero Trust sits across identity, endpoint, network, application and data teams, which usually report separately and own different tools. The failure is rarely technical disagreement. It is that no single owner is accountable for the end-to-end outcome, so each team optimizes its own piece and the gaps between them remain.
Name one accountable programme owner with authority across those teams, and agree a shared roadmap and a shared definition of done. A steering group with an executive sponsor settles cross-team conflicts faster than any architecture document.
6. Exceptions, break-glass and executives
Every policy needs a controlled way to be bypassed in an emergency, and every organization has people who will ask for a bypass for convenience. If exceptions are granted informally, they accumulate. If break-glass accounts are not monitored, they become the preferred route for an attacker.
- Keep a register of exceptions with an owner, a reason and an expiry date.
- Protect and alert on break-glass accounts, and test them on a schedule.
- Apply the same standard to senior leaders. Their accounts are the highest-value targets.
7. Visibility and the operations budget
Continuous verification generates a great deal of telemetry: sign-in events, device posture, access decisions, policy changes. Logging, storage and analysis costs rise, and a small security team can end up buried in new alerts. Decide what you need to detect, send that, and tune out the rest. More data is not more security unless someone can act on it.
What this means for the plan
None of these are reasons to avoid Zero Trust. They are reasons to start with the work that is least glamorous.
- Begin with inventory and ownership, not tooling.
- Fix identity, including machine identity, before network segmentation.
- Sequence by risk and by the readiness of the users and the systems, not by the vendor's product list.
- Plan the support load, the exception process and the retirement dates in advance.
- Report progress in terms the business understands: fewer standing privileges, fewer unmanaged devices, faster revocation.
A Zero Trust programme is a long change-management exercise that happens to involve technology. The organizations that do well treat it that way from the first week.
If you would like help assessing readiness or sequencing a Zero Trust roadmap, get in touch through the consultation form.