Kort: De uitrol van kwantumveilige digitale handtekeningen in certificaatketens stuit op hardnekkige technische en organisatorische blokkades. Dit artikel beschrijft concrete mitigatiestrategieën, sectordeadlines en operationele stappen voor een productie-implementatie.

Post-kwantum authenticatie productie-implementatie is het proces waarbij organisaties hun digitale handtekeningen, certificaatketens en PKI-infrastructuur vervangen door kwantumveilige algoritmen, zodat die bestand blijven tegen aanvallen door toekomstige kwantumcomputers. Dit onderscheidt zich van kwantumveilige sleuteluitwisseling, die al verder is uitgerold, en vereist een gelijktijdige migratie van alle lagen in een certificaathiërarchie.

Waarom authenticatiemigratie achterloopt op sleuteluitwisseling

Kwantumveilige sleuteluitwisseling vervangt één onderdeel van het TLS-handshake. Kwantumveilige authenticatie vereist dat het volledige vertrouwensmodel opnieuw wordt ingericht.

De asymmetrie is structureel. Algoritmen zoals ML-KEM (voor sleuteluitwisseling) kunnen worden ingezet in een hybride modus naast ECDH, zonder dat browsers, root-CA’s of eindcertificaten worden gewijzigd. Digitale handtekeningen in certificaatketens werken anders: een eindcertificaat wordt ondertekend door een intermediaire CA, die op zijn beurt wordt ondertekend door een root-CA. Als de root niet wordt bijgewerkt, helpt het niet om alleen het eindcertificaat te vervangen. Die coördinatie tussen certificaatautoriteiten, besturingssysteemfabrikanten, browsers en tienduizenden afnemers kost meerdere jaren.

Een tweede structureel probleem is de omvang van handtekeningen. ECDSA P-256 produceert handtekeningen van 71 bytes. ML-DSA op niveau 3 (FIPS 204) produceert handtekeningen van circa 3.293 bytes. SLH-DSA op het hoogste beveiligingsniveau (FIPS 205) loopt op tot circa 49.856 bytes per handtekening. Die omvang telt niet één keer, maar voor elke schakel in de certificaatketen afzonderlijk.

Let op: De “harvest now, decrypt later”-dreiging maakt sleuteluitwisseling urgent, maar raakt authenticatie indirect. Aanvallers die ondertekende documenten of authenticatietokens van nu bewaren, kunnen de integriteit ervan aanvechten zodra ze een kwantumcomputer hebben. Voor advocatenkantoren en overheden met langetermijnarchivering is dit een reëel risico.

Technische knelpunten bij ML-DSA en SLH-DSA in productie

De knelpunten zijn concreet en hangen samen met drie lagen: de TLS-stack, VPN-gateways en e-mailinfrastructuur.

TLS-verbindingen

In een standaard TLS 1.3-handshake worden doorgaans twee of drie certificaten uitgewisseld. Met ML-DSA op niveau 3 groeit dat totaal van een paar kilobyte naar ruim tien kilobyte. Op verbindingen met hoge latentie of pakketfragmentatie leidt dit tot meetbare vertragingen en verhoogde foutgevoeligheid bij UDP-gebaseerde varianten zoals QUIC. Certificaatvalidatie vereist bovendien dat alle intermediaire CA’s in de keten al PQC-handtekeningen dragen, wat bij de meeste commerciële CA’s nog niet het geval is.

VPN-gateways

IKEv2-implementaties in hardwarematige VPN-gateways zijn vaak gebonden aan de firmware van de fabrikant. Veel apparaten ondersteunen ML-DSA nog niet, of vereisen een firmwareupdate die niet beschikbaar is voor modellen ouder dan drie jaar. Organisaties die on-premise infrastructuur beheren, inclusief soevereine Nextcloud-omgevingen met VPN-toegang, stuiten hier het eerst op: het is niet voldoende om de serverzijde te upgraden als de clientzijde van de tunnel de nieuwe handtekeningen niet herkent.

E-mailinfrastructuur

