Post-kwantum authenticatie omvat de cryptografische mechanismen waarmee digitale identiteiten worden vastgesteld en handtekeningen worden geverifieerd op een manier die bestand is tegen aanvallen door kwantumcomputers. Voor compliance officers en IT-beslissers in overheidsinstellingen, de juridische sector en gereguleerde branches is dit geen toekomstig vraagstuk meer: de standaarden zijn vastgesteld, de migratiedruk neemt toe, en het achterliggende risico van onveilige authenticatieketens is structureel anders dan dat van versleuteling.
Waarom authenticatie achterblijft op sleuteluitwisseling
De migratie naar post-kwantumcryptografie (PQC) verloopt ongelijk: sleuteluitwisseling is al ver gevorderd, maar de migratie van authenticatie en digitale handtekeningen loopt achter. Dit heeft concrete, technische oorzaken.
Bij sleuteluitwisseling geldt het principe van “harvest now, decrypt later”: een aanvaller die nu versleuteld verkeer opslaat, kan dit later ontsleutelen zodra een krachtige kwantumcomputer beschikbaar is. Dit urgentie-argument heeft ertoe geleid dat TLS 1.3 met hybride sleuteluitwisseling (X25519 gecombineerd met ML-KEM, voorheen Kyber) relatief snel is ingevoerd. Cloudflare rapporteerde in 2024 dat meer dan 20% van het TLS-verkeer via hun netwerk al gebruikmaakt van post-kwantum sleuteluitwisseling.
Authenticatie kent een ander dreigingsmodel. Een aanvaller kan nu geen valse handtekening aanmaken met een klassieke computer; het risico materialiseert zich pas wanneer een kwantumcomputer operationeel is. Dat heeft de politieke en organisatorische urgentie verlaagd, terwijl de technische complexiteit juist hoger is. Handtekeningen zitten ingebakken in PKI-certificaten, identity tokens, firmware, softwarepakketten en juridisch bindende documenten. Elk van deze lagen vereist een aparte migratieaanpak.
Bas Westerbaan, cryptograaf bij Cloudflare, verwoordde dit als volgt: “Authentication is the harder problem. Key exchange has a relatively clean migration path, but signatures touch every layer of the stack, from firmware to identity federation.”
Kwetsbare protocollen: SAML, OpenID Connect, S/MIME en code signing
De meest kritieke kwetsbaarheid bevindt zich in protocollen waarbij RSA of ECDSA-handtekeningen de kern vormen van vertrouwen en identiteitsoverdracht.
SAML en OpenID Connect zijn de dominante standaarden voor federatieve identiteitsverificatie in bedrijfs- en overheidsomgevingen. SAML-assertions worden ondertekend door de identity provider; een vervalste handtekening zou een aanvaller in staat stellen willekeurige identiteitsclaims te injecteren. OpenID Connect ID-tokens zijn JWT’s (JSON Web Tokens) die standaard worden ondertekend met RS256 (RSA) of ES256 (ECDSA). Geen van beide is in de huidige implementaties kwantumbestendig.
S/MIME voor e-mailbeveiliging en code signing (het ondertekenen van softwarepakketten, drivers en firmware) zijn eveneens volledig afhankelijk van klassieke handtekeningalgoritmen. Code signing is bijzonder kritisch: een aanvaller die in de toekomst valse handtekeningen kan genereren voor historische softwareversies, ondermijnt de gehele software supply chain met terugwerkende kracht.
| Protocol of systeem | Huidig algoritme | Kwantumrisico | Migratieprioriteit |
|---|---|---|---|
| SAML 2.0 | RSA-SHA256, ECDSA | Hoog (identiteitsovername) | Hoog |
| OpenID Connect / OAuth 2.0 | RS256, ES256 | Hoog (token-vervalsing) | Hoog |
| S/MIME e-mail | RSA, ECDSA | Middel (non-repudiation) | Middel |
| Code signing (Authenticode, RPM, APT) | RSA, ECDSA | Hoog (supply chain) | Hoog |
| TLS-servercertificaten | RSA, ECDSA | Middel (sleuteluitwisseling al gemigreerd) | Middel |
ML-DSA en SLH-DSA integreren in IAM en PKI
NIST publiceerde in augustus 2024 de definitieve standaarden FIPS 204 (ML-DSA, gebaseerd op CRYSTALS-Dilithium) en FIPS 205 (SLH-DSA, gebaseerd op SPHINCS+). Beide standaarden zijn beschikbaar voor directe implementatie, maar de integratie in bestaande IAM- en PKI-infrastructuur vereist zorgvuldige stapsgewijze aanpak.
Het NIST NCCoE formuleert het migratievraagstuk helder: “The challenge is not just picking the right algorithm. It is understanding which certificates, tokens, and trust anchors in your environment are signed with RSA or ECDSA, and replacing them without breaking existing authentication chains.”
Een praktische migratiestrategie verloopt in drie fasen:
Fase 1: Cryptografische inventarisatie. Breng in kaart welke systemen RSA of ECDSA-handtekeningen genereren of consumeren. Dit omvat PKI-hiërarchieën, SAML-identity providers (zoals Microsoft ADFS, Keycloak of Shibboleth), OAuth-autorisatieservers, certificaatautoriteiten en code-signing pipelines. Het NIST NCCoE Migration to PQC-project biedt hiervoor gestructureerde methoden en testomgevingen.
Fase 2: Hybride handtekeningen. Introduceer PQC-algoritmen naast de bestaande klassieke algoritmen. Een hybride X.509-certificaat bevat zowel een ECDSA- als een ML-DSA-handtekening. Systemen die PQC nog niet begrijpen, vallen terug op de klassieke handtekening; systemen die PQC wel ondersteunen, valideren beide. Dit voorkomt dat de migratie de bestaande vertrouwensketen verbreekt.
Fase 3: Volledige migratie. Zodra alle componenten PQC ondersteunen, worden de klassieke handtekeningen verwijderd. Dit is het moment waarop root-CA’s worden vervangen, identity providers worden bijgewerkt en langlopende certificaten worden ingetrokken en heruitgegeven.
Inzichten uit de IETF SPIQE-workshop en de IAB-werkgroep
De IETF SPIQE-workshop (Signatures and Post-quantum Internet infrastructure for QUIC and Extensions), gepland voor 2026, en de IAB Post-Quantum Authentication Working Group richten zich specifiek op de deploymentknelpunten die de praktijk van PQC-authenticatie belemmeren.
Uit de voorbereidende documenten van de IAB komen drie structurele knelpunten naar voren. Ten eerste is er het vertrouwensankerprobleem: browsers, besturingssystemen en enterprise-clients bevatten harde lijsten van vertrouwde root-CA’s. Het bijwerken van deze lijsten vereist gecoördineerde acties van certificaatautoriteiten, browserleveranciers en OS-fabrikanten, een proces dat jaren duurt. Ten tweede zijn er de beperkingen van protocollen: sommige protocollen, waaronder oudere versies van SAML, kennen harde beperkingen op berichtgrootte of gebruiken formaten die geen algoritmische flexibiliteit bieden. Ten derde is er de afhankelijkheid van hardware-security modules (HSM’s): veel organisaties slaan privésleutels op in HSM’s die nog geen PQC-algoritmen ondersteunen. Firmware-updates of hardwarevervanging zijn dan vereist voor de migratie van signing-sleutels.
De werkgroep benadrukt verder dat het ontbreken van gestandaardiseerde PQC-profielen voor veelgebruikte federatiestandaarden (SAML, OpenID Connect) een praktische belemmering vormt. Interoperabiliteitstesten tussen verschillende implementaties zijn nog beperkt beschikbaar.
Aanpak van Cloudflare, Google en Microsoft: lessen voor soevereine omgevingen
Grote techplatforms volgen elk een eigen tempo en strategie voor PQC-authenticatieuitrol, en hun keuzes beïnvloeden indirect ook on-premise en soevereine omgevingen die met hun diensten communiceren.
Cloudflare heeft ML-DSA opgenomen in hun interne certificaatinfrastructuur en experimenteert met PQC-handtekeningen in QUIC-verbindingen. Hun aanpak is hybride: klassieke en PQC-handtekeningen worden parallel ingezet tot het ecosysteem gereed is. Google voert vergelijkbare experimenten uit in Chrome en hun interne PKI, met nadruk op het testen van groottes en latentie-effecten. Microsoft heeft aangekondigd de Azure Active Directory (nu Entra ID) identity stack voor te bereiden op PQC, maar concrete uitroldata voor PQC-token-signing zijn nog niet bevestigd.
Voor organisaties die juist bewust afstand nemen van publieke cloudplatforms en kiezen voor on-premise soevereine omgevingen, zijn de volgende lessen relevant:
Soevereine omgevingen hebben een voordeel in controle: zij hoeven niet te wachten op de releasecyclus van Microsoft of Google en kunnen hun eigen PKI en identity provider (bijvoorbeeld Keycloak of een zelfbeheerde ADFS-opvolger) direct bijwerken zodra PQC-ondersteuning beschikbaar is in de onderliggende bibliotheken (zoals OpenSSL 3.x, Bouncy Castle of liboqs). Het nadeel is dat de migratielast volledig intern valt en dat interoperabiliteit met externe partijen die nog klassieke handtekeningen gebruiken tijdelijk complex wordt.
Organisaties die migreren van Microsoft 365 naar een soevereine Nextcloud-omgeving doen er goed aan de identiteitslaag (SAML/OIDC-koppeling) vroegtijdig te evalueren op PQC-gereedheid van de gekozen identity provider. Een hybride handtekeningketen is op dit moment de meest stabiele transitieroute.
Aanbevelingen voor compliance en beleid
NIS-2 (Richtlijn EU 2022/2555) verplicht essentiële en belangrijke entiteiten tot passende cryptografische beveiligingsmaatregelen. ENISA heeft in haar richtlijnen voor cryptografisch beleid aangegeven dat organisaties nu moeten starten met de inventarisatie van kwetsbare cryptografie, ook al is de directe kwantumdreiging nog niet actueel. Onder de AVG (GDPR) zijn handtekeningen en authenticatie onderdeel van de technische en organisatorische maatregelen die verwerkingsverantwoordelijken moeten treffen.
Concrete stappen voor compliance officers:
- Voer een cryptografische inventarisatie uit conform de methodiek van het NIST NCCoE Migration to PQC-project.
- Stel een migratieplan op dat onderscheid maakt tussen kortetermijnacties (inventarisatie, HSM-beoordeling) en langetermijnacties (CA-vervanging, protocol-updates).
- Vereis van leveranciers en identity providers een schriftelijke roadmap voor PQC-ondersteuning, inclusief FIPS 204 en FIPS 205.
- Betrek juridische en archiefafdelingen bij de migratie van S/MIME en documenthandtekeningen, omdat langetermijn-geldigheid van handtekeningen een aparte standaardisatievraag is (zie ETSI ESI-standaarden voor gekwalificeerde handtekeningen).
FAQ: Post-kwantum authenticatie voor organisaties
Wat is het verschil tussen ML-DSA en SLH-DSA en welke kies ik?
ML-DSA (FIPS 204, gebaseerd op CRYSTALS-Dilithium) gebruikt roostergebaseerde wiskunde en biedt kortere handtekeninggroottes met snellere verificatie, geschikt voor hoge-doorvoer IAM-omgevingen. SLH-DSA (FIPS 205, gebaseerd op SPHINCS+) is hashgebaseerd en wordt beschouwd als conservatiever qua veiligheidsaannames, wat het aantrekkelijk maakt voor langetermijnarchivering en code signing waar grootte minder kritisch is.
Zijn SAML en OpenID Connect al kwantumbestendig?
Nee. SAML-assertions en OpenID Connect ID-tokens worden ondertekend met RSA of ECDSA, beide kwetsbaar voor een voldoende krachtige kwantumcomputer. De protocollen zelf zijn niet inherent onveilig, maar de onderliggende handtekeningalgoritmen moeten worden vervangen. Dat vereist aanpassingen in identity providers, vertrouwensketens en token-validatielogica.
Wat betekent “harvest now, decrypt later” voor digitale handtekeningen?
Bij versleuteling slaat een aanvaller nu versleuteld verkeer op om dit later te ontsleutelen. Bij digitale handtekeningen is het risico anders: een aanvaller kan in de toekomst valse handtekeningen aanmaken die geldig lijken voor documenten of code. Dit ondermijnt niet-weerlegbaarheid en authenticiteit, ook voor historische transacties en archiefstukken.
Hoe verhoudt NIS-2 zich tot de verplichting om PQC te implementeren?
NIS-2 verplicht organisaties in essentiële en belangrijke sectoren tot passende technische beveiligingsmaatregelen, waaronder cryptografisch beleid. Hoewel NIS-2 geen specifiek algoritme voorschrijft, geldt het gebruik van als verouderd beschouwde cryptografie bij een erkende kwantumdreiging als ontoereikende maatregel. ENISA raadt aan nu te beginnen met inventarisatie en migratieplanning.
Kan een on-premise soevereine omgeving sneller migreren dan een publieke cloudomgeving?
In principe wel. De organisatie heeft volledige controle over PKI, identity provider en sleutelopslag, zonder afhankelijkheid van de releasecyclus van externe cloudleveranciers. Een goed beheerde on-premise omgeving met een moderne IAM-stack zoals Keycloak kan ML-DSA sneller uitrollen zodra de bibliotheekondersteuning beschikbaar is. De migratielast valt dan wel volledig intern.
