Case Study: Zero Trust Transformatie bij een Nederlands Ministerie

Theoretische raamwerken en best practices zijn waardevol, maar échte transformatie vindt plaats in de weerbarstige praktijk van verouderde infrastructuur, interne politiek, beperkte budgetten en uiteenlopende belangen. Deze case study beschrijft een meerjarig Zero Trust‑programma dat wij hebben begeleid bij een groot Nederlands ministerie – in deze tekst aangeduid als Ministerie X. Het is nadrukkelijk geen gepolijste successtory, maar een eerlijke en gedetailleerde beschrijving van hobbels, fouten, bijsturingen en lessen die zijn geleerd tijdens een traject van drie jaar.

In 2021 werkte Ministerie X nog grotendeels volgens een klassiek “perimeter‑model”. Een ring van firewalls beschermde het interne netwerk, VPN‑toegang was verplicht voor iedereen die op afstand werkte en intern netwerkverkeer werd nauwelijks gemonitord omdat alles binnen de muren als betrouwbaar werd gezien. Dit model had jaren goed genoeg gefunctioneerd, maar was zichtbaar aan het einde van zijn levensduur.

De COVID‑19‑pandemie versnelde die werkelijkheid. In korte tijd werkten ongeveer 6.500 van de 8.000 medewerkers vanuit huis. De VPN‑omgeving was ontworpen voor zo’n 500 gelijktijdige verbindingen en werd zwaar overvraagd. Medewerkers klaagden over wegvallende verbindingen, trage systemen en onvoorspelbare prestaties. De IT‑afdeling moest onder tijdsdruk noodcapaciteit bijbouwen en directe internettoegang inschakelen voor enkele cloudapplicaties, met nieuwe beveiligingslacunes als gevolg. Het werd pijnlijk duidelijk dat het klassieke “kasteel‑en‑gracht”-model niet past bij moderne, gedistribueerde werkvormen.

Tegelijkertijd kwamen er strengere eisen vanuit wet- en regelgeving, waaronder de aankomende NIS2‑richtlijn en aanscherpingen in de BIO. Onafhankelijke audits legden zwakke plekken bloot in identity‑ en toegangsbeheer: te ruime rechten voor veel accounts, incidentele in plaats van structurele toegangsbeoordelingen en onvoldoende bescherming van beheerdersaccounts. Een bijna‑incident, waarbij een gerichte phishingaanval bijna leidde tot misbruik van een domeinbeheerder, zorgde intern voor een wake‑up call.

De top van het ministerie zag in dat kleine verbeteringen niet langer voldeden. Er was een fundamentele architectuurwijziging nodig waarin identiteit, en niet het netwerk, centraal zou staan. Zero Trust werd gekozen als doelarchitectuur: standaard uitgaan van “nooit vertrouwen, altijd verifiëren”, met sterke nadruk op identiteit, apparaatcompliance en context. Dat was een ambitieuze keuze voor een organisatie met aanzienlijke technische schulden: een on‑premises Active Directory die al vijftien jaar meeging, meer dan tweehonderd applicaties waarvan een groot deel maatwerk, en een IT‑organisatie die wel ervaren was in traditionele infrastructuur maar beperkte cloudervaring had.

De businesscase voor deze omslag was breder dan alleen beveiliging. Verhoogde weerbaarheid tegen cyberdreigingen was de primaire drijfveer, maar daarnaast speelden operationele efficiëntie (minder afhankelijkheid van VPN en on-premises datacenters), kostenreductie, vereenvoudigd beheer en aantoonbare compliance met regelgeving een grote rol. De geraamde investering bedroeg circa € 4,5 miljoen over drie jaar, inclusief licenties, externe expertise en interne inzet. In het vierde kwartaal van 2021 gaf de bestuursraad formeel groen licht, met als doel een afgeronde transformatie eind 2024.

Fase 1: Baseline Assessment en Architecture Design

Het programma startte in januari 2022 met een grondige nulmeting. Externe specialisten werkten nauw samen met het interne security‑ en infrastructuurteam om de huidige situatie in kaart te brengen: van directory‑structuur en netwerkarchitectuur tot applicatielandschap en processen rond identity en toegang. Deze analysefase duurde drie maanden en vormde de basis voor alle latere beslissingen. Zonder helder vertrekpunt zou elke roadmap vooral een theoretische exercitie zijn geweest.

Tijdens de technische verkenning werd de omvang van de technische schuld snel zichtbaar. Het Active‑Directory‑forest was in 2007 opgezet en in de loop der jaren steeds verder uitgebreid met nieuwe policies, scripts en tijdelijke oplossingen die nooit zijn opgeruimd. Er waren ruim zeshonderd groepsbeleidobjecten actief waarvan slechts een klein aantal nog actief werd beheerd. Oude schema‑uitbreidingen van inmiddels uitgefaseerde applicaties waren blijven staan. Ongeveer twintig procent van de computeraccounts bleek al langer dan een jaar niet meer te zijn aangemeld – systemen die in werkelijkheid allang niet meer bestonden. Het was een typisch voorbeeld van een omgeving waar iedereen bang is om op te ruimen uit vrees iets essentieels te breken.

