Varför post-kvantförtroende börjar inuti hårdvaran

Publicerad: september 2025. Uppdaterad: augusti 2026. Granskad av Encryption Consultings HSM-tjänster och PQC-rådgivningsteam.

Varje post-kvantummigreringsplan når så småningom samma väg: algoritmen kan standardiseras, applikationen kan patchas och certifikatpolicyn kan skrivas om, men inget av det betyder någonting om den privata nyckeln som allt beror på genererades, lagrades eller signerades på hårdvara som inte kan litas på att göra det korrekt. Ett programvarubibliotek kan implementera post-kvantumkryptografi (PQC) perfekt och ändå undergrävas av en nyckel som läckte genom en sidokanal, en slumptalsgenerator som inte var helt slumpmässig, eller firmware som tyst föll tillbaka till en klassisk algoritm under belastning. Det är därför post-kvantumförtroende måste börja inuti hårdvaran, särskilt inuti Hardware Security Module (HSM) som förankrar nyckelgenerering och signering för allt nedströms.

Detta är viktigt nu eftersom standarderna inte längre är teoretiska. NIST slutförde FIPS 203 (ML-KEM) , FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) den 13 augusti 2024, och HSM-leverantörer har ägnat det senaste året åt att omvandla den standardiseringen till leverans av firmware. Den återstående frågan för de flesta företag är inte vilken algoritm de ska välja, utan om hårdvaran under deras PKI, TLS-terminatorer, kodsigneringspipeline och nyckelhanteringssystem faktiskt kan köra dessa algoritmer inom en validerad säkerhetsgräns, i produktionsskala, utan att bryta tillgängligheten.

Varför börjar postkvantberedskap på hårdvaru- och HSM-nivå?

PQC-beredskap börjar på hårdvarunivå eftersom HSM är roten till förtroendet för varje nyckel som algoritmen någonsin berör. Om modulen som genererar, lagrar och använder en ML-KEM- eller ML-DSA-nyckel inte själv är pålitlig, är algoritmens matematiska styrka irrelevant. Fyra garantier på hårdvarunivå överförs direkt till PQC-eran, och var och en förändras på ett specifikt, testbart sätt när större postkvantnycklar kommer in i bilden.

• Oföränderlig enhetsidentitet. En hårdvarubunden identitet som inte kan klonas eller förfalskas autentiserar själva HSM:en gentemot de system som är beroende av den. I ett postkvantumkontext behöver denna identitet i allt högre grad signeras med en kvantresistent algoritm så att en angripare med framtida kvantkapacitet inte kan förfalska den retroaktivt.
• Säker nyckelförvaring. Nycklar som genereras och används inom HSM:s kryptografiska gräns lämnas aldrig i klartext. Detta är mer, inte mindre viktigt, med PQC, eftersom privata nycklar för ML-DSA och SLH-DSA och det operativa tillstånd som vissa signaturscheman kräver är större och dyrare att regenerera om de komprometteras.
• Sann slumpmässig talgenerering. Gitterbaserade scheman som ML-KEM och ML-DSA är beroende av högkvalitativ entropi för nyckelgenerering och, i vissa implementeringar, för randomiserad signering. En hårdvarubaserad True Random Number Generator (TRNG) som skapas från fysiskt brus är en starkare grund för PQC-nyckelmaterial än en mjukvarubaserad pseudoslumpgenerator.
• Säker start och firmware-signering. HSM validerar sin egen firmware innan den körs. Eftersom PQC-firmwareuppdateringar blir rutinmässiga måste säker start verifiera dessa uppdateringar med kvantresistenta signaturer, vilket är precis vad CNSA 2.0 kräver LMS, XMSS eller ML-DSA för i firmware- och programvarusigneringssammanhang.

Ingen av dessa fyra garantier är nya. Det som förändras i PQC-eran är storleken och formen på det material de skyddar, och det är där de flesta bristerna i PQC-beredskap faktiskt uppstår i HSM-kombivagnar i produktion.

CBOM-säkerhet

Få fullständig insyn med kontinuerlig kryptografisk identifiering, automatiserad inventering och datadriven PQC-sanering.

Boka en demo

Vad är det nuvarande läget för PQC-support för HSM-leverantörer?

