Zero Trust is een werkwoord.
Ga het doen.

Ik maak me al jaren zorgen over hoe weinig organisaties investeren in het voorkomen van aanvallen. En dan heb ik het niet over detecteren, reageren of rapporteren, maar over voorkomen. Het onopvallende werk dat ervoor zorgt dat de aanval überhaupt niet slaagt.

Waarom onopvallend? Omdat preventie een wrede eigenschap heeft: hoe beter je het doet, hoe minder er te laten zien is. Een geblokkeerde aanval verschijnt niet op een dashboard. Een inbraak die nooit plaatsvond, haalt de bestuurspresentatie niet. Niemand krijgt meer budget voor het incident dat niet gebeurde. Het werk dat het risico het meest verlaagt, wordt dus het minst gewaardeerd. En zo drijven organisaties langzaam af naar alles wat een mooie grafiek oplevert. Een leeg securitydashboard is het beste dashboard dat er is. Alleen krijg je er nooit de eer voor.

Waar we in plaats daarvan aan gewend zijn geraakt? Meldingen dat onze data is gestolen.

Nu ik zie wat AI kan, heb ik het gevoel dat we aan het verliezen zijn. De meeste organisaties zijn er bij lange na niet op voorbereid.

En dat ligt niet aan een gebrek aan een plan. We hebben een plan. Het ligt al sinds 2010 op tafel, het wordt goed begrepen, en waar het wordt toegepast, werkt het. De naam? Zero Trust.

De cybersecuritybranche verdient haar geld met het verkopen van producten. Niet met jou helpen om het werk te doen. Aan een strenger firewallbeleid of beheerders die via een jump host werken, valt niets te verdienen. Dus verkoopt de branche een doos, plakt er Zero Trust op, en blijft het werk dat het risico echt verlaagt liggen. Zero Trust is geen product. Je kunt het niet kopen, en niets wat je installeert maakt je Zero Trust.

De cijfers zeggen hetzelfde. Toen Gartner in 2023 naar grote ondernemingen keek, had minder dan één procent een volwassen, meetbaar Zero Trust-programma. Voor dit jaar werd tien procent verwacht. In onderzoek van Accenture noemt 88 procent van de organisaties het implementeren van Zero Trust een aanzienlijke uitdaging. Zestien jaar later is iedereen het over deze strategie eens. Afgerond? Bijna niemand.

Wat er veranderd is

Er gebeuren twee dingen tegelijk, en ze versterken elkaar.

Ten eerste zijn aanvallers nu aantoonbaar sneller dan verdedigers. In november 2025 publiceerde Anthropic de eerste gedocumenteerde inbraakcampagne waarin een AI-agent het meeste werk deed: een aan de Chinese staat gelieerde groep gebruikte Claude Code voor verkenning, exploitatie, laterale beweging en exfiltratie bij zo'n dertig organisaties. Tachtig tot negentig procent van de operatie draaide zonder dat er een mens aan te pas kwam. De campagne werd deels ontdekt omdat het model hallucineerde en toegang claimde die het niet had. Maar hoe beter de modellen worden, hoe kleiner die kans. In september beschreef Palo Alto Networks een ransomware-inbraak waarbij AI-agents elke stap uitvoerden, meer dan vijftig technieken van begin tot eind, in minder dan tien uur. En een menselijk team? Dat had er volgens hen ongeveer twee weken over gedaan.

Ondertussen loopt de klok van de verdedigers de andere kant op. Volgens het Data Breach Investigations Report 2026 van Verizon is het misbruiken van kwetsbaarheden nu de belangrijkste manier waarop aanvallers binnenkomen. Voor het eerst in de negentienjarige geschiedenis van het rapport staat dat vóór gestolen inloggegevens. En de mediane tijd tot een patch ging omhoog, van 32 naar 43 dagen. Edge devices, de firewalls en VPN-gateways die aan internet hangen, worden binnen enkele dagen na publicatie van een CVE misbruikt. Drieënveertig dagen tegenover een paar dagen: dan heeft de aanvaller al gewonnen voordat je begint.

Ten tweede duiken er overal agents op binnen de organisatie. Niet de drie die je via het identity-team hebt geonboard. De tientallen die een developer in een pipeline heeft ingebouwd, die een SaaS-leverancier in je tenant heeft aangezet, die een business unit met een creditcard heeft gekocht. Ze erven de rechten van degene die ze heeft gestart, ze starten subagents, ze praten met elkaar, en de meeste staan op niemands lijst.