Ook het applicatielandschap bleek complexer dan verwacht. In de Configuratie Management Database stonden 237 applicaties geregistreerd, maar netwerkmetingen, firewall‑logs en gebruikersinterviews brachten nog eens bijna negentig niet‑geregistreerde diensten aan het licht. In totaal ging het om 326 applicaties: een mix van SaaS‑diensten, commerciële standaardsoftware, maatwerkapplicaties en een restcategorie waarvan de eigenaar niet meer te achterhalen was omdat de oorspronkelijke ontwikkelteams het ministerie al hadden verlaten. Voor een aanzienlijk deel bestond er geen actuele documentatie.

De processen rond identity‑ en toegangsbeheer waren grotendeels handmatig. Nieuwe medewerkers kregen pas na gemiddeld drieënhalve dag een volledig werkend account, omdat verschillende teams achtereenvolgens handmatig acties moesten uitvoeren. Rechten werden vaak aangevraagd per e‑mail, zonder gestandaardiseerde rolmodellen of periodieke review. Het uitzetten van accounts na vertrek duurde nog langer: uit steekproeven bleek dat accounts van vertrokken medewerkers gemiddeld bijna twee weken actief bleven. Formeel waren er jaarlijkse toegangsrecensies, maar in de praktijk was de laatste volledige review anderhalf jaar eerder uitgevoerd.

Met behulp van Microsoft Secure Score en aanvullende metingen werd de uitgangssituatie voor beveiliging vastgesteld. De totaalscore kwam uit op ongeveer 42 procent, aanzienlijk lager dan vergelijkbare overheidsorganisaties. De belangrijkste oorzaken waren het ontbreken van verplichte meervoudige authenticatie, het ontbreken van consistente conditional‑access‑beleidsregels, intensief gebruik van verouderde protocollen zonder moderne beveiligingsfuncties, beperkte logretentie en afwezigheid van een volwassen endpoint‑detectie‑ en responsondersteuning. Het beeld dat daaruit naar voren kwam, was dat de organisatie veel vertrouwde op het interne netwerk, maar relatief weinig op sterke identiteiten en moderne detectiemechanismen.

Naast harde beveiligingscijfers werd expliciet gekeken naar de gebruikerservaring. Een enquête onder duizend willekeurige medewerkers liet zien dat slechts een minderheid tevreden was over de balans tussen veiligheid en gebruiksgemak. Ruim een derde gaf aan beveiligingsmaatregelen als “zeer hinderlijk” te ervaren, meer dan de helft gaf toe regelmatig omwegen te zoeken buiten de officiële middelen om, en een groot deel gaf aan de achterliggende rationale van maatregelen niet te begrijpen. Dit benadrukte dat technische verbeteringen zonder aandacht voor gebruikerservaring waarschijnlijk tot extra weerstand zouden leiden.

Op basis van deze nulmeting is een doelarchitectuur opgesteld die expliciet is gebaseerd op Zero Trust‑principes. Centrale elementen waren: Azure AD als primaire identiteitsbron in een hybride opzet met de bestaande on‑premises‑omgeving, verplichte meervoudige authenticatie voor alle gebruikers, conditional‑access‑beleidsregels die rekening houden met apparaatcompliance, gebruikersrisico en locatie, moderne endpointbeheerfuncties via Microsoft Intune, uitgebreide logging en monitoring met onder meer Microsoft Sentinel en het stapsgewijs afbouwen van traditionele VPN‑afhankelijkheid, waarbij voor de resterende on‑premises toepassingen gebruik wordt gemaakt van Azure AD Application Proxy.

De roadmap verdeelde de implementatie in logische fases over drie jaar, met duidelijke doelen per kwartaal. In het eerste jaar lag de focus op het neerzetten van de basis: licenties, inrichting van Azure AD, invoeren van meervoudige authenticatie en het aansluiten van de eerste endpoints op Intune. Het tweede jaar richtte zich vooral op applicatiemigratie en het onderbrengen van zoveel mogelijk applicaties onder moderne authenticatie. In het derde jaar lag de nadruk op het uitfaseren van verouderde protocollen, het afbouwen van VPN‑gebruik en het doorvoeren van verfijningen in beleid en monitoring.

Bij de risicoanalyse kwamen drie hoofdrisico’s naar voren. Ten eerste de compatibiliteit van verouderde applicaties met moderne protocollen: voor een deel was niet eens duidelijk of leveranciers nog actief waren. Ten tweede de organisatiecultuur: ingrijpende wijzigingen in inlogprocessen en werkpatronen konden gemakkelijk tot weerstand en productiviteitsverlies leiden. Ten derde de financiële onzekerheid: trajecten in complexe omgevingen kennen vrijwel altijd onverwachte kostenposten. Om deze risico’s te mitigeren werd gekozen voor uitvoerig testen in representatieve omgevingen, gefaseerde uitrol met duidelijke terugvalscenario’s, intensieve communicatie en training en een financiële reserve in het projectbudget.

Fase 2: Foundation Deployment - MFA en Conditional Access

In april 2022 begon de daadwerkelijke implementatie, met in het tweede kwartaal een duidelijke focus op de basisvoorzieningen rond identiteit. De reden was eenvoudig: in een Zero Trust‑architectuur vormt identiteit de nieuwe grens van het stelsel, en juist daar konden relatief snel grote verbeteringen worden gerealiseerd zonder direct alle applicaties te hoeven verbouwen.

