Post-quantum in 2026: crypto-agility wordt enterprise-architectuur

Managementsamenvatting

Met RFC 10024 heeft de IETF in augustus 2026 drie hybride mechanismen voor post-quantum sleuteluitwisseling in TLS 1.3 gestandaardiseerd. Daarmee verschuift post-quantumcryptografie van vooral roadmap en experiment naar een concrete ontwerpkeuze. Het is nog geen eindpunt: authenticatie, certificaten, legacyprotocollen, hardware en clouddiensten hebben ieder een eigen migratiepad. De kernopgave is daarom crypto-agility: cryptografie kunnen inventariseren, prioriteren en vervangen zonder onnodige bedrijfsverstoring. Voor architecten raakt dit niet alleen Security Architecture, maar ook capability-eigenaarschap, oplossingscontracten, dataclassificatie, infrastructuurlevenscycli en cloudverantwoordelijkheden. De eerste stap is niet overal algoritmen vervangen, maar afhankelijkheden en beslisrechten zichtbaar maken.

Van algoritmevraag naar verandervermogen

Post-quantumcryptografie wordt vaak besproken alsof organisaties vooral moeten wachten op een voldoende krachtige quantumcomputer. Dat is een misleidend startpunt. De migratie is nu al relevant omdat cryptografie diep is verweven met applicaties, protocollen, certificaten, hardware, cloudservices en gegevens die nog jaren vertrouwelijk moeten blijven. De echte architectuurvraag is niet wanneer een quantumcomputer bestaande publieke-sleutelcryptografie kan breken, maar hoe snel de organisatie kan veranderen wanneer standaarden, risico’s of leveranciers dat vereisen.

In augustus 2026 publiceerde de Internet Engineering Task Force RFC 10024 als Proposed Standard. Deze standaard definieert drie hybride sleuteluitwisselingsmechanismen voor TLS 1.3 die ML-KEM combineren met traditionele ECDHE-sleuteluitwisseling [1]. RFC 9954 had een maand eerder het algemene constructieprincipe voor hybride sleuteluitwisseling beschreven [2]. Het nieuwe signaal is dus concreet: er is nu een gestandaardiseerde route om klassieke en post-quantum bescherming in dezelfde TLS-handshake te combineren.

Dat is vooruitgang, maar geen volledige oplossing. RFC 9954 gaat over tijdelijke sleuteluitwisseling en niet over post-quantum authenticatie [2]. Het Britse National Cyber Security Centre benoemde eerder ook open vraagstukken rond WebPKI, X.509-certificaten, secure boot, hardware roots of trust en industriële besturingssystemen [4]. De verwachting uit die NCSC-publicatie dat een exacte hybride TLS-methode pas later zou worden gestandaardiseerd, is voor deze specifieke sleuteluitwisseling door RFC 10024 ingehaald. De bredere afhankelijkheden blijven echter bestaan.

NIST plaatst daarom crypto-agility centraal: het vermogen om cryptografische algoritmen in protocollen, applicaties, software, hardware, firmware en infrastructuur te vervangen, terwijl beveiliging en bedrijfsvoering doorgaan [3]. Dat verandert de opdracht voor alle zes architectuurdisciplines.

1. Business Architecture: maak cryptografische continuïteit bestuurbaar

Voor Business Architecture begint de migratie niet bij een algoritmenlijst, maar bij bedrijfsdiensten en capabilities. Welke diensten verwerken gegevens die lang gevoelig blijven? Welke processen zijn afhankelijk van digitale handtekeningen, identiteitsbewijzen, versleutelde verbindingen of hardwaregebonden vertrouwensankers? En wie mag besluiten dat een dienst naar een nieuw cryptografisch profiel overgaat?

Het gezamenlijke Europol-rapport voor financiële instellingen adviseert om eerst alle business-use-cases te inventariseren die publieke-sleutelcryptografie gebruiken. De prioritering combineert vervolgens quantumrisico en migratietijd. Bij het risico kijkt het rapport naar de houdbaarheid van de beschermde gegevens, de blootstelling aan potentiële aanvallers en de ernst van mogelijke schade [5]. Hoewel het rapport sectorspecifiek is, is het onderliggende patroon breder bruikbaar: prioriteer niet op techniek alleen, maar op bedrijfswaarde, gegevenslevensduur en veranderbaarheid.

