Snabbt svar: De flesta organisationer upptäcker FIPS 140-3 övergången är mycket mer komplex än ett certifikatbyte. Åtta utmaningar spårar ständigt ur program: vilseledande efterlevnadsspråk, en CMVP-valideringskö som löper i tolv till arton månader, äldre algoritmer inbäddade i leverantörskod, HSM-ledtider på tre till sex månader, standardinställningar för moln-KMS som inte är i FIPS-läge, ett okontrollerbart leverantörsekosystem, bedömningsomfång som missar SaaS och enheter, och en tidslinje som är mindre förlåtande än den ser ut. Var och en har en känd lösning, och varje lösning tar tid.

Viktiga takeaways

Leverantörsbekräftelser av "FIPS-efterlevnad” utan ett CMVP-certifikatnummer är overifierbara självdeklarationer. Checking-rute-metoden ger falskt förtroende, inte täckning.
Den vanligaste luckan i produktionsmiljöer är FIPS-kapabel men inte aktiverad: ett giltigt certifikat på en modul som körs i en icke-FIPS-standardkonfiguration, osynlig för standardgranskningar.
CMVP-kön löper mellan tolv och arton månader. En modul som skickades in i mitten av 2025 kanske inte har ett aktivt certifikat senast den 21 september 2026, och statusen "pågående" är inte ett giltigt efterlevnadsläge.
HSM:er är den längsta ledtiden: när ingen uppgraderingsväg för firmware finns tar det tre till sex månader att byta ut systemet, vilket innebär att leverantörssamtalen måste ske i början av programmet.
Ingen större molnleverantör sätter nyckelhantering i FIPS-läge som standard. AWS FIPS-slutpunkter, Azure HSM-baserade nivåer och GCP Cloud HSM nyckelringar är alla explicita konfigurationsval.

Detta är del 2 i en serie i tre delar. del 1 täcker vad FIPS 140-3 kräver, vad som ändrats från FIPS 140-2, och varför tidsfristen den 21 september 2026 har omedelbar efterlevnadsvikt. del 3 är steg-för-steg-handboken.

Så här fungerar det för de flesta FIPS 140-3 samtalen fortsätter. Någon ber sina leverantörer att bekräfta FIPS 140-3-certifiering. Leverantörerna säger ja, vi uppfyller kraven. Organisationen dokumenterar svaret, kryssar i rutan och går vidare, och känner sig rimligt täckt.

Den metoden skapar en falsk trygghetskänsla som på sätt och vis är farligare än ingen bedömning alls. De efterlevnadsluckor som faktiskt uppstår under granskningar och utredningar av intrång är nästan aldrig sådana som alla redan känner till. Det är de strukturella: produkten som har ett giltigt FIPS-certifikat men körs i en icke-FIPS-standardkonfiguration, molnnyckelhanteringstjänsten som pekade mot en standardslutpunkt när efterlevnad kräver FIPS-slutpunkten, HSM-firmwaren som ingen kontrollerade för en FIPS 140-3-uppgraderingsväg förrän det var för sent att ersätta hårdvaran.

Utmaning 1: Språket gör mycket arbete

Tre fraser förekommer synonymt i leverantörssvar, upphandlingsdokument och interna efterlevnadsgranskningar. De behandlas som likvärdiga. Det är de inte, och det är just skillnaden mellan dem som de flesta organisationer blir förvånade över.

FIPS validerad innebär att ett oberoende NIST-ackrediterat laboratorium har testat den specifika modulen i en specifik version, och att NIST har utfärdat ett aktivt certifikat, verifierbart på csrc.nist.gov. Det är detta som efterlevnad faktiskt kräver.
FIPS-kompatibel är en självdeklaration. Inget laboratorium, inget certifikat, ingen extern verifiering.
FIPS-kompatibel betyder att produkten innehåller en FIPS-validerad modul som kan köras i FIPS-läge men som för närvarande körs i en icke-FIPS-standard. Självtester avstängda, algoritmbegränsningar saknas. Certifikatet är giltigt; efterlevnaden är det inte.

Produkter levereras ofta med standardinställningar som inte är FIPS eftersom dessa konfigurationer exponerar mer funktionalitet. Att aktivera FIPS-läge är ett avsiktligt konfigurationssteg, och utan ett specifikt program för att verifiera det, används det ofta inte. Denna lucka genererar inga varningar, visas inte i någon sårbarhetsskanning och är osynlig för vanliga säkerhetsrevisioner. Det enda sättet att hitta den är en dedikerad kryptografisk bedömning som undersöker den faktiska körtidskonfigurationen mot varje moduls säkerhetspolicy.

Utmaning 2: CMVP-kön är längre än din övergångstidslinje