Alle 8.000 gebruikers kregen toegang tot Azure AD‑functionaliteit met uitgebreide beveiligingsmogelijkheden. De organisatie gebruikte al langer een synchronisatie‑oplossing tussen on‑premises Active Directory en Azure AD, maar de inrichting was historisch gegroeid en niet meer in lijn met de gewenste doelen. Daarom werd de volledige configuratie doorgelicht en waar nodig aangescherpt. Wachtwoordhash‑synchronisatie werd ingeschakeld om afhankelijkheid van een beperkte set connectiviteitsservers te verminderen, de configuratie voor het synchroniseren van groepen en apparaten werd opgeschoond en er werden expliciete uitzonderingen ingericht voor noodaccounts zodat deze ook bij strengere beleidsregels beschikbaar bleven. De synchronisatiefrequentie werd verhoogd zodat wijzigingen op locatie sneller zichtbaar werden in de cloudomgeving.

De invoering van meervoudige authenticatie bleek zowel politiek als praktisch een gevoelig onderwerp. In het verleden was MFA al eens “vrijblijvend” aangeboden, maar slechts een kleine minderheid van de medewerkers had de stap gezet. Veel medewerkers zagen het als een extra hindernis in hun dagelijkse werk. Dit keer werd bewust gestart met stevige bestuurlijke steun: de secretaris‑generaal stuurde een duidelijke boodschap aan alle medewerkers, waarin hij het dreigingsbeeld schetste en uitlegde waarom het ministerie niet langer kon volstaan met alleen wachtwoorden. Daarbij werden concrete voorbeelden gebruikt van aanvallen op overheidsinstellingen in binnen‑ en buitenland.

De technische uitrol verliep gefaseerd. In de eerste week werden vooral IT‑medewerkers en een kleine groep vrijwillige early adopters overgezet, zodat kinderziektes in een beperkte groep konden worden opgelost. In de daaropvolgende weken volgden afdelingshoofden en het management, zodat leidinggevenden ervaring opdeden voordat hun teams volgden. Daarna werd de rest van de organisatie in beheersbare groepen aangehaakt. Deze gefaseerde aanpak voorkwam dat de servicedesk in één klap werd overbelast en gaf ruimte om documentatie en communicatie stapsgewijs te verbeteren.

Medewerkers konden kiezen uit meerdere MFA‑methoden. De voorkeursoptie was de Microsoft Authenticator‑app, aangevuld met sms en telefonische oproepen voor medewerkers die geen geschikte smartphone hadden. Voor beheerders en andere hoogrisicodoelgroepen werden fysieke beveiligingssleutels verplicht gesteld. Zo werd het hoogste beschermingsniveau geconcentreerd op de accounts die bij misbruik de grootste schade konden veroorzaken.

Zoals verwacht stuitte de verandering op weerstand. Medewerkers uitten hun frustratie over “weer een extra stap”, spraken hun twijfel uit over wat er met hun gegevens gebeurde en hadden praktische vragen over installatie en gebruik. Het aantal telefoontjes en tickets richting de servicedesk verdrievoudigde tijdelijk. Om dit op te vangen werden extra ondersteuningskanalen ingericht: korte inloopsessies per afdeling, begrijpelijke handleidingen met schermafbeeldingen, video’s op het intranet en een netwerk van “MFA‑buddies” – collega’s die anderen in hun team hielpen bij de registratie.

Parallel aan de MFA‑uitrol werden de eerste conditional‑access‑beleidsregels ingevoerd. In de beginfase koos het team bewust voor relatief voorzichtige regels om grote verstoringen te voorkomen. Alle gebruikers moesten bij toegang tot cloudapplicaties een tweede factor gebruiken, verouderde protocollen zoals IMAP en POP3 werden geblokkeerd en een eerste pilotregeling vereiste een compliant apparaat voor toegang tot gevoelige informatie in SharePoint. Deze stappen sloten direct een aantal belangrijke aanvalsroutes zonder dat het werk van medewerkers volledig op de schop ging.

De eis van apparaatcompliance legde tegelijkertijd een grote blinde vlek bloot: slechts iets meer dan de helft van de laptops bleek op dat moment via moderne middelen beheerd te worden. Een aanzienlijk deel was nog afhankelijk van traditionele groepsbeleidinstellingen of was zelfs nooit op een beheerd platform aangesloten. In korte tijd werd een versnellingsprogramma opgezet om werkstations onder beheer van Intune te brengen, waarbij slim gebruik werd gemaakt van bestaande distributietools.

Om de voortgang goed te kunnen volgen, werd de monitoring uitgebreid. Aanmeldingsgegevens uit Azure AD werden naar een centrale analyseomgeving gestuurd en gecombineerd met informatie over apparaten en beleidsblokkades. Dashboards gaven het management wekelijks inzicht in de adoptiegraad van MFA, het aantal geblokkeerde aanmeldingen, de reden van blokkades en de groei van het aantal compliant apparaten. Op basis van deze informatie kon het tempo van de uitrol worden bijgestuurd.

