Most Zero Trust programmes stall at the same point: the architecture diagram is finished, and nobody can identify a first change that ships without breaking something.
The sequence below works because each quarter delivers a control that stands on its own. If the programme is cancelled after quarter two, quarter two still improved the estate.
Quarter 1: know what talks to what
You cannot segment traffic you have not measured. Deploy flow collection, then spend the quarter producing an inventory of actual service-to-service communication, not the one the documentation claims.
Expect surprises. Every estate we have mapped contained at least one production dependency nobody could account for.
Quarter 2: identity before network
Move authentication for internal applications behind a single identity provider with phishing-resistant factors. This is the change with the highest return, because it removes the credential replay that most intrusions still rely on.
Do not attempt network segmentation in the same quarter. Doing both at once means you cannot tell which change caused an outage.
Quarter 3: conditional access, in monitor mode first
Write the access policies. Run them in report-only for six weeks. Read what they would have blocked.
The policies you wrote in quarter three are always wrong in ways the inventory from quarter one did not predict. Finding that out in monitoring costs nothing.
Quarter 4: enforce, then segment
Enforce the policies that survived monitoring. Only then start network segmentation, beginning with the backup infrastructure and the identity provider itself.
Those two are worth isolating before anything else, because they are what an operator goes for once inside.
What this deliberately omits
There is no product recommendation here. The sequence works with tooling most organisations already own. Buying a platform before completing quarter one is how programmes end up with an expensive control enforcing rules written against an imaginary network.