Overgang naar FIPS 140-3 – Tijdlijn en wijzigingen

Gepubliceerd: januari 2021. Bijgewerkt: augustus 2026. Beoordeeld door het HSM Services-team van Encryption Consulting.

FIPS 140 (“Federal Information Processing Standard”) is de Amerikaanse overheidsstandaard voor cryptografische modules, de hardware, firmware en software die sleutels genereren, transacties ondertekenen en gegevens versleutelen binnen een HSM. FIPS 140-3 is de huidige versie. Deze vervangt FIPS 140-2 en de vervanging is geen toekomstige gebeurtenis meer: ​​er is een strikte deadline voor naleving over drie weken. Deze handleiding beschrijft wat FIPS 140-3 precies heeft veranderd, de exacte overgangstermijn en de technische werkzaamheden die nodig zijn voor de migratie van een HSM-vloot, inclusief implementatietopologie, sleutelceremonies, hoge beschikbaarheid en integratietesten, voordat FIPS 140-2-certificaten als verouderd worden beschouwd.

Encryption Consulting publiceert ook een begeleidende gids, FIPS 140-3: Wat organisaties moeten weten vóór september 2026 , die de nalevingsaspecten van deze transitie uitgebreid behandelt, inclusief het onderscheid tussen FIPS Validated, FIPS Compliant en FIPS Capable, en de elf beveiligingsgebieden die een beoordeling moet omvatten. Dit artikel richt zich op de aanschaf van HSM's en de technische migratie: wat er verandert op de hardwarevloer, en niet alleen op het nalevingsformulier.

Wat is FIPS 140-3 en waarin verschilt het van FIPS 140-2?

FIPS 140-3 is de huidige NIST-standaard die de beveiligingsvereisten definieert waaraan een cryptografische module moet voldoen om gevalideerd te worden voor gebruik in Amerikaanse federale systemen en de vele frameworks in de private sector die ernaar verwijzen. Het vervangt FIPS 140-2 en stemt voor het eerst de Amerikaanse federale vereisten voor cryptografische modules af op de internationale standaard ISO/IEC 19790:2012 , met een testmethodologie die is afgestemd op ISO/IEC 24759:2017.

De verschillen zijn niet louter cosmetisch. Vier veranderingen zijn het belangrijkst voor kopers en exploitanten van HSM:

De Omgeving	FIPS 140-2	FIPS 140-3
Niet-invasieve beveiliging	Niet aan de orde gekomen. De weerstand van de zijkanalen is slechts informeel getest, of zelfs helemaal niet.	Een nieuwe, speciaal daarvoor bestemde beveiligingszone. Formele tests voor risicobeperking, waaronder vermogensanalyse, elektromagnetische analyse en timinganalyse, zijn vereist vanaf niveau 3 en hoger.
Integriteit van software en firmware	Minder strenge foutdetectiecontroles werden geaccepteerd.	Vanaf niveau 2 moet de module zijn eigen code verifiëren met een goedgekeurde digitale handtekening of een HMAC-gebaseerde test.
Algoritme ondersteuning	Triple-DES, SHA-1 voor handtekeningen, RSA-1024 en MD5 zijn in veel contexten toegestaan.	Triple-DES, SHA-1 voor digitale handtekeningen, RSA-1024 en MD5 worden volledig geweigerd. TLS 1.0 en 1.1 zijn incompatibel met de goedgekeurde configuratie van de module.
Module typen	Het programma is opgebouwd rond hardwaremodules, waarbij hybride en softwaremodules later zijn toegevoegd aan de hand van interpretatieve richtlijnen.	Hiermee worden hardware-, firmware-, software-, hybride-software- en hybride-firmwaremodules formeel gedefinieerd, zonder beperking op het beveiligingsniveau dat een hybride module kan bereiken.

