Every Zero Trust conversation eventually reaches the same question, and it is usually asked nervously: how long is this going to take. The honest answer is that it does not finish, and that is not evasion. Zero Trust is a posture the environment holds, not a project with a closing date.
That said, the phases have a shape, and the shape is predictable enough to plan around. What varies is not the sequence. It is how much of the past the organization is carrying.
The sequence that works
I run these in order, because each one makes the next cheaper.
Identity comes first. Conditional Access designed rather than accumulated, standing privilege removed, privileged access put behind elevation, and legacy authentication closed off. Nothing above this layer behaves predictably until it is done.
Device posture comes second. Access decisions become useful only when the policy can ask whether the device meeting the request is one you trust. Before that, Conditional Access is making decisions with half the information.
Data comes third. Classification, labels and the controls that follow them. This is where the work stops being technical and starts being a conversation with the business about what matters.
Detection and response come fourth. By this point the signals are worth collecting, because the environment generates meaningful events rather than noise.
Governance runs last and then never stops, because everything above it drifts.
What actually makes it slow
Almost nothing on that list is slow for technical reasons. The delays come from the same places every time.
- Legacy applications that cannot do modern authentication, and the one team that depends on them
- Service accounts nobody will claim, doing work nobody can describe
- Shared and break-glass credentials that exist because a real process is missing
- Change control that adds weeks to a policy that takes an hour to write
- People, specifically the negotiation about who loses standing admin rights
The last one is the real schedule risk. The identity phase is rarely blocked by Entra. It is blocked by a conversation about privilege that somebody has to own.
Why the first phase feels disproportionate
Teams are often surprised that identity takes as long as it does relative to everything after it. That is the correct ratio, not a problem with the plan. Identity is where you discover what the environment actually is, as opposed to what the documentation says it is. Every unclaimed service account and every undocumented exception surfaces here.
The phases that follow move faster precisely because that discovery already happened. Skipping ahead does not save the time. It moves the discovery to a worse moment, usually during an incident or an audit.
How to plan it honestly
I would rather agree a first phase with a defined end than a program with a date attached to the whole thing. Identity, scoped and finished, with an explicit list of what is out of scope and why. That gives the organization something real to point at, and it gives the next phase a foundation instead of an assumption.
Then treat the rest as a sequence of scoped pieces rather than one long march. Each one should stand on its own and leave the environment better even if funding stops afterwards. A Zero Trust program that only pays off at the end is a program that will be cancelled in the middle.
The measure that matters
The useful question is not how far through the plan you are. It is whether the number of things that get access without an explicit decision is going down. If standing privilege is falling, exceptions are documented and expiring, and access decisions run through policy rather than habit, the program is working regardless of which phase the slide deck says you are in.
If those numbers are flat while the deployment checklist fills up, the tools are being installed and the posture is not changing. That is the failure mode worth watching for, and it is far more common than running late.