De drie meest voorkomende fouten bij de implementatie van SASE zijn het behandelen van de migratie als een verandering van tool in plaats van een verandering van architectuur, het kopi\u00ebren van oude VPN-toegangsregels naar een ZTNA-model zonder ze te heroverwegen, en het laten draaien van oude infrastructuur “voor het geval dat” lang nadat deze had moeten worden verwijderd. Elk van deze zaken voegt maanden toe aan de tijdlijn en tast de beveiligingswinst aan die het project in de eerste plaats rechtvaardigde. <\/p>\n
Na tientallen organisaties in het middensegment te hebben geholpen bij de uitrol van SASE, komen er steeds weer drie fouten naar voren bij de implementatie van SASE. Geen technische randgevallen. Organisatorische patronen die van een project van zes weken een project van zes maanden maken. We schreven eerder dit jaar over 10 veelgemaakte ZTNA fouten<\/a>. De lijst die volgt is breder. Dit zijn de patronen die hele SASE programma’s doen vastlopen, niet alleen ZTNA configuraties. <\/p>\n De meest schadelijke fout gebeurt voordat de eerste polis is geschreven. Teams benaderen SASE als een productaankoop, niet als een architectuurwijziging. Ze plaatsen het naast bestaande firewalls en VPN’s als een extra laag, in plaats van de vervanging voor de meeste ervan. <\/p>\n We hebben dit onlangs gezien bij een logistiek bedrijf met 200 gebruikers. Hun IT manager kocht een SASE licentie, configureerde het naast hun bestaande firewall cluster en begon wat verkeer door het nieuwe platform te routeren. Zes maanden later draaiden ze beide systemen parallel, betaalden ze voor beide en beheerden ze het beleid in twee consoles. De beveiliging was nauwelijks veranderd omdat niemand had besloten welk systeem gezaghebbend was. <\/p>\n Dit patroon komt vaker voor dan de meeste leveranciers willen toegeven. Onderzoek van Gartner wijst uit dat minder dan \u00e9\u00e9n op de tien organisaties de volledige waarde uit hun SASE-investering haalt. De reden is bijna nooit de technologie. Het is het niet behandelen van SASE als een consolidatieproject in plaats van een toevoeging. <\/p>\n De oplossing begint v\u00f3\u00f3r de aanschaf. Bepaal welke tools SASE zal vervangen, niet aanvullen. Breng je huidige stack in kaart, je firewalls, VPN-concentrators, web gateways, standalone SD-WAN, en markeer ze allemaal met een beoogde pensioendatum. Als je niet kunt benoemen wat SASE vervangt, voeg je eerder complexiteit toe dan dat je het verwijdert. In het artikel over ontsnappen aan de Frankenstack<\/a> wordt deze consolidatielogica in detail besproken. <\/p>\n De praktische tip: schrijf voordat je iets ondertekent \u00e9\u00e9n zin die aanvult “nadat SASE volledig is uitgerold, zullen we ______ niet langer nodig hebben.” Als die zin moeilijk te schrijven is, neem dan een stap terug en herzie je architectuurplan. <\/p>\n De tweede fout is subtieler. Teams migreren hun oude firewall en VPN toegangsregels direct naar het nieuwe ZTNA model. Het “Finance team” krijgt dezelfde brede toegang die ze hadden via de VPN-tunnel. “Externe medewerkers” erft hetzelfde groepsbeleid. De oude rechtenstructuur krijgt een nieuw label. Eigenlijk verandert er niets. <\/p>\n Dit is de “lift-and-shift” val. Het voelt effici\u00ebnt omdat het de moeilijke gesprekken vermijdt over wie echt toegang tot wat nodig heeft. Maar het omzeilt het hele punt van Zero Trust. Een gecompromitteerd account in een lift-and-shift ZTNA implementatie heeft dezelfde straal als een gecompromitteerd VPN account, dat wil zeggen, veel te groot. <\/p>\n Het diepere probleem is meestal vuile identiteitsdata. De meeste organisaties in het middensegment van de markt hebben identity providers vol verouderde groepslidmaatschappen, overge\u00ebrfde rechten en generieke serviceaccounts die niemand in jaren heeft gecontroleerd. Door die rommel in een ZTNA-platform te stoppen, wordt het disfunctioneren alleen maar gedigitaliseerd. Uit gegevens uit de sector blijkt consequent dat problemen met identiteitshygi\u00ebne tot de belangrijkste oorzaken behoren van mislukte toegangscontrole, en ze zijn volledig te voorkomen. <\/p>\n De oplossing bestaat uit vier stappen. Ten eerste, saniteer je identity provider voor de migratie. Verwijder verouderde accounts, controleer groepslidmaatschappen en stem groepen af op werkelijke bedrijfsrollen. Ten tweede, breng gebruikers in kaart met applicaties, niet met netwerken. Vraag “welke drie applicaties gebruikt deze rol eigenlijk dagelijks?” in plaats van “welk netwerksegment hebben ze nodig?”. Ten derde, begin met alleen-lezen applicaties met een laag risico in je pilot. Met een wiki of tijdregistratiesysteem kan je team het model leren kennen voordat er veel op het spel staat. Ten vierde, schakel vanaf dag \u00e9\u00e9n apparaatposture checks in. Door deze over te slaan tijdens de pilot, wat veel teams doen om wrijving te verminderen, leren gebruikers toegang te verwachten zonder beveiligingsvalidatie. <\/p>\n Dat laatste is belangrijker dan het lijkt. Als je eenmaal het precedent hebt geschapen dat onbeheerde apparaten dezelfde toegang krijgen als beheerde, wordt het terugdraaien van die verwachting een politieke strijd. Doe het vanaf het begin goed. <\/p>\n Voor een diepere kijk op hoe identiteitsproviders integreren met Zero Trust toegang<\/a>, behandelt die gids de specifieke integratiepatronen die deze fout voorkomen.<\/p>\n De derde fout is degene die verantwoordelijk voelt, maar stilletjes alles ondermijnt. Teams voltooien hun SASE uitrol. Gebruikers zijn verbonden via ZTNA. Het beleid werkt. Dan zegt iemand: “Laten we de oude VPN-gateway aanhouden als fallback. Voor het geval dat.” <\/p>\n Maanden later is het VPN nog steeds actief. De oude firewallregels bestaan nog steeds. Springservers die buiten gebruik gesteld zouden worden, zijn nog steeds bereikbaar. Elk van deze servers is een onbewaakt toegangspad dat elke Zero Trust controle omzeilt die je zojuist hebt gebouwd. <\/p>\n We hebben dit in bijna elke verloving gezien. De redenering klinkt altijd voorzichtig. “Wat als het nieuwe platform een storing heeft?” “Wat als we moeten terugdraaien?” Maar de risicoberekening is omgekeerd. Een slapende VPN-concentrator met verouderde firmware en brede toegangsregels is geen vangnet. Het is een aanvalsoppervlak. Gegevens van cyberverzekeringsclaims uit 2025 laten zien dat verouderde VPN-infrastructuur betrokken is bij de meeste ingangen voor ransomware in de Benelux. De systemen die teams “voor het geval dat” bewaren, zijn de systemen die gecompromitteerd raken. <\/p>\n De oplossing is een ontmantelingsschema, opgeschreven en toegewezen. Stel voor elke applicatie die je migreert naar SASE een datum vast waarop het oude toegangspad wordt uitgeschakeld. Niet “uiteindelijk”. Een specifieke kalenderdatum, meestal twee tot vier weken na een succesvolle migratie, met een gedocumenteerde terugvalprocedure als er iets misgaat tijdens dat venster. <\/p>\n Zo ziet dat er in de praktijk uit:<\/p>\nFout 1: SASE behandelen als nog een hulpmiddel op de stapel<\/h2>\n
Fout 2: VPN-regels kopi\u00ebren naar ZTNA en het Zero Trust noemen<\/h2>\n
Fout 3: legacy-infrastructuur laten draaien “voor het geval dat”<\/h2>\n