Aanvallers worden sneller, en het aantal dingen dat binnen je netwerk actief is zonder dat je het expliciet hebt toegestaan, explodeert. Juist die combinatie baart me zorgen. Een inbraak van tien uur, uitgevoerd door iets dat nooit slaapt, houd je met detectie alleen niet bij. Je moet aanvallen voorkomen, en dat moet je al gedaan hebben voordat de inbraak begint.

Wat Zero Trust op een dinsdag echt betekent

Ik help organisaties al jaren op weg naar een Zero Trust-omgeving, en het patroon is bijna elke keer hetzelfde. De technologie is zelden de bottleneck. Het werk wel. En de bereidheid om het te doen.

Het eerste wat we samen doen, is naar het firewallbeleid kijken. Bij bijna elke opdracht vinden we regels met "any" erin die niemand kan uitleggen. Ze zijn jaren geleden geschreven voor een migratie die allang klaar is, en zijn blijven staan omdat verwijderen riskant voelde. Ik ken een any-any-regel die drie generaties firewalls overleefde en nog gekoppeld was aan een change-ticket van een medewerker die in 2016 is vertrokken. Die regel maakte van een firewall een doorgang, en die doorgang werd gebruikt. Een beleid streng maken? Dat is maandenlang uitzoeken wat echt met wat praat. En het is het waardevolste wat de meeste organisaties kunnen doen. Als we het strenge beleid eindelijk aanzetten en er gaat niets kapot, beseffen mensen dat de wijziging veel minder riskant was dan iedereen dacht. De oude regels laten staan was al die tijd het grotere risico.

Dan de jump host. Beheertoegang via één deur, met MFA, gelogd, en nergens anders. Geen gedeelde machine tussen productie en ontwikkeling, en geen "air-gapped" OT-netwerk met een dagelijkse RDP-sessie erin. We stuiten altijd op weerstand bij de mensen die al tien jaar directe RDP naar productie hebben. Zes maanden later wil niemand meer terug.

Dan SSO op alles. Elke applicatie, elke beheerconsole, elke tool waarvan de business zweert dat hij "alleen intern" is. Intern is precies waar de aanvaller staat na de eerste phishingmail.

Dan patchen, gericht op waar de blootstelling zit: systemen die aan internet hangen (webservers, VPN-gateways, de security-appliances zelf) en endpoints (laptops, telefoons). Die worden dezelfde dag gepatcht, niet in het volgende onderhoudsvenster. De mediaan in de branche is 43 dagen, terwijl de exploit er binnen een paar dagen is. Patchen op dezelfde dag kan alleen als je patchen niet langer behandelt als een reeks besluiten en een patchmachine bouwt: een proces dat vanzelf draait. Het securityadvies van de leverancier gaat er aan de ene kant in, het gepatchte systeem komt er aan de andere kant uit. Een mens komt er alleen aan te pas als er iets moet worden tegengehouden.

Dan hardening van wat je draait. Kubernetes kan heel streng worden ingericht: rootless containers, bijna alle capabilities uitgeschakeld, read-only bestandssystemen, geen automatisch gekoppelde service account tokens, network policies die standaard alles weigeren. Standaard is een Kubernetes-cluster een plat netwerk waarin een shell in één pod elke andere pod in elke namespace kan bereiken, van daaruit de node, en vanaf de node het cloudaccount. Ik heb nog geen organisatie gezien die dat op dag één dichtzette. Ik heb er wel veel gezien die het in maand drie alsnog deden, zodra iemand besloot dat het belangrijk was.

En onder dat alles: segmenteer rond wat echt belangrijk is. Definieer de Protect Surface. Breng de transaction flows van en naar die Protect Surface in kaart. Schrijf beleid voor die flows en alleen die flows. Monitor. Onderhoud. Pak dan de volgende Protect Surface.

Geen project, maar een cultuur

Ik zie vooral organisaties worstelen die een Zero Trust-project draaiden, het afsloten en verdergingen. Een project heeft een einddatum. Het beleid drijft af, de uitzonderingen stapelen zich op, en twee jaar later staat de firewall weer op "any". Het andere faalscenario is het tegenovergestelde: één enorm programma met een groot budget vooraf, dat ergens tussen maand twaalf en maand achttien wordt geschrapt omdat het nog geen resultaat heeft laten zien. Volgens Gartner liep meer dan een derde van de organisaties die Zero Trust probeerden, tegen een mislukking aan die de business schade deed. Beide faalscenario's hebben dezelfde oorzaak: het werk werd behandeld als iets wat ooit af is.