Ook tijdshorizonnen moeten bestuurlijk worden gemaakt. Het NCSC gebruikt 2028 als richtpunt voor discovery, assessment en een eerste migratieplan, 2031 voor de hoogste prioriteiten en 2035 voor voltooiing [4]. Dit zijn Britse richtsnoeren, geen Nederlandse of Europese wettelijke deadlines. Ze laten wel zien dat grote organisaties meerdere jaren nodig kunnen hebben voor inventarisatie, leveranciersafstemming en uitvoering.

Wat dit voor architecten betekent. Voeg cryptografische continuïteit toe aan capability- en risicomodellen. Leg per kritieke bedrijfsdienst een eigenaar, gewenste vertrouwelijkheidsduur, maximaal aanvaardbare migratieduur en belangrijke externe afhankelijkheden vast. Behandel crypto-agility als onderdeel van bedrijfscontinuïteit en investeringsplanning, niet uitsluitend als technisch securityproject.

2. Solution Architecture: ontwerp de overgang, niet alleen de doelstandaard

RFC 10024 maakt voor Solution Architecture een concrete ontwerpoptie beschikbaar. De standaard definieert X25519MLKEM768, SecP256r1MLKEM768 en SecP384r1MLKEM1024 als hybride groepen voor TLS 1.3 [1]. De kracht van de hybride aanpak is dat de verbinding beschermd blijft zolang ten minste één van de gecombineerde sleuteluitwisselingsmechanismen veilig blijft [1][2]. Daarmee kan een organisatie post-quantum bescherming introduceren zonder de klassieke component direct los te laten.

Maar hybride betekent ook meer ontwerpcomplexiteit. RFC 10024 specificeert grotere key-exchange-berichten dan bij alleen de traditionele componenten en stelt aanvullende controles aan sleutels, ciphertextlengtes en foutafhandeling [1]. RFC 9954 waarschuwt bovendien dat grotere berichten, berekeningen en protocolkeuzes de prestaties en latency kunnen beïnvloeden; de praktische tolerantie hangt af van de gebruikscontext [2]. Een vinkje “ondersteunt PQC” is daarom geen architectuurbesluit.

NIST adviseert modulair ontwerp, expliciete algoritme-identificatie, onderhandelbare cipher suites en interfaces die verschillende sleutel- en parametersizes aankunnen [3]. Dat wijst naar een oplossing waarin applicatielogica zo min mogelijk direct aan één cryptografische implementatie vastzit. Tegelijk is abstractie geen vrijbrief: te veel configureerbare opties vergroten de complexiteit en kunnen nieuwe aanvalsvlakken of downgrade-risico’s introduceren [3].

Wat dit voor architecten betekent. Neem in oplossingsontwerpen een migratiepad op naast de gekozen standaard. Beschrijf waar cryptografie wordt beëindigd, welke component het beleid afdwingt, welke fallback is toegestaan en hoe kan worden vastgesteld welk mechanisme werkelijk is onderhandeld. Test compatibiliteit, latency, foutgedrag en rollback. Markeer expliciet welke delen nog niet post-quantum zijn, zoals certificaatgebaseerde authenticatie.

3. Data Architecture: gegevenslevensduur bepaalt de urgentie

Voor Data Architecture is het risico ongelijk verdeeld. RFC 9954 benoemt retroactieve ontsleuteling: een aanvaller kan versleuteld verkeer nu vastleggen en mogelijk later ontsleutelen als de gebruikte cryptografische aanname wordt gebroken [2]. Dat is een risico, geen bewijs dat zo’n ontsleuteling op een bepaalde datum mogelijk wordt. De architectuurrelevantie volgt uit de combinatie van bewaartermijn, gevoeligheidsduur en blootstelling.

Een gegevenscategorie die over twee jaar zijn gevoeligheid verliest, heeft een ander profiel dan medische, financiële, intellectuele-eigendoms- of staatsgevoelige gegevens die veel langer beschermd moeten blijven. Het Europol-model maakt dit expliciet door “shelf life” van beschermde data mee te nemen in de prioritering [5]. NIST voegt een tweede dimensie toe: bij het vervangen van encryptie voor data-at-rest moet ook worden bepaald wat met al versleutelde gegevens gebeurt; bij een nieuwe handtekeningstandaard geldt dezelfde vraag voor eerder ondertekende documenten [3].

