Je cryptografie post-quantum-proof maken: van inventaris tot migratie in golven

Je weet dat je ooit naar quantumveilige encryptie moet. De vraag is niet of, maar hoe je daar als organisatie aan begint zonder je hele IT-landschap in een keer overhoop te halen. Voor de meeste bedrijven, van een MKB'er met een handvol cloudtools tot een ICT-afdeling binnen een groter concern, voelt post-quantum cryptografie als iets voor wiskundigen en grootbanken. De migratie zelf is dat niet. Het is geen rekenwerk, het is inventariseren, prioriteren en in golven uitrollen, precies het soort project dat je kunt plannen.

Deze gids loopt dat stappenplan met je door: wat je nodig hebt, welke concrete stappen je in welke volgorde zet, waar het misgaat, en wanneer je beter een kant-en-klare oplossing aanzet dan zelf gaat sleutelen. De achterliggende reden om hier niet mee te wachten, dat de echte deadline niet de komst van de quantumcomputer is maar de optelsom van je bewaartermijn en je migratietijd, laat ik hier grotendeels rusten. Dit stuk gaat over het doen.

Wat je nodig hebt

Voordat je begint, leg je een paar dingen klaar. Het scheelt later maanden aan giswerk.

• Een actueel overzicht van je systemen en leveranciers. Welke applicaties, servers, VPN's en SaaS-diensten gebruik je, en wie levert ze? Je hebt het straks nodig om te bepalen wat onder jouw beheer valt en wat onder dat van een ander.
• Toegang tot je infrastructuur. De TLS-certificaten van je websites en API's, de configuratie van je VPN en firewall, je mailservers en de plekken waar je data versleuteld opslaat (backups, databases, fileshares).
• Een manier om je cryptografie vast te leggen. Een gestructureerde inventaris, bij voorkeur als machine-leesbare CBOM (een Cryptography Bill of Materials in het CycloneDX-formaat), of voor een kleine omgeving gewoon een nette spreadsheet om mee te beginnen.
• Een testomgeving met moderne crypto-tooling. OpenSSL 3.5 of nieuwer ondersteunt de nieuwe algoritmes native; voor oudere of exotische opstellingen vul je dat aan met het Open Quantum Safe-project (liboqs en de oqs-provider).
• Iemand die de risicoclassificatie van data kan maken. De kernvraag per dataset: hoe lang moet dit geheim blijven? Dat bepaalt je hele prioritering.

Het stappenplan in vijf stappen

Je maakt je cryptografie quantumveilig door eerst in kaart te brengen waar encryptie zit, die te prioriteren op risico, de NIST-standaarden te kiezen en je systemen daarna in golven over te zetten naar hybride post-quantum cryptografie. Het is geen eenmalige overstap maar een verbouwing in fasen, met de meest kwetsbare data eerst. Loop de stappen hieronder in volgorde door.

1. Maak een cryptografische inventaris

Wat je niet in kaart hebt, kun je niet migreren, en voor de meeste organisaties is juist die inventaris het ontbrekende begin. Breng in kaart waar in je systemen, software en dataverkeer cryptografie zit: elk TLS-certificaat, elke VPN-tunnel, elke versleutelde database, elke ondertekende update of e-mail. Een CBOM legt per component vast welke algoritmes, sleutels en certificaten in gebruik zijn en koppelt ze aan je software, zodat je in een oogopslag ziet welke nog op kwetsbare cryptografie leunen. Heb je nog geen tooling, begin dan handmatig en gebruik een cybersecurity-basischeck voor het MKB in vijf lagen om die nulmeting te structureren. Het resultaat van deze stap is een lijst: waar zit welke encryptie, en hoe diep zit ze ingebakken?

2. Prioriteer op risico, niet op systeem

Niet alle data is even urgent, en daar zit je grootste tijdwinst. De aanval die nu al loopt heet "harvest now, decrypt later": versleuteld verkeer wordt vandaag gekopieerd en bewaard om het over jaren te ontsleutelen. Dus alles met een lange houdbaarheid loopt nu risico, ook al kan niemand het vandaag kraken. Sorteer je inventaris op twee assen: hoe gevoelig en langlevend is de data (persoonsgegevens onder de AVG, medische en juridische dossiers, broncode, contracten), en hoe asymmetrisch is de bescherming. Want het goede nieuws is dat je niet alles hoeft te vervangen. Symmetrische encryptie zoals AES-256 blijft tegen een quantumcomputer ruim voldoende sterk; het risico zit vrijwel volledig in de asymmetrische cryptografie, RSA en elliptische curves, die je sleuteluitwisseling en handtekeningen dragen. Dat versmalt je werk aanzienlijk. De Rijksinspectie Digitale Infrastructuur waarschuwt niet voor niets dat de voorbereiding op de quantumdreiging organisaties jaren kost, juist omdat die prioritering en uitrol tijd vragen.

3. Kies de algoritmes: de NIST-standaarden en hybride uitrol

De standaarden zijn er. In augustus 2024 legde NIST de eerste drie definitieve standaarden voor quantumveilige encryptie vast, en in maart 2025 koos het een vijfde algoritme als reserve. Dit is wat je nodig hebt om uit te kiezen:

