Bijgewerkt november 2, 2026
Kort: Een soevereine ZTNA-architectuur plaatst policy engine, identiteitsbeheer en enforcement points volledig buiten Amerikaanse jurisdictie. Dit artikel legt uit welke open-source en Europese alternatieven beschikbaar zijn en hoe compliance officers de keuzes documenteren in een DPIA en NIS-2-risicobeheerdossier.

Een soevereine zero trust-architectuur (ZTNA) is een netwerktoegangsmodel waarbij elke verbindingsaanvraag voortdurend wordt geverifieerd op basis van identiteit, apparaatstatus en context, en waarbij de volledige controlelaag, inclusief policy engine en identiteitsbeheer, buiten de jurisdictie van niet-EU-wetgeving wordt geplaatst. Voor compliance officers en IT-beslissers in overheid, juridische dienstverlening en andere gereguleerde sectoren is die jurisdictiecomponent niet bijzaak, maar de kern van de architectuurbeslissing.

Kerncomponenten van een soevereine ZTNA-architectuur

NIST SP 800-207 (Zero Trust Architecture) definieert drie onlosmakelijk verbonden lagen: de policy engine, de policy administrator en de policy enforcement points (PEP). De soevereiniteit van het geheel staat of valt met de locatie van de policy engine, want die neemt de autorisatiebeslissingen op basis van identiteits- en contextdata.

Policy engine en policy administrator

De policy engine vergelijkt een toegangsverzoek met het geldende beleid en geeft een vertrouwensscore terug. De policy administrator zet die uitkomst om in een opdracht aan de enforcement point: toestaan, weigeren of isoleren. Beide componenten kunnen volledig on-premise worden geplaatst op eigen hardware of bij een Europese hostingprovider die geen dochteronderneming is van een Amerikaans bedrijf. Zodra de policy engine draait op infrastructuur van een aanbieder die onder de Amerikaanse CLOUD Act valt, kunnen Amerikaanse autoriteiten in beginsel de beleidsdata opvragen zonder dat de Europese klant daar formeel van op de hoogte wordt gesteld.

Identiteitsbeheer en SPIFFE/SPIRE

Robuust identiteitsbeheer vereist zowel menselijke identiteiten (via een soevereine identity provider zoals Keycloak, zelfgehost) als machine-identiteiten. Het SPIFFE/SPIRE-framework, beheerd door de Cloud Native Computing Foundation, biedt een open standaard voor kortlevende cryptografische service-identiteiten in gedistribueerde omgevingen. SPIRE-servers kunnen volledig on-premise draaien en certificaten uitgeven zonder afhankelijkheid van een externe certificate authority. Juist in hybride architecturen, waarbij microservices deels on-premise en deels bij een Europese cloudprovider draaien, voorkomt SPIFFE/SPIRE dat service-to-service-communicatie op vaste geheimen of langlevende tokens berust.

Let op: Plaatst u de policy engine bij een Amerikaanse cloudaanbieder terwijl u meent soeverein te opereren? Dan verplaatst u de beleidsautoriteit buiten uw eigen jurisdictie. Dat is een architectuurbeslissing met directe juridische gevolgen, ook als de data zelf in Europa staat.

De SASE-markt en jurisdictierisico’s

Cloud-delivered SASE-diensten van Zscaler, Palo Alto Networks en Microsoft integreren ZTNA, firewall-as-a-service en SD-WAN in één platform. Het operationele gemak is evident, maar voor Europese organisaties in gereguleerde sectoren introduceert dit een structureel jurisdictierisico.

Aanbieder Hoofdkantoor Policy engine-locatie Jurisdictierisico
Zscaler VS Zscaler-cloud (wereldwijd) CLOUD Act van toepassing op controlelaag
Palo Alto Prisma Access VS Palo Alto-cloud CLOUD Act van toepassing op controlelaag
Microsoft Entra Private Access VS Azure (EU-datacenters mogelijk) CLOUD Act van toepassing; Microsoft is Amerikaans bedrijf
OpenZiti (zelfgehost) Open source / CNCF Eigen infrastructuur of EU-provider Geen externe jurisdictie
NetBird (zelfgehost) Open source Eigen infrastructuur of EU-provider Geen externe jurisdictie

Gartner voorspelde dat in 2025 60% van de ondernemingen meerdere zero trust-oplossingen tegelijk gebruikt, maar dat minder dan 10% een volwassen, volledig geïmplementeerde zero trust-architectuur heeft (Gartner, 2023). Dat gat wordt deels verklaard doordat organisaties commerciële SASE aanschaffen zonder de jurisdictie van de controlelaag te beoordelen.