S/MIME en PGP zijn beide afhankelijk van certificaten en sleutelparen. RFC 9958 (Post-Quantum Cryptography for Engineers, IETF juni 2026) beschrijft de aanbevolen migratievolgorde: eerst sleuteluitwisseling, dan handtekeningen, met composiet-sleutelparen als tussenoplossing. Veel e-mailclients ondersteunen echter geen certificaten groter dan een bepaalde drempel, en de S/MIME-standaard schrijft geen minimale ondersteuning voor PQC voor. Dat maakt e-mail op dit moment de meest kwetsbare authenticatielaag voor organisaties die soevereine communicatie willen garanderen.

Handshake-overhead en mitigatiestrategieën

De overhead is meetbaar en vergt actieve mitigatie. Twee strategieën zijn in productieomgevingen het meest realistisch inzetbaar.

Strategie Werking Geschikt voor Beperking
Composiet-handtekeningen Één certificaat draagt zowel een klassieke als een PQC-handtekening. Legacy-systemen gebruiken de klassieke handtekening, kwantumveilige systemen de PQC-handtekening. TLS, VPN, PKI-overgangsperiode Vergroot certificaatformaat verder; beide algoritmen moeten worden bijgehouden.
Merkle Tree Certificates (MTC) Certificaatbinding via een geaggregeerde Merkle-boomstructuur; individuele certificaten bevatten geen volledige handtekeningketen. Grootschalige webpki, CDN-omgevingen Vereist aanpassingen aan CA-infrastructuur en validatieprotocollen; nog niet breed geïmplementeerd.

Composiet-handtekeningen zijn beschreven in lopende IETF-drafts en zijn de meest pragmatische tussenoplossing voor organisaties die nu al beginnen. Merkle Tree Certificates bieden structureel lagere overhead maar zijn afhankelijk van bredere ecosysteemondersteuning, die nog enkele jaren op zich laat wachten.

Bevindingen van de IAB PQC Authentication Workshop, Praag 2026

De IAB Post-Quantum Authentication Workshop (oktober 2026, Praag) bracht technische experts samen om de specifieke blokkades bij authenticatiemigratie te inventariseren en prioriteren.

De Internet Architecture Board stelde vast: “The challenge with post-quantum signatures is not just size, it is the entire ecosystem of certificate validation, revocation and path building that has to change simultaneously.” Deze observatie heeft directe gevolgen voor organisaties die nu al migreren naar soevereine infrastructuur: een on-premise PKI die overgaat op ML-DSA, heeft op korte termijn alleen voordeel als de vertrouwensketen van buiten (zoals een externe root-CA of een koppeling met een overheidsPKI) ook PQC-compatibel is.

De workshop identificeerde drie prioriteiten: ten eerste het standaardiseren van composiet-certificaatprofielen voor de overgangsperiode; ten tweede het vaststellen van interoperabiliteitseisen voor TLS-implementaties die ML-DSA ondersteunen; en ten derde het aanpakken van de OCSP- en CRL-validatieoverhead, die bij PQC-handtekeningen proportioneel zwaarder drukt op netwerkbandbreedte.

Operationele implementatie van RFC 9881 en RFC 9909 in bestaande PKI

RFC 9881 (ML-DSA in X.509) en RFC 9909 (SLH-DSA in X.509) bieden het technische kader om PQC-handtekeningen in bestaande certificaatinfrastructuur op te nemen zonder volledige vervanging.

De kern van de aanpak is het gebruik van de OID-structuren die beide RFC’s definiëren, in combinatie met composiet-extensies. Concreet betekent dit voor een organisatie die een interne PKI beheert:

  • De root-CA wordt uitgebreid met een parallelle ML-DSA-sleutel, vastgelegd conform RFC 9881. De bestaande root blijft actief voor legacy-systemen.
  • Intermediaire CA’s worden opnieuw uitgegeven met composiet-sleutelparen. Beide handtekeningen (klassiek en PQC) zijn aanwezig in hetzelfde certificaat.
  • Eindcertificaten voor servers en gebruikers worden uitgegeven met ML-DSA als primaire handtekening, met de klassieke handtekening als fallback.
  • Revocatie-infrastructuur (OCSP-responders) moet worden bijgewerkt om PQC-handtekeningen in OCSP-responses te genereren, anders ontstaat een kwetsbaar gat in de keten.
