An organisation replaces its VPN with an identity-aware access model. What actually has to change beyond the network, and where do these programmes stall?

What has to change beyond the network

Replacing the VPN is the visible part and the smallest part. The model requires:

1. Every application to authenticate and authorise independently. The VPN's implicit trust — "you are on the network, therefore you are trusted" — was doing real work. Legacy applications with no authentication of their own, relying on network position, must be fronted by a proxy that enforces identity, or modified.

2. Device posture as an input to access decisions. Managed, patched, encrypted, running required software. This needs a device management estate that many organisations do not have, and it is frequently the longest pole in the programme.

3. Continuous evaluation rather than a session-establishment check. Access re-evaluated as conditions change — location, device posture, risk signals — rather than granted once for a session.

4. Service-to-service identity, not just user identity. The same principle applied internally means workload identity and mutual authentication between services, which is a separate large project.

5. Comprehensive inventory. You cannot protect applications you do not know about. Discovery usually finds a substantial number of undocumented internal applications, and that discovery is itself valuable.

Where these programmes stall

1. The legacy long tail. The first 80% of applications are modern and straightforward. The remainder are old, unowned, or use protocols that do not fit an identity-aware proxy — a thick client, a database connection, a hard-coded address. These consume most of the programme and generate pressure to keep the VPN "just for those", which preserves the flat network the programme existed to eliminate.

2. Device posture requirements colliding with reality. Contractors, personal devices, unmanageable systems. Each exception weakens the model, and exceptions accumulate.

3. The identity provider becoming a critical dependency. Every access decision now flows through it, so its availability requirement is now the maximum of everything it protects — and its compromise is total. Break-glass access must exist and be tested, which is uncomfortable to design and essential.

4. Treating it as a network project. Owned by the network team, scoped as a VPN replacement, with no mandate to change applications. It then delivers a proxy and leaves the trust model intact.

The pragmatic sequencing

Start with the applications where the benefit is highest and the change is smallest — internet-facing internal tools accessed by remote staff. Get device posture in place for managed devices first. Segment the legacy remainder into a shrinking, explicitly-bounded network with its own controls, and treat reducing it as an ongoing programme with a named owner rather than as a phase that ends.

The measure of progress is not "VPN decommissioned" but "how many applications still rely on network position for their security" — because that number is the actual risk, and it is the one that tends to go unmeasured.