Alla tre stora HSM-leverantörer, Thales, Entrust och Utimaco, levererar nu NIST CAVP-validerat ML-KEM- och ML-DSA-stöd i nuvarande firmware, levererat som en uppgradering snarare än en hårdvaruersättning. Täckningen av SLH-DSA och de tillståndsfulla hashbaserade signaturschemana är där leverantörerna fortfarande skiljer sig åt, och FIPS 140-3-modulvalidering som kombinerar PQC-algoritmer inom den certifierade gränsen, inte bara algoritmerna isolerat, är den nyaste och mest betydelsefulla differentiatorn.

Leverantör och produktlinje	PQC-algoritmer för frakt	leverans metod	FIPS 140-3-status (per uppdatering)
Thales Luna HSM (firmware 7.9, juli 2025)	ML-KEM (FIPS 203), ML-DSA (FIPS 204), hybrid PQC för säkerhetskopiering och nyckelsynkronisering	Uppgradering av firmware till befintlig Luna-hårdvara, ingen extern funktionsmodul behövs	FIPS 140-3 Nivå 3-validering rapporterades pågå vid lansering
Thales Trusted Cyber ​​Technologies Luna T-serien (firmware 7.15.1, certifikat 5450)	ML-DSA, ML-KEM, LMS, hela CNSA 2.0 PQC-uppsättningen	USA-tillverkad Luna PCIe HSM, Luna Network HSM, Luna as a Service, CipherTrust Manager	FIPS 140-3 Nivå 3 validerad från och med augusti 2026, den första HSM-linjen som kombinerar alla CNSA 2.0 PQC-algoritmer i en FIPS 140-3-validering
Thales Luna 8 (tillkännagavs augusti 2026)	Klassiska och postkvantumalgoritmer på en anpassad kryptografisk processor	Ny hårdvarugeneration, specialbyggd för PQC- och AI-erans arbetsbelastningar	FIPS 140-3 Nivå 3 och Common Criteria-bedömning pågår, ännu inte slutförd vid tillkännagivandet
Entrust nShield (firmware 13.8.0, släppt 22 augusti 2025)	ML-DSA, ML-KEM, SLH-DSA, alla tre NIST CAVP-validerade	Stöd för inbyggd firmware, tillkännagavs med NIST CAVP-validering den 10 september 2025	CAVP-validering på algoritmnivå bekräftad; kontrollera aktuell FIPS 140-3-status på modulnivå före anskaffning
Utimaco u.trust GP HSM (Se-serien och CSe-serien)	ML-DSA (FIPS 204), ML-KEM (FIPS 203), LMS, med SLH-DSA på planen	Quantum Protect-applikationspaket, aktiverat på befintlig hårdvara, inget hårdvarubyte	CAVP-validering på algoritmnivå bekräftad för leveransalgoritmer; inkluderar en egenutvecklad tillståndshanteringsdesign för LMS och XMSS i HA- och backupscenarier

Två saker är värda att vara tydliga med här. För det första är algoritmvalidering och modulvalidering inte samma händelse, och att behandla en leverantörs CAVP-meddelande som bevis på att en specifik HSM-apparat är helt FIPS 140-3-validerad med PQC inom gränsen är ett vanligt upphandlingsmisstag; Encryption Consulting täcker den skillnaden i detalj i Are Your HSMs PQC-Ready?. För det andra är stödet för SLH-DSA (FIPS 205) verkligen ojämnt: Entrust har validerat det, Utimaco listar det som en roadmap, och de Thales-källor som granskats för denna uppdatering bekräftar det inte i leveransens firmware. Om din PQC-roadmap är specifikt beroende av SLH-DSA, till exempel som en konservativ hashbaserad reserv för långlivade signeringsnycklar, bekräfta aktuell leverantörsstatus direkt innan du bestämmer dig för en plattform.

Vad är kryptoagilitet på hårdvarunivå, och varför är det viktigt?

Kryptoagilitet på hårdvarunivå innebär att en HSM kan anta nya algoritmer genom en firmwareuppdatering och ett modulärt SDK, utan en fysisk hårdvaruersättning eller en omdesign av de applikationer som anropar den. Thales, Entrust och Utimacos firmwareuppdateringar ovan är det praktiska beviset: alla tre lade till ML-KEM och ML-DSA till hårdvara som kunder redan ägde, genom en uppgraderingsväg snarare än en gaffeltrucksersättning.

