Wat zijn de meest voorkomende fouten bij de implementatie van SASE?
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ëren 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.
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. De lijst die volgt is breder. Dit zijn de patronen die hele SASE programma’s doen vastlopen, niet alleen ZTNA configuraties.
Fout 1: SASE behandelen als nog een hulpmiddel op de stapel
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.
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.
Dit patroon komt vaker voor dan de meeste leveranciers willen toegeven. Onderzoek van Gartner wijst uit dat minder dan één 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.
De oplossing begint vóór 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 wordt deze consolidatielogica in detail besproken.
De praktische tip: schrijf voordat je iets ondertekent één 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.
Fout 2: VPN-regels kopiëren naar ZTNA en het Zero Trust noemen
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.
Dit is de “lift-and-shift” val. Het voelt efficiënt 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.
Het diepere probleem is meestal vuile identiteitsdata. De meeste organisaties in het middensegment van de markt hebben identity providers vol verouderde groepslidmaatschappen, overgeërfde 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ëne tot de belangrijkste oorzaken behoren van mislukte toegangscontrole, en ze zijn volledig te voorkomen.
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 één 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.
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.
Voor een diepere kijk op hoe identiteitsproviders integreren met Zero Trust toegang, behandelt die gids de specifieke integratiepatronen die deze fout voorkomen.
Fout 3: legacy-infrastructuur laten draaien “voor het geval dat”
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.”
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.
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.
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.
Zo ziet dat er in de praktijk uit:
| Fase | Actie | Tijdschema |
|---|---|---|
| Migratie voltooid | Applicatie geverifieerd op SASE, gebruikers bevestigd | Dag 0 |
| Bewakingsperiode | Let op toegangsproblemen, volg supporttickets | Dagen 1-14 |
| Oud pad uitgeschakeld | VPN/firewall regel verwijderd, gedocumenteerd | Dag 15 |
| Infrastructuur buiten gebruik gesteld | Hardware buiten gebruik gesteld, licenties geannuleerd | Dag 30 |
Het belangrijkste inzicht: ontmanteling is geen taak die je na het project uitvoert. Het maakt deel uit van het project. Elke fase van het uitrollen van je SASE architectuur moet “het ding dat dit vervangt met pensioen laten gaan” als een deliverable bevatten, niet als een bijzaak.
Hoe je deze patronen kunt herkennen voordat ze je afremmen
Als je drie vragen eerlijk kunt beantwoorden voordat de implementatie begint, voorkom je ongeveer 80% van de vertraging die we in het veld zien.
Ten eerste: wat schakelen we precies uit nadat SASE is uitgerold? Als het antwoord “niets” is, dan ben je een tool aan het toevoegen, niet je architectuur aan het veranderen. Ga terug naar het architectuurplan.
Ten tweede: hebben we onze identity provider de afgelopen zes maanden gecontroleerd? Als groepslidmaatschappen en machtigingen niet zijn gecontroleerd, importeert u problemen direct in ZTNA. Schone identiteitsgegevens zijn de grootste voorspeller van een soepele uitrol.
Ten derde: wie is de eigenaar van het ontmantelingsschema? Als niemand een naam en een datum naast elk legacy component heeft staan, zullen die componenten over een jaar nog steeds draaien. Noem de eigenaar. Stel de data vast.
De organisaties die deze drie vragen beantwoorden voordat ze beginnen, zijn meestal op tijd klaar. Degenen die ze overslaan, bellen ons zes maanden later met de vraag waarom alles zo lang duurt.
Voor teams die op dit moment leveranciers evalueren, beschrijft het SASE raamwerk voor leveranciersvergelijking waar ze op moeten letten, naast de checklists met functies, inclusief hoe ze kunnen beoordelen of de architectuur van een platform daadwerkelijk de consolidatie en eenvoud ondersteunt die deze fouten voorkomt.
Veelgestelde vragen
Hoe lang moet een SASE-proeffase duren?
Voor organisaties in het middensegment is het gebruikelijk om twee tot vier weken de tijd te nemen voor een eerste pilot met toegang op afstand voor 50 tot 100 gebruikers. De pilot moet ten minste drie tot vijf applicaties omvatten, waarbij vanaf het begin de apparaatstatus wordt gecontroleerd. Als de pilot langer dan zes weken duurt, betekent dit meestal dat het team een beslissing uit de weg gaat in plaats van gegevens te verzamelen.
Moeten we onze firewall buiten gebruik stellen voor of na de uitrol van SASE?
Na. Draai beide parallel tijdens de migratie, maar met een vast schema voor buitengebruikstelling. De meeste organisaties behouden perimeter firewalls voor noord-zuid verkeer tijdens de overgang en ontmantelen ze wanneer de SASE-dekking wordt uitgebreid om die functies te dekken. Het gevaar is niet om beide tijdelijk te gebruiken. Het gevaar is om beide permanent te gebruiken.
Wat is de grootste tijdverspiller bij een SASE implementatie?
Vuile identiteitsgegevens. Organisaties die beginnen met migreren voordat ze hun identity provider hebben opgeschoond, besteden weken aan het oplossen van toegangsproblemen die niets te maken hebben met het SASE platform. Verouderde groepslidmaatschappen, verweesde accounts en vage roldefinities zorgen voor wrijving bij elke stap. Trek minstens een week uit voor identiteitshygiëne voordat de technische migratie begint.
Hebben we een speciale projectmanager nodig voor SASE?
Niet noodzakelijkerwijs een fulltime projectmanager, maar iemand moet verantwoordelijk zijn voor de tijdlijn, het ontmantelingsschema en de teamoverkoepelende coördinatie. SASE raakt aan netwerken, beveiliging en identiteit, drie domeinen die vaak in verschillende teams zitten. Zonder iemand die alle drie op één lijn zit, lopen beslissingen vast. Voor middelgrote teams is dit vaak de IT-manager of een senior engineer met een duidelijk mandaat.
Kunnen we SASE uitrollen zonder de dagelijkse werkzaamheden te verstoren?
Ja, als u het gefaseerd aanpakt. Begin met toegang op afstand via ZTNA, voeg dan webbeveiliging toe en vervolgens connectiviteit op locatie via SD-WAN. Elke fase levert onafhankelijk van elkaar waarde, terwijl de bestaande infrastructuur actief blijft als fallback. De combinatie van een cloud-native architectuur en één beheerconsole maakt gefaseerde uitrol praktisch, zelfs voor kleine teams. Daarom hebben we Jimber gebouwd om precies dat patroon te ondersteunen, component voor component, zonder een big-bang migratie.
Klaar om de fouten te vermijden die de meeste SASE implementaties vertragen? Boek een demo en we zullen een gefaseerde uitrol in kaart brengen die past bij je tijdlijn en je team.
