You rolled out MFA and conditional access. Your workloads still trust each other completely

Most zero-trust programmes do the human half well and then quietly stop.

Multi-factor authentication everywhere. Conditional access by device state and location. Sign-in risk policies. This is real work and it is usually done competently, because the vendor has a product for it, the project has a name, and the progress is easy to show.

Then the programme is declared complete. Meanwhile every service principal, managed identity, automation account and CI credential in the tenant still holds the standing, broadly-scoped access it was granted on the day someone needed it to work.

That gap is where cloud breaches actually happen.

The problem: you verified the people, not the machines

Zero trust is usually explained as "never trust, always verify," which is true and unhelpfully abstract. A more useful framing: zero trust is a set of decisions about what each identity in your environment is allowed to reach, enforced continuously rather than assumed from position.

Read that way, the reason programmes stall becomes obvious. Human identity has an owner, a budget line and a vendor. Workload identity has none of those. Nobody is accountable for the service principal that a project created in 2022, and there is no product to buy that makes that problem visible on a slide.

So it does not get done — not through disagreement, but because nothing forces it.

What actually goes wrong

Lateral movement does not re-authenticate. An attacker who compromises a workload does not log in again. They inherit whatever that workload already holds: its managed identity, its stored secrets, its network position. Your conditional access policies never see them, because no sign-in occurs. This is the single most common shape of a cloud incident, and it is untouched by the human half of the programme.

Permissions diverge from purpose almost immediately. A credential created to write to one storage account frequently carries Contributor on a whole subscription, because that was the role that was easy to attach on a Friday. Nobody revisits it. Two years later the identity's purpose and its permissions have almost nothing to do with each other, and only the permissions are enforced.

Shared secrets outlive the systems they were made for. A client secret in a pipeline, a connection string in an app setting, an API key in a configuration store — long-lived, broadly valid, rarely rotated, and valid from anywhere. Rotation is the control everyone agrees with and almost nobody has automated.

The network still assumes a perimeter. Many cloud estates have identity controls that are genuinely modern sitting on top of a flat virtual network where any compromised host can reach any other, and where egress is unrestricted so exfiltration is trivial. Identity and network are treated as separate programmes with separate owners, so neither is asked to cover the other's gap.

Nobody can answer the blast radius question. Ask what a specific identity could reach if it were compromised right now. In most organisations that question takes days and produces a hedged answer. If you cannot answer it, you cannot claim the trust boundaries are where you think they are.

What to do, in order

1. Inventory non-human identities and what they can actually reach

Before changing anything, produce the list. Every service principal, managed identity, automation account and deployment credential — and for each, what it currently permits, not what it was created for.

This takes a few days and it is the step that makes everything after it argue for itself. Two things always come out of it: identities nobody can explain, and identities whose scope is far wider than anyone expected. Both are findings you can act on immediately without a design phase.

2. Remove standing privilege at the highest scopes first

Start where the blast radius is largest — subscription and management group — rather than where the assignments are most numerous. Just-in-time elevation is the mechanism, but the sequencing is what determines whether it survives: inventory what is actually used, run a parallel period where elevation is available but standing access still exists, then remove.

The parallel period is the step most organisations skip, and skipping it is why these projects get rolled back after the first outage.

Define the emergency path explicitly and test it. Without one, someone will recreate a standing administrator account at 3am and it will still be there next year.

3. Replace stored secrets with workload identity federation

Where a workload authenticates to another system, prefer a short-lived token issued to that workload's own identity over a stored credential. Managed identities inside the cloud, federated credentials for anything outside it.

This removes the highest-value object in most environments — a long-lived, broadly-scoped, location-independent secret — and it is a configuration change rather than a project. If you do one technical thing from this list, do this.

4. Make the network segment by design, not by convention

Identity controls do not remove the need for network boundaries; they change what those boundaries are for. Hub-and-spoke topology so segments are structural rather than agreed. Private endpoints so platform services are not reachable from the internet by default. Egress filtering, which is consistently the weakest control in otherwise mature environments — plenty of estates carefully restrict inbound traffic and allow any workload to talk to anything outbound.

5. Verify continuously, not at the door

A session established under good conditions should not remain trusted indefinitely when those conditions change. Continuous access evaluation, revocation that takes effect in minutes rather than at token expiry, and re-evaluation on risk signals.

This is the part of "always verify" that most implementations skip, because the initial sign-in check is the visible one.

6. Instrument for the blast radius question

Make "what could this identity reach" answerable in minutes. Identity graph tooling helps, but the more important input is a tagged, current inventory — step one, kept alive rather than produced once for a project.

The number worth reporting

Not the percentage of users with MFA. That reaches 100% early and then measures nothing, which is exactly why it is the figure most often presented.

Report the count of identities — human and non-human — holding standing privileged access at subscription scope or above, and the change since last month. It starts uncomfortably high, it is hard to argue with, and it goes down only when someone does real work.

Where to start

If your programme has finished the human half and stalled:

1. Inventory the non-human identities and what they permit.
2. Remove standing privilege at the highest scopes, with a parallel period and a tested emergency path.
3. Replace stored secrets with federated workload identity.
4. Turn on egress filtering somewhere it will be noticed, and fix what breaks.

Zero trust is not a product you finish deploying. It is the ongoing position that nothing in your environment is trusted because of where it sits — and the honest test of whether you hold that position is whether you can say, today, what any given identity could reach.