Twee van deze wijzigingen hebben directe operationele gevolgen voor een HSM-vloot. Niet-invasieve beveiligingstests betekenen dat een HSM-leverancier nu een robuuste weerstand tegen fysieke side-channel-aanvallen moet aantonen, en niet alleen tegen logische aanvallen. Dit is een aanzienlijke lat voor de hardware- en firmware-engineering. De eis inzake software-integriteit dicht een reële lacune in de toeleveringsketen: een gecompromitteerde firmware-update kan het gedrag van een module ongemerkt wijzigen zonder de externe interface aan te passen. FIPS 140-3 vereist dat de module zichzelf tegen precies dat scenario verifieert voordat deze kan worden uitgevoerd.

Wat is het tijdschema voor de overgang naar FIPS 140-3?

Drie data markeren deze overgang, en alle drie worden bevestigd door de gegevens van het Cryptographic Module Validation Program (CMVP) van NIST.

Datum	Milestone
22 september 2019	FIPS 140-3 wordt de geldende norm, die wordt gepubliceerd na goedkeuring door de minister van Handel.
22 september 2020	CMVP accepteert nu aanvragen voor FIPS 140-3-validatie.
1 april 2022	CMVP accepteert geen nieuwe FIPS 140-2-aanvragen meer voor validatiecertificaten. Dit was een verlenging van de oorspronkelijke deadline van 21 september 2021, die gold voor laboratoria en leveranciers die al een contract hadden.
21 september 2026	Alle resterende FIPS 140-2-certificaten worden overgeplaatst naar de CMVP-historische lijst. Deze datum is over drie weken.

Praktische informatie: FIPS 140-3 is al meer dan vier jaar de enige standaard waaraan CMVP nieuwe modules valideert. Wat er op 21 september 2026 verandert, is niet het validatieproces – die overgang heeft al plaatsgevonden – maar de status van alle certificaten die nog steeds onder FIPS 140-2 vallen. Als uw HSM-vloot, de roadmap van uw leverancier of uw inkoopspecificaties nog steeds verwijzen naar FIPS 140-2 als een acceptabele norm, vervalt die verwijzing op een vaste datum, niet op een doorlopende datum.

Wat gebeurt er als een FIPS 140-2-certificaat niet meer geldig is?

De historische status is een wijziging in de CMVP-database, geen noodstop op de hardware. Een HSM met een FIPS 140-2 gevalideerde module blijft versleutelen, ondertekenen en sleutels genereren precies zoals de dag ervoor. Niets op het apparaat stopt met werken op 21 september 2026.

Wat niet meer werkt, is de status van het certificaat als actueel bewijs van gevalideerde cryptografie. Een historisch certificaat voldoet niet langer aan de federale aanbestedingseisen voor nieuwe systemen, biedt op zichzelf geen ondersteuning meer voor FedRAMP Authorization to Operate, voldoet niet langer aan de technische beveiligingseisen van HIPAA op basis van de huidige NIST-normen en houdt geen stand meer bij een PCI HSM-controle of een beoordeling door een financieel toezichthouder. CMVP zelf biedt nog steeds historische modules aan en blijft de aanschaf en het gebruik van bestaande systemen die daarop gebouwd zijn ondersteunen, maar adviseert kopers expliciet om voor nieuwe implementaties te kiezen voor modules die momenteel gevalideerd zijn.

In de praktijk ervaren drie categorieën organisaties dit verschillend:

• Organisaties zonder nalevingsverplichting gekoppeld aan de CMVP-status. Een historisch certificaat is geen prioriteitskwestie. Plan een normale hardwarevernieuwingscyclus in richting FIPS 140-3.
• Organisaties met een nalevingsverplichting die verwijst naar "gevalideerde" cryptografie. (FedRAMP, HIPAA, PCI HSM, defensiecontracten, aanbestedingen van de staat en de federale overheid). Een historisch certificaat is een actuele bevinding die aan het licht zal komen bij de volgende audit, controle of contractverlenging.
• Organisaties zijn momenteel actief bezig met de aanschaf van nieuwe HSM's. Elke inkooporder die FIPS 140-2 als acceptabel validatiedoel specificeert in plaats van een actief FIPS 140-3-certificaat te vereisen, creëert nu al een compliance-kloof voor volgend jaar.

Welke implementatietopologie moet u plannen voor een HSM-vlootmigratie?