Open-source en Europese ZTNA-alternatieven

Voor organisaties die de volledige controlelaag binnen eigen beheer willen houden, zijn er inmiddels volwassen open-source alternatieven die productierijp zijn voor gebruik in gereguleerde sectoren.

OpenZiti

OpenZiti is een volledig zelfhostbaar zero trust-netwerkoverlayplatform met een formeel SDK-ecosysteem voor meerdere programmeertalen. De architectuur omvat een eigen controller (de policy engine), edge routers (enforcement points) en een identiteitslaag op basis van X.509-certificaten. OpenZiti wordt in productieomgevingen ingezet bij financiële instellingen en is onderdeel van de CNCF-sandbox. Zelfhosting vereist dat de organisatie zelf verantwoordelijkheid draagt voor updates en certificaatrotatie.

NetBird

NetBird bouwt een peer-to-peer overlay-netwerk op basis van WireGuard en heeft een volledig zelfhostbare management-server. De access control-laag, inclusief groepsbeleid en logging, draait op eigen infrastructuur. NetBird is relatief eenvoudig te deployen en geschikt voor organisaties die een lagere operationele complexiteit nastreven dan OpenZiti, maar wel volledige soevereiniteit vereisen.

Headscale en Tailscale on-premise

Headscale is een open-source reimplementatie van de Tailscale-controleserver. Tailscale zelf is een Amerikaans bedrijf waarvan de controleserver onder de CLOUD Act valt. Headscale elimineert die afhankelijkheid, maar de gemeenschap is kleiner dan die van OpenZiti of NetBird. Voor NIS-2-plichtige organisaties verdient het aanbeveling de volwassenheid van de gekozen tool te valideren via een formele risicoanalyse, niet slechts via GitHub-statistieken.

Integratie met PQC, AVG en NIS-2

Een soevereine ZTNA-architectuur bestaat niet in isolatie. Ze moet aansluiten op drie parallelle complianceverplichtingen: de post-quantum cryptografie (PQC)-migratie, de AVG-vereisten voor toegangslogging en de NIS-2-zorgplicht voor netwerksegmentatie.

NIST SP 1800-35 (Implementing a Zero Trust Architecture) beschrijft hoe organisaties cryptografische algoritmen in de TLS-handshake van enforcement points kunnen vervangen. De huidige NIST PQC-standaarden (ML-KEM, ML-DSA, gepubliceerd in 2024) zijn relevant voor de sleuteluitwisseling tussen clients en de ZTNA-controlelaag. Organisaties die nu een soevereine ZTNA-architectuur bouwen, doen er verstandig aan cryptografische agiliteit als ontwerpeis op te nemen: het algoritme moet vervangbaar zijn zonder de gehele architectuur te herbouwen.

Onder de AVG (artikel 5 lid 1 sub f en artikel 32) moeten toegangslogs vertrouwelijkheid, integriteit en beschikbaarheid waarborgen. ZTNA-architecturen genereren per definitie rijke toegangsdata: wie heeft op welk moment, vanaf welk apparaat en met welk vertrouwensniveau toegang gekregen tot welke resource? Die logs vormen tegelijk een AVG-verwerkingsactiviteit en een beveiligingsmaatregel. Ze moeten worden opgeslagen op soevereine infrastructuur en worden bewaard conform de proportionaliteitseis van de AVG.

NIS-2 artikel 21 verplicht essentiële en belangrijke entiteiten tot passende maatregelen voor netwerksegmentatie en toegangsbeheer. Het BIO2-netwerksegmentatiebeleid vertaalt dit voor Nederlandse overheidsorganisaties in concrete eisen voor scheiding van netwerksegmenten op basis van vertrouwensniveau. Microsegmentatie via ZTNA enforcement points is een directe technische invulling van beide verplichtingen, mits de segmentatiebeslissingen worden vastgelegd en periodiek worden getoetst.

IBM rapporteerde in het Cost of a Data Breach Report 2023 dat organisaties met een geïmplementeerde zero trust-architectuur gemiddeld 1,76 miljoen dollar minder kosten hadden bij een datalek dan organisaties zonder zero trust (IBM, 2023). De ENISA Threat Landscape 2023 bevestigde dat ransomware en data-exfiltratie meer dan 40% van alle incidenten in gereguleerde EU-sectoren uitmaakten (ENISA, 2023), wat de urgentie van microsegmentatie onderstreept.