Kryptoagilitet för hårdvara beror på några specifika designval som är värda att kontrollera vid alla beslut om HSM-upphandling eller förnyelse:

• Mekanism för uppdatering av firmware. Kan nytt algoritmstöd levereras som en signerad firmwareuppdatering, och är själva uppdateringsprocessen skyddad av en kvantresistent signatur så att den inte kan förfalskas under övergången?
• Modulära kryptografiska leverantörer. Är PQC-stöd inbyggt i kärnfirmware, som med Thales Luna-metoden, eller levereras det som ett separat applikationspaket, som med Utimacos Quantum Protect? Båda modellerna fungerar, men upphandlings- och licensieringskonsekvenserna skiljer sig åt.
• API och standardjustering. Exponerar HSM PQC-operationer genom nuvarande PKCS#11-mekanismidentifierare och leverantörs-SDK-versioner som dina applikationer redan anropar, eller kräver den en parallell integrationsväg?
• Utrymme för nästa standard. NIST utvärderar fortfarande ytterligare signaturscheman utöver de tre första FIPS-standarderna. En agil HSM-plattform bör kunna absorbera en fjärde algoritmfamilj utan ytterligare hårdvarucykel.

Kryptoagilitet är en säkring, inte en mållinje. En HSM som teoretiskt kan uppgraderas är bara agil i praktiken om din organisation har den firmwareuppdateringsprocess, testmiljö och disciplinen för ändringskontroll som krävs för att faktiskt tillämpa uppgraderingen innan de algoritmer den skyddar blir den svaga länken.

Hur ser en hybrid klassisk plus PQC HSM-distributionstopologi ut?

Nästan ingen organisation går direkt från klassisk till PQC-nativ HSM-verksamhet. Den realistiska distributionstopologin kör klassiska och postkvantumalgoritmer sida vid sida inom samma HSM-kluster under ett flerårigt övergångsfönster, med hjälp av hybridnyckelutbyte och, där applikationen stöder det, dubbla eller sammansatta signaturer.

En typisk hybridtopologi har tre lager:

1. HSM-klusterlagret. Ett HSM-kluster med hög tillgänglighet, oavsett om det är lokala enheter, moln-HSM-instanser eller en HSM-som-en-tjänst driftsättning, kör firmware som stöder både klassiska (RSA, ECC) och PQC (ML-KEM, ML-DSA) algoritmer samtidigt, med partitionering så att olika applikationsgrupper kan migreras enligt oberoende scheman.
2. Protokolllagret. TLS-terminatorer och PKI-utgivningssystem förhandlar om hybridnyckelutbyte, till exempel X25519 i kombination med ML-KEM-768, så en session förblir säker om antingen den klassiska eller post-kvantumkomponenten är trasig. Certifikatutfärdare utfärdar sammansatta eller dubbla certifikat där klientens ekosystem stöder dem, och återgår till klassiska certifikat för klienter som ännu inte förhandlar om PQC.
3. Applikationslagret. Kodsignering, databaskryptering och långlivade arbetsflöden för dokumentsignering anropar HSM för lämplig algoritm per användningsfall, informerad av hur länge signaturen eller chiffertexten behöver förbli tillförlitlig, snarare än att byta varje arbetsbelastning till PQC samma dag.

Beslutet om vilket lager som ska migreras först bör styras av exponering, inte bekvämlighet. Nyckelupprättande som används för konfidentialitet (TLS-sessionsnycklar, VPN-tunnlar, krypterade säkerhetskopior) är utsatt för skörd-nu-dekryptera-senare-attacker idag, eftersom infångad chiffertext kan dekrypteras retroaktivt när en kryptografiskt relevant kvantdator finns. Digitala signaturer som används för autentisering har en annan riskprofil: en signatur som valideras idag blir inte ogiltig retroaktivt, så signeringsarbetsbelastningar kan generellt sekvenseras något efter krypteringsarbetsbelastningar, med det anmärkningsvärda undantaget för långlivade kod- och firmware-signeringsnycklar, där en förfalskad signatur om flera år fortfarande skulle vara skadlig idag. Denna exponeringsbaserade prioritering är samma logik som Encryption Consulting tillämpar i RSA: Secure Today, Scheduled for Retirement , som går igenom den klassiska algoritmsidan av samma migrering.

Hur gäller FIPS 140-3-gränsen för PQC-validerade HSM:er?