Aan het einde van het tweede kwartaal waren de resultaten duidelijk zichtbaar. Vrijwel alle actieve accounts maakten gebruik van meervoudige authenticatie, de belangrijkste cloudapplicaties waren afgeschermd met conditional‑access‑regels en een groot deel van het werkpleklandschap stond onder modern beheer. De Secure Score steeg in enkele maanden van een zorgelijke waarde naar een niveau dat vergelijkbaar was met of beter dan andere overheidsorganisaties. Hoewel er nog steeds kritiek klonk op extra stappen en inlogschermen, nam de stroom aan meldingen bij de helpdesk langzaam af – een teken dat de nieuwe werkwijze begon in te slijten.

Fase 3: Application Migration Challenges en Lessons

Van het derde kwartaal van 2022 tot en met het tweede kwartaal van 2023 lag de nadruk op het migreren van applicaties naar moderne authenticatie op basis van Azure AD. Dit bleek de meest uitdagende fase van het hele traject. Het doel was helder: zoveel mogelijk toepassingen voorzien van eenvormige aanmelding, centrale autorisatie en de mogelijkheid om conditional‑access‑regels per applicatie af te dwingen. De praktijk bleek een stuk weerbarstiger dan de architectuurplaten deden vermoeden.

Om structuur aan te brengen, werden de applicaties onderverdeeld in migratiegolven. De eerste golf bestond uit moderne SaaS‑diensten met goede ondersteuning voor SAML of OpenID Connect. Deze integraties waren technisch relatief eenvoudig: applicatie registreren in Azure AD, de juiste claims configureren, een pilotgroep laten testen en vervolgens gecontroleerd omschakelen naar productie. In een periode van ongeveer zes maanden werden op deze manier 87 SaaS‑applicaties gemigreerd, waarmee een belangrijk deel van het dagelijks gebruikte landschap al onder centraal identiteitsbeheer viel.

De tweede golf omvatte commerciële standaardapplicaties die weliswaar ondersteuning boden voor moderne authenticatie, maar waarbij de kwaliteit van documentatie en ondersteuning sterk varieerde. Sommige leveranciers leverden duidelijke stappenplannen en betrokken actief hun supportorganisatie. Andere leveranciers adverteerden wel met “ondersteuning voor Azure AD”, maar in de praktijk bleek dat dit neerkwam op minimale SAML‑functionaliteit zonder mogelijkheden voor geautomatiseerde inrichting van gebruikersrechten. In verschillende gevallen moesten aanvullende licentiepakketten worden aangeschaft om de gewenste integratie mogelijk te maken. Deze niet‑geplande kosten liepen op tot een aanzienlijk bedrag en dwongen het projectteam ertoe prioriteiten scherper te stellen.

De derde golf draaide om maatwerkapplicaties die specifiek voor het ministerie waren ontwikkeld. Veel van deze systemen waren ooit gebouwd op geïntegreerde Windows‑authenticatie en gingen er impliciet van uit dat alle clients zich binnen het vertrouwde netwerk bevonden. Ontwikkelteams moesten zich nieuwe concepten eigen maken zoals token‑gebaseerde authenticatie, autorisatieclaims en levenscyclusbeheer van sessies. Externe experts hielpen bij de eerste concrete migraties en verzorgden kennisoverdracht, maar het werd al snel duidelijk dat niet alle 76 maatwerkapplicaties binnen de looptijd volledig konden worden omgebouwd. Uiteindelijk werd een selectie gemaakt van bedrijfskritische systemen die wél zouden worden gemoderniseerd, terwijl andere toepassingen via een omweg beschikbaar zouden blijven.

Een illustratief voorbeeld was een omvangrijk zaakbeheersysteem dat dagelijks door duizenden medewerkers werd gebruikt. Authenticatie en autorisatie waren diep verweven met de functionele logica van de applicatie. Het loskoppelen van deze onderdelen zonder de werking te verstoren vergde maanden aan ontwikkel- en testwerk. Tijdens de gebruikersacceptatietest kwamen subtiele autorisatieproblemen naar voren: bepaalde rollen konden dossiers niet meer benaderen die voorheen wel toegankelijk waren. De migratie moest worden teruggedraaid, de logica aangepast en de volledige testcyclus opnieuw worden doorlopen. Uiteindelijk werd de overgang vier maanden later dan gepland succesvol afgerond.

Voor een vierde categorie applicaties was volledige migratie simpelweg niet realistisch. Het ging om onder meer mainframegebaseerde systemen, gebouwbeheersystemen, specialistische onderzoekssoftware en pakketten van leveranciers die inmiddels geen ondersteuning meer boden. Voor deze toepassingen werd gekozen voor een benadering waarbij toegang aan de voorkant werd beschermd door Azure AD en meervoudige authenticatie, terwijl de achterliggende applicatie intern met de bestaande methoden bleef werken. Met behulp van Application Proxy konden medewerkers toch veilig vanaf externe locaties werken, zonder dat de applicatie zelf ingrijpend hoefde te worden aangepast.

De impact van deze migratiefase op de bedrijfsvoering werd nauwlettend gevolgd. Productie‑omschakelingen vonden bij voorkeur plaats in avonden en weekenden en er lagen draaiboeken klaar om bij ernstige problemen snel terug te kunnen vallen op de oude situatie. Desondanks deden zich incidenten voor. Zo leidde een fout in de configuratie van een financieel systeem tot corruptie van gebruikersprofielen, waardoor ongeveer tweehonderd medewerkers een werkdag lang niet konden inloggen. De herstelactie vergde intensieve samenwerking tussen het interne team en de leverancier en resulteerde in aangescherpte testcriteria voor volgende migraties.