Kön för valideringsprogrammet för kryptografiska moduler har historiskt sett löpt på tolv till arton månader från inlämning till aktivt certifikat. Det är inte en tillfällig eftersläpning; det är en strukturell del av valideringsprocessen.

Den praktiska implikationen: en leverantörsmodul som skickats in för FIPS 140-3-validering i mitten av 2025 kanske inte har ett aktivt certifikat senast den 21 september 2026. Organisationer som behandlar en CMVP-inlämning under process som likvärdig med aktiv certifiering bär på efterlevnadsrisker som de inte har karakteriserat korrekt. En FedRAMP-bedömning, en OCR-revision och en granskning av en finansiell granskare accepterar inte statusen "under process" som ett giltigt efterlevnadsläge.

Svaret: övervaka CMVP:s "In-Process"-lista på csrc.nist.gov för varje leverantörsmodul som ingår, kontakta leverantörer direkt gällande realistiska tidslinjer för slutförande och skapa beredskapsplaner för moduler vars tidslinjer skapar verklig osäkerhet. Dessa samtal måste ske nu, parallellt med resten av bedömningen, eftersom leverantörernas tidslinjer ligger helt utanför er kontroll och inte kan pressas enbart av brådska.

Utmaning 3: Att ta bort äldre algoritmer är inte en konfigurationsändring

FIPS 140-3 förbjuder algoritmer som finns i äldre miljöer inom alla reglerade branscher. Att hitta dem är den enkla delen. Att ta bort dem är en helt annan kategori av problem.

Trippel-DES finns kvar i betalningsgränssnitt, äldre mellanprogram och databaskryptering som inte har berörts på flera år. I många miljöer är det inbäddat i leverantörsstyrd kod som organisationen inte kan ändra. Borttagning kräver en leverantörskoordineringscykel, inte en konfigurationsändring.
SHA-1 Liv i certifikatkedjor från PKI-distributioner stod upp för flera år sedan och utfärdades aldrig på nytt. Att ersätta det innebär att ersätta alla certifikat i kedjan, roten, mellanliggande och löv, vilket leder till kaskadeffekt i alla system som är beroende av dessa certifikat.
RSA-1024 förekommer i äldre PKI-konfigurationer, smartkortssystem och enhetsinbyggda programvaror där endast tillverkaren kan uppdatera kryptografistacken. Dina alternativ är att kontakta tillverkaren och vänta, eller att byta ut enheten.
TLS 1.0 och 1.1 kvarstår på äldre portaler och interna slutpunkter där samordning av plattformsleverantörer upprepade gånger har nedprioriterats. Att hitta dem kräver aktiv skanning; att åtgärda dem kräver leverantörscykler proportionella mot antalet berörda system.

Åtgärdningsvägen för varje åtgärd varierar från en konfigurationsändring som tar timmar till ett leverantörsersättningsprogram som tar månader. Organisationer som startar identifiering sent har helt enkelt inte tid att genomföra de längre vägarna före den 21 september. Det är inte en varning; det är en schemaläggningsbegränsning med en fast slutpunkt.

Utmaning 4: Era HSM:er är den artikel med längst ledtid i programmet

Hårdvarusäkerhetsmoduler är den kryptografiska ryggraden i PKI, nyckelhantering och betalningsbehandling. De är också den komponent med den längsta ledtiden för åtgärdande, och den som är mest sannolikt att ge en obekväm överraskning när frågan om firmware ställs för första gången.

Många driftsatta HSM:er har FIPS 140-2-certifikat som går över till historiska lägen i september. Frågan för var och en av dem är inte bara om det finns ett FIPS 140-3-certifikat för modellen. Det handlar om huruvida den specifika firmwareversionen som körs i produktion har det certifikatet och om leverantören erbjuder en stödd uppgraderingsväg. Många organisationer upptäcker att svaret på den andra frågan är nej.

När det inte finns någon uppgraderingsväg för firmware är utbyte av hårdvara den enda vägen: upphandling, fysisk installation, nyckelmigrering, testning och ändringshantering, tre till sex månader i de flesta miljöer. En organisation som upptäcker detta i juni eller juli 2026 kommer nästan säkert inte att slutföra utbytet före den 21 september. Denna konversation med HSM-leverantörer hör hemma i början av bedömningen, inte efter att allt annat är klart.

Utmaning 5: Din moln-KMS är nästan säkert inte i FIPS-läge

Organisationer som använder huvudämnen cloud Leverantörer av nyckelhantering antar rutinmässigt att detta uppfyller FIPS-efterlevnaden. Det kan det, men inte automatiskt, och inte utan specifika konfigurationsval som inte är standard i någon större molnplattform.

