Jamie van der Pijll

ZTNA vs VPN: wanneer is het echt de betere route?

Written by

in

,

3 mei 2026 · Door Jamie van der Pijll · 6 min leestijd

ZTNA klinkt vaak als de nette opvolger van VPN, maar in de praktijk zijn het geen simpele vervangers. De nuttige vraag is meestal kleiner: wil je netwerktoegang geven, of wil je heel gericht toegang tot een applicatiepad geven op basis van identiteit, device-state en context?

In de SASE-hoek wordt ZTNA vaak verkocht als het antwoord op oude VPN-pijn. Soms klopt dat. Soms trek je er vooral een nieuw label overheen terwijl de omgeving nog steeds netwerkbreed denkt. Daarom kijk ik liever eerst naar het toegangsmodel zelf: welke applicaties zijn er, hoe lopen de paden echt, waar zit identity al goed, en hoeveel uitzonderingen wil je daarna nog blijven dragen?

Korte keuzehulp

Kies eerder ZTNA als je toegang per applicatie wilt knippen, identity en device-context al redelijk op orde zijn en je de blast radius van brede netwerktoegang kleiner wilt maken. Kies eerder VPN als complete netwerktoegang nog functioneel nodig is, de applicaties daar echt om vragen of de omgeving nog niet klaar is voor fijnmaziger applicatiebeleid.

De vergelijking wordt vaak verkeerd ingezet

VPN en ZTNA lossen niet exact hetzelfde probleem op. Een klassieke VPN zet in essentie een netwerkpad open. Daarna moet de rest van je segmentatie, firewalling en applicatielogica het verschil maken. ZTNA probeert eerder bij de applicatiegrens te beginnen: wie ben je, op welk device zit je, naar welke app wil je, onder welke voorwaarden mag dat, en hoe klein kan dat pad blijven?

Daar zit ook meteen de nuance. Als een team nog steeds denkt in ‘geef deze gebruiker toegang tot het interne netwerk’, dan helpt ZTNA alleen als je bereid bent het model echt te veranderen. Anders bouw je vooral extra complexiteit bovenop een oud toegangspatroon.

Wanneer ZTNA echt de betere route is

  • als je toegang vooral wilt beperken tot specifieke interne apps in plaats van brede netwerksegmenten;
  • als identity, MFA en device posture al bruikbaar genoeg zijn om beleid op te bouwen;
  • als third parties, hybride users of unmanaged devices gecontroleerd bij een klein applicatieoppervlak moeten komen;
  • als je later ook beter wilt kunnen uitleggen wie bij welke app kan, en waarom.

Dan is ZTNA vaak de schonere route. Niet omdat het moderner klinkt, maar omdat het dichter bij de echte toegangsbeslissing zit. Je geeft minder ‘omgeving’ en meer ‘specifieke toegang’.

Wanneer VPN nog steeds logisch is

  • als gebruikers of beheerders echt meerdere interne protocollen, managementvlakken of brede netwerkdiensten nodig hebben;
  • als de applicatielandschap nog te heterogeen of te legacy is om snel per app te modelleren;
  • als de omgeving vooral een betrouwbaar tijdelijk remote-netwerkpad nodig heeft en niet direct een heel nieuw toegangsmodel;
  • als je zicht op identity, applicaties en afhankelijkheden nog te zwak is voor fijnmazig ZTNA-beleid.

VPN is dus niet automatisch ‘achterhaald’. Het is vaak gewoon grover. En soms is grover nog steeds functioneel nodig, zolang je maar eerlijk bent over de operationele prijs die daarbij hoort.

Waar teams meestal de fout in gaan

  • ZTNA kiezen zonder applicatie-overzicht. Dan wordt policy vooral gokken.
  • VPN laten staan zonder segmentatie-hygiëne. Dan blijft brede netwerktoegang groter dan nodig.
  • Identity overschatten. Een mooie IdP helpt niet als uitzonderingen, service-accounts en schaduwtoegang niet goed in beeld zijn.
  • Alleen op de client focussen. De echte moeite zit vaak in applicatiepaden, DNS, certificaten, policy-uitzonderingen en operationeel beheer daarna.

Daarom begin ik zelden met de vraag welk product iemand wil. Ik wil eerst snappen of het probleem vooral netwerkbreed is, of juist applicatiegericht. Pas dan wordt de keuze tussen ZTNA en VPN bruikbaar.

Mijn praktische keuzevolgorde

  1. Kies ZTNA als je toegang klein, app-gericht en identity-gedreven wilt maken.
  2. Kies VPN als brede netwerktoegang nog echt functioneel nodig is en je die voorlopig nog niet per app kunt opbreken.
  3. Kies eerst overzicht als applicaties, identities, uitzonderingen en afhankelijkheden nog te onduidelijk zijn om een nette beslissing te nemen.

Verder lezen in deze SASE-reeks

Conclusie

ZTNA is niet ‘VPN maar dan beter’. Het is een andere manier van toegang organiseren. Als je de stap echt maakt naar identity, context en applicatiegericht beleid, dan is ZTNA vaak de betere route. Als je nog steeds netwerkbreed moet denken of simpelweg brede toegang functioneel nodig hebt, dan blijft VPN logisch.

Mijn voorkeur blijft hetzelfde als in de rest van deze reeks: eerst begrijpen hoe toegang nu echt werkt, daarna pas kiezen welke route de minste operationele ruis en de meeste grip oplevert.

More posts