Gaandeweg het traject werd migratiemoeheid zichtbaar. Medewerkers moesten herhaaldelijk wennen aan nieuwe inlogschermen, aangepaste url’s en gewijzigde autorisaties. Sommige gebruikers uitten de indruk dat IT vooral nieuwe problemen introduceerde. De communicatie werd daarom sterker gericht op het benoemen van voordelen: minder losse wachtwoorden om te onthouden, veiliger toegang vanaf verschillende locaties en betere bescherming tegen misbruik. Cijfers over de afname van wachtwoordresettickets en succesvolle blokkades van verdachte aanmeldingen werden actief gedeeld om de meerwaarde concreet te maken.

Aan het einde van het tweede kwartaal van 2023 waren de resultaten significant. Een groot deel van de actief gebruikte applicaties maakte gebruik van Azure AD voor authenticatie, tientallen andere waren via een beveiligde proxy ontsloten en alleen het resterende lange‑staartsegment moest nog worden aangepakt. In totaal draaide nu ongeveer tweederde van het applicatielandschap op moderne identiteiten in plaats van op netwerkvertrouwen – een grote sprong vooruit ten opzichte van de uitgangssituatie, waarin vrijwel alles afhankelijk was van het interne domein.

Fase 4: VPN Deprecation - De Symbolische Overgang

In het derde kwartaal van 2023 begon de fase waarin het traditionele VPN‑gebruik stapsgewijs werd afgebouwd. Symbolisch was dit een belangrijk moment: het markeerde de overgang van een netwerk‑gecentreerde beveiligingsfilosofie naar een benadering waarin identiteit, apparaat en context leidend zijn. Tegelijkertijd was snel duidelijk dat het volledig uitschakelen van VPN‑functionaliteit meer nuance vroeg dan in eerste instantie gedacht.

Uit metingen bleek dat vóór de pandemie dagelijks ongeveer 2.800 medewerkers via VPN inlogden. Tijdens de coronaperiode piekte dat aantal naar 6.500 gelijktijdige verbindingen en in 2023 was het teruggelopen tot circa 4.200. Een groot deel van dat verkeer bestond inmiddels uit toegang tot applicaties die al via Azure AD veilig beschikbaar waren, maar medewerkers bleven uit gewoonte de VPN‑client starten zodra de laptop werd aangezet. Daarnaast werd de VPN intensief gebruikt voor het benaderen van klassieke fileshares en voor een kleiner deel voor systemen die nog daadwerkelijk netwerktoegang vereisten.

De eerste stap bestond uit een communicatietraject. De IT‑organisatie bracht overzichtelijk in kaart welke applicaties zonder VPN bereikbaar waren en hoe medewerkers deze konden openen. Op het intranet verschenen praktische handleidingen per gebruikersgroep en tijdens korte bijeenkomsten werd gedemonstreerd hoe werken “zonder tunnel” in de praktijk sneller en stabieler kon zijn. Het doel was om het beeld te doorbreken dat de VPN‑verbinding synoniem is met veilig werken.

Vervolgens werd de technische basis aangepakt, met name voor bestandsdeling. Met behulp van Azure‑diensten werden afdelingsshares gemigreerd naar cloudgebaseerde opslag, waarbij toegang niet langer gekoppeld was aan het interne netwerk maar aan de identiteit van de gebruiker en de toestand van het apparaat. Voor medewerkers bleef het vertrouwd: de bekende driveletters en mappenstructuren bleven bestaan, terwijl de onderliggende opslag in de achtergrond werd vervangen. Vooral voor thuiswerkers betekende dit een merkbare verbetering in prestaties, omdat verkeer niet langer omgeleid hoefde te worden via het datacenter.

In een derde stap werd bekeken waar de VPN om veiligheids- of technische redenen nog noodzakelijk was. Beheertaken op netwerkapparatuur en bepaalde legacy‑beheertools mogen uit veiligheidsoverwegingen niet direct via internet benaderd worden en bleven daarom afhankelijk van een beveiligde tunnel. Ook sommige koppelingen met externe partners waren gebaseerd op site‑to‑site‑verbindingen die op korte termijn niet konden worden vervangen. In deze gevallen werd besloten de VPN beschikbaar te houden, maar expliciet als beheer‑ en uitzonderingsmiddel in plaats van generiek toegangskanaal.

Daarna volgde een gefaseerde aanscherping van het beleid. Voor de meeste reguliere medewerkers werd de standaardtoegang tot de VPN ingetrokken. Pogingen om toch een verbinding op te zetten leverden een duidelijke melding op met uitleg over alternatieve toegang. Medewerkers die aantoonbaar specifieke behoeften hadden, konden tijdelijk toegang aanvragen, waarbij het gebruik periodiek werd geëvalueerd. IT‑medewerkers en enkele andere specialistische functies behielden structurele toegang onder strikte voorwaarden. Analyse van logbestanden hielp om teams te identificeren die extra ondersteuning nodig hadden bij de overgang.