De overstap naar FIPS 140-3-gevalideerde modules is een goede stimulans om de HSM-topologie opnieuw te evalueren, in plaats van simpelweg hardware te vervangen. Vier beslissingen bepalen de migratie:

• Gecentraliseerde versus gedistribueerde clusters. Een gecentraliseerd HA-cluster in één of twee datacenters is eenvoudiger te valideren en te bewaken, maar het concentreert het risico. Een geografisch verspreid cluster spreidt het risico en ondersteunt regionale vereisten voor dataopslag, ten koste van complexere sleutelsynchronisatie en netwerksegmentatie.
• On-premises, cloud HSM of hybride. Cloud-HSM-services zoals AWS CloudHSM en Google Cloud HSM worden nu geleverd met FIPS 140-3 Level 3-gecertificeerde hardware, wat een migratie aanzienlijk kan verkorten in vergelijking met een volledige hardwarevernieuwing op locatie. Een hybride model, met HSM's op locatie voor root- en CA-sleutels en een cloud-HSM voor applicaties met een hoge doorvoer, is gebruikelijk wanneer de vereisten voor sleutelbeheer per gebruiksscenario verschillen.
• Partitionering en multi-tenancy. Bepaal of de nieuwe modules logische partities per applicatie of per bedrijfseenheid zullen gebruiken en bevestig dat de FIPS 140-3-grens en het beveiligingsniveau consistent van toepassing zijn op elke partitie, en niet alleen op het fysieke apparaat als geheel.
• Netwerksegmentatie voor beheerinterfaces. HSM-beheer en PKCS#11/KMIP-clientverkeer moeten zich op aparte, strikt gecontroleerde netwerksegmenten bevinden. Gebruik de migratie als controlepunt om te bevestigen dat deze segmentatie nog steeds overeenkomt met de huidige architectuur, vooral als het aantal apparaten is toegenomen sinds de laatste topologiebeoordeling.

Documenteer de gewenste topologie voordat u hardware bestelt. Een migratie die begint met "koop dezelfde box, maar dan nieuwer" leidt vaak tot dezelfde topologieproblemen die de huidige systemen al hebben.

Wat is de FIPS 140-3 cryptografische grens en waarom is die hier van belang?

De cryptografische grens is de expliciete fysieke of logische omtrek die alle hardware-, firmware- en softwarecomponenten omsluit die cryptografische bewerkingen uitvoeren binnen de module. Alles binnen deze grens is als één geheel getest en gevalideerd; niets daarbuiten kan ervan uitgaan dat het de certificaatgarantie biedt, zelfs niet als het zich in dezelfde fysieke behuizing bevindt.

Dit is om drie redenen direct van belang tijdens een migratie. Ten eerste produceert een firmware-update die iets binnen de beveiligingsgrenzen wijzigt, inclusief een patch die cryptografische codepaden aanraakt, technisch gezien een andere module dan de module die gevalideerd is. Daarom moeten leveranciers de bijgewerkte firmware opnieuw indienen voor een eigen certificaat, in plaats van dit te beschouwen als een kleine versie-update. Ten tweede ondersteunt FIPS 140-3 formeel hybride modules (hardware plus firmware, of hardware plus software) zonder beperking op het beveiligingsniveau dat ze kunnen bereiken. Een migratie die het moduletype wijzigt, bijvoorbeeld van een puur hardware-apparaat naar een cloud-HSM-service met een softwarematig beheerd controlevlak, vereist daarom een ​​eigen beoordeling van de beveiligingsgrenzen, en niet de aanname dat "HSM naar HSM" een één-op-één-uitwisseling is. Ten derde is het bij de evaluatie van een cloud-HSM of HSM-as-a-Service-aanbod essentieel om precies te controleren wat zich binnen de gevalideerde beveiligingsgrenzen van de leverancier bevindt en wat zich daarbuiten bevindt in de gedeelde infrastructuur van de provider. Een certificaat dat de onderliggende hardware dekt, dekt niet automatisch elke laag van een multi-tenant service die daarop is gebouwd.

