Zero trust wordt vaak gebracht alsof het een nieuw product is dat je bovenop je bestaande toegang zet. Dan gaat het meestal al scheef. Voor mij begint zero trust niet met een tool, maar met de vraag welk vertrouwen je nu nog blind uitgeeft en waarom dat eigenlijk nog steeds zo is.
De kern van zero trust is vrij klein. NIST 800-207 beschrijft het in essentie als het loslaten van impliciet vertrouwen op basis van netwerkplek. Dus niet: intern is veilig, extern is verdacht. Maar: iedere toegangsvraag opnieuw bekijken in context van identiteit, device, applicatie, beleid en risico.
Dat klinkt strak, maar in de praktijk gaat het zelden mis op die definitie. Het gaat mis zodra teams doen alsof zero trust vooral een technische vervanging is van VPN, firewallregels of een oude remote-accessoplossing. Dan verplaats je bestaand gedoe naar een nieuw dashboard en noem je het volwassen.
Zero trust is voor mij geen productkeuze, maar een manier om toegang en datagebruik kleiner, explicieter en beter uitlegbaar te maken. ZTNA, CASB, policy engines en posture checks zijn pas nuttig als dat fundament klopt.
Waarom het woord zo vaak verkeerd landt
De term roept snel twee verkeerde reacties op. De eerste is technisch enthousiasme: we kopen ZTNA, dus we doen zero trust. De tweede is bestuurlijke vaagheid: we willen iets met zero trust, maar zonder eerst uit te spreken welke systemen, rollen en datastromen echt kritiek zijn. In beide gevallen ontbreekt hetzelfde: een leesbaar besluit over vertrouwen.
Als je niet weet welke applicaties gevoelig zijn, welke beheerders echt brede rechten nodig hebben, welke leveranciers tijdelijk toegang krijgen en welke data buiten je klassieke netwerkgrens terechtkomt, dan kun je ook niet eerlijk autoriseren. Dan bouw je vooral uitzonderingen.
Wat zero trust voor mij praktisch betekent
Ik vertaal zero trust meestal naar vier simpele vragen:
- Wie vraagt toegang?
- Waarnaar precies?
- Onder welke voorwaarden mag dat wel of niet?
- Hoe zie je terug dat beleid ook echt werkt of faalt?
Daarmee kom je automatisch uit bij identity, device-context, applicaties, data, logging en governance. Dat sluit ook netjes aan op CISA’s zero trust maturity model: identity, devices, networks, applications & workloads en data, met visibility, automation en governance er dwars overheen. Handig, juist omdat het laat zien dat je niet in één keer “klaar” hoeft te zijn.
Waarom rollen en classificatie eerder komen dan tooling
Zero trust zonder classificatie is voor mij vooral een nette manier om op gevoel te blijven beslissen. Je moet eerst een beeld hebben van wat kritisch, gevoelig of bedrijfsondersteunend is. Niet per se met een enorme bureaucratische exercitie, wel met genoeg scherpte om verschil te maken tussen bijvoorbeeld een publieksportal, een beheervlak, HR-data, financiële data en SaaS waar bedrijfskennis langzaam naartoe lekt.
Dat is ook waarom ik rollen belangrijker vind dan losse groepen of historische rechten. Rollen helpen om toegang te koppelen aan werk. En zodra rollen nog te grof zijn, kom je uit bij attributen: locatie, device state, type sessie, gevoeligheid van de data, beheerfunctie of leverancierstoegang. Dan wordt ABAC of policy-based access ineens geen theoretisch model meer, maar gewoon een praktische brug tussen beleid en techniek.
Waar ZTNA en CASB dan wel passen
ZTNA is voor mij vaak de eerste zichtbare technische vertaling van zero trust. Niet omdat het het hele model afdekt, maar omdat je er brede netwerktoegang mee kleiner kunt maken en beleid dichter op applicaties kunt zetten. Dat werkt vooral goed als je al redelijk weet wie bij welke apps moet kunnen, en onder welke voorwaarden.
CASB komt in beeld zodra het probleem niet alleen toegang is, maar ook data buiten de klassieke rand. Zodra gebruikers in SaaS werken, bestanden delen, data kopiëren tussen tenants en ook nog generatieve AI-tools gebruiken zonder dat iemand precies weet wat daarheen gaat, is een puur netwerkgericht model gewoon niet meer genoeg. Dan wil je zicht op apps, sessies, datagebruik en beleid rond gevoelige informatie.
Het punt is dus niet dat ZTNA of CASB “de zero-trust-tool” zijn. Ze zijn technische verlengstukken van een beleidskeuze die je eerst leesbaar moet maken.
De koppeling met AVG, NIS2 en ISO 27001
Ik zou zero trust nooit verkopen als compliance-snelkoppeling. AVG-compliance krijg je er niet gratis bij. Maar de gedachte erachter sluit wel logisch aan op eisen die je toch al kent: dataminimalisatie, passende beveiligingsmaatregelen, toegangsbeheersing, accountability en het kunnen uitleggen van je keuzes.
- AVG artikel 25 en 32 duwen je richting privacy by design, passende maatregelen en niet méér toegang of verwerking dan nodig.
- NIS2 verhoogt de druk op risicobeheersing, governance en aantoonbare beveiligingsmaatregelen.
- ISO 27001 helpt vooral als managementsysteem eromheen: rollen, beleid, reviews en continue verbetering.
Zero trust is dus geen vinkje voor die kaders, maar wel een bruikbare manier om technische en organisatorische keuzes consistenter te maken.
Een route die meestal beter werkt dan meteen een platform kopen
- Maak eerst een kleine kaart van kritieke apps, beheervlakken en gevoelige data.
- Bepaal welke rollen echt bestaan en welke toegangsrechten nu eigenlijk op gewoonte draaien.
- Kies één eerste use case waar smaller access direct helpt, bijvoorbeeld third-party access, beheertoegang of een set interne webapps.
- Zet daarna techniek in zoals ZTNA, device checks of CASB, maar alleen waar beleid al duidelijk genoeg is.
- Meet of het werkt met signalen rond denied access, policy exceptions, shadow IT, datagebruik en operationele frictie.
Daarmee voorkom je ook dat zero trust een prestigeproject wordt dat op slides groot is maar in operations vooral extra uitzonderingen achterlaat.
Waar het meestal misgaat
- Te snel productdenken. Alsof de architectuur zich vanzelf aanpast aan het platform.
- Te vage rollen. Dan kun je technisch nauwelijks anders dan brede rechten blijven geven.
- Geen dataperspectief. Alsof alleen login en netwerkpad tellen, terwijl data al in SaaS, share-links en AI-tools zit.
- Geen governance voor uitzonderingen. Tijdelijke toegang blijft dan gewoon permanent bestaan.
- Te weinig zichtbaarheid. Zonder goede signalen weet je niet of beleid werkt of alleen ongemerkt wordt omzeild.
Verder lezen in deze zero-trust-reeks
- Bekijk de zero-trust-hub
- Waarom zero trust zonder classificatie en rollen vooral extra gedoe wordt
- CASB wordt interessant zodra je data, SaaS en shadow AI serieus neemt
- ZTNA vs VPN: wanneer is het echt de betere route?
Conclusie
Zero trust begint voor mij niet met een tool omdat tools alleen goed werken als je al weet welk vertrouwen je kleiner wilt maken. Zonder rollen, classificatie, databeleid en een eerlijke eerste use case blijft het vooral een nieuwe laag bovenop oude uitzonderingen.
Maar als je dat fundament wel bouwt, wordt zero trust ineens heel praktisch: minder impliciet vertrouwen, kleinere toegangsoppervlakken, betere uitlegbaarheid en meer grip op data die al lang niet meer netjes binnen de rand blijft.