Migreren tussen HSM-leveranciers tijdens de PQC-vernieuwing

Hardwarebeveiligingsmodules (HSM's) zijn de meest conservatieve component in de meeste cryptografische architecturen. Ze zijn duur, gecertificeerd, traag in het doorvoeren van veranderingen, en dat is bewust zo, omdat ze de sleutels bevatten waarop al het andere vertrouwt. Toch lijkt 2026 een jaar van ongebruikelijke HSM-ontwikkelingen te worden, en de reden daarvoor is post-kwantumcryptografie . De belangrijkste leveranciers hebben firmware uitgebracht die de post-kwantumalgoritmen van NIST rechtstreeks in de module integreert, en die ene verandering zet organisaties ertoe aan hun platforms te herzien, systemen te consolideren en in sommige gevallen over te stappen naar een andere leverancier.

Het migreren van sleutels tussen HSM-platformen is een van de meest risicovolle operaties die een cryptografieteam kan uitvoeren. Goed uitgevoerd, is het onzichtbaar. Slecht uitgevoerd, kan het ondertekeningsdiensten verstoren, een vertrouwensbasis ongeldig maken of sleutelmateriaal in een niet-conforme staat achterlaten. Dit artikel legt uit waarom de PQC-update momenteel de drijvende kracht is achter HSM-migraties, wat de migratie technisch gezien inhoudt, welke specifieke risico's moeten worden ingecalculeerd en hoe de werkzaamheden moeten worden gepland om de betrouwbaarheid en beschikbaarheid gedurende het hele proces te waarborgen.

Waarom is dit nu belangrijk?

Drie ontwikkelingen hebben de migratie van HSM-leveranciers van een zeldzaam en moeizaam project tot een actuele vraag voor veel teams in 2026 gemaakt. De post-kwantumalgoritmen zijn nu gestandaardiseerd en worden standaard meegeleverd in de firmware van HSM's; de certificeringsstatus van die firmware verschilt sterk per leverancier; en de prestatie- en sleutelformaatwijzigingen die PQC met zich meebrengt, geven organisaties een logische reden om het platform waarop hun root of trust draait opnieuw te evalueren. Dit is geen anticiperend werk meer: ​​op ML-KEM gebaseerde hybride sleuteluitwisseling is al standaard ingeschakeld in de belangrijkste browsers en TLS-stacks, dus de algoritmen die een HSM moet ondersteunen, zijn de algoritmen die vandaag de dag in productie zijn, niet iets voor de toekomst.

PQC is verplaatst naar binnen de module.

Jarenlang betekende post-quantum-ondersteuning in HSM's een add-on of een experimenteel optiepakket. Dat veranderde in 2025. Entrust kondigde aan dat de implementatie van post-quantum-algoritmen in de firmware van zijn nShield 5 HSM's was voltooid en dat deze CAVP-certificering voor ML-DSA , ML-KEM en SLH-DSA was behaald. Deze mijlpaal werd bereikt met firmwareversie 13.8.0, die in augustus 2025 werd uitgebracht. Thales volgde met Luna HSM-firmwareversie 7.9, die native ML-KEM (FIPS 203) en ML-DSA ( FIPS 204 ) in de firmware integreert, waardoor een externe functionaliteitsmodule niet langer nodig is. Wanneer de twee dominante HSM-platformen voor algemeen gebruik beide tegelijkertijd een productieversie met PQC uitbrengen, versnelt de vernieuwingscyclus in de hele markt.

De gestandaardiseerde set wordt nog steeds uitgebreid. Naast ML-KEM (FIPS 203), ML-DSA (FIPS 204) en SLH-DSA ( FIPS 205 ) selecteerde NIST in maart 2025 de op code gebaseerde HQC als een back-upmechanisme voor sleutelinkapseling, gebouwd op een andere wiskundige basis dan ML-KEM. FN-DSA (FALCON) wordt verwacht als FIPS 206. Een module die vandaag wordt aangeschaft, moet daarom worden beoordeeld op hoe gemakkelijk er later algoritmen aan kunnen worden toegevoegd, en niet alleen op welke algoritmen er nu in zitten.

Vernieuwingscycli dwingen tot platformbeslissingen.

Een firmware-upgrade die PQC toevoegt, is zelden een op zichzelf staande gebeurtenis. Het valt vaak samen met het einde van de levensduur van hardware, capaciteitsplanning voor groter post-quantum sleutelmateriaal en contractverlengingen. Precies op die momenten evalueren organisaties of ze op hun huidige platform moeten blijven of moeten overstappen. PQC verandert ook de prestatieberekening: post-quantum algoritmen zijn zwaarder dan hun klassieke equivalenten, en zowel hun sleutels als handtekeningen zijn aanzienlijk groter, terwijl ondertekenings- en sleuteluitwisselingsbewerkingen per bewerking meer rekenkracht kosten dan RSA of ECC.

De toename in omvang is concreet: een ML-DSA-65-handtekening is ongeveer 3.3 KB en een ML-KEM-768-publieke sleutel ongeveer 1.2 KB, tegenover een ECDSA P-256-handtekening van 64 bytes en een RSA-2048-sleutel van 256 bytes. Gepubliceerde doorvoerbenchmarks variëren sterk afhankelijk van de parameterinstellingen en het platform, maar de trend is consistent: meer cycli per bewerking en aanzienlijk meer opslagruimte per sleutel en per handtekening. Een HSM die is gedimensioneerd voor een RSA- en ECC- workload moet mogelijk opnieuw worden gedimensioneerd voor een post-quantum workload, wat op zich al een reden is voor een nieuwe aanschaf. Dit maakt de PQC-upgrade een logisch moment om te beslissen of het huidige platform moet worden verlengd of dat er volledig moet worden overgestapt naar een andere leverancier.

De certificeringskloof bemoeilijkt gereguleerde migraties.

Kopers in gereguleerde sectoren worden geconfronteerd met een subtiel timingprobleem. Algoritmecertificering en modulecertificering zijn afzonderlijke processen en ze worden niet gelijktijdig afgerond. Eind 2025 beschikken verschillende leveranciers over FIPS 140-3 Level 3 CMVP-validatie voor hun HSM's en afzonderlijk over CAVP-certificering voor de PQC-algoritmen, maar geen enkele had nog FIPS 140-3 Level 3-validatie met PQC-ondersteuning behaald. Alle leveranciers bevonden zich nog in de fase 'Modules in Process' of 'Implementation Under Test'. Thales heeft zijn Luna-firmware v7.9.2 beschreven als de volgende FIPS-kandidaat met PQC, en Entrust heeft de nShield 5-firmware ingediend voor bijgewerkte FIPS 140-3 Level 3-validatie via het CMVP-programma.

Voor een organisatie met een strikte FIPS 140-3 Level 3-verplichting betekent dit dat PQC nu al getest en in een pilotfase kan worden uitgevoerd, maar mogelijk buiten de gevalideerde omgeving moet draaien totdat de gecombineerde certificering is behaald. Deze nuance moet bepalend zijn voor de timing van de migratie. In de praktijk betekent dit dat de gecombineerde FIPS-validatie als een belangrijke mijlpaal voor de productieovergang moet worden beschouwd, terwijl PQC-pilots alleen in een duidelijk afgebakende, niet-gevalideerde omgeving mogen worden uitgevoerd. Twee externe tijdslimieten versterken dit nog verder.

Ten eerste loopt het FIPS 140-2-tijdperk ten einde: op 21 september 2026 plaatst NIST's CMVP alle resterende FIPS 140-2-certificaten op de historische lijst. Na deze datum mogen federale instanties deze certificaten niet meer aanhalen voor nieuwe aanbestedingen. Daarom voeren veel organisaties nu al een FIPS 140-3-update uit, die tevens dient als PQC-update. Ten tweede wordt de migratie steeds vaker verplicht gesteld in plaats van optioneel.

Het CNSA 2.0-programma van de NSA vereist dat National Security Systems overstapt op ML-KEM-1024 en ML-DSA-87. Nieuwe aankopen moeten de suite vanaf 2027 ondersteunen, en de ondertekening van software- en firmwarecontracten moet op zijn vroegst in 2030 plaatsvinden. Executive Order 14144 van januari 2025 heeft deze federale planning verder bekrachtigd. Voor de betrokken kopers is de HSM-beslissing niet langer puur een technische kwestie; het is een probleem met de aanbestedingstermijnen.

Hoe werkt HSM-migratie?

Het overzetten van sleutels tussen HSM-leveranciers wordt beperkt door het doel van een HSM, namelijk het beschermen van privésleutels tegen extractie. Een veilige migratie begint met inzicht in wat er daadwerkelijk wordt overgezet, wat er binnen de module vergrendeld blijft en hoe de twee toonaangevende platforms post-kwantumalgoritmen implementeren. De onderstaande paragrafen behandelen elk aspect afzonderlijk.

Wat HSM-migratie daadwerkelijk verplaatst

Migreren tussen HSM's is geen kwestie van bestanden kopiëren. Sleutelmateriaal in een HSM is over het algemeen niet in platte tekst te exporteren; het verlaat de module alleen in een versleutelde vorm, of het verlaat de module helemaal niet en wordt opnieuw gegenereerd. Bij een migratie moet daarom rekening worden gehouden met de sleutels zelf, het toegangs- en authenticatiemodel eromheen (zoals partities, rollen en quorum- of PED-authenticatie ), het beleid dat bepaalt hoe sleutels mogen worden gebruikt, en de vertrouwensrelaties die afhankelijk zijn van de sleutels, inclusief hiërarchieën van certificeringsinstanties en applicatie-integraties die zijn gekoppeld via PKCS#11.

Het leveranciersmigratiemodel

Leveranciers bieden gestructureerde migratiepaden aan, en inzicht in de werking ervan is belangrijk, zelfs als u migreert tussen verschillende leveranciers in plaats van binnen één leverancier te upgraden. Thales beschrijft drie methoden voor het overzetten van sleutels naar een nieuwe Luna HSM: back-up en herstel, directe slot-naar-slot-kloning en kloning via een tijdelijke high-availability-groep die speciaal voor de migratie is aangemaakt. De richtlijnen van Thales vermelden expliciet dat alle drie de methoden de kloonprotocollen achter de commando's die u uitvoert, aanroepen en dat een tijdelijke HA-groep na gebruik voor de migratie moet worden verwijderd, omdat de leden niet dezelfde softwareversie hebben.

Het detail waar teams vaak tegenaan lopen, is de protocolcompatibiliteit tussen verschillende firmwaregeneraties. In het Luna-model gebruiken oudere HSM's van vóór firmware 7.8.0 een ouder kloonprotocol dat geen rekening houdt met meerdere domeinen. Hierdoor kan een oudere HSM alleen communiceren met het aangewezen primaire domein op een nieuwere HSM. Volgens Thales betekent dit in de praktijk dat het gemeenschappelijke domein tussen bron en doel moet worden ingesteld als het primaire domein op elke HSM met firmware 7.8.0 of nieuwer voordat er gekloond kan worden. Overstappen tussen verschillende generaties en leveranciers zijn volledig afhankelijk van deze compatibiliteitsbeperkingen.

Rollen en authenticatie worden ook overgenomen.

Migratie gaat niet alleen over sleutels; het gaat erom wie ze beheert. De Luna-procedures vereisen specifieke partitierollen: de Partition Security Officer voor HA-bewerkingen en het aanmaken van de Crypto Officer, en de Partition Crypto Officer voor back-up-, herstel- en kloonbewerkingen. Wanneer de bron gebruikmaakt van multifactor-quorumauthenticatie (PED) en het doel van wachtwoordauthenticatie, vermeldt de documentatie dat wachtwoordgeauthenticeerde HSM's geen gebruik kunnen maken van Remote PED, dus moet er lokaal een PED worden aangesloten. Deze operationele details maken deel uit van het migratieontwerp, en zijn geen bijzaak.

Migratie tussen verschillende leveranciers is complexer dan een upgrade binnen dezelfde leverancier.

Wanneer de bron en het doel verschillende leveranciers zijn, bestaan ​​er doorgaans geen handige kloon- en HA-paden, omdat kloonprotocollen leverancierspecifiek zijn. Deze paden zijn afhankelijk van een gedeeld, proprietair kloonprotocol en een gemeenschappelijk beveiligingsdomein dat alleen binnen het ecosysteem van één leverancier bestaat. Een Luna-partitie kan dus niet naar een nShield worden gekloond, en omgekeerd. De enige bruggen tussen leveranciers zijn op standaarden gebaseerde mechanismen zoals PKCS#11-sleutelversleuteling, en zelfs die werken alleen als het sleutelbeleid export toestaat en beide platforms een compatibel versleutelingsmechanisme implementeren.

Bij een migratie tussen verschillende leveranciers worden doorgaans drie benaderingen gekozen: het opnieuw genereren van sleutels op het nieuwe platform en het opnieuw uitgeven van de certificaten of referenties die daarvan afhankelijk zijn (de meest efficiënte methode is wanneer sleutels kunnen worden geroteerd); het inpakken en importeren van sleutels wanneer beide platforms een compatibel sleutelinpakmechanisme ondersteunen en het beleid export toestaat; of, voor een certificeringsinstantie, het opzetten van een nieuwe CA die is geworteld in de nieuwe HSM en het geleidelijk overzetten van certificaten of het migreren van ondergeschikte vertrouwensrelaties. De juiste keuze hangt af van de vraag of de sleutels kunnen worden geroteerd, of ze gedurende de gehele migratie binnen een FIPS-grens moeten blijven en hoeveel downtime de afhankelijke services kunnen tolereren.

Risico's en valkuilen

HSM-migraties concentreren verschillende risicocategorieën in één wijzigingsvenster.

Risico	Veroorzaken	consequentie
Verlies van de basis van vertrouwen	De CA-ondertekeningssleutels zijn onjuist behandeld of niet correct gemigreerd.	Uitgegeven certificaten kunnen niet langer worden gevalideerd of verlengd.
Niet-conforme sleutelstatus	Sleutels die buiten de gevalideerde grens in een configuratie zijn geïmporteerd.	Verlies van FIPS 140-3 niveau 3-conformiteit voor gereguleerde werkzaamheden.
Protocol-incompatibiliteit	De bron- en doelfirmware gebruiken verschillende kloonprotocollen.	De migratie mislukt of maakt stilletjes gebruik van een zwakkere route.
Service-uitvaltijd	Ondertekenings- of TLS-services zijn tijdens de migratie afhankelijk van sleutels.	Stroomstoringen in PKI, code ondertekening, oftewel transactieverwerking.
Capaciteitstekort	HSM is gedimensioneerd voor klassieke workloads, niet voor PQC.	Doorvoervermindering nadat post-kwantumalgoritmen in gebruik worden genomen.
Authenticatie komt niet overeen	De met PED geverifieerde bron is overgezet naar een met wachtwoord geverifieerd doel.	Operationele blokkering of onveilige noodoplossingen.

De nalevingsperiode is de strengste beperking.

Voor gereguleerde kopers is de eerder beschreven certificeringskloof de allerbelangrijkste factor bij de planning. Het uitvoeren van PQC-sleutels in een configuratie die nog niet is gevalideerd volgens FIPS 140-3 Level 3 CMVP, is mogelijk acceptabel voor testen en pilots, maar is niet hetzelfde als het uitvoeren ervan binnen de gevalideerde grenzen. Organisaties die onder FedRAMP, FISMA of vergelijkbare regimes vallen, moeten hun migratietijdlijn afstemmen op de CMVP-voortgang van de leveranciers en weloverwogen beslissen of ze PQC nu al in productie nemen, buiten de gecombineerde validatie, of dat ze dit uitstellen tot de certificering is verkregen. Dit is een gedocumenteerde risicobeslissing, geen detail dat tijdens een audit aan het licht komt.

Belangrijk exportbeleid kan de voor de hand liggende weg blokkeren.

Teams gaan er soms van uit dat sleutels eenvoudigweg kunnen worden ingepakt en verplaatst. In een strikte FIPS 140-3 Level 3-beveiligingsomgeving ondersteunt de HSM alleen goedgekeurde algoritmen en sleuteltypen, en kunnen niet-exporteerbare sleutels helemaal niet worden geëxtraheerd. Thales wijst ook op een huidige Luna-beperking: voor de v7.9.0-release wordt het inpakken van ML-DSA- en ML-KEM-sleutels niet ondersteund, wat direct van invloed is op hoe post-quantum-sleutels kunnen worden verplaatst. Controleer het export- en inpakbeleid voor elke sleutelklasse voordat u een migratiemethode kiest.

Beste praktijken voor implementatie

Een gedisciplineerde HSM- migratie omvat de stappen ontdekking, ontwerp en overschakeling, zodat de vertrouwensbasis nooit in gevaar komt. De onderstaande stappen worden in volgorde uitgevoerd, waarbij elke stap ervan uitgaat dat de vorige is voltooid. Het overslaan van ontdekkings- of compatibiliteitscontroles kan er namelijk toe leiden dat een migratie een sleutel achterlaat die niet kan worden verplaatst.

1. Inventariseer elke sleutel en de bijbehorende afhankelijkheden: Catalogiseer sleutels op type, exporteerbaarheid, beleid, eigenaar en de services die ervan afhankelijk zijn. certificaat autoriteit Een ondertekeningssleutel, een codeondertekeningssleutel en een TLS-sleutel vereisen elk een andere aanpak, en u kunt geen migratiemethode plannen zonder te weten welke sleutels kunnen worden geroteerd en welke niet. Sleutels die door hardwarematige niet-exporteerbaarheid worden beschermd, zoals een CA-rootsleutel, vereisen een andere strategie dan sleutels die eenvoudig opnieuw kunnen worden uitgegeven. Encryption Consulting's CBOM Secure Dit automatiseert de ontdekking door een cryptografische materiaallijst op te stellen die elke sleutel koppelt aan de eigenaar, het beleid en de afhankelijke systemen.
2. Bepaal de migratiemethode per sleutelklasse: Gebruik rotatie en heruitgifte wanneer sleutels kunnen veranderen, vendorcloning of back-up en herstel voor upgrades binnen de leverancier, en sleutelversleuteling alleen wanneer zowel de platforms als het beleid dit ondersteunen. Ga er niet van uit dat één methode geschikt is voor de gehele omgeving en documenteer de gekozen methode voor elke sleutelklasse, zodat het migratieplan controleerbaar is.
3. Los eerst de compatibiliteitsproblemen met de firmware en het protocol op: Controleer bij upgrades binnen dezelfde leverancier de kloonprotocolversies en domeininstellingen voordat u belangrijke wijzigingen aanbrengt, waaronder het instellen van het gedeelde domein als primair domein op nieuwere firmware indien nodig.
4. Leg de nalevingshouding vast: Koppel de migratie aan de voortgang van het CMVP-programma van de leverancier en documenteer expliciet of PQC tijdens de overgang binnen of buiten de gevalideerde grenzen zal opereren. Zorg voor goedkeuring van deze beslissing vóór de implementatie. PQC Advisory Services leest het CMVP-certificaat en het beveiligingsbeleid, niet de brochure, dus de beveiligingsstatus is gebaseerd op wat de validatie daadwerkelijk omvat.
5. Grootte voor belasting na kwantum: Valideer de HSM-doorvoer in een pilot met de zwaardere PQC-algoritmen en plan voor leveranciersacceleratie waar beschikbaar. Entrust merkt bijvoorbeeld op dat nShield 5 gebruikmaakt van een FPGA-gebaseerde beveiligingsprocessor waarvan de PQC-acceleratie via een latere firmware-update kan worden uitgerold. Door te controleren of acceleratie aanwezig is in de firmware die u valideert, voorkomt u een onaangename verrassing wanneer de doorvoer onder belasting wordt gemeten. Wanneer het niet praktisch is om gevalideerde, PQC-compatibele hardware intern te implementeren, biedt HSM-as-a-Service deze op aanvraag.
6. Behoud beschikbaarheid door parallelle uitvoering: Implementeer het nieuwe platform naast het oude, migreer of genereer nieuwe sleutels, valideer afhankelijke services met de nieuwe HSM en schakel pas daarna over. Overweeg voor CA-hiërarchieën kruiscertificering, zodat de vertrouwensoverdracht geleidelijk verloopt.
7. Oefen, en houd vervolgens een terugdraaioptie achter de hand: Test de volledige procedure in een niet-productieomgeving, houd de bron-HSM's beschikbaar en maak er back-ups van totdat de migratie is geverifieerd, en neem ze pas buiten gebruik nadat is bevestigd dat de afhankelijke services stabiel draaien op het nieuwe platform. Een migratie is niet voltooid wanneer de sleutels op de nieuwe HSM aankomen; de migratie is voltooid wanneer het oude platform onopgemerkt kan worden buiten gebruik gesteld.

Wat betekent dit voor beveiligingsteams?

Een HSM-migratie tijdens de PQC-vernieuwing is geen project van één team; het raakt iedereen die afhankelijk is van de root of trust. De verantwoordelijkheden verschillen per functie, maar de combinatie van een leverancierswissel en een cryptografische transitie verhoogt de risico's voor iedereen.

CISO's lopen het risico van een migratie die de vertrouwensbasis van de organisatie aantast en hebben de zekerheid nodig dat de compliance-positie tijdens de verandering behouden blijft, aangezien een onderbreking in de gevalideerde dekking tijdens de migratie op zich al een auditbevinding is. Een PQC Advisory- traject biedt hen een verdedigbaar, gedocumenteerd migratieplan om naar te verwijzen.

De cryptografie- en PKI-teams zijn verantwoordelijk voor de technische aspecten: sleutelbeheer, continuïteit van de CA-hiërarchie en de per-sleutel migratiebeslissingen die het succes bepalen. PKI-as-a-Service kan de CA-hiërarchie naadloos tijdens de migratie overzetten.

Beveiligingsarchitecten beslissen of de vernieuwing ook het moment is om leveranciers te consolideren, crypto-flexibiliteit te omarmen en een nieuw platform te ontwikkelen dat klaar is voor de post-quantumperiode. Een inventarisatie van CBOM Secure laat hen zien wat er daadwerkelijk als eerste moet worden aangepakt.

Infrastructuurengineers plannen de parallelle omgeving, HA-groepen en capaciteit voor zwaardere PQC-workloads. HSM-as-a-Service kan die belasting opvangen zonder dat er hardware hoeft te worden aangeschaft.

Compliance- en auditteams hebben een gedocumenteerd overzicht nodig van hoe sleutels zijn gemigreerd en of ze gedurende het hele proces binnen gevalideerde grenzen zijn gebleven. Dit bewijsmateriaal is een direct resultaat van dezelfde adviesopdracht.

Hoe kan encryptieconsulting u helpen?

HSM-migratie tijdens de PQC-vernieuwing is zelden een geïsoleerde hardwarevervanging; het is één onderdeel van een grotere cryptografische modernisering, en de moeilijkste aspecten zijn de afwegingen: welke sleutels kunnen worden verplaatst, wat het CMVP-certificaat precies dekt en hoe een overgang gefaseerd kan worden uitgevoerd zonder de vertrouwensbasis te verbreken. Dit is precies waar de Post-Quantum Cryptographic Advisory Services van Encryption Consulting van pas komen. Het team beoordeelt uw kwantumrisico, leest het certificaat en het beveiligingsbeleid in plaats van de brochure van de leverancier, en stelt een migratieplan op dat is afgestemd op uw compliance-eisen. Dit plan omvat cryptografische ontdekking, HSM-gereedheid, algoritmeselectie, hybride implementatie en een gefaseerde overgang.

Waar het plan tools vereist voor de uitvoering, maakt dezelfde aanpak gebruik van CBOM Secure voor cryptografische ontdekking en een dynamische cryptografie-lijst (Bill of Materials), HSM-as-a-Service voor FIPS-gevalideerde, PQC-compatibele sleutelbescherming zonder dat er zelf hardware hoeft te worden geïnstalleerd, en PKI-as-a-Service wanneer de migratie het herbouwen of kruiscertificeren van CA-hiërarchieën omvat. Het resultaat is één enkel, door experts geleid programma dat een HSM-leveranciersmigratie transformeert van een risicovol eenmalig project naar een gecontroleerde stap richting crypto-flexibiliteit. Neem contact op met Encryption Consulting voor een beoordeling van uw gereedheid na de kwantumtijdperk en een roadmap voor uw HSM-transitie.

Conclusie

De introductie van native post-quantum cryptografie in de nShield 5- en Luna 7.9-firmware heeft de HSM (Hardware Security Module) getransformeerd van het meest statische onderdeel van de stack tot een actief migratiedoelwit. Dit biedt een kans om te moderniseren, maar HSM-migratie brengt ook reële risico's met zich mee: de vertrouwensbasis, naleving van regelgeving, beschikbaarheid van diensten en sleutelvertrouwelijkheid zijn allemaal afhankelijk van een succesvolle migratie. De certificeringskloof, waarbij PQC-algoritmen CAVP-gevalideerd zijn en modules FIPS 140-3 Level 3-gevalideerd, maar de twee nog niet gecombineerd zijn, is de bepalende factor voor gereguleerde afnemers en zou de timing moeten bepalen.

Migreren tussen HSM-leveranciers tijdens de PQC-vernieuwing beloont vooral een goede voorbereiding. Inventariseer elke sleutel en de bijbehorende afhankelijkheden, kies een migratiemethode per sleutelklasse, los firmware- en protocolcompatibiliteitsproblemen op voordat er iets wordt verplaatst, bepaal uw compliance-positie weloverwogen en voer parallel een geteste terugdraaiprocedure uit. Beschouw de HSM-migratie als de zorgvuldige verplaatsing van een root of trust in plaats van een hardware-upgrade, en de post-quantumvernieuwing wordt een gecontroleerde stap richting crypto-flexibiliteit in plaats van een bedreiging voor de sleutels waarvan al het andere afhankelijk is.