Opvallend genoeg kwam de felste weerstand niet van de meer technisch onderlegde medewerkers, maar van een deel van het senior management. Voor hen stond het inschakelen van de VPN gelijk aan “echt verbonden zijn met het ministerie”. Ondanks inhoudelijke uitleg dat moderne identiteits‑ en toestandscontroles een hogere mate van beveiliging boden, bleef de emotionele waarde van het vertrouwde icoontje in de systeembalk groot. In enkele gevallen was directe interventie van de bestuurlijke sponsor nodig om duidelijk te maken dat het nieuwe model geen vrijblijvende keuze was.

De resultaten na enkele maanden waren overtuigend. Het aantal dagelijkse VPN‑verbindingen daalde met ruim negentig procent en de overgebleven sessies waren grotendeels te herleiden tot beheertaken en enkele specialistische scenario’s. De infrastructuur kon worden afgeschaald, wat directe licentie‑ en beheerkosten bespaarde. Daarnaast nam het aantal storingen en tickets rond VPN‑verbindingen drastisch af, waardoor de servicedesk zich meer kon richten op andere vormen van ondersteuning. Medewerkers rapporteerden merkbaar snellere toegang tot cloudapplicaties doordat het omweg‑verkeer via het datacenter was verdwenen.

In latere gebruikersonderzoeken gaf een ruime meerderheid aan dat werken zonder standaard VPN‑verbinding als eenvoudiger werd ervaren. Een kleine groep met complexe werkpatronen bleef kritisch, maar zelfs daar groeide het besef dat het nieuwe model meer flexibiliteit bood. De belangrijkste succesfactor was dat de voordelen – snelheid, eenvoud, minder storingen – concreet en dagelijks merkbaar waren, in plaats van dat het verhaal uitsluitend ging over abstracte beveiligingsconcepten.

Measured Impact: Quantitative en Qualitative Results

Eind 2024 werd het project formeel afgerond en kon de balans worden opgemaakt. Het beoordelen van het succes vroeg om meer dan alleen technische indicatoren; zowel harde cijfers over beveiliging en kosten als zachte factoren zoals cultuur, vertrouwen en gebruikersbeleving moesten in samenhang worden bekeken.

De objectieve verbetering van de beveiligingspositie was duidelijk. De Microsoft Secure Score steeg van een uitgangswaarde rond de veertig procent naar bijna tachtig procent. Achter die totaalscore ging een reeks concrete maatregelen schuil: identiteitsbeveiliging werd aanzienlijk versterkt door verplichte meervoudige authenticatie, modern toegangsbeleid en beter beheer van beheerdersrechten, endpoints werden beter bewaakt en beheerd, gegevens werden systematischer geclassificeerd en beschermd, en applicaties waren veel beter ingeregeld op moderne authenticatie‑ en autorisatiemodellen. Het aantal openstaande aanbevelingen uit diverse beveiligingsscans nam zichtbaar af.

Ook de incidentcijfers lieten een duidelijke trend zien. Het aantal beveiligingsincidenten dat nader onderzoek vereiste, daalde over de projectperiode met meer dan de helft. Met name aanvallen waarbij inloggegevens werden buitgemaakt, hadden veel minder vaak succes omdat aanvullende factoren nodig waren om toegang te krijgen. Verbeterde logging‑ en analysemogelijkheden zorgden ervoor dat verdachte activiteiten sneller aan het licht kwamen. Tijdige signalering maakte het mogelijk om potentiële incidenten in een vroeg stadium te blokkeren voordat er daadwerkelijke schade ontstond.

Op het gebied van compliance werd grote vooruitgang geboekt. De dekking van BIO‑maatregelen steeg tot een niveau waarbij vrijwel alle relevante controls waren ingevuld, en de resterende aandachtspunten waren helder beschreven inclusief plan van aanpak. Tijdens audits bleek dat de organisatie beter in staat was aantoonbaar te maken hoe processen werkten en welke maatregelen waren getroffen. Rapportages die voorheen weken aan handmatig bewijsvergaren kostten, konden nu grotendeels worden samengesteld op basis van centrale beleidsregels en geautomatiseerde controles.

Operationeel leverde de transformatie eveneens voordelen op. Doordat medewerkers minder verschillende wachtwoorden hoefden te onthouden en gebruikmaakten van zelfservicevoorzieningen, nam het aantal wachtwoordresetverzoeken richting de servicedesk sterk af. Het inrichten van accounts voor nieuwe medewerkers ging aanzienlijk sneller dankzij gestandaardiseerde rollen en geautomatiseerde toekenningsprocessen. Beheerders besteedden minder tijd aan routine‑mutaties in rechten en konden die tijd gebruiken voor verbeteringen en optimalisaties.

Financieel gezien was het beeld genuanceerd maar uiteindelijk positief. De totale projectkosten vielen iets hoger uit dan oorspronkelijk begroot, vooral door extra werkzaamheden rond complexe applicaties en aanvullende licentiekosten bij sommige leveranciers. Daar stonden structurele besparingen tegenover, zoals het terugbrengen van VPN‑capaciteit, het verkleinen van de fysieke datacenterfootprint en efficiëntere inzet van personeel. Bovendien werd benadrukt dat vermeden schade door grote incidenten en boetes moeilijk precies in euro’s uit te drukken is, maar een belangrijk deel van de businesscase vormde.