Let op: Cryptografische agiliteit is geen luxe. Als de ZTNA-controlelaag vandaag wordt gebouwd op een hardgecodeerd algoritme, kan de PQC-migratie over twee jaar een volledige herimplementatie vereisen in plaats van een configuratiewijziging.

Operationele uitdagingen bij microsegmentatie in hybride omgevingen

De meeste organisaties in gereguleerde sectoren hebben een hybride infrastructuur: een deel van de werklast staat on-premise, een deel bij een Europese cloudprovider zoals IONOS, Hetzner of OVHcloud. Microsegmentatie in zo’n omgeving kent drie terugkerende knelpunten.

Het eerste knelpunt is identiteitscontext over segmentgrenzen. Een enforcement point on-premise en een enforcement point in de Europese cloud moeten dezelfde identiteits- en contextdata raadplegen. Dat vereist een hoog-beschikbare, soevereine identity provider met synchronisatie over beide omgevingen, zonder dat die synchronisatie via een niet-EU-tussenpunt loopt. SPIFFE/SPIRE biedt hier een oplossing via federated SPIRE-servers die wederzijds certificaten erkennen zonder centrale controleserver.

Het tweede knelpunt is latentie bij continue verificatie. ZTNA veronderstelt dat elke sessie voortdurend wordt herbeoordeeld. In hybride omgevingen kan de afstand tot de policy engine latentie introduceren. De oplossing is het distribueren van enforcement points dicht bij de resource, terwijl de policy engine gecentraliseerd blijft. Dat vereist zorgvuldig capaciteitsontwerp en afspraken over failover wanneer de policy engine tijdelijk onbereikbaar is.

Het derde knelpunt is zichtbaarheid. Microsegmentatie werkt alleen als de organisatie volledig inzicht heeft in welke services met welke andere services communiceren. In hybride omgevingen ontbreekt dat inzicht regelmatig, waardoor segmentatieregels te ruim worden geconfigureerd om operationele problemen te voorkomen. Een service mesh met observability-instrumenten is een voorwaarde, geen optie.

ZTNA-architectuurkeuzes documenteren voor DPIA en NIS-2

Scott Rose, hoofdauteur van NIST SP 800-207, formuleerde het kernprincipe treffend: “Zero trust is geen product dat je koopt, maar een strategie die je implementeert. De vraag is niet óf je het vertrouwensmodel herziet, maar wáár de policy engine draait en wie er toegang toe heeft.” Die vraag moet de compliance officer beantwoorden in zowel de DPIA als het NIS-2-risicobeheerdossier.

De DPIA beschrijft de gegevensstromen naar de policy engine, de verwerkingslocatie van iedere component, de bewaartermijn en het doel van de toegangslogs, en de grondslag voor verwerking onder de AVG. De afwezigheid van doorgifte buiten de EER wordt expliciet als mitigerende maatregel opgenomen. Een architectuurtekening met componentnamen en hostinglocaties is een verplichte bijlage.

Het NIS-2-risicobeheerdossier documenteert de keuze voor specifieke ZTNA-componenten als invulling van artikel 21-maatregelen, de beoordeling van open-source alternatieve versus commerciële oplossingen inclusief jurisdictiebeoordeling, de frequentie van beleidsreview en de procedure bij wijziging van het dreigingslandschap. De BIO2-netwerksegmentatieeis vereist dat de segmentatiearchitectuur periodiek wordt getoetst; het dossier legt vast wanneer en door wie die toetsing plaatsvindt.

Een compliance officer die deze documentatie opbouwt, creëert tegelijk de audittrail die toezichthouders zoals de Rijksinspectie Digitale Infrastructuur en sectorspecifieke autoriteiten verwachten bij een NIS-2-inspectie of AVG-handhavingsprocedure.

FAQ

Kan een zero trust-architectuur volledig on-premise worden uitgevoerd zonder afhankelijkheid van cloudaanbieders?

Ja. De drie kerncomponenten van NIST SP 800-207, de policy engine, de policy administrator en de policy enforcement points, kunnen alle drie on-premise of bij een Europese hostingprovider worden geplaatst. Open-source tools zoals OpenZiti en NetBird ondersteunen volledige zelfhosting, inclusief de controlelaag.

Wat is het verschil tussen SASE van Zscaler of Palo Alto en een soevereine ZTNA-oplossing?

