Kies pas een post-quantumalgoritme als u weet waar public-key cryptografie in uw IT-landschap zit. NIST publiceerde in augustus 2024 FIPS 203, 204 en 205 en stelt dat organisaties nu met migreren moeten beginnen. De standaarden zeggen waar u naartoe moet. Ze zeggen niets over wat u vandaag draait, en dat uitzoeken is het tijdrovende deel.
Wat de deadlines van u vragen
Volgens de projectpagina van NIST worden quantum-kwetsbare algoritmen onder de transitietijdlijn in NIST IR 8547 uiterlijk in 2035 afgekeurd (deprecated) en uiteindelijk uit de standaarden van NIST verwijderd, waarbij hoogrisicosystemen veel eerder aan de beurt zijn. Op de pagina van de draft van IR 8547 staat dat de definitieve versie die draft op 27 oktober 2026 verving. In onze bronnen staan de kwetsbare standaarden en de eerdere datums voor hoogrisicosystemen niet vermeld, dus lees die in de eigen tekst van NIST.
De Britse NCSC vertaalt de tijdlijn in zijn guidance on PQC migration timelines naar mijlpalen waartegen een IT-team een budget kan opstellen:
| Uiterlijk | Wat de NCSC verwacht |
|---|---|
| 2028 | Migratiedoelen bepalen, een volledige discovery-oefening afronden, een eerste plan opstellen |
| 2031 | De vroege migratie met de hoogste prioriteit uitvoeren; het plan uitwerken tot een volledige roadmap |
| 2035 | Migratie van alle systemen, diensten en producten afronden |
De inventaris voedt alle drie de taken voor 2028. Is hij mager, dan zijn de andere twee gokwerk.
Wat op de lijst hoort
Het doel is alles wat leunt op asymmetrische public-key cryptografie, die volgens de NCSC door quantumcomputers te breken zal zijn. De discovery-paragraaf van de NCSC beslaat de volgende gebieden:
- systemen en diensten die u beheert, voor interne gebruikers en voor externen;
- producten die u maakt of gebruikt met een functie op het gebied van cryptografie, beveiliging, communicatie of gegevensverwerking;
- softwareapplicaties en netwerkhardware zoals routers, switches, gateways, VPN's en basisstations;
- mobiele apparaten, servers en werkstations;
- IoT- en ICS-apparaten met een communicatiefunctie, tokens die aan gebruikers zijn uitgegeven, en apparaten en sensoren die in het veld zijn geïnstalleerd;
- de data die u bewaart, de verwachte levensduur ervan en de waarde voor een aanvaller, en hoe die data tijdens transport en in rust wordt beschermd.
Certificaten worden in die lijst niet genoemd, hoewel de NCSC een aparte paragraaf over enterprise PKI heeft. Voeg publieke webcertificaten, interne CA's, clientcertificaten en code-signing keys als eigen rijen toe; dat is ons oordeel, niet dat van de NCSC. Voeg ook managed serviceproviders toe.
Dit is geen formeel assetregister. Noteer per systeem de aard, schaal, versie, patchstatus en afhankelijkheden; één rij per systeem volstaat.
Waar inventarissen misgaan
Drie plekken verdienen een bewuste blik, omdat geen ervan opduikt in een certificaatexport of pakketlijst: keys die hard-coded in applicatiecode of configuratie staan, signing keys in een HSM, en firmware in embedded apparaten en apparaten in het veld, die u niet zo kunt updaten als een server. De NCSC noemt langlevende hardware en zeldzame vervangingscycli als beperking, en juist bij die apparaten speelt dat.
De lijst in een week opstellen
Begin top-down, bij de kerndiensten en hun onderlinge afhankelijkheden, en ga daarna bottom-up waar dat beeld ophoudt. Een werkbare verdeling voor een klein team:
- Dag één. Zet de belangrijkste diensten op een rij met de data die elk verwerkt, en markeer data die jarenlang geheim moet blijven. Stuur dezelfde dag de onderstaande e-mail aan leveranciers, want antwoorden duren het langst.
- Dag twee en drie. Exporteer certificaatlijsten van elke CA die u beheert en vraag elk team dat certificaten inkoopt om de zijne. Voeg VPN- en remote-access-configuraties toe. Verzamel SBOM's, lockfiles of pakketlijsten van software die u bouwt en draait, en zoek daarin naar cryptografische libraries en versies. Doorzoek repositories en configuratiemappen op gecommitte private keys en certificaten; elke treffer is een rij, en een private key in een repository moet sowieso worden aangepakt.
- Dag vier. Draai een TLS-scanner tegen externe en interne endpoints en controleer de SSH-hostkeys en de VPN- of IPsec-proposals die uw gateways aanbieden. Vergelijk de resultaten met uw rijen; scanuitvoer is een kruiscontrole, geen vervanging.
- Dag vijf. Voeg alles samen, markeer de hiaten en schrijf "onbekend" waar u iets niet kon bevestigen.
Vragen aan leveranciers die in één e-mail passen:
- Welke van uw producten of diensten die wij gebruiken leunen op public-key cryptografie, en welke libraries en versies bevatten ze?
- Wat is uw PQC-migratieplan, met data?
De NCSC zegt dat u ervoor moet zorgen dat managed providers deze beoordelingen uitvoeren voor de diensten die zij voor u draaien. Schriftelijk vragen is onze aanbeveling om dat te regelen.
De lijst omzetten in een plan
Kies per rij een van de strategieën van de NCSC: in-place migratie, re-platforming, de dienst uitfaseren, laten draaien tot end-of-life, of het risico tolereren. Systemen zonder public-key cryptografie vragen geen actie.
Rangschik de rijen op de levensduur en waarde van de data die ze beschermen, en daarna op afhankelijkheid van langlevende hardware.
Reken erop dat oud en nieuw een tijd naast elkaar draaien. Geef de voorkeur aan producten met cryptografische flexibiliteit (crypto-agility), dat wil zeggen dat ze alternatieve algoritmesuites eenvoudig ondersteunen, en bepaal vooraf wanneer u de traditionele ondersteuning beëindigt.
Pas dan kiest u algoritmen. NIST verwacht dat ML-KEM (FIPS 203) voor key establishment en ML-DSA (FIPS 204) en SLH-DSA (FIPS 205) voor handtekeningen de basis van de meeste implementaties worden. FIPS 203 bevat een planningsnotitie over een kwestie die in een toekomstige revisie wordt gecorrigeerd, dus controleer de errata voordat u op basis ervan implementeert. NIST is nog bezig Falcon en HQC te standaardiseren; de PQC-projectpagina is de plek om wijzigingen in de gaten te houden.
Hulp nodig bij discovery? Ons adviesteam voert assessments uit.
Waar u kunt beginnen
- Wijs een eigenaar aan, reserveer één week en stuur op dag één de e-mail aan leveranciers.
- Maak één rij per systeem: eigenaar, doel, waar public-key cryptografie wordt gebruikt, versies, afhankelijkheden, levensduur van de data, leverancier, gekozen strategie, streefdatum.
- Verzamel certificaten, VPN-configuraties en SBOM's en voer daarna de TLS-, SSH- en repositoryzoekopdrachten uit.
- Controleer hard-coded keys, signing met een HSM en embedded firmware handmatig, en markeer alles wat u niet kunt bevestigen als "onbekend".
- Rangschik de rijen op levensduur van de data en hardwareafhankelijkheid en geef elke rij een NCSC-strategie en streefdatum, zodat de sheet uw plan voor 2028 wordt.
- Lees de definitieve IR 8547 voor de deprecation-data van hoogrisicosystemen en stel interne data eerder dan 2035 vast waar dat vereist is.