FIPS 140-3 -validering gäller för en definierad kryptografisk modulgräns, inte för en algoritm i abstrakt mening. Den distinktionen är den mest missförstådda delen av HSM PQC-upphandling. NIST:s Cryptographic Algorithm Validation Program (CAVP) testar om en implementering av ML-KEM eller ML-DSA är matematiskt korrekt. NIST:s Cryptographic Module Validation Program (CMVP) testar om hela hårdvaru- och firmwaremodulen, inklusive algoritmimplementeringen, nyckelhantering, fysiskt manipuleringsskydd och självtester, uppfyller FIPS 140-3-kraven som en enhet. En leverantör kan inneha ett giltigt CAVP-certifikat för ML-KEM långt innan HSM-enheten som kör den har ett uppdaterat FIPS 140-3-modulcertifikat som täcker PQC-operationer inom gränsen.

Denna lucka är inte hypotetisk. Thales Lunas firmwareuppdatering från juli 2025 levererade ML-KEM- och ML-DSA-stöd med FIPS 140-3 nivå 3-validering som beskrivs som pågående, vilket innebär att algoritmerna var tillgängliga innan modulcertifikatet som täckte dem slutfördes. Det var inte förrän i augusti 2026 som Thales Trusted Cyber ​​Technologies Luna T-serie, som kör firmware 7.15.1 under certifikat 5450, blev den första HSM-linjen som dokumenterats för att kombinera hela CNSA 2.0 PQC-algoritmuppsättningen, ML-DSA, ML-KEM och LMS, inuti en slutförd FIPS 140-3 nivå 3-validering. Det är ungefär ett år mellan algoritmens tillgänglighet och en validerad modulgräns som reglerade köpare faktiskt kan åberopa i en revision.

För organisationer i reglerade miljöer, DFARS, FedRAMP, PCI DSS eller myndigheter som omfattas av CNSA 2.0, är ​​den praktiska regeln: behandla inte en leverantörs PQC-algoritmmeddelande som likvärdigt med en validerad modul som du kan distribuera i en reglerad arbetsbelastning. Fråga specifikt vilket FIPS 140-3-certifikatnummer som täcker den firmwareversion du avser att köra och bekräfta att certifikatets validerade algoritmlista inkluderar de PQC-algoritmer du planerar att använda, inte bara modulens ursprungliga klassiska algoritmuppsättning.

Vilka förändringar sker i nyckelceremonin för PQC-nyckelgenerering?

En PQC-nyckelceremoni följer samma styrningsstruktur som en klassisk ceremoni, dubbel kontroll, bevittnad generering, dokumenterade förvaltarroller, men de tekniska detaljerna i ceremonin ändras på sätt som ett manus skrivet för RSA eller ECC inte tar hänsyn till.

• Större nyckel- och signaturmaterial. En offentlig nyckel för ML-KEM-768 är ungefär 1.2 kB lång och en offentlig nyckel och signatur för ML-DSA-65 är flera kilobyte lång tillsammans, jämfört med 32 till 64 byte för en ECC-nyckel av motsvarande styrka. Ceremonimanus, planering av kapacitet för säkerhetskopiering av media och alla processer som manuellt transkriberar eller verifierar viktiga fingeravtryck måste ta hänsyn till detta före ceremonin, inte under den.
• Entropikrav. Gitterbaserad nyckelgenerering förbrukar mer entropi per operation än ECC-nyckelgenerering. Kontrollera att HSM:s hårdvaru-TRNG-dataflöde är validerat för de PQC-nyckelgenereringsvolymer som din ceremoniplan kräver, särskilt för massnyckelgenereringshändelser inför en migreringsvåg.
• Tillståndskänsliga hashbaserade signaturer behöver tillståndsdisciplin, inte bara nyckeldisciplin. LMS och XMSS, de tillståndsfulla hashbaserade scheman som CNSA 2.0 godkänner för signering av firmware och programvara, genererar ett fast antal engångssignaturblad per nyckel. Ceremoniprocedurer måste dokumentera hur den privata nyckelns signeringsstatus spåras och aldrig återanvänds, inklusive över någon säkerhetskopia eller klon av den nyckeln, eftersom återanvändning av ett engångssignaturblad helt bryter mot säkerhetsgarantin.
• Ceremonimanus och vittnesutbildning. Vittnen och förmyndare som är utbildade i RSA- och ECC-ceremonier behöver en kort, specifik genomgång av vad ett verifieringssteg för en PQC-ceremoni faktiskt bekräftar, eftersom en visuell jämförelse av ett fingeravtryck med en offentlig nyckel på flera kilobyte inte är samma sak som att jämföra ett kort ECC-fingeravtryck.