Voor de meeste organisaties is ML-KEM (FIPS 203) het werkpaard: het beschermt de sleuteluitwisseling waar de oogst-aanval op mikt. En vervang RSA of ECC niet zomaar door een kaal post-quantum algoritme, maar kies een hybride combinatie. De de-factostandaard op het web is X25519MLKEM768, die de vertrouwde X25519 combineert met ML-KEM-768: gaat er met het jonge algoritme onverhoopt iets mis, dan houdt de klassieke helft je nog steeds veilig. Dat is geen tussenoplossing uit voorzichtigheid alleen, het is de aanbevolen route.

4. Rol uit in golven

Migreer niet alles tegelijk, maar in golven, met de meest kwetsbare laag eerst. De volgorde volgt het risico: vertrouwelijkheid op transport eerst, opslag daarna, handtekeningen als laatste omdat hun standaarden nog niet volgroeid zijn.

• Golf 1, sleuteluitwisseling op transport. Zet hybride post-quantum TLS aan op je externe verbindingen en VPN-tunnels. Hier zit de directe winst tegen harvest now, decrypt later, en hier is de tooling het verst.
• Golf 2, data in rust. Versleutelde backups, databases en archieven die jaren bewaard blijven. Controleer hoe de sleutels die deze data beschermen worden uitgewisseld en opgeslagen.
• Golf 3, handtekeningen en certificaten. Bewust als laatste: de standaard voor post-quantum certificaten is nog niet rond, en een ML-DSA-handtekening maakt een TLS-handshake fors zwaarder. Loop deze laag voorlopig in pilots, niet in productie-brede uitrol.

5. Borg crypto-agiliteit en blijf monitoren

De grootste denkfout is dat je een keer migreert en klaar bent. De standaarden van vandaag zijn niet het eindstation: HQC en Falcon komen er nog aan, en er volgen vast bijstellingen. Crypto-agiliteit is het vermogen om je algoritmes te vervangen zonder je systemen opnieuw te bouwen. Leg vast welke component welk algoritme gebruikt (je CBOM blijft dus leven), kies waar mogelijk libraries en producten waarin je de cryptografie kunt omwisselen, en plan de volgende wissel in als een aanpassing, geen verbouwing.

Veelgemaakte valkuilen

• Je leveranciers vergeten. Een groot deel van je cryptografie zit niet in je eigen code maar in de producten en clouddiensten die je inkoopt. Vraag elke leverancier expliciet naar hun post-quantum routekaart, want hun tempo wordt jouw tempo.
• Alleen je eigen servers doen. De keten telt mee: lever je aan grotere organisaties, dan gaan die straks vragen hoe het bij jou zit, mede onder druk van regelgeving zoals NIS2.
• Handtekeningen willen forceren. Wie nu al overal post-quantum certificaten wil uitrollen, loopt vast op standaarden die nog niet af zijn en op handshakes die onnodig zwaar worden. Geduld is hier de juiste keuze.
• Kiezen voor puur in plaats van hybride. Een kaal post-quantum algoritme zonder klassieke tweede laag is een onnodig risico zolang de algoritmes nog jong zijn. Hybride is de veilige route.
• Tijd verspillen aan symmetrische crypto. AES-256 hoef je niet te vervangen. Wie zijn hele symmetrische laag gaat ombouwen, verbrandt budget op de verkeerde plek.
• Geen eigenaarschap. Zit je cryptografie vastgemetseld in een dichtgetimmerd product waar je geen eigenaar van je eigen software bent, dan migreer je op het tempo van je leverancier, of helemaal niet. De quantumdreiging maakt de prijs van vendor lock-in alleen maar zichtbaarder.

Kant-en-klaar vs. maatwerk

Je hoeft lang niet alles zelf te bouwen. Een fors deel van je verkeer loopt via grote providers die de hybride uitrol al voor je hebben gedaan: meer dan de helft van het menselijke webverkeer via Cloudflare is inmiddels beschermd met post-quantum encryptie, Chrome en Firefox bieden X25519MLKEM768 standaard aan, en AWS KMS, ACM en Secrets Manager ondersteunen hybride ML-KEM als opt-in. Voor dat soort verkeer is "aanzetten" vaak letterlijk het werk.

De eerlijke afweging: begin bij kant-en-klaar voor alles wat al via een moderne provider loopt, dat is gratis risicoreductie. Reserveer je maatwerk voor je eigen infrastructuur en voor de data met de langste schaduw, waar je niet afhankelijk wilt zijn van het migratietempo van een ander. Dat is geen politieke keuze maar risicobeheer: je legt quantumveiligheid in je eigen architectuur in plaats van haar in te kopen.

Tot slot

De druk neemt toe. NIST haalt de kwetsbare algoritmes uiterlijk 2035 uit zijn standaarden, met de eerste afschrijving al na 2030, en aan de overkant van de oceaan moeten Amerikaanse federale systemen hun sleuteluitwisseling eind 2030 en hun handtekeningen eind 2031 quantumveilig hebben. Die data markeren niet het moment waarop je begint, maar het moment waarop je klaar moet zijn.

Het mooie is dat het eerste deel van dit stappenplan, weten waar je cryptografie zit en welke data een lange houdbaarheid heeft, waardevol is los van welke deadline dan ook. Het is gewoon weten wat je hebt. Wie dat dit jaar rustig doet, kiest zelf zijn tempo. Wie wacht tot de dreiging concreet voelt, ontdekt dat de tijd om iets te doen al verstreken is. Een inventaris en een eerste hybride golf zijn een dag werk dat zichzelf jaren later terugbetaalt.