Moving to zero-trust access

Zero trust programmes fail in a characteristic way: a policy is written, enforcement is enabled, and a group of people who need access lose it. The rollback is immediate, confidence is damaged, and the next attempt is harder to fund.

The failure is almost never the policy. It is that enforcement was enabled before anyone knew who was actually accessing what.

The principle, briefly

Zero trust replaces the assumption that being on the network confers trust. Instead, every access request is evaluated on its own: who is asking, what device they are on, what they are asking for, and whether the context is reasonable.

The practical consequence is that the network stops being the control. Identity and device posture become the control, and applications are reached through a broker that evaluates each request rather than through a tunnel that grants broad network access.

Order matters more than technology

The migration order below is designed so that nothing is enforced until it is understood.

1. Make identity solid first

Nothing that follows works if identity is weak. Before anything else:

• Every user in one identity provider, with the joiner, mover and leaver processes actually working.
• Strong multi-factor authentication everywhere, with phishing-resistant methods for administrators.
• Service accounts inventoried and, where possible, replaced with managed identities.
• Group membership that reflects current roles rather than accumulated history.

This is unglamorous and it is where most of the real work is. A zero trust deployment on a messy directory enforces the mess.

2. Inventory the applications

You cannot broker access to applications you have not listed. For each: who owns it, who should use it, how it authenticates, and whether it can integrate with your identity provider.

Applications sort into three groups, and the third determines your timeline:

• Modern applications that support standard federation. Straightforward.
• Legacy web applications with their own logins, which can usually be fronted by a proxy.
• Everything else: thick clients, applications requiring specific network protocols, systems with hard-coded addresses. These need individual attention and they are the reason zero trust programmes take longer than planned.

3. Observe before enforcing

This is the step that prevents the characteristic failure.

Deploy the access broker in a mode where it evaluates and logs but does not block. Run it for at least a month, and preferably through a full business cycle so that month-end and quarter-end activity is captured.

What you are looking for:

• Who actually accesses each application, which is regularly different from who is supposed to.
• Access from locations, devices and hours nobody anticipated.
• Machine-to-machine traffic that would break under a policy written for humans.
• The integrations nobody documented.

Every one of these would have been an outage if enforcement had been enabled on day one.

4. Start with new and low-risk applications

The first enforced applications should be ones where a mistake is recoverable and where there is no existing access pattern to break. New deployments are ideal, because there is no legacy behaviour to accommodate.

This builds operational familiarity with the policy engine, the logging and the support path before anything critical depends on it.

5. Move the remote access use case next

Replacing broad VPN access with brokered per-application access is usually the highest-value early step, because VPN typically grants network-level reach far beyond what any individual needs.

It is also well-bounded: the user population is known, they already expect a specific sign-in step, and the change is comprehensible to them.

Run the two in parallel initially. Move a group at a time, keep the old path available, and only remove it when the new path has been proven for that group.

6. Then internal applications, by owner

Work through the application inventory. Group by owner rather than by technology, so that each conversation is with one person who can confirm who should have access.

This is where the observation data earns its keep. Presenting an owner with a list of who actually accessed their application in the last month produces a far better access decision than asking them to specify it from memory.

7. Add device posture last

Requiring a managed, compliant device is a strong control and the one most likely to lock people out. Add it once identity-based access is stable, and stage it: report on non-compliant devices first, warn users next, enforce last.

Be explicit about contractors, personal devices and anything you do not manage. These need a designed answer, not an exception granted under pressure.

What breaks, and how to avoid it

Service accounts and integrations. Automated access that does not present a human identity. Identify these during observation and handle them explicitly before enforcement.

Break-glass access. There must be a path to critical systems when the identity provider is unavailable. Documented, monitored, and tested.

Applications with hard-coded network assumptions. Discovered late and requiring individual work. The application inventory should flag them early.

Support staff. Helpdesk and infrastructure teams often have unusual access patterns that a policy written for typical users will break. Involve them early rather than exempting them permanently.

Measuring progress honestly

Not "percentage of zero trust achieved", which means nothing. Track:

• Applications behind the broker, as a proportion of the inventory.
• Users still using broad network access, trending to zero.
• Standing privileged access, replaced by time-bound elevation.
• Access decisions denied, and how many were legitimate requests wrongly blocked. A rising number here means a policy that is too tight or observation that was too short.

The realistic timeline

For most organisations this is eighteen months to three years, and it is never entirely finished, because there is always an application that resists.

That is fine, provided the sequence holds: identity first, observation before enforcement, easy applications before hard ones, device posture last. Programmes that follow that order tend to keep their funding. Programmes that enable enforcement early tend not to get a second attempt.