Wat zijn de belangrijkste gevolgen voor de ceremonies bij de overstap naar een nieuw HSM-systeem?

Het overzetten van cryptografisch materiaal naar een nieuw gevalideerde module is zelden een simpele kopieerbewerking, en het behandelen ervan als zodanig is de meest voorkomende technische fout bij een HSM-migratie.

• Root- en CA-sleutels vereisen vrijwel altijd een nieuwe ceremonie. Omdat de cryptografische grens verandert met de module, moeten root-CA's en andere langlevende ondertekeningssleutels over het algemeen opnieuw worden gegenereerd, binnen de gevalideerde grens van de nieuwe module, tijdens een gedocumenteerde ceremonie met getuigen, in plaats van te worden geëxporteerd en opnieuw geïmporteerd. Plan de rollen van beheerders, de M-van-N-quorumvereisten en het vastleggen van bewijsmateriaal (video, ondertekende logboeken, getuigenverklaringen) op dezelfde manier als bij een eerste root-CA-ceremonie.
• Applicatie- en gegevensversleutelingssleutels kunnen een gedocumenteerd migratiepad ondersteunen. Sommige leveranciers bieden beveiligde sleutelklonering of versleutelde export/import tussen modules binnen dezelfde productfamilie, op voorwaarde dat beide modules FIPS-gecertificeerd zijn en de overdracht van begin tot eind versleuteld blijft of gebruikmaakt van split-knowledge-procedures. Controleer deze mogelijkheid en de naleving ervan rechtstreeks bij de leverancier voordat u erop vertrouwt; ga er niet zomaar vanuit dat deze mogelijkheid bestaat.
• Werk uw CP/CPS- en ceremoniedocumentatie bij. Als een certificeringsbeleid of een certificeringspraktijkverklaring verwijst naar specifieke hardware, certificaatnummers of modulenamen, leidt de migratie tot een update van de documentatie, niet alleen een technische update. Deze update zelf vereist mogelijk ook goedkeuring van het management voordat de nieuwe module in productie wordt genomen.
• Bevestig de rollen van beheerder opnieuw. Controleer of de belangrijkste beheerders, ceremoniegetuigen en goedkeurders die in uw governance-documentatie worden genoemd, nog steeds actueel zijn en bevestig hun rollen formeel opnieuw als onderdeel van het ceremonieverslag voor de nieuwe module.

Voor een volledige beschrijving van de ceremoniestructuur, beheersmechanismen en bewijsmateriaal, raadpleegt u de handleiding van Encryption Consulting voor het ontwerpen van een root CA-sleutelceremonie.

Hoe plan je een FIPS 140-3 HSM-migratie?

Een praktische migratieprocedure, in de juiste volgorde:

1. Inventariseer alle cryptografische modules die binnen het toepassingsgebied vallen, inclusief HSM's, cloud-HSM-services en leveranciersbibliotheken, en noteer voor elk ervan het huidige CMVP-certificaatnummer en de status.
2. Controleer elk certificaat rechtstreeks op de pagina 'CMVP Validated Modules Search' in plaats van af te gaan op de marketingclaim van een leverancier over FIPS-conformiteit.
3. Controleer de roadmap van uw HSM-leverancier voor FIPS 140-3-gevalideerde firmware of hardware, inclusief het beoogde certificaatnummer en de verwachte beschikbaarheidsdatum.
4. Bepaal de gewenste implementatietopologie, de locatie in het datacenter of de cloudregio, de grootte van het HA-cluster en het partitioneringsmodel voordat u vervangende hardware bestelt.
5. Plan de sleutelceremonie voor de nieuwe module: rollen van beheerders, M-van-N-quorum, methode voor sleutelgeneratie of -migratie en het vastleggen van bewijsmateriaal.
6. Plaats de nieuwe module naast de bestaande in een parallelle of actief-passieve configuratie en voer de applicatie-integraties in gecontroleerde batches uit.
7. Valideer alle afhankelijke applicaties, back-uppaden en disaster-recovery-knooppunten ten opzichte van de nieuwe HSM voordat u de FIPS 140-2-module buiten gebruik stelt.