Let op: RFC 9958 (Post-Quantum Cryptography for Engineers, IETF juni 2026) bevat een praktische migratievolgorde en benoemt expliciet de risico’s van gedeeltelijke implementatie. Een PKI die alleen eindcertificaten vervangt zonder de revocatielaag bij te werken, biedt geen aantoonbaar hogere beveiliging en kan toezichthouders niet overtuigen van NIS-2-compliance.

Sectorspecifieke deadlines en risicoprofielen

ENISA stelt: “Harvest now, decrypt later attacks are already occurring; organizations that postpone PQC migration are accepting a known, measurable risk.” Die uitspraak heeft voor drie sectoren directe operationele consequenties.

Sector Regulatoire basis PQC-relevante deadline Belangrijkste risico
Overheid NIS-2 (EU 2022/2555), nationale implementatiewetten NIS-2-implementatieplicht actief; geen harde PQC-datum, wel aantoonbare cryptografische risicobeheerplicht Onderschept overheidsverkeer dat over tien jaar ontsleutelbaar is
Advocatenkantoren GDPR (AVG), beroepsgeheimplicht, NIS-2 als verwerker van essentiële sectoren Geen harde sectordeadline; toezichthouders verwachten aantoonbare maatregelen Vertrouwelijkheid van cliëntcommunicatie op lange termijn
Financiële instellingen DORA (EU 2022/2554), EBA-richtsnoeren ICT-risico, NIS-2 DORA volledig van kracht per januari 2025; EBA verwacht crypto-inventarisatie in ICT-risicorapportages Integriteit van transactiehandtekeningen en authenticatietokens

Voor overheden die soevereine on-premise of Zwitserse cloudinfrastructuur gebruiken, geldt een extra overweging: het is niet voldoende om dataopslag jurisdictioneel te beveiligen. Als authenticatieverkeer via klassieke cryptografie loopt, is de soevereine opslagoplossing kwetsbaar via de transportlaag. Post-kwantum authenticatie en soevereine infrastructuur zijn complementaire, niet inwisselbare maatregelen.

FAQ: post-kwantum authenticatie productie-implementatie

Waarom kunnen organisaties al beginnen met PQC-sleuteluitwisseling maar nog niet volledig met PQC-authenticatie?

Sleuteluitwisseling (zoals ML-KEM) vervangt één punt in het TLS-handshake. Authenticatie vereist dat alle lagen van de certificaatketen tegelijk worden vervangen. Die coördinatie tussen browsers, besturingssystemen, CA’s en eindgebruikersystemen kost meerdere jaren.

Wat is het praktische verschil tussen ML-DSA (FIPS 204) en SLH-DSA (FIPS 205)?

ML-DSA is sneller en produceert kleinere handtekeningen, maar is gebaseerd op roosterwiskunde met een kortere staat van dienst. SLH-DSA levert handtekeningen tot bijna 50 kilobyte, wat het ongeschikt maakt voor latentiegevoelige TLS-verbindingen. De meeste productie-implementaties kiezen ML-DSA voor TLS en VPN, en bewaren SLH-DSA voor langetermijnarchivering en code signing.

Wat schrijven RFC 9881 en RFC 9909 voor over implementatie in bestaande PKI?

RFC 9881 specificeert de OID’s en codering voor ML-DSA in X.509-certificaten. RFC 9909 doet hetzelfde voor SLH-DSA. Beide RFC’s ondersteunen composiet-certificaten, waarbij één certificaat zowel een klassieke als een PQC-handtekening draagt, zodat legacy-systemen blijven functioneren.

Welke sectoren hebben de strengste urgentie voor PQC-authenticatiemigratie?