Hur bedömer ni PQC-beredskap i ert HSM-område?

En strukturerad bedömning besvarar om varje HSM i ert system kan köra PQC idag, kan uppgraderas för att köra det, eller behöver bytas ut innan er migreringsdeadline infaller. Encryption Consulting kör detta som en process i fem steg:

1. Inventera varje HSM och dess firmwareversion. Bygg en komplett inventering av kryptografiska tillgångar som täcker lokala enheter, moln-HSM-instanser och inbäddade moduler, inspelningsmodell, firmwareversion och aktuell FIPS 140-3-certifikatstatus för varje.
2. Kartlägg algoritmanvändning till företagsexponering. Identifiera vilka HSM:er som skyddar nyckeletablering för långlivade konfidentiella data (skörda-nu-dekryptera-senare exponering) kontra signaturer för långlivade förtroendeartefakter som rot-CA:er och firmware-signeringsnycklar, eftersom dessa driver olika migreringsbrådskande faktorer.
3. Bekräfta leverantörens PQC-färdplan och valideringsstatus per modell. För varje HSM-modell i vagnen, bekräfta aktuell tillgänglighet av firmware för ML-KEM, ML-DSA och, om det behövs, SLH-DSA eller LMS/XMSS, samt FIPS 140-3-certifikatet som täcker den firmware, inte bara leverantörens allmänna PQC-meddelande.
4. Testa hybriddrift i en icke-produktionsmiljö. Validera uppgraderingar av firmware, hybridnyckelutbyte och hantering av större nyckel- och signaturer mot verklig applikationstrafik innan du vidrör produktion, inklusive dataflöde och latens under förväntad belastning.
5. Skapa den etappvisa migrerings- och avvecklingsplanen. Sekvensera uppgraderingar efter exponering och affärsrisk, flagga alla HSM som inte kan nå PQC-förberedelser via firmware och kräver utbyte, och sätt avvecklingsdatum som överensstämmer med er CNSA 2.0-tidslinje eller intern efterlevnadstidslinje.

Vilka överväganden gällande hög tillgänglighet och säkerhetskopiering gäller för PQC-aktiverade HSM:er?

Hög tillgänglighet och backupdesign för PQC-aktiverade HSM:er måste lösa två problem som klassisk HSM-klustring inte gjorde: större nyckelmaterial som flyttas mellan klustermedlemmar, och, för tillståndskänsliga hashbaserade signaturer, att förhindra att någon backup- eller redundanshändelse någonsin återanvänder ett signeringstillstånd.

Standard HSM-klustring replikerar nycklar mellan medlemmar så att ett nodfel inte avbryter signerings- eller dekrypteringsoperationer. Med ML-KEM och ML-DSA flyttar replikeringen helt enkelt mer data per nyckel, vilket är en kapacitets- och bandbreddsplaneringsfråga, inte ett strukturellt problem. LMS och XMSS är det svårare fallet: om ett kluster redundansväxlar till en säkerhetskopia som har en osynkroniserad vy över vilka engångssignaturblad som redan har använts, kan samma blad signeras två gånger, vilket bryter mot algoritmens säkerhetsgaranti helt och hållet. Utimacos Quantum Protect-paket adresserar detta direkt med vad leverantören beskriver som en patenterad tillståndshanteringsmetod byggd specifikt för HA- och säkerhetskopieringsscenarier med tillståndskänsliga algoritmer; alla leverantörer eller HSM-plattformar som du utvärderar för LMS- eller XMSS-stöd bör kunna förklara, i specifika tekniska termer, hur det förhindrar återanvändning av tillstånd över klusterredundans och säkerhetskopieringsåterställning, inte bara att det stöder algoritmen.

Säkerhetskopierings- och återställningsprocedurer behöver också uppdaterade antaganden om kapacitet och tidpunkt. Större PQC-nycklar och signaturer innebär att säkerhetskopieringsmedia, krypterade exportfiler och återställningsfönster för katastrofåterställning bör omvärderas snarare än att antas matcha storlek och tidpunkt från klassisk tid.