Door de lange levertijden van hardware en de wachtrijen voor laboratoriumvalidatie duurt dit proces doorgaans drie tot zes maanden voor een productieomgeving met hoge beschikbaarheidseisen. Het starten van de inventarisatie vandaag, drie weken voor de historische deadline, is nog steeds haalbaar voor de planning, maar voor de meeste organisaties zal de volledige hardwarevervanging niet vóór 21 september 2026 voltooid zijn. Het realistische doel is op dit moment een gedocumenteerd en gefinancierd migratieplan met een actief FIPS 140-3-aanbestedingsproces, en niet een complete vervanging van de gehele vloot.

Hoe waarborgt u hoge beschikbaarheid en back-up tijdens de migratie?

Een HSM-migratie mag nooit een single point of failure creëren, zelfs niet tijdelijk. Een paar regels zorgen ervoor dat de beschikbaarheid gewaarborgd blijft:

• Behoud de N+1-capaciteit gedurende de gehele swap. Voeg de nieuwe FIPS 140-3-module toe aan het cluster naast de bestaande module, in plaats van een knooppunt volledig te vervangen. Zo blijft de failovercapaciteit van het cluster tijdens de migratie altijd binnen de normale capaciteit.
• Controleer of uw back-up HSM's ook FIPS 140-3 gevalideerd zijn. Een back-up- of DR-site HSM die nog steeds FIPS 140-2-firmware gebruikt, ondermijnt het compliancevoordeel van de migratie van het primaire cluster en zal na 21 september 2026 nog steeds een historisch certificaat weergeven.
• Exporteer belangrijke back-ups in een formaat dat de nieuwe module accepteert. Het maken van back-ups en het herstellen van sleutels moet zowel tijdens de overdracht als in rust versleuteld blijven, met behulp van door de leverancier ondersteunde 'wrapped export'- of 'split-knowledge'-procedures die compatibel zijn met de beperkingen van de nieuwe module, en niet met een onbewerkte export die uitgaat van identieke firmware aan beide uiteinden.
• Oefen failover en herstel op de nieuwe modules voordat de omschakeling is voltooid. Test of een live failover naar de nieuwe HSM werkt onder belasting, en of een herstel vanuit een back-up naar een nieuw geconfigureerde module slaagt, voordat u het laatste FIPS 140-2-knooppunt buiten gebruik stelt.

Wat zijn de integratievoorwaarden voordat u kunt migreren?

Controleer het volgende voordat u een applicatie naar de nieuwe module migreert:

• De PKCS#11-, KMIP-, CNG- of JCE-clientbibliotheek van elke applicatie is compatibel met de firmware en API-versie van de nieuwe module. Een bibliotheek die is gebouwd voor een oudere interface kan stilzwijgend falen in plaats van luidruchtig.
• De FIPS-modus is daadwerkelijk ingeschakeld in de productieconfiguratie van elke afhankelijke applicatie, en wordt niet alleen ondersteund door de module. Een FIPS-gevalideerde module die draait in een niet-FIPS-standaardconfiguratie, in de praktijk "FIPS-compatibel" in plaats van "FIPS-conform", is een van de meest voorkomende tekortkomingen die bij compliance-beoordelingen over het hoofd worden gezien.
• Doorvoer en latentie worden getest onder realistische belasting. Niet-invasieve beveiligingsmaatregelen en strengere zelftests in FIPS 140-3-modules kunnen de prestaties van ondertekening en encryptie meetbaar verbeteren ten opzichte van oudere FIPS 140-2-hardware; plan de capaciteit dienovereenkomstig in plaats van uit te gaan van een directe vervanging.
• Monitoring, waarschuwingen en auditlogboeken verwijzen naar het certificaatnummer en de serienummers van de nieuwe module, zodat operationele dashboards en bewijsmateriaal voor naleving accuraat blijven na de overstap.
• De draaiboeken voor sleutelrotatie, back-up en incidentafhandeling zijn bijgewerkt om de procedures van de nieuwe module weer te geven, aangezien de strengere authenticatie- en sleutelbeheerregels van FIPS 140-3 stappen kunnen wijzigen die voorheen routinematig waren.