Zero Trust moet cultuur zijn. Het is het standaardantwoord als iemand om een firewallregel vraagt: welke flow, vanuit welke Protect Surface, naar welke, en waarom. Het is de reflex als er een nieuw platform wordt geonboard: eerst SSO, dan praten we verder. Het is de vaste verwachting dat het beleid in de loop van de tijd strenger wordt, nooit losser. Het is netwerk en security in dezelfde vergadering met hetzelfde doel, in plaats van dat de een optimaliseert voor uptime en de ander voor controle.

Een projectplan eindigt, en het beleid eindigt mee. Gewoonten in hoe een team beslist, overleven personeelswisselingen, reorganisaties en de volgende technologiegolf.

Deze film hebben we al eens gezien

Toen de cloud kwam, was security nergens te bekennen. Teams zetten in een middag een omgeving op, en dat was precies de bedoeling, maar het netwerkontwerp waar on-premises jaren aan was gewerkt, ging niet mee. Gartner voorspelde dat tot en met 2025 maar liefst 99 procent van de cloudsecurityfouten door de klant zelf zou komen, niet door de provider. Meer dan tien jaar later hebben veel organisaties nog steeds geen fatsoenlijke firewalling en segmentatie in hun cloudomgevingen. Platte netwerken, security groups die alles van alles toestaan, een management plane die vanaf internet bereikbaar is.

Elke nieuwe technologiegolf brengt hetzelfde geheugenverlies. De business ziet de voordelen, security krijgt te horen dat ze het moet bijbenen, en de basis wordt overgeslagen omdat die alles vertraagt.

Agents zijn niet anders. Kijk naar de argumenten waarom agents Zero Trust zouden "breken":

Hoe moet een agent er dan uitzien in een Zero Trust-omgeving? Zijn identiteit en rechten zijn kortlevend en beperkt tot precies wat hij nu voor deze taak nodig heeft. Least privilege, en steeds vaker least agency: de kleinste set acties die hij zelfstandig mag uitvoeren. Subagents krijgen gedelegeerde credentials die nog beperkter zijn. Acties met grote gevolgen die niet terug te draaien zijn, krijgen een goedkeuringsstap. Alles laat een onveranderbaar spoor na. En hij draait binnen een Protect Surface met gedefinieerde flows, zodat de schade binnen die surface blijft als het misgaat.

Dit is Zero Trust, toegepast op een nieuw soort gebruiker.

Het risico dat niemand op de slide zet

En toch hoor ik nog steeds dit soort uitspraken in change boards en stuurgroepen:

Elk van deze uitspraken weegt het risico van de wijziging en de moeite die het kost. Maar het risico van niets doen? Dat weegt niemand mee. Een firewall die één keer per jaar wordt gepatcht, heeft twaalf maanden lang bekende, gepubliceerde en actief misbruikte kwetsbaarheden, op het meest blootgestelde apparaat dat je hebt, in een jaar waarin het misbruiken van precies dat apparaat de belangrijkste manier werd om binnen te komen. Een IPS in alert mode is een heel duur logbestand. Niets doen is ook een besluit, en in 2026 het gevaarlijkste dat je kunt nemen.

Dat moet echt anders. De vraag in de change board moet niet zijn: "Wat kan er misgaan als we dit doen?" Maar: "Wat gaat er nu mis omdat we het niet hebben gedaan?"

Waar je maandag begint

Kies één Protect Surface. Die waarmee je in de krant zou komen. Breng de flows in kaart. Schrijf het beleid. Zet het aan. Houd het in de gaten. Kies dan de volgende. Zoals John Kindervag het zegt: het gaat er niet om waar je begint, maar dat je begint.

Behandel elke agent zoals je een nieuwe externe kracht met een laptop zou behandelen: een tijdelijke badge, toegang tot één ruimte, en iemand die de deur in de gaten houdt.

Patch de edge vandaag, en begin morgen met het bouwen van de machine die het zonder jou doet.

En noem het geen project meer.

Als je het zware werk niet zelf kunt doen, zoek dan iemand die het samen met jou doet in plaats van je nog een doos te verkopen. Daarom zijn we ON2IT begonnen: om klanten te helpen de juiste keuze te maken, en hun daarna het werk uit handen te nemen zodat het ook echt gebeurt.

FAQ