Vilka är integrationsförutsättningarna innan PQC aktiveras på produktions-HSM:er?

Innan du aktiverar PQC-åtgärder på en produktions-HSM, bekräfta att dessa förutsättningar är på plats, eftersom en saknad sådan förvandlar en planerad uppgradering till ett avbrott:

• Klient-SDK och PKCS#11-leverantörsversioner. Applikationer integreras med HSM via ett klientbibliotek och PKCS#11 eller en leverantörsspecifik SDK; det biblioteket behöver en version som känner igen de nya PQC-mekanismidentifierarna före uppgraderingen av den inbyggda programvaran, annars kommer anrop att misslyckas även om HSM-firmwaren stöder algoritmen.
• Kompatibilitet med PKI- och CA-programvara. Din certifikatutfärdarprogramvara, oavsett om den är lokal eller hanterad PKI-som-en-tjänst plattformen, eller en publik CA-integration, måste ha stöd för utfärdande av certifikat mot PQC eller hybrida publika nycklar innan dessa nycklar är användbara i produktion.
• Stöd för nätverks- och protokollförhandlingar. TLS-terminatorer, lastbalanserare och VPN-gatewayer i trafikvägen behöver TLS-stackar som stöder hybridnyckelutbytesgrupper; en HSM som kan generera ML-KEM-nycklar hjälper inte om ingenting i anslutningsvägen kan förhandla om dem.
• MTU och fragmenteringshantering. Större PQC-nycklar och certifikat ökar storleken på TLS-handskakningsmeddelanden, vilket kan få handskakningar att passera MTU-gränserna för vissa nätverksvägar och exponera fragmenteringshanteringsfel i äldre nätverksutrustning som handskakningar av klassisk storlek aldrig utlöste.
• Övervakning och varning för uppdateringar. Operativa instrumentpaneler och aviseringströsklar som är inställda för klassisk nyckelgenerering och signeringslatens behöver uppdateras, eftersom PQC-operationer har andra, generellt sett högre, beräkningskostnader per operation.

En kryptografisk plattform för identifiering och inventering är det snabbaste sättet att bekräfta dessa förutsättningar över en stor databaser snarare än att kontrollera applikation för applikation; det är just detta som CBOM Secure är byggt för att täcka.

Vilka fellägen bör du planera för?

De flesta PQC-fel vid hårdvaran faller inom ett litet antal förutsägbara kategorier. Att planera för dessa före migreringen minskar risken för ett oplanerat avbrott eller en efterlevnadsbrist som upptäcks under en revision.

Feltillstånd	Varför det händer	Mitigation
Det går inte att uppdatera den inbyggda programvaran för PQC	HSM-hårdvara som har upphört att fungera eller som har upphört att stödjas får aldrig en PQC-firmware-version från leverantören.	Slutdatum för firmware i lager nu; budgetuppdatering av hårdvara för alla modeller utan en bekräftad PQC-firmwareplan
Genomströmning och latens försämras under PQC-belastning	ML-DSA-signering och större nyckelhantering kostar mer beräkning per operation än RSA eller ECC på samma hårdvara	Belastningstesta PQC-verksamheten vid förväntad produktionsvolym före övergång; bekräfta leverantörspublicerade prestandasiffror mot dina egna trafikmönster
Återanvändning av tillståndsbaserad signatur vid redundansväxling	HA-klustermedlemmar eller säkerhetskopieringsåterställningar blir osynkroniserade i LMS- eller XMSS-engångssignaturstatus	Använd HSM-plattformar med dokumenterade, testade tillståndssynkroniseringsgarantier för tillståndskänsliga algoritmer över HA och säkerhetskopiering
Handskakning eller meddelandestorlek bryter äldre nätverksvägar	Större PQC-nycklar och certifikat överskrider MTU- eller buffertantaganden i äldre nätverksutrustning	Testa hybrid TLS-handskakningar över den faktiska nätverksvägen, inklusive eventuella äldre lastbalanserare eller mellanboxar, före produktionslansering
Algoritmen är validerad men modulgränsen är inte	CAVP-algoritmvalidering behandlas som likvärdig med ett slutfört FIPS 140-3-modulcertifikat	Bekräfta det specifika FIPS 140-3-certifikatnumret och dess validerade algoritmlista för den exakta firmwareversionen som distribuerats
Klient- eller programbiblioteksinkompatibilitet	PKCS#11-leverantören eller SDK-versionen föregår PQC-mekanismidentifierarna som den nya firmware exponerar	Uppgradera och testa klientbibliotek i en mellanlagringsmiljö före uppgraderingen av den inbyggda programvaran, inte samtidigt som den