Wat dit voor architecten betekent. Breid dataclassificatie uit met vertrouwelijkheidsduur, cryptografische bescherming, sleutelbeheerder en herbeschermingsstrategie. Koppel gegevensobjecten aan de applicaties, protocollen, certificaten en leveranciers die de bescherming uitvoeren. Zonder die relaties blijft een cryptografische inventaris een technische lijst die niet laat zien welke bedrijfsinformatie werkelijk risico loopt.

4. Infrastructure Architecture: inventariseer tot in firmware en vertrouwensanker

Infrastructure Architecture krijgt te maken met de fysieke grenzen van crypto-agility. NIST wijst erop dat cryptografie voorkomt in libraries, hardware, firmware, HSM’s, secure boot en andere infrastructuurcomponenten. Niet alle onderdelen zijn na productie bij te werken; soms is vervanging nodig, soms kan een crypto-gateway tijdelijk bescherming toevoegen rond een legacycomponent [3]. Dat maakt levensduurbeheer en vervangingsplanning onderdeel van de migratie.

Resourcegebruik is eveneens relevant. Post-quantum sleutels, handtekeningen of ciphertexts kunnen groter zijn dan hun traditionele tegenhangers. NIST waarschuwt dat dit protocollimieten, geheugen, opslag, netwerkcapaciteit en hardwaremogelijkheden kan raken [3]. Project Leap van de Bank for International Settlements testte post-quantum digitale handtekeningen in een bestaand betalingssysteem. De proef was functioneel succesvol, maar vereiste aanpassingen aan meerdere systeemcomponenten en liet betekenisvolle prestatieverschillen tussen traditionele en post-quantum algoritmen zien [7]. Die uitkomst is contextgebonden en mag niet als universele benchmark worden gelezen.

Wat dit voor architecten betekent. Bouw één herleidbare cryptografische inventaris over certificaten, libraries, protocollen, HSM’s, netwerkapparatuur, firmware, images en hardware roots of trust. Neem updatebaarheid, end-of-life, prestaties en eigenaarschap op. Maak een proefomgeving waarin nieuwe profielen op representatief verkeer en apparatuur worden getest. Gebruik een gateway alleen als bewust tijdelijk patroon met einddatum en restrisico, niet als permanente camouflage van onveranderbare legacy.

5. Cloud Architecture: maak gedeelde verantwoordelijkheid toetsbaar

In de cloud verdeelt het shared-responsibilitymodel de cryptografische migratie over provider en klant. Volgens NIST beheert de provider onder meer onderliggende hardware, HSM’s, roots of trust, attestation, cryptografische libraries en aangeboden beveiligingsdiensten; de precieze verdeling verschilt tussen IaaS, PaaS en SaaS [3]. De klant blijft verantwoordelijk voor eigen configuraties, gegevens en applicatiekeuzes, maar kan niet zelfstandig een beheerde dienst van algoritme laten wisselen.

Daarmee ontstaat een afhankelijkheid die in een architectuurplaat vaak onzichtbaar blijft. Een cloudprovider kan een nieuwe hybride TLS-groep ondersteunen aan de publieke rand, terwijl interne serviceverbindingen, message brokers, managed databases, key management of certificaatketens een ander migratiepad volgen. NIST merkt bovendien op dat providerspecifieke cryptografische functies de portabiliteit van applicaties kunnen beperken [3].

Wat dit voor architecten betekent. Leg per clouddienst vast waar cryptografie eindigt, wie sleutels beheert, welke profielen worden ondersteund en hoe wijzigingen worden aangekondigd en bewezen. Vraag leveranciers om roadmaps, inventarisinformatie, testmogelijkheden en contractuele afspraken over deprecatie. Beoordeel niet alleen of een provider “PQC ondersteunt”, maar welke verbindingen en diensten dat aantoonbaar omvat en welke verantwoordelijkheid bij de klant blijft.

6. Security Architecture: van eenmalige selectie naar beheerst verandermechanisme

Security Architecture blijft de primaire discipline, maar de opdracht wordt breder dan het kiezen van sterke algoritmen. RFC 10024 is belangrijk omdat het drie concrete hybride groepen en bijbehorende IANA-registraties levert [1]. Het document is een Proposed Standard op de IETF Standards Track, niet het bewijs dat iedere TLS-stack, appliance of clouddienst de groepen al correct ondersteunt. Implementatie, configuratie, interoperabiliteit en operationele controle blijven afzonderlijke vraagstukken.