De grootste verandering was misschien wel zichtbaar in houding en gedrag van medewerkers. Waar beveiliging aan het begin van het traject vaak werd gezien als hinderlijke randvoorwaarde, kreeg het onderwerp gaandeweg meer vanzelfsprekende plek in het dagelijks werk. Medewerkerstevredenheidsonderzoeken lieten een duidelijke verschuiving zien: een groeiende meerderheid gaf aan de balans tussen veiligheid en gebruiksgemak acceptabel of zelfs positief te vinden. Het aantal toegegeven “workarounds” buiten de officiële kanalen liep sterk terug. Tijdens interviews gaven medewerkers aan waarde te hechten aan de duidelijkheid van richtlijnen, de herkenbaarheid van inlogschermen en de mogelijkheid om veilig vanaf verschillende locaties te werken.

De inspanningen op het gebied van verandermanagement speelden daarin een doorslaggevende rol. Het programma met afdelingsambassadeurs, themagerichte kennissessies en regelmatig bestuurders die in begrijpelijke taal uitleg gaven over voortgang en keuzes, zorgde ervoor dat het onderwerp op de agenda bleef. Succesmomenten – zoals het behalen van tussentijdse mijlpalen of het oplossen van lastige knelpunten – werden zichtbaar gemaakt en gedeeld, wat bijdroeg aan trots op het bereikte resultaat.

Daarnaast kwamen er onverwachte voordelen naar voren. Doordat identiteiten en rechten beter waren ingericht, werd het veel eenvoudiger om gecontroleerd samen te werken met andere overheidsorganisaties en externe partners. Nieuwe cloud‑diensten konden sneller maar toch verantwoord worden ingevoerd, omdat de basis voor identiteit en toegang al op orde was. Ook bleek dat het fundament dat voor Zero Trust was gelegd, direct bruikbaar was bij nieuwe initiatieven, bijvoorbeeld op het gebied van geautomatiseerde data‑classificatie en geavanceerde detectie van dreigingen.

Tegelijkertijd werd erkend dat het werk niet “af” is. Een deel van het applicatielandschap is nog niet volledig gemigreerd, waardoor een hybride situatie voorlopig realiteit blijft. Bepaalde verouderde componenten in de on‑premises‑omgeving vragen nog om consolidatie of vervanging. En net als in iedere grote organisatie zijn er medewerkers die het liefst zouden terugkeren naar oude, vertrouwde werkwijzen. Het projectteam benadrukte daarom dat Zero Trust niet gezien moet worden als eindbestemming, maar als een manier van denken die voortdurende doorontwikkeling vraagt.

Lessons Learned en Aanbevelingen voor Andere Organisaties

Terugkijkend op drie jaar transformatie vallen een aantal lessen op die relevant zijn voor andere organisaties die met Zero Trust of vergelijkbare hervormingen aan de slag willen. Sommige inzichten bevestigen wat in theorie al bekend was, andere zijn pas duidelijk geworden door de dagelijkse praktijk en de fouten die onderweg zijn gemaakt.

Een eerste les is dat stevig en zichtbaar eigenaarschap vanuit de top onmisbaar is. Zolang een dergelijk traject primair als “IT‑project” wordt gezien, blijft de impact beperkt en is weerstand moeilijk te doorbreken. Pas toen de bestuurlijke leiding zich expliciet achter de koers schaarde, zelf het gesprek aanging met kritische afdelingshoofden en in communicatie aan alle medewerkers het belang benadrukte, ontstond er voldoende ruimte om lastige beslissingen te nemen. Daarbij hielp het dat de boodschap consequent werd herhaald en gekoppeld bleef aan de bredere opdracht van het ministerie.

Een tweede les is dat verandermanagement geen bijzaak mag zijn. De eerste fases van het project waren sterk techniek‑gedreven en gingen uit van de veronderstelling dat medewerkers vanzelf zouden volgen zodra de oplossing inhoudelijk goed was. De werkelijkheid liet zien dat onvoldoende uitleg, training en begeleidende ondersteuning leiden tot frustratie, productiviteitsverlies en negatieve beeldvorming. Pas toen er structureel middelen werden vrijgemaakt voor communicatie, opleidingen en lokale ambassadeurs, kantelde de sfeer.

Een derde les gaat over fasering en terugvalmogelijkheden. Grootschalige “big bang”‑veranderingen zijn in een complexe overheidsomgeving vrijwel nooit realistisch. Door in behapbare stappen te werken, steeds eerst te testen met een beperkte groep en standaard terugvalscenario’s klaar te hebben, konden problemen weliswaar nog steeds optreden, maar bleef de impact beheersbaar. Enkele keren moest een wijziging tijdelijk worden teruggedraaid. Dat was niet prettig, maar bleek vele malen beter dan krampachtig vasthouden aan een foutieve implementatie.

Daarnaast werd duidelijk hoe groot de invloed van historische technische keuzes is. Verouderde systemen, niet‑gedocumenteerde koppelingen en maatwerkoplossingen die ooit snel zijn gebouwd, zorgden voor veel extra werk en kosten. Het projectteam concludeerde dat organisaties die aan een soortgelijk traject beginnen, ruim moeten begroten voor onbekende complexiteit. Het is realistischer uit te gaan van een forse onzekerheidsmarge dan te hopen dat alle aannames precies kloppen.