Begränsningar

• NIST IR 8547 är fortfarande ett initialt offentligt utkast från och med denna uppdatering; kommentarsperioden avslutades den 10 januari 2025, och den övergångstidslinje som föreslås är ännu inte slutförd och kan komma att ändras.
• Leverantörens PQC-stöd och FIPS 140-3-certifikatstatus ändras ofta. Leverantörsuppgifterna i den här artikeln återspeglar offentligt tillgänglig information som är aktuell från och med den här uppdateringen. Bekräfta den exakta firmwareversionen och certifikatnumret med leverantören före anskaffning eller distribution.
• CNSA 2.0:s obligatoriska milstolpar gäller direkt för amerikanska nationella säkerhetssystem; kommersiella företag är inte bundna av CNSA 2.0 men många använder det som en planeringsreferens för algoritmval och timing.
• Prestandasiffrorna för PQC-operationer varierar avsevärt beroende på HSM-modell, firmwareversion och arbetsbelastning. Behandla de allmänna riktlinjerna här som en utgångspunkt för dina egna belastningstester, inte som en ersättning för dem.

Vad skulle krypteringskonsulter rekommendera?

Behandla HSM-lagret som den första grinden i varje PQC-migrering, inte den sista att kontrollera. Konkret innebär det att börja med en kryptografisk inventering snarare än en algoritmpilot, bekräfta FIPS 140-3-modulens status snarare än att lita på en CAVP-rubrik, och bygga nyckelceremonin och HA-runbookändringarna innan en enda produktionsnyckel genereras.

Encryption Consultings PQC Advisory Services driver detta som en strukturerad färdplan i nio faser som omfattar kryptografisk upptäckt, riskbaserad prioritering, leverantörs- och hårdvaruutvärdering, hybridarkitekturdesign och fasad implementering, så att hårdvaruskiktet och applikationslagret migrerar enligt ett samordnat schema istället för oberoende av varandra.

Där bristen specifikt gäller hårdvara utvärderar vårt HSM- tjänsteteam aktuell HSM-firmware och FIPS-valideringsstatus mot era PQC-krav, kör proof-of-concept-tester för hybrid- och PQC-nativa konfigurationer och utformar de HA- och nyckelceremoniändringar som tillståndsfulla algoritmer kräver. För fastigheter där det första problemet helt enkelt är att inte veta vad som distribueras var, bygger och underhåller CBOM Secure den kontinuerliga kryptografiska inventeringen som gör varje steg efter det möjligt.

PQC-rådgivningstjänster

Få postkvantberedskap med expertledd kryptografisk bedömning, migreringsstrategi och praktisk implementering i linje med NIST-standarder.

Läs mer

Slutsats

Algoritmer får uppmärksamheten i de flesta PQC-konversationer, men HSM-lagret avgör om dessa algoritmer är tillförlitliga i praktiken. Hårdvaran måste generera PQC-nycklar med verklig entropi, lagra dem inom en validerad gräns, överleva en uppgraderingsväg för firmware som håller jämna steg med en föränderlig standard och stödja HA- och säkerhetskopieringsprocedurer som respekterar de specifika krav som stateful signature-scheman introducerar. Thales, Entrust och Utimaco har båda stängt det mesta av gapet mellan algoritm och stöd under det senaste året, och de första FIPS 140-3-validerade modulerna som kombinerar hela CNSA 2.0 PQC-sviten anlände 2026. Det som återstår är operativt: inventering av din HSM-tillgång, bekräftelse av validering på modulnivå snarare än algoritmnivåmeddelanden, och ombyggnad av nyckelceremonier och HA-runbooks kring större nycklar och, där det är relevant, engångssignaturtillstånd. Organisationer som behandlar hårdvarulagret som startpunkten för PQC-migrering, snarare än en eftertanke till applikationslagret, är de som kommer att vara redo när de deadlines som är viktiga för dem faktiskt anländer.

Vanliga frågor om partihandel med mat och dryck