Wat gebeurt er als je de deadline van 21 september 2026 mist?

De meest voorkomende vorm van falen is geen dramatische uitval. Het is een stille nalevingskloof die ontstaat door onopgemerkte documentatie in de inkoop. Een typisch voorbeeld: een inkoopteam plaatst een verlengingsorder met verwijzing naar hetzelfde HSM-model en specificatieblad dat twee of drie jaar eerder werd gebruikt, waarop FIPS 140-2 nog steeds als acceptabel validatiedoel staat vermeld. De hardware wordt verzonden, geïnstalleerd en werkt technisch gezien prima, maar de organisatie heeft zojuist een module toegevoegd waarvan het certificaat binnenkort, of al, op de lijst met verouderde modules staat, in een omgeving die aan compliance-eisen moet voldoen.

De gevolgen manifesteren zich later en ongelijkmatig: een FedRAMP-controleur die de module continu monitort, wijst de module af, een HIPAA-onderzoek toont aan dat de gebruikte encryptie niet voldoet aan de safe harbor-regeling, een verlenging van een defensiecontract loopt vast omdat het vereiste actieve FIPS 140-3-certificaat niet kan worden overlegd, of een financieel inspecteur opent een onderzoek dat uw team niet kan afsluiten zonder een nieuwe hardwarecyclus. Geen van deze gevallen is hypothetisch; het zijn de directe, voorzienbare gevolgen van een aanbestedingsspecificatie die nooit is bijgewerkt om aan de compliance-deadline te voldoen.

Twee maatregelen dichten deze kloof voordat deze ontstaat. Ten eerste: controleer elke openstaande inkooporder, RFP en leverancierscontract voor HSM-hardware of -firmware en voeg "actief FIPS 140-3 CMVP-certificaat op het moment van levering" toe als een harde vereiste, niet als een voorkeur. Ten tweede: controleer elke HSM-levering die al gepland staat voor na 21 september 2026 aan de hand van het bevestigde FIPS 140-3-certificaatnummer van de leverancier; als de leverancier dit niet kan overleggen, vormt die levering de lacune.

Beslissingstabel voor modulestatus

Modulestatus	Wat te doen	Deadline
FIPS 140-2 certificaat, momenteel actief	Blijf de reeds geïnstalleerde hardware gebruiken; begin nu met de planning en aanschaf van de FIPS 140-3-migratie.	Het certificaat wordt op 21 september 2026 overgeplaatst naar de historische status.
FIPS 140-2 certificaat, reeds historisch of ingetrokken	Gebruik het niet voor nieuwe, aan regelgeving gebonden aanbestedingen; geef prioriteit aan vervanging voor gereguleerde werkzaamheden.	Nu.
FIPS 140-3 certificaat, actief	Voorkeursstatus voor alle nieuwe HSM-aankopen en compliance-gevoelige implementaties.	Doorlopend; bevestig de status bij elke verlenging.
FIPS 140-3-aanvraag vermeld op de CMVP-lijst met modules in behandeling.	Volg de status van de aanvraag; vermeld een aanvraag die nog in behandeling is niet als actuele validatie in een audit of verklaring totdat deze de status 'Actief' heeft bereikt.	Verschilt per leverancier en CMVP-wachtrij.
Geen CMVP-certificaat; leverancier beweert alleen "FIPS-conform" te zijn.	Beschouw dit als niet geverifieerd. Vraag het certificaatnummer aan en bevestig de actieve status rechtstreeks op csrc.nist.gov vóór de implementatie.	Vóór de aanschaf, niet erna.

Beperkingen

