Post-kwantumcryptografie (PQC) en zero trust zijn twee complementaire beveiligingsparadigma’s: zero trust beschrijft wie toegang krijgt en hoe dat continu wordt geverifieerd, terwijl PQC garandeert dat de cryptografische laag waarop die verificatie rust bestand blijft tegen toekomstige kwantumcomputers. Voor compliance officers en IT-beslissers in de overheid, de juridische sector en andere gereguleerde omgevingen is het onderscheid tussen beide concepten geen academische kwestie, maar een directe randvoorwaarde voor NIS-2- en DORA-naleving.
Waarom PQC het zero-trust-model versterkt maar niet vervangt
Zero trust is een architectuurprincipe, geen encryptiestandaard. PQC is een encryptietechnologie, geen toegangsbeleid. De twee opereren op verschillende lagen en vullen elkaar aan.
Het zero-trust-model veronderstelt dat geen enkel netwerksegment of gebruiker inherent vertrouwd is. Elke toegangspoging wordt geverifieerd aan de hand van identiteit, context en beleid. Die verificatie verloopt over versleutelde kanalen: TLS-verbindingen, wederzijdse authenticatiecertificaten (mTLS) en versleutelde beleidsartefacten. Precies op die kanalen is klassieke cryptografie kwetsbaar voor de zogenoemde “harvest now, decrypt later”-aanval: een aanvaller onderschept versleuteld verkeer vandaag en ontsleutelt het zodra een cryptografisch relevante kwantumcomputer beschikbaar is.
ENISA schat dat cryptografisch relevante kwantumcomputers binnen tien tot vijftien jaar operationeel kunnen zijn (ENISA Threat Landscape 2023). Dat lijkt ver weg, maar data die nu wordt vastgelegd met een geheimhoudingsplicht van twintig jaar, valt al binnen die horizon.
De kritieke integratiepunten: waar PQC als eerste moet worden ingevoerd
Niet elk onderdeel van een zero-trust-architectuur hoeft tegelijk te worden gemigreerd. Prioritering op basis van risico en blootstellingsduur is verstandiger.
mTLS en service-to-service-verkeer
In een zero-trust-netwerk authenticeren services elkaar via mTLS. De certificaten en handshakes die daarvoor worden gebruikt, zijn gebaseerd op RSA of ECDSA, beide kwetsbaar voor kwantumalgoritmen zoals Shor’s algoritme. Migratie naar ML-DSA (FIPS 204, gebaseerd op CRYSTALS-Dilithium) voor ondertekening van die certificaten geeft de hoogste winst per ingezette inspanning, omdat het een punt beschermt waar elke north-south en east-west verbinding doorheen loopt.
Sessie-handshakes bij identity providers en VPN-gateways
Identiteitsproviders zoals een interne OIDC-server of een SAML-endpoint genereren sessietokens die via een sleuteluitwisseling worden beveiligd. Dezelfde logica geldt voor VPN-gateways die een zero-trust-netwerktoegangslaag (ZTNA) implementeren. Dit zijn de punten waar IETF draft-ietf-uta-pqc-app concrete toepassingsrichtlijnen geeft voor het invoeren van PQC in TLS en vergelijkbare protocollen.
Identiteitscertificaten voor workload-identiteiten
In containeromgevingen (Kubernetes, Docker Swarm) krijgt elke workload een kortstondig certificaat dat haar identiteit bewijst. Als die certificaten nog met RSA-2048 zijn ondertekend, biedt het zero-trust-model geen kwantumveilige garantie voor de bron van uitvoerbare code.
ML-KEM (FIPS 203) integreren in TLS 1.3 voor soevereine netwerken
ML-KEM, gestandaardiseerd als FIPS 203 door NIST in augustus 2024, is een key encapsulation mechanism gebaseerd op CRYSTALS-Kyber. Het vervangt de Diffie-Hellman-gebaseerde sleuteluitwisseling in TLS 1.3-handshakes.
In de praktijk verloopt de integratie via een named group extension in TLS 1.3. De client kondigt ondersteuning voor de ML-KEM-groep aan; de server antwoordt met een ingekapselde sleutel. Beide partijen leiden hieruit een gedeeld geheim af zonder dat de privésleutel ooit over het netwerk reist. Cloudflare implementeerde dit eerder als X25519Kyber768, een hybride combinatie, en rapporteerde dat meer dan twintig procent van het TLS 1.3-verkeer via haar netwerk al gebruik maakte van dit schema (Cloudflare Blog, 2023). Cloudflare biedt dit ook aan als onderdeel van haar Quantum-Safe Zero Trust-product voor zakelijke klanten.
Voor soevereine organisaties die eigen infrastructuur beheren, bijvoorbeeld een on-premise Nextcloud-omgeving of een Zwitserse gehoste Kubernetes-cluster, vereist dit een bijgewerkte versie van de TLS-bibliotheek (OpenSSL 3.x met liboqs-integratie, of BoringSSL) en een PKI die ML-DSA-certificaten kan uitreiken.
Hybride sleuteluitwisseling en dubbele certificaten in de transitieperiode
Tijdens de overgangsperiode, waarin niet alle systemen tegelijk kunnen worden gemigreerd, biedt hybride cryptografie de meest risicoarme aanpak.
| Aanpak | Algoritmen | Beveiliging bij kwantumdreiging | Achterwaartse compatibiliteit |
|---|---|---|---|
| Klassiek | X25519 + RSA/ECDSA | Kwetsbaar | Volledig |
| Hybride | X25519 + ML-KEM (CRYSTALS-Kyber) | Veilig zolang één algoritme intact is | Hoog (met nieuwere TLS-stacks) |
| Volledig PQC | ML-KEM + ML-DSA | Volledig kwantumveilig | Beperkt, vereist volledige migratie |
Dubbele certificaten, waarbij een server zowel een klassiek ECDSA-certificaat als een ML-DSA-certificaat presenteert, maken het mogelijk dat oudere clients via de klassieke verbinding communiceren terwijl nieuwe clients direct kwantumveilig verbinden. Dit verdubbelt beheerslast, maar is de enige manier om een gefaseerde uitrol te ondersteunen zonder downtime of toegankelijkheidsverlies.
PQC-integriteit van containerimages, workload-identiteiten en beleidsartefacten
Een soevereine zero-trust-omgeving beperkt zich niet tot netwerkverkeer. De integriteit van de software zelf, de identiteiten van processen en de beleidsbestanden die toegangsregels vastleggen, moeten allemaal kwantumveilig zijn geborgd.
Voor containerimages betekent dit: ondertekening via ML-DSA (FIPS 204) als aanvulling op of vervanging van de huidige Cosign/Notary-workflow die RSA of ECDSA gebruikt. De handtekening wordt geverifieerd door de admission controller van het orkestratieplatform voordat een image wordt gestart. Zo wordt alleen kwantumveilig geverifieerde software toegelaten in de cluster.
Beleidsartefacten, zoals Open Policy Agent (OPA)-bundles of Kubernetes RBAC-manifests, kunnen worden ondertekend met ML-DSA en via een versleuteld kanaal (ML-KEM in TLS 1.3) naar de beleidsmotor worden gedistribueerd. De gehele keten van beleid tot uitvoering is dan kwantumveilig, wat essentieel is voor organisaties die gevoelige besluitvorming automatiseren, bijvoorbeeld in de rechtspraak of de financiële sector.
NIS-2 en DORA: aanvullende eisen aan PQC-gereedheid
Beide Europese regelgevingskaders verplichten technische maatregelen op het gebied van cryptografie, maar formuleren die eisen functioneel in plaats van algoritmisch specifiek.
NIS-2 (Richtlijn EU 2022/2555, van kracht per oktober 2024) verplicht aanbieders van essentiële en belangrijke diensten tot passende technische en organisatorische maatregelen, waaronder cryptografisch beschermde netwerken en systemen. De bevoegde nationale autoriteiten, in Nederland de AIVD en het NCSC, kunnen in technische richtsnoeren expliciet PQC-gereedheid eisen. De ENISA PQC Roadmap, opgesteld met de NIS Cooperation Group, dient als referentiedocument voor toezichthouders bij de invulling van die richtsnoeren.
DORA (Verordening EU 2022/2554, van toepassing per januari 2025) richt zich specifiek op financiële entiteiten en vereist dat ICT-risicobeheer, inclusief encryptie, periodiek wordt getoetst aan actuele dreigingen. De Europese toezichthoudende autoriteiten (ESA’s) kunnen technische uitvoeringsnormen (RTS) uitvaardigen die PQC-geschiktheid als meetcriterium opnemen. Financiële organisaties die reeds een zero-trust-roadmap uitvoeren, doen er verstandig aan PQC-gereedheid als expliciet criterium op te nemen in hun jaarlijkse ICT-risicobeoordelingen.
| Regelgeving | Doelgroep | Relevante PQC-eis | Handhavingsorgaan (NL) |
|---|---|---|---|
| NIS-2 (EU 2022/2555) | Essentiële en belangrijke diensten | Passende cryptografische bescherming, PQC in ENISA-richtsnoeren | NCSC / AIVD |
| DORA (EU 2022/2554) | Financiële entiteiten | Periodieke toetsing encryptie aan actuele dreigingen, RTS door ESA’s | DNB / AFM |
Praktische prioritering voor soevereine organisaties
Een soevereine organisatie die weg beweegt van publieke cloud naar on-premise of Zwitserse gehoste infrastructuur, staat voor een dubbele migratie: van Big Tech-afhankelijkheid én van klassieke naar post-kwantumcryptografie. De meest effectieve volgorde is: begin met de identiteitslaag (PKI, certificaatuitgifte via een eigen Certificate Authority die ML-DSA ondersteunt), migreer daarna de TLS-handshakes in de service mesh naar hybride sleuteluitwisseling, en implementeer ten slotte kwantumveilige ondertekening van containerimages en beleidsartefacten.
IETF draft-ietf-uta-pqc-app biedt daarvoor protocol-specifieke richtlijnen die aansluiten op bestaande TLS 1.3-implementaties, en vormt de technische onderbouwing voor de stap van CRYSTALS-Kyber (de eerdere naam) naar de genormeerde ML-KEM in FIPS 203, en van CRYSTALS-Dilithium naar ML-DSA in FIPS 204.
FAQ: PQC zero trust integratie
Vervangt post-kwantumcryptografie mijn bestaande zero-trust-architectuur?
Nee. PQC vervangt het zero-trust-model niet; het versterkt de cryptografische grondslag ervan. Zero trust regelt wie toegang krijgt en hoe dat continu wordt geverifieerd. PQC zorgt ervoor dat de versleuteling van die verificatie bestand blijft tegen kwantumcomputers.
Wat is hybride sleuteluitwisseling en waarom is het nodig tijdens de transitie?
Hybride sleuteluitwisseling combineert een klassiek algoritme zoals X25519 met een post-kwantum algoritme zoals ML-KEM in één handshake. Zo blijft de sessie beveiligd zolang ten minste één van beide algoritmen niet gebroken is, wat de overgangsperiode overbrugt totdat alle systemen volledig zijn gemigreerd.
Welke integratiepunten verdienen de hoogste prioriteit voor PQC-migratie?
mTLS-verbindingen tussen services, sessie-handshakes bij identity providers en VPN-gateways, en de certificaten waarmee workload-identiteiten worden vastgesteld. Dit zijn de punten met het grootste risico op “harvest now, decrypt later”-aanvallen, omdat het verkeer dat daar doorheen gaat nu al kan worden vastgelegd voor latere ontsleuteling.
Wat eisen NIS-2 en DORA concreet op het gebied van PQC?
NIS-2 verplicht passende technische maatregelen voor cryptografische bescherming, waarbij ENISA-richtsnoeren PQC steeds expliciet meenemen. DORA vereist dat financiële entiteiten hun encryptie periodiek toetsen aan actuele dreigingen. Beide kaders laten ruimte voor toezichthouders om PQC-gereedheid op te nemen in technische uitvoeringsnormen.
Hoe borgt een organisatie de PQC-integriteit van containerimages?
Door containerimages te ondertekenen met ML-DSA (FIPS 204) en de signatuurverificatie op te nemen in de admission-controlestap van het container-orkestratieplatform. Zo wordt alleen software toegelaten waarvan de herkomst kwantumveilig is geverifieerd, waarmee de gehele softwaretoeleveringsketen binnen de zero-trust-garanties valt.