Overheidsinstellingen en financiële instellingen hebben de hoogste urgentie vanwege NIS-2, DORA en de langetermijn-vertrouwelijkheidseisen van hun gegevens. Advocatenkantoren volgen vanwege de combinatie van beroepsgeheim en GDPR-verplichtingen. Voor alle drie sectoren geldt dat een crypto-inventarisatie de eerste verplichte stap is.

Wat is de “harvest now, decrypt later”-dreiging en hoe beïnvloedt die de migratieurgentie?

Aanvallers slaan versleuteld verkeer nu op en ontsleutelen het zodra een kwantumcomputer beschikbaar is. Voor organisaties met geheimhouding op langere termijn, zoals overheden en advocatenkantoren, betekent dit dat verkeer van vandaag over tien jaar leesbaar kan zijn. Wie data op soevereine infrastructuur beheert maar PQC-migratie uitstelt, beschermt de opslaglocatie maar niet de vertrouwelijkheid van het transport.

Veelgestelde vragen

Waarom kunnen organisaties al beginnen met PQC-sleuteluitwisseling maar nog niet volledig met PQC-authenticatie?
Sleuteluitwisseling (zoals ML-KEM) vervangt u00e9u00e9n punt in het TLS-handshake. Authenticatie vereist dat alle lagen van de certificaatketen, inclusief root-CA's, intermediaire CA's en eindcertificaten, tegelijk worden vervangen. Die cou00f6rdinatie tussen browsers, besturingssystemen, CA's en eindgebruikersystemen kost meerdere jaren.
Wat is het praktische verschil tussen ML-DSA (FIPS 204) en SLH-DSA (FIPS 205) bij een productie-implementatie?
ML-DSA is sneller en produceert kleinere handtekeningen dan SLH-DSA, maar is gebaseerd op roosterwiskunde die minder lange staat-van-dienst heeft. SLH-DSA is gebaseerd op hash-functies met een sterker bewijs van veiligheid, maar levert handtekeningen tot bijna 50 kilobyte, wat het ongeschikt maakt voor latentiegevoelige TLS-verbindingen. De meeste productie-implementaties kiezen ML-DSA voor TLS en VPN, en bewaren SLH-DSA voor langetermijnarchivering en code signing.
Wat schrijven RFC 9881 en RFC 9909 voor over het opnemen van PQC-handtekeningen in bestaande PKI-omgevingen?
RFC 9881 specificeert de OID's en codering voor ML-DSA in X.509-certificaten. RFC 9909 doet hetzelfde voor SLH-DSA. Beide RFC's zijn ontworpen zodat organisaties composiet-certificaten kunnen inzetten: u00e9u00e9n certificaat draagt zowel een klassieke als een PQC-handtekening, zodat legacy-systemen blijven functioneren terwijl kwantumveilige systemen de nieuwe sleutel gebruiken.
Welke sectoren hebben de strengste deadlines voor PQC-authenticatiemigratie?
Overheidsinstellingen in de VS zijn op grond van NSM-10 verplicht om vu00f3u00f3r 2035 te migreren. In Europa stelt de NIS-2-richtlijn (EU 2022/2555) dat essentiu00eble entiteiten aantoonbaar risicobeheermaatregelen treffen voor cryptografie, zonder harde PQC-datum. De Europese Centrale Bank en de EBA publiceren richtsnoeren die financiu00eble instellingen aanmoedigen om nu inventarisaties te starten. Advocatenkantoren vallen onder GDPR en NIS-2 als ze gegevens van essentiu00eble sectoren verwerken.
Wat is de 'harvest now, decrypt later'-dreiging en hoe beu00efnvloedt die de migratieurgentie voor soevereine infrastructuur?
Aanvallers slaan versleuteld verkeer nu op en ontsleutelen het zodra een kwantumcomputer beschikbaar is. Voor organisaties met geheimhouding op langere termijn, zoals overheden en advocatenkantoren, betekent dit dat verkeer dat vandaag wordt onderschept over tien jaar leesbaar kan zijn. Wie data op soevereine infrastructuur beheert maar PQC-migratie uitstelt, beschermt de opslaglocatie maar niet de vertrouwelijkheid van het transport.