Post-quantum: ik wil weten of mijn organisatie op tijd kan overstappen
Bij post-quantum kijk ik eerst naar de gegevens die we langdurig moeten beschermen en de systemen die moeilijk te veranderen zijn. Nieuwe beveiligingsstandaarden helpen, maar voorbereiding vraagt ook keuzes over eigenaarschap, leveranciers en continuïteit.
Ik wil bij post-quantum vooral weten of een organisatie op tijd kan overstappen op andere beveiliging. Welke gegevens moeten nog lang vertrouwelijk blijven? Welke systemen kunnen we aanpassen? En bij welke leverancier moeten we daarvoor aankloppen? Met die vragen wordt een technisch onderwerp een concrete bestuurlijke opgave.
Post-quantumcryptografie is de naam voor cryptografische technieken die ontworpen zijn om aanvallen met quantumcomputers te weerstaan. Inmiddels zijn er concrete standaarden om zulke technieken in beveiligde verbindingen toe te passen. RFC 10024 beschrijft daarvoor drie combinaties van traditionele en post-quantumtechnieken.
Dat geeft richting. Voor mij begint de voorbereiding echter bij de mensen die op onze diensten vertrouwen: klanten van wie we gegevens bewaren, medewerkers die systemen gebruiken en beheerders die een wijziging veilig moeten uitvoeren.
Waarom ik nu al naar de gegevens zou kijken
Het risico zit ook in informatie die vandaag wordt verstuurd. Een aanvaller zou versleuteld verkeer kunnen verzamelen en later proberen te ontsleutelen, zodra daarvoor voldoende krachtige middelen beschikbaar komen. De IETF beschrijft dit risico in RFC 9954. Het is geen voorspelling van een exacte datum waarop dat mogelijk wordt.
Daarom zou ik beginnen met de vraag hoe lang informatie gevoelig blijft. Stel dat een organisatie onderzoeksgegevens uitwisselt die nog jarenlang concurrentiegevoelig zijn. Dan wil ik bij het ontwerp van die uitwisseling al rekening houden met de bescherming over die hele periode.
Dat voorbeeld is hypothetisch, maar de afweging is praktisch: hoe langer informatie beschermd moet blijven, hoe belangrijker het wordt om tijdig te onderzoeken of de huidige bescherming kan worden aangepast.
Ik zou dat gesprek samen voeren met de verantwoordelijke voor de bedrijfsdienst, een dataspecialist en een beveiligingsspecialist. De een kent de gevolgen voor klanten of bedrijfsvoering, de ander weet waar de gegevens staan en hoe ze worden beschermd. Hun antwoorden moeten in hetzelfde overzicht terechtkomen.
Wat de nieuwe standaard wel oplost
Om een beveiligde verbinding op te zetten, moeten twee systemen cryptografisch sleutelmateriaal afspreken. TLS is het protocol dat onder meer wordt gebruikt voor beveiligde webverbindingen. RFC 10024 beschrijft hoe TLS 1.3 hiervoor een traditionele methode kan combineren met een post-quantummethode. Dat heet een hybride aanpak. Het ontwerp beoogt bescherming zolang ten minste één van die twee methoden veilig blijft. IETF, RFC 10024
Voor de lezer die geen beveiligingsspecialist is, is vooral de begrenzing relevant. Deze ontwikkeling gaat over één onderdeel van de verbinding. Ze maakt niet automatisch alle beveiliging binnen een organisatie bestand tegen quantumaanvallen. Het achterliggende raamwerk behandelt bijvoorbeeld niet de overstap van authenticatie naar post-quantumtechnieken: het controleren met wie een systeem communiceert vraagt dus afzonderlijke aandacht. IETF, RFC 9954
Mijn conclusie daaruit: vraag bij een leverancier precies welk onderdeel wordt ondersteund. Een algemene productclaim geeft mij nog onvoldoende informatie om over een complete bedrijfsdienst te kunnen oordelen.
Ik wil één overzicht dat tot besluiten leidt
NIST gebruikt het begrip *crypto-agility*: cryptografie kunnen vervangen of aanpassen terwijl beveiliging en bedrijfsvoering blijven functioneren. Het begrip omvat software, hardware en infrastructuur. NIST, Considerations for Achieving Crypto Agility
Ik zou dat vertalen naar een overzicht per belangrijke bedrijfsdienst. Daarin wil ik de volgende vragen kunnen beantwoorden:
| Vraag | Waarvoor ik het antwoord gebruik |
|---|---|
| Welke informatie beschermen we en hoe lang blijft die gevoelig? | Bepalen welke diensten prioriteit verdienen |
| Welke systemen en leveranciers verzorgen die bescherming? | Zien wie bij de verandering nodig is |
| Kunnen onderdelen worden bijgewerkt of moeten ze worden vervangen? | De uitvoerbaarheid en planning beoordelen |
| Wie beslist en wie voert de verandering uit? | Voorkomen dat verantwoordelijkheid tussen teams blijft liggen |
| Hoe tonen we aan dat de dienst na de wijziging goed werkt? | Vooraf bepalen welk bewijs nodig is |
Ik zou dit overzicht bewust beperkt houden. Het hoeft geen tweede technische administratie te worden. Verwijs naar bestaande systeem- en leveranciersregistraties en voeg de informatie toe die nodig is om een besluit te nemen.
Een onbekend antwoord zou ik zichtbaar laten staan, met iemand die het uitzoekt. Juist zo wordt duidelijk waar de voorbereiding nog onvoldoende is.
De leverancier hoort vroeg aan tafel
Een organisatie kan haar ambitie uitspreken, maar moet ook weten wat leveranciers daadwerkelijk ondersteunen. Het Britse NCSC neemt afhankelijkheden van leveranciers en fysieke infrastructuur expliciet op in zijn migratieaanpak. Het adviseert om de inventarisatie en eerste planning uiterlijk in 2028 af te ronden. Dat is een Brits richtsnoer, geen Nederlandse wettelijke deadline. NCSC, migratietijdlijnen
Ik zou leveranciers daarom vroeg vragen naar de betrokken producten, ondersteunde versies, testmogelijkheden en onderdelen die nog moeten volgen. Ook wil ik weten wat de organisatie zelf moet doen. Krijgen we een update, moeten we instellingen wijzigen of vraagt de overgang om vervanging?
Neem een hypothetische dienst die bestaat uit een website, een achterliggende applicatie en een externe gegevensleverancier. Als alleen de website een nieuwe methode ondersteunt, wil ik de andere verbindingen afzonderlijk laten beoordelen. Het etiket op de voorkant vertelt mij onvoldoende over de hele route die de gegevens afleggen.
Voor de planning betekent dit dat inkoop, beheer en de eigenaar van de bedrijfsdienst samen moeten kunnen besluiten. Ik zou die afstemming onderdeel maken van bestaande vervangings- en investeringsbesluiten.
Eerst een proef die iets bewijst
Mijn voorkeur is om één relevante gegevensuitwisseling te kiezen en de overgang daarop te beproeven. Kies een situatie waarvan we de betrokken systemen en partijen kennen en waarvoor de uitkomst betekenis heeft.
Ik zou vooraf vastleggen wat we willen aantonen: de afgesproken beveiliging is daadwerkelijk actief, de betrokken systemen blijven samenwerken en gebruikers kunnen hun werk blijven doen. Test ook wat er gebeurt als een onderdeel de nieuwe instellingen niet ondersteunt.
Een terugvalmogelijkheid vraagt eveneens een besluit. Wie mag haar activeren, onder welke omstandigheden en welk risico accepteren we dan tijdelijk? Ik wil voorkomen dat een technische noodoplossing ongemerkt de vaste werkwijze wordt.
De proef moet uiteindelijk een bruikbaar besluit opleveren: doorgaan, aanpassen of eerst een afhankelijkheid oplossen. Een technisch geslaagde verbinding is daarvoor een begin; de werking van de hele dienst bepaalt of we verder kunnen.
Waar ik het gesprek mee zou afsluiten
Ik zou een eerste bespreking laten eindigen met een benoemde bedrijfsdienst, een verantwoordelijke en een afspraak over de ontbrekende informatie. Daarmee ontstaat een concrete volgende stap.
De vraag die ik wil kunnen beantwoorden is eenvoudig: als onze beveiliging moet veranderen, weten we dan wie wat moet doen en kunnen we dat uitvoeren zonder klanten of medewerkers onnodig te hinderen? Dat is voor mij de praktische betekenis van voorbereiding op post-quantum.
Bronnen
Bronnen
Bronnen die voor dit artikel zijn gebruikt of geraadpleegd.
- RFC 10024 — Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 — Internet Engineering Task Force (IETF)
- RFC 9954 — Hybrid Key Exchange in TLS 1.3 — Internet Engineering Task Force (IETF)
- Considerations for Achieving Crypto Agility: Strategies and Practices (CSWP 39-upd1) — National Institute of Standards and Technology (NIST)
- Timelines for migration to post-quantum cryptography — UK National Cyber Security Centre