De CISO vraagt waar RSA en elliptische krommen worden gebruikt. De beheerder opent een spreadsheet uit 2019. De leverancier zegt dat zijn platform “quantum-ready” is. En ergens in de directiekamer vraagt iemand of er volgend kwartaal budget nodig is voor een quantumcomputer.
Dat gesprek gaat meestal meteen de verkeerde kant op. Niet omdat quantumcomputing onbelangrijk is, maar omdat de discussie wordt teruggebracht tot een spectaculair toekomstbeeld. De vraag is niet wanneer de eerste cryptografisch relevante quantumcomputer verschijnt. De vraag is hoeveel tijd jouw organisatie nodig heeft om alle systemen, contracten, certificaten, apparaten en leveranciersafhankelijkheden rondom cryptografie te veranderen.
De hoofdstelling is daarom eenvoudig: er is nog geen reden voor paniek, maar wel alle reden om nu te inventariseren. Wie wacht op zekerheid over de exacte datum van de quantumdoorbraak, ontdekt straks dat de echte vertraging niet in de wiskunde zat, maar in de eigen administratie, architectuur en besluitvorming.
De dreiging zit niet in morgen
Een voldoende krachtige quantumcomputer kan bepaalde veelgebruikte asymmetrische cryptografie onder druk zetten. Denk aan cryptografie die wordt gebruikt voor sleuteluitwisseling, digitale handtekeningen en certificaten. Dat betekent niet dat morgen alle versleutelde verbindingen openliggen. Er is geen knop waarop een aanvaller drukt waarna het internet zijn geheimen prijsgeeft.
Er zijn bovendien nog technische en operationele onzekerheden. De benodigde machines zijn complex, foutgevoelig en niet op grote schaal beschikbaar. Wie daaruit concludeert dat het onderwerp voorlopig kan worden genegeerd, verwart onzekerheid met afwezig risico. Dat is een bekende bestuurlijke reflex: zolang niemand een datum op de kalender kan zetten, wordt voorbereiding behandeld als overdrijving.
Voor een deel van de informatie is de tijdshorizon echter veel langer dan de levensduur van de huidige infrastructuur. Persoonsgegevens, medische dossiers, onderzoeksinformatie, intellectueel eigendom en staats- of bedrijfsgeheimen kunnen vandaag worden onderschept en later worden ontsleuteld. Dat risico staat bekend als “harvest now, decrypt later”. De aanvaller hoeft dus niet vandaag al over de juiste machine te beschikken. Bewaren kan voorlopig voldoende zijn.
Encryptie is geen vinkje in een securitydashboard
De meeste organisaties weten wel dát ze encryptie gebruiken. Ze weten zelden waar precies, met welke algoritmen, op basis van welke bibliotheken en onder wiens verantwoordelijkheid. TLS aan de internetzijde is nog redelijk zichtbaar. Veel lastiger zijn back-ups, mobiele apparaten, integraties tussen oude applicaties, industriële systemen, certificaatketens, hardware security modules, documentondertekening en data die door een leverancier wordt verwerkt.
Daar komt bij dat cryptografie vaak niet als zelfstandig onderdeel in een architectuurplaat staat. Het zit verstopt in besturingssystemen, databases, middleware, API-gateways, libraries, firmware en SaaS-diensten. Een applicatieteam kan denken dat het alleen een API aanroept, terwijl daaronder een cryptografische bibliotheek zit die door een leverancier wordt beheerd. De organisatie gebruikt dan wel de cryptografie, maar bezit niet de mogelijkheid om haar zelfstandig te wijzigen.
Daarom is een inventarisatie geen lijst met algoritmen alleen. Je moet weten welke gegevens worden beschermd, hoe lang die bescherming nodig is, welke sleutel of certificaat erbij hoort, welke systemen ervan afhankelijk zijn en hoe een wijziging wordt getest. Wie alleen “RSA” in een spreadsheet zet, heeft vooral bewezen dat hij een zoekfunctie kan gebruiken.
De eerste prioriteit is niet quantum, maar zichtbaarheid
Begin met de informatie die lang vertrouwelijk moet blijven. Niet ieder bestand verdient dezelfde migratiesnelheid. Een tijdelijke sessie tussen twee publieke webdiensten is iets anders dan een archief dat over twintig jaar nog gevoelig is. De waarde, bewaartermijn en verwachte levensduur van een systeem bepalen samen de prioriteit.
Kijk vervolgens naar de cryptografische afhankelijkheden die moeilijk te vervangen zijn. Een moderne webapplicatie is doorgaans eenvoudiger aan te passen dan een apparaat dat jarenlang in een fabriek, ziekenhuis of energievoorziening blijft draaien. Firmware, embedded apparatuur en systemen zonder regelmatig updatepad verdienen vroeg aandacht, net als toepassingen met lange certificaat- of contractcycli.
Ook digitale handtekeningen vragen een eigen beoordeling. Vertrouwelijkheid en authenticiteit zijn niet hetzelfde probleem. Een handtekening die vandaag wordt gezet, moet mogelijk over vele jaren nog aantoonbaar geldig zijn. Dan spelen niet alleen het algoritme en het certificaat een rol, maar ook tijdstempels, archivering, sleutelbeheer en de vraag hoe een oude handtekening wordt gevalideerd nadat een algoritme niet langer betrouwbaar wordt geacht. Goed key management en beheer van signing keys zijn dus geen detail voor later.
PQC is vooral een architectuurprobleem
Post-quantum cryptografie, kortweg PQC, wordt soms gepresenteerd als een nieuwe set algoritmen die je op termijn installeert. Dat is te simpel. De algoritmen zijn belangrijk, maar de migratie raakt protocollen, certificaatformaten, prestaties, sleutelgroottes, logging, hardware, softwareontwikkeling en beheer. Een wijziging op één plek kan gevolgen hebben voor systemen die niemand meer als eigenaar herkent.
Daarom is crypto-agility meer dan een configuratieoptie met een fraaie naam. Een organisatie is pas wendbaar als cryptografische keuzes niet diep in applicatielogica, leveranciersproducten en ongedocumenteerde koppelingen zijn vastgebakken. Algoritmen moeten vervangbaar zijn, maar ook sleutels, certificaten, bibliotheken en validatiemechanismen. Dat vraagt om expliciete architectuurkeuzes en testen die verder gaan dan de vraag of een verbinding technisch tot stand komt.
Er kunnen goede redenen zijn om voorlopig met hybride oplossingen te werken, waarbij bestaande en post-quantummechanismen naast elkaar worden gebruikt. Maar “hybride” is geen synoniem voor automatisch veilig. Het kan extra complexiteit, grotere berichten en nieuwe configuratiefouten introduceren. De juiste keuze hangt af van het protocol, de toepassing, de prestaties en de dreiging. Een leverancier die alleen meldt dat een product quantum-ready is, heeft nog niet uitgelegd wat dat in jouw landschap betekent.
Leveranciers kunnen de inventarisatie niet voor je doen
Leveranciers zullen ongetwijfeld routekaarten, productverklaringen en migratiepaden aanbieden. Die informatie is nuttig, maar niet voldoende. Een leverancier kent zijn product. De klant kent de keten waarin dat product terecht is gekomen, inclusief oude koppelingen, lokale uitzonderingen en gegevensstromen die nooit in het oorspronkelijke ontwerp stonden.
Vraag daarom niet alleen of een product PQC ondersteunt. Vraag welke componenten cryptografie uitvoeren, welke algoritmen en sleutelgroottes worden gebruikt, hoe certificaten worden vervangen, welke versies nodig zijn, hoe lang oudere apparatuur wordt ondersteund en welke impact een migratie heeft op opslag, netwerk en beheer. Vraag ook wat er gebeurt als de leverancier stopt, wordt overgenomen of besluit dat een oud platform niet langer wordt aangepast.
Leg zulke antwoorden vast in architectuurdocumentatie, contracten en lifecyclebesluiten. Een leverancier kan een algoritme toevoegen, maar niet jouw verantwoordelijkheid voor informatieclassificatie, bewaartermijnen en continuïteit overnemen. Dat is precies waarom onzichtbare afhankelijkheden zo gevaarlijk zijn: ze worden pas zichtbaar wanneer een wijziging noodzakelijk is.
Maak er geen nieuw complianceproject van
De slechtste reactie is een quantumprogramma met een nieuw dashboard, een stuurgroep en een verzameling groene statussen. Dat levert vooral geruststelling op papier. De betere aanpak begint klein en technisch concreet. Breng de belangrijkste gegevensstromen en cryptografische toepassingen in kaart. Leg eigenaarschap vast. Bepaal welke systemen niet eenvoudig kunnen worden vervangen. Test vervolgens hoe certificaten, sleutels en cryptografische libraries daadwerkelijk worden gewisseld.
Neem cryptografische afhankelijkheden mee in nieuwe aanbestedingen en architectuurreviews. Vraag om een aantoonbaar migratiepad, niet om een marketinglabel. Zorg dat ontwikkelteams cryptografie niet zelf gaan uitvinden of verspreid in applicaties vastleggen. Maak daarnaast duidelijk wie beslist over uitzonderingen, wie risico accepteert en wie betaalt wanneer een oud systeem niet mee kan.
De planning hoeft niet te doen alsof de einddatum bekend is. Wel moet zij rekening houden met de traagheid van organisaties. Een certificaat vervangen kan snel zijn. Een vloot apparaten, een archief met langdurige vertrouwelijkheid of een keten met meerdere leveranciers veranderen is dat niet. Wie nu inventariseert, koopt tijd. Wie pas begint wanneer de dreiging onomstotelijk en urgent wordt verklaard, koopt vooral haast.
Wat is dan de echte IT-realiteit?
Post-quantum cryptografie is geen reden om bestaande beveiligingsproblemen te parkeren. Een organisatie die haar identiteiten, sleutels, back-ups, legacy en leveranciersafhankelijkheden niet beheerst, wordt niet gered door een nieuw algoritme. PQC maakt juist zichtbaar hoe weinig organisaties weten over de fundamenten waarop hun digitale vertrouwen rust.
De juiste reactie is ook geen massale vervanging van alles wat vandaag cryptografie gebruikt. Dat zou duur, verstorend en inhoudelijk ongericht zijn. De juiste reactie is onderscheid maken: welke informatie moet lang geheim blijven, welke systemen zijn moeilijk te migreren, welke vertrouwensketens zijn kritiek en welke leveranciers kunnen hun beloften werkelijk onderbouwen?
Wie die vragen nu beantwoordt, hoeft niet te voorspellen wanneer quantumcomputing volwassen wordt. Die organisatie bouwt iets veel nuttigers: zichtbaarheid, vervangbaarheid en bestuurlijke keuzevrijheid. De quantumdreiging komt misschien later dan de paniek, maar de inventarisatie had allang moeten beginnen.
Ontdek meer van IT realiteit
Abonneer je om de nieuwste berichten naar je e-mail te laten verzenden.