Commerciële SASE-platformen van Amerikaanse aanbieders hosten de policy engine doorgaans in hun eigen cloud, die onder de CLOUD Act valt. Een soevereine ZTNA-oplossing plaatst de volledige controlelaag binnen de EU of on-premise, zodat geen enkele Amerikaanse rechtsmacht toegang kan afdwingen op de beleidsinfrastructuur.

Hoe verplicht NIS-2 artikel 21 tot netwerksegmentatie en hoe sluit ZTNA daar op aan?

NIS-2 artikel 21 vereist passende maatregelen voor toegangsbeheer en netwerksegmentatie als onderdeel van het risicobeheer van netwerk- en informatiesystemen. ZTNA vertaalt dit in technische microsegmentatie: elke verbinding wordt per sessie geautoriseerd op basis van identiteit, apparaatstatus en context, zodat laterale beweging bij een incident wordt beperkt.

Hoe documenteer ik een soevereine ZTNA-keuze in een DPIA?

De DPIA moet de gegevensstromen naar de policy engine beschrijven, de verwerkingslocatie per component benoemen, de grondslag voor toegangslogging onderbouwen onder artikel 5 en 32 AVG, en de residuele risico’s kwantificeren. Verwijs expliciet naar de afwezigheid van doorgifte buiten de EER als mitigerende maatregel, en leg de architectuurtekening vast als bijlage bij het NIS-2-risicobeheerdossier.

Zijn open-source ZTNA-tools zoals NetBird en OpenZiti volwassen genoeg voor gereguleerde sectoren?

NetBird en OpenZiti zijn beide actief onderhouden projecten met volledige zelfhostingmogelijkheid. OpenZiti heeft een formeel SDK-ecosysteem en wordt in productieomgevingen bij financiële instellingen ingezet. De volwassenheid vereist wel dat de organisatie zelf verantwoordelijkheid neemt voor updates, auditlogging en incidentrespons, wat interne capaciteit vraagt of contractueel bij een Europese beheerder kan worden belegd.

Veelgestelde vragen

Kan een zero trust-architectuur volledig on-premise worden uitgevoerd zonder afhankelijkheid van cloudaanbieders?
Ja. De drie kerncomponenten van NIST SP 800-207, namelijk de policy engine, de policy administrator en de policy enforcement points, kunnen alle drie on-premise of bij een Europese hostingprovider worden geplaatst. Open-source tools zoals OpenZiti en NetBird ondersteunen volledige zelfhosting, inclusief de controlelaag.
Wat is het verschil tussen SASE van Zscaler of Palo Alto en een soevereine ZTNA-oplossing?
Commerciu00eble SASE-platformen van Amerikaanse aanbieders hosten de policy engine doorgaans in hun eigen cloud, die onder de CLOUD Act valt. Een soevereine ZTNA-oplossing plaatst de volledige controlelaag binnen de EU of on-premise, zodat geen enkele Amerikaanse rechtsmacht toegang kan afdwingen op de beleidsinfrastructuur.
Hoe verplicht NIS-2 artikel 21 tot netwerksegmentatie en hoe sluit ZTNA daar op aan?
NIS-2 artikel 21 vereist passende maatregelen voor toegangsbeheer en netwerksegmentatie als onderdeel van het risicobeheer van netwerk- en informatiesystemen. ZTNA vertaalt dit in technische microsegmentatie: elke verbinding wordt per sessie geautoriseerd op basis van identiteit, apparaatstatus en context, zodat laterale beweging bij een incident wordt beperkt.
Hoe documenteer ik een soevereine ZTNA-keuze in een DPIA?
De DPIA moet de gegevensstromen naar de policy engine beschrijven, de verwerkingslocatie per component benoemen, de grondslag voor toegangslogging onderbouwen onder artikel 5 en 32 AVG, en de residuele risico's kwantificeren. Verwijs expliciet naar de afwezigheid van doorgifte buiten de EER als mitigerende maatregel, en leg de architectuurtekening vast als bijlage bij het NIS-2-risicobeheerdossier.
Zijn open-source ZTNA-tools zoals NetBird en OpenZiti volwassen genoeg voor gereguleerde sectoren?
NetBird en OpenZiti zijn beide actief onderhouden projecten met volledige zelfhostingmogelijkheid. OpenZiti heeft een formeel SDK-ecosysteem en wordt in productieomgevingen bij financiu00eble instellingen ingezet. De volwassenheid vereist wel dat de organisatie zelf verantwoordelijkheid neemt voor updates, auditlogging en incidentrespons, wat interne capaciteit vraagt of contractueel bij een Europese beheerder kan worden belegd.