Behöver vi ny HSM-hårdvara för att stödja PQC, eller räcker det med en firmware-uppgradering? För de flesta HSM:er av nuvarande generation räcker det med en firmware-uppgradering. Thales, Entrust och Utimaco har alla lagt till stöd för ML-KEM och ML-DSA till befintlig hårdvara genom firmware-uppdateringar. Äldre eller uttjänta HSM-modeller som aldrig kommer att få en PQC-firmware-release är undantaget, och dessa måste identifieras och budgeteras för ersättning nu.

Är en leverantörs tillkännagivande om PQC-algoritmen detsamma som en FIPS 140-3-validerad PQC-kompatibel modul? Nej. Algoritmvalidering genom NIST:s CAVP-program och modulvalidering via CMVP är separata processer, och ett gap på ungefär ett år mellan de två har varit typiskt i den nuvarande generationen av PQC-firmware-utgåvor. Bekräfta det specifika FIPS 140-3-certifikatnumret som täcker den firmwareversion du planerar att distribuera.

Vilken PQC-algoritm bör vår HSM stödja först, ML-KEM eller ML-DSA? Prioritera baserat på exponering, inte preferens. ML-KEM skyddar nyckeletablering, som idag är exponerad för "harvest now-decrypt-late"-attacker på all trafik som fångas upp och dekrypteras när en kryptografiskt relevant kvantdator finns. ML-DSA skyddar signaturer, där exponeringsfönstret öppnas senare för de flesta användningsfall, förutom för långlivade kod- och firmware-signeringsnycklar, vilka bör behandlas med samma brådska som nyckeletablering.

Kräver LMS och XMSS annan operativ hantering än ML-DSA? Ja. LMS och XMSS är tillståndskänsliga hashbaserade signaturscheman med ett fast antal engångssignaturblad per nyckel; återanvändning av ett blad, vilket kan ske under en felaktigt hanterad HA-redundans eller säkerhetskopiering, bryter säkerhetsgarantin. ML-DSA och ML-KEM har inte detta krav på tillståndshantering.

Hur mycket större är PQC-nycklar och signaturer än RSA eller ECC i praktiken? En ML-KEM-768 offentlig nyckel är ungefär 1.2 kB jämfört med cirka 32 till 64 byte för en ECC-nyckel av motsvarande styrka, och ML-DSA offentliga nycklar och signaturer ligger på de få kilobyte tillsammans. Planera för detta i kapaciteten för säkerhetskopieringsmedia, storleksgränser för certifikat och handskakningar, och i alla seremoniprocesser som manuellt verifierar nyckelmaterial.

Referensprojekt

• NIST FIPS 203, modulgitterbaserad nyckelinkapslingsmekanismstandard: https://csrc.nist.gov/pubs/fips/203/final
• NIST FIPS 204, modulgitterbaserad standard för digitala signaturer: https://csrc.nist.gov/pubs/fips/204/final
• NIST FIPS 205, standard för statslösa hashbaserade digitala signaturer: https://csrc.nist.gov/pubs/fips/205/final
• NIST IR 8547 (inledande offentligt utkast, november 2024), Övergång till postkvantkryptografistandarder: https://csrc.nist.gov/pubs/ir/8547/ipd
• NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) vägledning: https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
• Thales, Luna HSM v7.9 levererar PQC-beredskap i stor skala: https://cpl.thalesgroup.com/blog/encryption/luna-hsm-pqc-quantum-safe-encryption
• Thales Trusted Cyber ​​Technologies, USA-tillverkad post-kvant HSM uppnår FIPS 140-3 nivå 3: https://www.thalestct.com/hsm-fips140-3-validation/
• Thales Group, Thales bygger kryptografisk säkerhet för AI-åldern och postkvantberäkning (Luna 8): https://www.thalesgroup.com/en/news-centre/press-releases/thales-builds-cryptographic-security-age-ai-and-post-quantum-computing
• Entrust, nShield HSM:er Post-kvantkryptografiska algoritmer uppnår validering från NIST:s kryptografiska algoritmvalideringsprogram: https://www.entrust.com/company/newsroom/entrust-nshield-hsms-achieve-validation-from-nist-cryptographic-algorithm-validation-program
• Utimaco, Deadline efter kvantum 2029: Kan era HSM:er genomföra migreringen? https://utimaco.com/news/blog-posts/post-quantum-hsm-migration-2029