Provider	Vad FIPS-läget faktiskt kräver
AWS KMS	FIPS-slutpunkter (kms-fips.[region].amazonaws.com). Program som anropar regionala standardslutpunkter använder inte den FIPS-validerade sökvägen, oavsett vad den underliggande infrastrukturen (FIPS 140-3 nivå 3 HSM:er) är certifierad för.
Azure Key Vault	Maskinvarubaserad validering gäller Premium-nivån och Managed HSM, båda nu validerade på FIPS 140-3 nivå 3. Key Vault på standardnivå lagrar nycklar i programvara, utanför den maskinvarugränsen.
Google Cloud KMS	Cloud HSM-nyckelringar (FIPS 140-2 nivå 3-validerade HSM:er) måste explicit provisioneras. Programvarunycklar i standard Cloud KMS har endast nivå 1-validering; arbetsbelastningar som kräver hårdvarubaserad säkring behöver Cloud HSM.

Standardgranskningar av molnsäkerhet undersöker inte KMS-slutpunktskonfiguration eller val av nyckelnivåer på kryptografisk nivå. Denna lucka uppstår bara när någon specifikt letar efter den, och i de flesta molnmiljöer har ingen gjort det. Det är konsekvent ett av de vanligaste fynden i de bedömningar vi utför.

Utmaning 6: Dina leverantörer är ett beroende som du inte direkt kan kontrollera

En organisations FIPS 140-3-status är bara så stark som den svagaste kryptografiska modulen i dess leverantörsekosystem. EHR-plattformar, SaaS-verktyg, laboratoriesystem, betalningsprocessorer, betalningsnätverksgränssnitt: alla bäddar in kryptografiska moduler, och varje modul behöver ett aktivt FIPS 140-3-certifikat för att den övergripande statusen ska hålla.

Många leverantörer har ännu inte slutfört FIPS 140-3-validering. Vissa står i kön; andra har inte påbörjats. Disciplinen som gör detta hanterbart är enkel: kräv ett CMVP-certifikatnummer från varje leverantör med moduler inom scopet och verifiera var och en på csrc.nist.gov. Det omvandlar en förtroendeövning till en verifieringsövning, vilket är precis vad tillsynsmyndigheter och revisorer kräver.

Medicintekniska produkter är den svåraste versionen av detta problem. Där du inte kan modifiera kryptografiska stacken kan bara tillverkaren åtgärda det, och deras tidslinjer ligger helt utanför din kontroll. Att engagera dem tidigt är inte förhastat; det är den enda metoden som ger tillräckligt med ledtid för att svara om deras svar inte är lugnande.

Utmaning 7: Din bedömningsomfattning är förmodligen för snäv

Organisationer som genomför interna FIPS-bedömningar tenderar att fokusera på den infrastruktur de redan känner till: HSM:er, TLS slutpunkter och VPN-gateways. Det omfånget missar en betydande del av det faktiska kryptografiska fotavtrycket, och det utelämnade materialet är inte trivialt.

SaaS-plattformar är den kategori som oftast hoppas över. Verktyg för intäktscykeln, plattformar för patientengagemang och analysapplikationer bäddar alla in kryptografiska kontroller som infrastrukturskanningar inte kan nå. Den enda vägen är strukturerade leverantörsfrågeformulär med direkt CMVP-verifiering.
Anpassade applikationer Vid direkta kryptografiska biblioteksanrop behövs en bedömning på kodnivå. Nätverksskanning visar att en TLS-anslutning finns; den visar inte vilken algoritm ett nyckelgenereringsanrop gör, eller om biblioteket som används har ett FIPS-validerat läge som faktiskt är aktiverat.
Uppkopplade enheter och OT-utrustning ligger nästan alltid utanför infrastrukturbedömningar. NIST-dokumentationen noterar att OT-uppdateringscykler mäts i årtionden, vilket innebär att föråldrade algoritmer kan sitta fast i operativa miljöer i åratal utan någon styrningsprocess som någonsin har berört dem.

Utmaning 8: Tidslinjen är mindre förlåtande än den ser ut

Organisationer som startar FIPS 140-3-program i juni 2026 har ungefär fjorton veckor på sig före den 21 september. Det låter som en rimlig tidsram. Om man går igenom beräkningarna blir det knappt.

Grundlig kryptografisk upptäckt och CBOM utveckling tar två till fyra veckor. Gappanalys och riskklassificering tar ytterligare två till tre. Det lämnar sju till tio veckor för all åtgärdsaktivitet, vilket måste tillgodose uppgraderingscykler för HSM-firmware på minst fyra till sex veckor, certifikatutbyte över stora PKI miljöer, omkonfigurering av moln-KMS med nedströmskompatibilitetstestning och tidslinjer för leverantörseskalering utanför din kontroll.

Organisationer som börjar nu kör ett strukturerat program och når den 21 september med en försvarbar hållning. Organisationer som börjar i juli fattar prioriteringsbeslut, åtgärdar de högst prioriterade punkterna och accepterar risker för resten. Organisationer som börjar i augusti hanterar inte en övergång; de hanterar en Efterlevnad glipa.