Deze handleiding beschrijft het algemene migratiepad voor HSM's en vervangt geen leverancierspecifieke gap-analyse. Sectorspecifieke frameworks, zoals FedRAMP, PCI HSM en defensie-inkoop, kunnen strengere tussentijdse eisen of eigen transitietermijnen opleggen, bovenop de CMVP-deadline. Vereisten voor beveiligingsniveaus (niveau 2, niveau 3 of niveau 4) bepalen ook hoe een "conforme" migratie er voor een bepaalde use case uitziet; een betalings-HSM van niveau 3 en een softwaremodule van niveau 1 hebben niet dezelfde migratielast. Dit artikel richt zich op de validatie van modules volgens FIPS 140-3 en behandelt niet de migratie van post-quantumalgoritmen, wat een gerelateerd maar apart project is voor de meeste HSM-vloten. De status van CMVP-certificaten en de bijbehorende wachttijden kunnen wijzigen; controleer altijd de actuele status op de pagina 'CMVP Validated Modules Search' voordat u een aankoop- of compliancebeslissing neemt.

Wat zou Encryption Consulting aanbevelen?

Begin met een geverifieerde inventaris, niet met een inkooporder. Controleer voordat u een HSM vervangt precies welke modules in uw omgeving actieve FIPS 140-2-certificaten hebben, welke al historische certificaten zijn en welke al FIPS 140-3-gecertificeerd zijn. Alleen al deze inventarisatiestap neemt het grootste deel van het valse vertrouwen weg waarmee organisaties deze deadline tegemoet gaan, aangezien "FIPS-conform" op een leveranciersspecificatieblad en "FIPS 140-3 gevalideerd" in de CMVP-database niet dezelfde bewering zijn.

Van daaruit adviseren we doorgaans twee parallelle trajecten. Het HSM Services -team van Encryption Consulting verzorgt de technische kant: inventarisatie van de hardware, ontwerp van de implementatietopologie, planning en uitvoering van de sleutelceremonie en gefaseerde migratie naar FIPS 140-3-gecertificeerde hardware of cloud-HSM-services, waarbij de hoge beschikbaarheid gedurende het hele proces gewaarborgd blijft. Voor organisaties die de hardware liever beheerd dan zelf in bezit hebben, biedt HSM-as-a-Service FIPS 140-3-gecertificeerde, dedicated HSM-capaciteit zonder de doorlooptijd of kapitaalkosten van een volledige on-premises vernieuwing. Dit kan de tijdlijn voor teams die later starten aanzienlijk verkorten.

Tegelijkertijd brengt het Compliance Advisory- team van Encryption Consulting de migratie in kaart naar het raamwerk waaraan uw organisatie voldoet, zoals FedRAMP, HIPAA, PCI HSM of defensie-inkoop, zodat het bewijsmateriaal (certificaatnummers, ceremonieverslagen, bijgewerkte CP/CPS) klaar is voor de volgende audit of controle in plaats van achteraf te worden samengesteld.

Conclusie

21 september 2026 is geen vaag streefdoel. Het is een vaste datum die CMVP al jaren hanteert en die over enkele weken, niet over kwartalen, dichterbij komt. Organisaties die dit alleen als een hardware-vernieuwing beschouwen, missen de onderdelen die daadwerkelijk risico's met zich meebrengen: een implementatietopologie die nooit opnieuw is geëvalueerd, een sleutelceremonie die informeel in plaats van gedocumenteerd is uitgevoerd, back-up HSM's die nog steeds op oude firmware draaien en integratietests die zijn overgeslagen omdat "het dezelfde HSM is, alleen nieuwer". Het technische werk, de inventarisatie, de geverifieerde certificaatstatus, het topologieontwerp, de sleutelceremonie, de HA-veilige overgang en de integratievalidatie, dat is wat een conforme migratie onderscheidt van een hardwareaankoop die er op papier conform uitziet.

Neem contact op met Encryption Consulting via [email protected] om te beginnen met een inventarisatie van uw HSM-vloot en een migratieplan naar FIPS 140-3 vóór de deadline van 21 september 2026.

Referenties

NIST CSRC: FIPS 140-3 overgangsinspanning

Federal Register: Aankondiging van de publicatie van FIPS 140-3

NIST CSRC: Cryptographic Module Validation Program (CMVP)

Encryptieconsultancy: FIPS 140-3 Wat organisaties moeten weten vóór september 2026