Does zero trust mean getting rid of the VPN?

Eventually, for most access. Not on day one, and not as the first move. A VPN that terminates into a segmented network with per-application policy is a reasonable intermediate state and is far better than a flat one. The order that works is to make the applications enforce identity first, and remove the VPN when it has stopped being the thing holding the controls.

Where does this start if the network is currently flat?

With segmentation, because zero trust assumes a compromise is contained while you deal with it, and a flat network gives you nowhere to contain it. Separate users from servers, put unpatched operational devices on their own segment, and move infrastructure management out of band. That work pays on its own even if the programme stops there.

Do we need device certificates for every machine?

For the applications where the consequence of a compromised but authenticated session is serious, yes. Device identity is what separates zero trust from single sign-on with extra steps: without it, a stolen credential from an unmanaged machine looks exactly like a legitimate one. Rolling it out application by application, hardest first, keeps it affordable.

How long does this take?

Google's programme ran for roughly a decade with a dedicated team. A mid-sized organisation is not doing that, and does not need to: most of the risk reduction comes from the first two or three applications and from segmentation. Treat it as a direction with an order of work rather than as a project with an end date.

Zero trust without rebuilding the network

The BeyondCorp papers are among the most useful things published about enterprise security, and among the most misread. The common reading is that Google abolished the VPN. The useful reading is that Google stopped using network location as evidence of trustworthiness, and then spent years rebuilding access control around identity and device state instead.

The second reading is the one you can act on, because it describes a direction rather than a destination.

The assumption being removed

A traditional network grants access by position. Inside the perimeter you are trusted; outside you are not. Every control is arranged around keeping the boundary intact.

The assumption fails for reasons nobody disputes any more. Laptops leave the building. Contractors need access. Applications moved to providers that were never inside the perimeter. And a single compromised workstation is, by this model, a trusted entity.

Zero trust replaces “where are you” with “who are you, on what device, and are you allowed this particular thing”.

NIST SP 800-207 states it in those terms, and so does the CISA maturity model. It is not a product. It is a change in what an access decision is made from.

The order that pays first

An estate cannot adopt this everywhere at once, so the question is sequence, and sequence should follow risk rather than ease.

Adoption order, by what it reduces

Step 1 pays: even if the programme stops there
Decision input: identity and device state, not location
Finished: never. It is a direction, not a project

This diagram as text

1 · Segment the flat network — containment first — pays even if the programme stops here
2 · One identity provider, MFA everywhere
3 · Device identity on managed machines
4 · Per-application policy — hardest application first
5 · Decisions logged centrally
6 · Retire the VPN for most access — an outcome, not a task

Relationships

1 · Segment the flat network → 2 · One identity provider, MFA everywhere
1 · Segment the flat network → 3 · Device identity on managed machines
2 · One identity provider, MFA everywhere → 4 · Per-application policy — identity
3 · Device identity on managed machines → 5 · Decisions logged centrally — device state
4 · Per-application policy → 6 · Retire the VPN for most access
5 · Decisions logged centrally → 6 · Retire the VPN for most access

Open full size · after NIST SP 800-207

Segmentation comes first and is the step most often skipped, because it is unglamorous and does not have a vendor attached. Zero trust assumes a compromise will happen and be contained while you respond. On a flat network there is nowhere to contain it. Separating users from servers, putting unpatchable operational technology on its own segment, and moving infrastructure management out of band reduces real risk immediately, whatever happens to the rest of the programme.

One identity provider is the precondition for everything above it. Three directories with partially overlapping accounts cannot produce a trustworthy access decision, and the effort spent reconciling them later exceeds the effort of consolidating now.

Device identity is what separates this from single sign-on with extra steps. Without it, a credential stolen from an unmanaged machine presents exactly like a legitimate one. A certificate issued by your own authority, checked at access time, is the difference.

Per-application policy, hardest first. The instinct is to start with something easy to prove the model. Start instead with the application whose compromise would be worst, because that is where the risk reduction is and because the hard case surfaces the design problems while the programme still has attention.

What this costs that nobody mentions

An internal certificate authority with a real lifecycle. Device identity means certificates, and certificates mean issuance, renewal and revocation that someone owns. Manual renewal is how this fails on a weekend eighteen months in.

A joiner-mover-leaver process that actually works. Access decisions made from identity are only as good as the identity data. If leavers remain enabled for three weeks, you have moved the weakness rather than removed it, and an ISO 27001 auditor will find it by sampling.

Somewhere for the decisions to go. Access decisions that are not logged centrally cannot be reviewed, and the review is most of what an auditor samples under Annex A 8.3.

An answer for the things that cannot participate. Every estate has a machine running software that cannot do modern authentication. The answer is a documented exception on its own segment with compensating controls, not a quiet permanent allowance that nobody revisits.

The mistake that wastes the budget

Buying the product first. Zero trust network access gateways are useful and they do not produce a zero trust posture on their own, because they enforce decisions made from data you have to supply. A gateway in front of a flat network, fed by three directories and no device identity, is a VPN with a better login page and a larger invoice.

The order above is deliberately the opposite: get the inputs right, then buy the thing that enforces decisions from them.

What to do in the first quarter

Draw the current segments honestly. Not the diagram from the design document. What the switches are actually configured with today.
Find the flattest part and separate the thing with the worst consequence: usually operational technology, or servers from users.
Count the directories. Agree which one is authoritative and set a date for the others.
Turn on MFA where it is not on, starting with administrative access and remote access.
Pick the one application whose compromise would be worst and design its access policy from identity and device state. Do not deploy it yet. Designing it will tell you what is missing.

That is a quarter of work, costs little beyond time, and moves the risk more than most of what is sold as zero trust.

How STP approaches this

We start with segmentation and with the directory, because every later decision is made from them, and we take the hardest application first so the design problems surface early. Device identity comes with its certificate lifecycle automated at the same time, since the renewal is what fails. Where an estate already has a gateway deployed, the review usually finds it enforcing decisions made from data that cannot support them, which is a cheaper problem to fix than it looks.

More on networking and audit and compliance, or start a conversation.