De hybride route heeft ook beperkingen. RFC 9954 behandelt sleuteluitwisseling, niet post-quantum authenticatie [2]. Het NCSC noemt juist WebPKI, certificaten, secure boot en industriële protocollen als moeilijk te coördineren onderdelen [4]. Bovendien maakt configureerbaarheid een systeem niet automatisch veilig: NIST waarschuwt voor complexiteit, foutieve combinaties en downgrade-aanvallen wanneer onderhandeling of beleid onvoldoende wordt beschermd [3].

De Europese Commissie en EU-lidstaten hebben al in 2025 een gecoördineerde implementatieroadmap voor PQC uitgebracht [6]. De actuele architectuurontwikkeling is nu dat protocolstandaardisatie dit beleidsniveau begint te verbinden met implementeerbare bouwblokken. Dat maakt governance meetbaar: welke cryptografie is in gebruik, welke profielen zijn toegestaan, hoeveel assets zijn migreerbaar en hoe lang duurt een gecontroleerde wissel?

Wat dit voor architecten betekent. Definieer een cryptografische architectuur met beleid, toegestane profielen, uitzonderingen, sleutelbeheer, meetpunten en deprecatieprocedures. Laat configuratie waar mogelijk machineleesbaar afdwingen, maar beperk keuzevrijheid tot geteste combinaties. Meet niet alleen naleving van de huidige standaard; meet ook ontdekkingstijd, migratieduur, leveranciersdekking en het vermogen om een kwetsbaar algoritme gecontroleerd uit te faseren.

Conclusie

RFC 10024 is een materieel nieuw signaal: hybride post-quantum sleuteluitwisseling voor TLS 1.3 is niet langer alleen experimenteel of conceptueel. Toch zou het een fout zijn om dit als voltooiing van de post-quantummigratie te presenteren. De nieuwe standaard raakt één belangrijk protocolonderdeel; certificaten, authenticatie, data-at-rest, hardware, legacy en beheerde diensten volgen andere paden.

De praktische enterprise-architectuuropgave is daarom crypto-agility. Business Architecture bepaalt prioriteit en eigenaarschap. Solution Architecture ontwerpt de overgang. Data Architecture koppelt urgentie aan gegevenslevensduur. Infrastructure Architecture maakt technische afhankelijkheden en vervangbaarheid zichtbaar. Cloud Architecture concretiseert gedeelde verantwoordelijkheid. Security Architecture bewaakt beleid, interoperabiliteit en veilige uitfasering.

De eerstvolgende verstandige stap is geen generieke massamigratie. Het is een risicogestuurde inventaris van bedrijfsdiensten, gegevens en cryptografische afhankelijkheden, gevolgd door gerichte pilots met de nieuwe TLS-profielen en expliciete afspraken met leveranciers. Zo wordt post-quantum geen los securityprogramma, maar een toetsbaar onderdeel van architectuur en verandervermogen.

Bronnen

[1] IETF, *RFC 10024 — Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3*, augustus 2026. https://www.rfc-editor.org/info/rfc10024/

[2] IETF, *RFC 9954 — Hybrid Key Exchange in TLS 1.3*, juli 2026. https://www.rfc-editor.org/info/rfc9954/

[3] NIST, *Considerations for Achieving Crypto Agility: Strategies and Practices*, CSWP 39-upd1, bijgewerkt 29 juni 2026. https://csrc.nist.gov/pubs/cswp/39/upd1/considerations-for-achieving-crypto-agility/final

[4] UK National Cyber Security Centre, *Timelines for migration to post-quantum cryptography*, 20 maart 2025. https://www.ncsc.gov.uk/guidance/pqc-migration-timelines

[5] Europol en partners, *Prioritising post-quantum cryptography migration activities in financial services*, 21 januari 2026. https://www.europol.europa.eu/publications-events/publications/prioritising-post-quantum-cryptography-migration-activities-in-financial-services

[6] Europese Commissie en NIS Cooperation Group, *A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography*, 23 juni 2025. https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography

[7] Bank for International Settlements Innovation Hub, *Project Leap phase 2: quantum-proofing payment systems*, 11 december 2025. https://www.bis.org/publ/othp107.htm