Hur krypteringskonsulting kan hjälpa

Var och en av dessa åtta utmaningar har en känd lösning. Det som avgör om organisationer når den 21 september med en försvarbar efterlevnadsposition är om de har rätt rådgivningsstruktur och den återstående tidsramen för att genomföra.

FIPS 140-3-efterlevnadsbedömningOmfattande kryptografisk identifiering över HSM:er, TLS-slutpunkter, moln-KMS, PKI, SaaS-plattformar, anpassade applikationer och anslutna enheter, vilket producerar en komplett kryptografisk materiallista med varje lucka klassificerad efter risknivå.
FIPS-lägesverifiering: Konfigurationsbedömning av körtid mot varje moduls säkerhetspolicy. Det här är kontrollen som avslöjar bristen på FIPS-kompatibla men inte kompatibla funktioner som standardgranskningar inte kan upptäcka, och den dyker upp i nästan varje miljö vi undersöker.
Program för leverantörsengagemangDirekt verifiering av CMVP-certifikat för varje leverantörsmodul inom ramen, insamling av certifieringstidslinje, karakterisering av CMVP-risker för eftersläpning och stöd för beslut om ersättning, med start dag ett av uppdraget.
FIPS 140-3-övergångsstrategiEn riskprioriterad, sekvenserad åtgärdsplan som återspeglar de faktiska begränsningarna i din miljö, HSM-ledtider, CMVP-köpositioner, beroenden för molnomkonfiguration och leverantörstillgänglighet, kalibrerad till deadline den 21 september 2026.

Vanliga frågor och svar

Hur lång tid tar CMVP-validering?

Historiskt sett tolv till arton månader från inlämning till ett aktivt certifikat. Status "pågående" accepteras inte som ett giltigt efterlevnadstillstånd av FedRAMP-bedömare, OCR-revisorer eller finansiella granskare.

Räcker det med en leverantörs påstående om FIPS-efterlevnad?

Nej. Utan ett verifierat CMVP-certifikatnummer på csrc.nist.gov är det en overifierbar självdeklaration. Kräv numret, bekräfta aktiv status och matcha modulversionen med vad som faktiskt är distribuerat.

Hur kontrollerar jag om FIPS-läget faktiskt är aktiverat?

Granska körtidskonfigurationen mot varje moduls säkerhetspolicy: bekräfta att självtester körs, att algoritmbegränsningar tillämpas och att konfigurationen matchar det validerade driftläget. Innehav av certifikat ensamt bevisar ingenting om körtillståndet.

Är nyckelhantering i AWS, Azure eller Google Cloud FIPS-kompatibel som standard?

Inte på den säkerhetsnivå som de flesta program behöver. AWS kräver FIPS-slutpunkter (kms-fips.[region].amazonaws.com), Azure kräver den HSM-baserade Premium-nivån eller Managed HSM, och Google Cloud kräver Cloud HSM-nyckelringar för hårdvarubaserade nycklar; programvarunycklar har endast nivå 1-validering. Ingen av dessa är standardkonfigurationen.

Vad händer om min leverantör inte kan certifiera sig före september 2026?

Fatta beslut om beredskap tidigt: riskacceptans med kompenserande kontroller för lågrisksystem, eller ersättningsupphandling för system som hanterar reglerad data. Sena beredskapsbeslut blir omöjliga.

Slutsats

Ingen av de åtta utmaningarna är olöslig. CMVP-eftersläpningen är hanterbar om leverantörsengagemanget börjar tillräckligt tidigt. FIPS-lägesgapet kan identifieras genom en bedömning av runtime-konfigurationen. HSM-ledtiderna ryms inom det tillgängliga fönstret om hårdvarubedömningen sker i början av programmet. Felkonfigurationer i moln-KMS är en engångsåtgärd när någon faktiskt letar efter dem.

Den röda tråden genom alla åtta är tid. Varje utmaning kräver mer av den än organisationer initialt förväntar sig, och ingen kan komprimeras av brådska när deadline är tillräckligt nära för att brådska är det enda tillgängliga verktyget. De organisationer som slutför FIPS 140-3-övergångar i tid behandlar dem som strukturerade program med definierade faser och realistiska tidslinjer, inte projekt som kan accelereras till en sprint när september syns vid horisonten.

Del 3 i den här serien är steg-för-steg-guiden: det kompletta ramverket för migrering i fyra faser, leverantörshanteringsmetoden som avgör om programmet slutförs före deadline och den åtta punkter långa checklistan för efterlevnad som definierar när arbetet faktiskt är klart. Kontakt Krypteringskonsulting på [e-postskyddad] för att boka ditt personliga konsultationssamtal.