Ook de rol van leveranciers kwam scherp in beeld. Partners die hun producten en documentatie goed op orde hadden, fungeerden als versnellers, terwijl andere leveranciers met vage roadmaps of beperkte ondersteuning voor moderne protocollen de voortgang juist remden. Inkoop‑ en contractmanagement bleken daarmee directe beïnvloeders van het succes van het securityprogramma. Het opnemen van eisen rond moderne authenticatie, API’s en lifecycle‑ondersteuning in aanbestedingen is een van de aanbevelingen die hieruit voortkwamen.

Een volgende les betreft kennisopbouw binnen de eigen organisatie. Externe expertise is vaak nodig om tempo te maken en specifieke vraagstukken op te lossen, maar als alle cruciale beslissingen en implementaties alleen door externe partijen worden uitgevoerd, blijft de organisatie afhankelijk. In de laatste fasen van het project is daarom sterker gestuurd op kennisoverdracht: interne medewerkers werkten zij aan zij met consultants en namen geleidelijk het eigenaarschap over complexe onderdelen. Dat vergrootte het vertrouwen dat de omgeving ook na afloop van het project goed beheerd kan worden.

Verder bleek dat het zichtbaar maken van voortgang essentieel is om draagvlak vast te houden. Overzichten van verbeterde scores, dalende aantallen incidenten en positieve gebruikersfeedback werden regelmatig gedeeld in managementoverleggen en interne nieuwsbrieven. Door successen te vieren, ook als het “slechts” ging om het succesvol afronden van een lastige migratie of het oplossen van een veelvoorkomend probleem, bleef het programma levend en voorkwam men dat het werd gezien als een eindeloos traject zonder tastbare resultaten.

Ten slotte zijn er de aanbevelingen aan andere Nederlandse overheidsorganisaties. Wacht niet tot alle drukte rond andere dossiers voorbij is; een structurele verbetering van digitale weerbaarheid kost tijd en overlapt altijd met andere prioriteiten. Zorg vroegtijdig voor duidelijke bestuurlijke verankering en betrek zowel security‑specialisten als lijnmanagers en ondernemingsraden. Gebruik bestaande kaders, zoals de BIO en de aankomende NIS2‑verplichtingen, als richtinggevend kompas in plaats van als administratieve last achteraf. Reserveer voldoende middelen voor verandercommunicatie en opleiding, ook buiten de IT‑afdeling. En vooral: behandel Zero Trust niet als een product om “in te voeren”, maar als een gedachtegoed dat keuzes op het gebied van architectuur, processen en gedrag voor langere tijd beïnvloedt.

Voor Ministerie X betekent het einde van het project geen einde aan de ontwikkeling. De gelegde basis maakt het eenvoudiger om nieuwe technologieën veilig te omarmen, variërend van geavanceerde analysetools tot vormen van kunstmatige intelligentie en toekomstige cryptografische technieken. De organisatie beschikt nu over processen, kennis en een cultuur waarin beveiliging niet losstaat van de dagelijkse operatie, maar daar integraal onderdeel van uitmaakt. Daarmee is een fundament gelegd voor een blijvend hogere weerbaarheid in een dreigingslandschap dat voortdurend verandert.

De Zero Trust‑transformatie bij Ministerie X laat zien dat theoretische modellen daadwerkelijk toepasbaar zijn in de complexe werkelijkheid van een grote overheidsorganisatie met verouderde systemen, beperkte middelen en ingesleten routines. Het traject verliep allesbehalve rechtlijnig: technische beperkingen, organisatorische weerstand en onvoorziene complicaties zorgden regelmatig voor vertraging en bijsturing. Toch maakte de combinatie van volharding, lerend vermogen en duidelijke sturing het mogelijk om de beveiligingspositie ingrijpend te verbeteren zonder de continuïteit van de dienstverlening in gevaar te brengen.

Eind 2024 is de omgeving nog niet perfect. Er zijn nog steeds applicaties die afhankelijk zijn van verouderde technologie, bepaalde processen kunnen verder worden geautomatiseerd en niet iedere medewerker is even enthousiast over de nieuwe werkwijze. Tegelijkertijd is de sprong voorwaarts onmiskenbaar: een veel hoger niveau van bescherming, aantoonbare verbetering van compliance en een gebruikerservaring die – in tegenstelling tot de verwachtingen vooraf – door de meeste medewerkers als overzichtelijker en flexibeler wordt ervaren.

De belangrijkste boodschap voor andere organisaties is dat dit soort transformaties een lange adem vergt. Ze vragen om realistische verwachtingen, voldoende ruimte voor experiment en correctie, en een stevige investering in communicatie en cultuur naast de technische vernieuwing. Technologie is een noodzakelijke randvoorwaarde, maar uiteindelijk zijn het de mensen, processen en bestuurlijke keuzes die bepalen of de beoogde verandering daadwerkelijk landt.

De ervaring van Ministerie X bewijst dat zelfs organisaties met aanzienlijke technische schuld en complexe besluitvorming in staat zijn hun beveiligingsfundament structureel te versterken. Argumenten als “te ingewikkeld”, “te duur” of “onacceptabel voor gebruikers” blijken in veel gevallen te relativeren zodra er een heldere visie, consequente uitvoering en aandacht voor de menselijke kant van verandering aanwezig zijn. De investering in een Zero Trust‑benadering betaalt zich dan niet alleen terug in minder risico’s, maar ook in betere wendbaarheid en een professionelere digitale dienstverlening.