De meeste artikelen over machine-identiteit volgen hetzelfde patroon. Machines zijn nu in de meerderheid op het netwerk, zero trust schrijft voor dat alles geverifieerd moet worden, en kwantumcomputers zullen de onderliggende cryptografie overnemen. Dat is allemaal waar, en we zullen het behandelen. Maar de gangbare conclusie, dat je elk certificaat onmiddellijk moet vervangen door een kwantumveilig certificaat, draait het probleem om.
Machine-identiteiten worden niet met één, maar met twee kwantumdreigingen geconfronteerd, die zich op zeer verschillende tijdlijnen afspelen. De meeste van uw identiteiten bevinden zich aan de kant die veel minder urgent is dan de krantenkoppen doen vermoeden. Het echte gevaar schuilt in een kleine set langlevende identiteiten die zelden in een migratieplan worden opgenomen. De bemoedigende rode draad door dit alles is dat de kortstondige, geautomatiseerde identiteiten waar zero trust u al naartoe stuurt, het grootste deel van uw kwantumverdediging vormen. Deze blog laat zien hoe deze onderdelen in elkaar passen en waar u uw inspanningen daadwerkelijk op moet richten. Het begint met wat een machine-identiteit is en het ene onderscheid dat later alles verandert.
Het begrijpen van machine-identiteiten
Een machine-identiteit is de manier waarop een niet-menselijk systeem bewijst wie het is. Mensen gebruiken een gebruikersnaam en een wachtwoord. Een machine gebruikt meestal een digitaal certificaat in combinatie met een privésleutel, en soms een SSH-sleutel , een API-sleutel, een cloudtoegangsrol of een kortstondig token. Je kunt een certificaat zien als een identiteitsbewijs voor software: een vertrouwde instantie geeft het uit, en het stelt twee machines in staat elkaars identiteit te controleren voordat ze gegevens uitwisselen.
Wat dit lastig maakt, is het aantal identiteiten en hoe snel ze veranderen. Eén applicatie kan bijvoorbeeld opgebouwd zijn uit tientallen kleine services, elk met een eigen identiteit, en cloudsystemen creëren en verwijderen deze workloads constant. Een enkele workload kan verschijnen, een paar seconden zijn werk doen en dan weer verdwijnen. Vermenigvuldig dat met een drukke omgeving en je hebt duizenden identiteiten die elke dag worden aangemaakt, gebruikt en verwijderd.
Eén onderscheid is belangrijker dan welk algoritme je ook kiest: een machine-identiteit vervult twee verschillende functies. De eerste is authenticatie, wat inhoudt dat je bewijst wie je bent op het moment dat twee systemen verbinding maken. De tweede is vertrouwelijkheid, waarbij de identiteit de sleuteluitwisseling authenticeert die de uitgewisselde gegevens geheim houdt, vaak jarenlang. Beide functies zijn gebaseerd op cryptografie, waardoor ze op het eerste gezicht één probleem lijken, maar ze gedragen zich heel anders zodra kwantumcomputers hun intrede doen.
De manier waarop deze identiteiten dagelijks worden beheerd, is net zo belangrijk als de cryptografie erachter. Dit is waar zero trust om de hoek komt kijken: de gewoonten die het al aanmoedigt, zoals korte levensduur en constante rotatie, zorgen er ongemerkt voor dat een groot deel van je kwantumvoorbereiding voor je wordt gedaan.
Hoe Zero Trust de helft van het werk doet
Lange tijd was beveiliging gebaseerd op een simpel idee: bouw een sterke perimeter rond het netwerk en vertrouw vrijwel alles daarbinnen. Het probleem is duidelijk: zodra een aanvaller binnen is, kan hij zich vrij bewegen. Zero trust vervangt dit door een eenvoudigere regel: vertrouw niets automatisch en controleer elk verzoek op zijn eigen merites, ongeacht de herkomst. NIST beschrijft deze aanpak in SP 800-207 , de richtlijn voor zero trust-architectuur, en het is de standaard geworden voor moderne beveiliging.
Voor machines vertaalt die regel zich in een paar praktische gewoonten. Elke verbinding bewijst zijn identiteit, dus beide partijen tonen hun certificaat en bevestigen de ander voordat er gegevens worden overgedragen. Inloggegevens worden slechts kort bewaard, dus een gestolen certificaat werkt snel niet meer. Elke machine krijgt alleen toegang tot wat nodig is voor zijn taak. En in cloudsystemen heeft elke workload een eigen identiteit die meereist, zodat dezelfde controles gelden, ongeacht waar de workload draait.
Let nu eens op iets. Korte levensduur, automatische rotatie, beperkte reikwijdte en identiteiten die naar believen opnieuw kunnen worden uitgegeven. Elk van deze kenmerken maakt het voor een toekomstige kwantumaanvaller ook moeilijker om iets nuttigs met een identiteit te doen. Zero trust staat vooral bekend om het beperken van inbreuken, en dat doet het goed. Dezelfde investering blijkt echter ook het grootste deel van je kwantumvoorbereiding te omvatten. Om te begrijpen waarom, moeten we kijken naar hoe kwantumcomputing identiteiten daadwerkelijk bedreigt, want dat gebeurt op twee heel verschillende manieren.
Twee kwantumdreigingen, twee tijdlijnen
De huidige machine-identiteiten zijn gebaseerd op publieke-sleutelcryptografie, wat om een ​​praktische reden veilig is: gewone computers zouden er veel te lang over doen om het te kraken. Een voldoende krachtige kwantumcomputer zou die berekening snel kunnen uitvoeren, en dat is de dreiging waar iedereen het over heeft. Wat vaak over het hoofd wordt gezien, is dat deze dreiging niet in één keer ontstaat. Het werkt volgens twee verschillende principes.
Het eerste risico is de vertrouwelijkheidsklok, en die tikt al. Een aanvaller kan vandaag nog versleutelde gegevens vastleggen, opslaan en jaren later ontsleutelen, zodra kwantumcomputers gereed zijn. Dit wordt ' nu verzamelen, later ontsleutelen' genoemd . Alles wat lange tijd geheim moet blijven, zoals medische of financiële gegevens, wordt blootgesteld zodra het het netwerk oversteekt, zelfs als de inbraak nog niet heeft plaatsgevonden. Voor dit soort gegevens begint het risico dus niet pas wanneer kwantumcomputers er zijn. Het begint al op het moment dat de gegevens voor het eerst worden verzonden, omdat een aanvaller ze toen al kon kopiëren en simpelweg kon wachten.
Het tweede aspect is de authenticatieklok, en die werkt precies andersom. Om een ​​identiteit of handtekening te vervalsen, heeft een aanvaller op dat moment een werkende kwantumcomputer nodig. Ze kunnen een reeds tot stand gebrachte verbinding niet meer verbreken. Een authenticatiebewijs dat verloopt voordat kwantumcomputers bestaan, is dus veilig voor deze dreiging. Een certificaat dat negentig seconden geldig was, jaren voordat er überhaupt een kwantumcomputer bestond, liep eigenlijk nooit gevaar. Het was immers al lang verlopen voordat de dreiging reëel werd.
Een voorbeeld maakt het verschil duidelijk. Stel je voor dat een aanvaller vandaag je versleutelde verkeer kopieert en opslaat. Als dat verkeer de medische geschiedenis van een patiënt bevat, hoeft hij alleen maar te wachten tot er kwantumcomputers beschikbaar komen, en het geheim komt jaren later aan het licht. Stel je nu voor dat dezelfde aanvaller probeert zich voor te doen als een van je diensten. Het vervalsen van je certificaat vereist een kwantumcomputer, en tegen de tijd dat die er is, is dat certificaat allang verlopen. Het is dezelfde aanvaller en dezelfde cryptografie, maar de urgentie is totaal anders.
Door de twee klokken samen te voegen, komen we tot een nuttige conclusie. Omdat machine-identificatie meestal een kortstondige authenticatie betreft, heeft het grootste deel ervan een lage kwantumurgentie, waardoor er geen noodzaak is om het snel te vervangen. Dat betekent niet dat de standaarden genegeerd kunnen worden. Je hebt de juiste standaard nu nog steeds nodig voor de vertrouwelijkheid, die vandaag de dag urgent is, en later voor de langdurige identiteiten waarnaar je uiteindelijk zult migreren. De nieuwe standaarden die NIST in 2024 heeft afgerond, sluiten naadloos aan op de twee klokken: de ene beschermt het privékanaal en de andere behandelt identiteit en handtekeningen. Hier is het plaatje in eenvoudige bewoordingen:
| Algoritme | Wat het beschermt | Welke klok | Status |
|---|---|---|---|
| ML-KEM (FIPS203) | Genereert en versleutelt een gedeeld geheim voor symmetrische sleutelafleiding (vervangt RSA/ECDH-sleuteluitwisseling). | Vertrouwelijkheid (handelt nu) | Finale, 2024 |
| ML-DSA (FIPS204) | Authenticiteit en integriteit door middel van digitale handtekeningen | authenticatie | Finale, 2024 |
| SLH-DSA (FIPS205) | Authenticiteit en integriteit door middel van hash-gebaseerde digitale handtekeningen | authenticatie | Finale, 2024 |
| hoofdkwartier | Biedt sleutelinkapseling op basis van coderingstheorie en cryptografische diversiteit als alternatief voor de op roosters gebaseerde aanpak van ML-KEM. | Vertrouwelijkheid | Geselecteerd maart 2025; concept 2026, definitieve versie 2027 |
| FN-DSA | Authenticiteit en integriteit door middel van compacte digitale handtekeningen. | authenticatie | Eerste openbare conceptversie gepubliceerd in september 2025; momenteel in openbare beoordeling; definitieve versie wordt eind 2026 of begin 2027 verwacht. |
Er is één belangrijke uitzondering, en daar gaat de rest van deze blog over. Sommige handtekeningen moeten jarenlang geldig blijven, en sommige geheimen moeten net zo lang privé blijven. Voor die gevallen is de authenticatietijd niet langer geduldig, maar net zo urgent als de vertrouwelijkheid. En daar schuilt het echte risico.
Risicofactoren
Laten we beginnen met de langdurige vertrouwensankers. Een rootcertificaat van een certificeringsinstantie kan twintig jaar of langer geldig zijn. Code- en firmware-ondertekeningssleutels ondertekenen zaken die tot ver in de toekomst geverifieerd moeten blijven, dus een firmware-image die vandaag wordt uitgebracht, moet mogelijk over vijftien jaar nog steeds bewijzen dat deze authentiek is. Als die handtekening met de huidige algoritmen is gemaakt, zou een toekomstige kwantumcomputer deze kunnen vervalsen lang voordat het apparaat buiten gebruik wordt gesteld. Je kunt ook niet zomaar een rootcertificaat vervangen dat in miljoenen apparaten en vertrouwensarchieven is ingebouwd. Daarom staat het ondertekenen van software en firmware in de nationale veiligheidsrichtlijnen op de vroegst mogelijke deadline, vóór bijna al het andere.
Dan is er nog het onderdeel dat de meeste quantum-migratieplannen volledig overslaan. Een groot deel van de machine-identiteit bestaat helemaal niet uit certificaten. Het gaat om SSH-sleutels , API-sleutels, cloudtoegangsrollen, geheimen in configuratiebestanden en serviceaccounts. Veel daarvan hebben geen vervaldatum, geen duidelijke eigenaar en geen inventaris. Het zijn de reservesleutels die onder de mat liggen. Los van quantum-migraties, beginnen veel echte inbreuken juist hier, en ze komen bijna nooit aan het licht in een migratieplan na quantum-migratie.
Het helpt om je voor te stellen hoe dit mis kan gaan. Een ontwikkelaar maakt een SSH-sleutel aan om een ​​server te bereiken, verlaat later het bedrijf, en de sleutel blijft jarenlang bestaan ​​zonder vervaldatum en zonder enige registratie. Of een buildserver ondertekent software met een sleutel die nooit wordt geroteerd, waardoor één onopgemerkt lek elke volgende release ondermijnt. Geen van beide problemen vereist een kwantumcomputer om schade aan te richten, en geen van beide wordt opgelost door een webcertificaat te vervangen door een nieuw algoritme. Ze worden opgelost door de identiteit van de gebruiker te herkennen, er een levensduur aan toe te kennen en er een eigenaar aan te koppelen.
Een plan dat alleen openbare certificaten vervangt door een nieuw algoritme, negeert dus de twee onderdelen die een reëel risico vormen. Dat zijn de langdurige ankers die door kwantumcomputing daadwerkelijk worden bedreigd, en de onbeheerde identiteiten die aanvallers nu al misbruiken. Een goede strategie voor machine-identiteit moet met al deze aspecten rekening houden, niet alleen met de certificaten die gemakkelijk te tellen zijn. Deze herformulering wijst op een verstandigere aanpak dan de gebruikelijke haast.
Het plannen van de migratie
Begin met het zo kort mogelijk houden van identiteiten en zorg ervoor dat ze automatisch beheerd worden. Waarschijnlijk doet u dit al, zowel vanwege het zero trust-principe als omdat de levensduur van openbare certificaten tegen 2029 naar een maximum van 47 dagen wordt verkort . Wanneer u dit goed doet, wordt het kwantumkritische deel van uw omgeving tot een klein percentage gereduceerd, omdat alles wat kortstondig is, verloopt lang voordat de dreiging reëel wordt.
In de praktijk betekent dit twee dingen. Ten eerste worden certificaten automatisch vernieuwd via dezelfde systemen die uw applicaties al draaien. Ten tweede worden er telkens nieuwe inloggegevens verstrekt wanneer een workload start, in plaats van dat ze ergens worden opgeslagen en hergebruikt. Hoe korter de levensduur en hoe minder menselijke tussenkomst er is, hoe minder er te stelen, te traceren of handmatig te migreren valt wanneer de algoritmes veranderen.
Zoek en herstel vervolgens eerst de onderdelen die het langst meegaan. Identificeer uw vertrouwensankers en uw duurzame handtekeningen, de basiscertificaten en de ondertekening van code en firmware, en plan de overstap naar kwantumveilige algoritmen als eerste. Deze onderdelen hebben de minste speling en het grootste bereik, dus verdienen ze de aandacht die doorgaans alleen aan gewone certificaten wordt besteed.
Stel de inventaris gaandeweg samen en zorg ervoor dat deze ook de identiteiten bevat die geen certificaten zijn. Je kunt niet beschermen wat je niet kunt zien, en SSH-sleutels en vergeten geheimen zijn meestal het minst zichtbaar en het gevaarlijkst.
Koppel dit alles aan één geautomatiseerd systeem voor het uitgeven en beheren van identiteiten. Dit is het echte voordeel, want dat ene systeem betaalt zich drievoudig terug. Het dwingt zero trust af, het houdt gelijke tred met de steeds korter wordende vernieuwingsperioden en het maakt de uiteindelijke overstap naar kwantumveilige algoritmen mogelijk. Zodra dat systeem operationeel is, wordt het wijzigen van een algoritme een instelling in plaats van een heropbouw, en dat is precies waar crypto-agility om draait.
Dit alles wordt in concrete data geplaatst. De limiet van 47 dagen voor certificaten wordt in 2029 bereikt, en NIST heeft voorgesteld om de huidige kwetsbare algoritmen, zoals RSA, ECDSA, ECDH, DSA en Diffie-Hellman, rond 2030 uit te faseren en ze in 2035 volledig te verbieden, hoewel deze richtlijnen nog in conceptfase zijn. De CNSA 2.0-suite van de NSA plaatst de Amerikaanse nationale veiligheidssystemen op een overgangstraject in 2035 (NSM-10), waarbij software- en firmwareondertekening als eerste aan de beurt komen. Ondersteuning hiervoor is vereist in 2025 en exclusief gebruik in 2030, met LMS en XMSS (SP 800-208) als de primaire ondertekeningsalgoritmen.
CNSA 2.0 gebruikt ML-KEM-1024 voor sleuteluitwisseling en ML-DSA-87 voor algemene digitale handtekeningen. Voor federale of gereguleerde kopers moeten deze post-kwantumalgoritmen draaien in een FIPS 140-3 gevalideerde cryptografische module, en FIPS 140-2 certificaten worden in september 2026 als verouderd beschouwd. Het geruststellende is dat als u de meeste van uw identiteiten kortstondig en beheerd hebt, het grootste deel van uw vermogen al een laag risico vormt en u uw energie kunt richten op de paar zaken die dat echt nodig hebben. Goed plannen en een vaste hand zijn daarbij essentieel, en dat is waar deskundige hulp vaak het verschil maakt.
Hoe encryptieconsultancy kan helpen
Onze CBOM Secure- tool van Encryption Consulting speelt een cruciale rol bij de voorbereiding van organisaties. In plaats van te werken met spreadsheets, handmatige OpenSSL-uitvoer of verspreide configuratiebestanden, biedt onze CBOM-tool een helder overzicht van het cryptografische gebruik in verschillende omgevingen. Het laat zien welke algoritmen worden gebruikt, wat er moet veranderen voor beveiliging na de kwantumcomputertijd en of systemen aan de beveiligingsdoelstellingen voldoen. Voor organisaties die zich voorbereiden op bestuursvergaderingen, architectuurkeuzes of complianceplanning, biedt onze tool duidelijkheid en snelheid.
Onze CBOM Secure is meer dan alleen een rapportagetool; het versnelt ook het proces. Het automatiseert cryptografische inventarisaties, controleert TLS-configuraties, valideert algoritmen en stemt beleid af, zodat teams van de ontdekkingsfase direct naar de actiefase kunnen overgaan zonder te hoeven gissen. In toekomstige releases is Encryption Consulting van plan om geautomatiseerde oplossingen, cloud-native integraties en beleidshandhaving toe te voegen om configuraties te allen tijde in lijn te houden met de beveiligingsnormen.
Dit is een uitstekend moment om te beginnen: test PQC in een testomgeving, breng uw huidige cryptogebruik in kaart en begin met het opstellen van interne beleidsregels. Als uw organisatie kwantumveilige projecten wil testen, feedback wil geven of wil meewerken aan de ontwikkeling van nieuwe functies, moedigen wij van Encryption Consulting u aan om contact met ons op te nemen. Hoe eerder de teams beginnen, hoe gemakkelijker het werk op de lange termijn zal zijn.
Heeft uw organisatie behoefte aan ondersteuning, gestructureerde assessments of een begeleide aanpak? Encryption Consulting staat klaar om u te helpen met workshops, advies en implementatieondersteuning met behulp van onze CBOM Secure. Neem vandaag nog contact met ons op, zodat u vol vertrouwen de overstap kunt maken in plaats van te wachten tot u daartoe gedwongen wordt.
Conclusie
Machine-identiteiten zijn stilletjes het meest kwetsbare onderdeel van moderne technologie geworden, en het gangbare advies om alle certificaten in één keer te vervangen, onderschat het risico. Quantum computing bedreigt identiteiten op twee manieren, en de meeste machine-identiteiten zijn kortstondig genoeg om aan de ene kant van die twee uitersten te vallen. Het gevaar concentreert zich in een kleine set langlevende ankers en in de onbeheerde identiteiten die nu al tot datalekken leiden.
De weg vooruit is vrij eenvoudig. Maak de meeste identiteiten tijdelijk en automatisch beheerd, iets waar zero trust je al toe aanzet, en concentreer je vervolgens op de paar identiteiten die echt niet kunnen wachten. Begin met een duidelijke inventarisatie van waar je identiteiten en cryptografie zich bevinden, en laat die inventarisatie de rest bepalen.
