Schnelle Antwort: Die meisten Organisationen entdecken die FIPS 140-3 Die Umstellung ist deutlich komplexer als ein Zertifikatstausch. Acht Herausforderungen führen immer wieder zum Scheitern von Projekten: irreführende Formulierungen zur Einhaltung von Vorschriften, eine CMVP-Validierungswarteschlange mit einer Bearbeitungszeit von zwölf bis achtzehn Monaten, veraltete Algorithmen im Quellcode von Anbietern, HSM-Vorlaufzeiten von drei bis sechs Monaten, Cloud-KMS-Standardeinstellungen, die nicht dem FIPS-Modus entsprechen, ein unkontrollierbares Anbieter-Ökosystem, Bewertungsbereiche, die SaaS und Endgeräte nicht berücksichtigen, und ein Zeitplan, der weniger Spielraum lässt als er scheint. Für jede dieser Herausforderungen gibt es eine bekannte Lösung, und jede Lösung kostet Zeit.

Die zentralen Thesen

Lieferantenbestätigungen von „FIPS-KonformitätSelbstauskünfte ohne CMVP-Zertifikatsnummer sind nicht überprüfbar. Das bloße Abhaken von Checklisten erzeugt falsches Vertrauen, aber keine umfassende Abdeckung.
Die häufigste Lücke in Produktionsumgebungen ist die FIPS-Fähigkeit, die jedoch nicht aktiviert ist: ein gültiges Zertifikat auf einem Modul, das in einer Nicht-FIPS-Standardkonfiguration läuft und für Standardprüfungen unsichtbar ist.
Die CMVP-Warteschlange hat eine Laufzeit von zwölf bis achtzehn Monaten. Ein Mitte 2025 eingereichtes Modul kann bis zum 21. September 2026 möglicherweise kein aktives Zertifikat besitzen, und der Status „In Bearbeitung“ ist kein gültiger Konformitätsstatus.
HSMs haben die längste Lieferzeit: Wenn kein Firmware-Upgrade möglich ist, dauert der Austausch drei bis sechs Monate, was bedeutet, dass das Gespräch mit dem Hersteller zu Beginn des Programms stattfinden muss.
Kein großer Cloud-Anbieter setzt die Schlüsselverwaltung standardmäßig auf FIPS. AWS FIPS-Endpunkte, Azure HSM-gestützte Tarife und GCP Cloud HSM Schlüsselringe sind allesamt explizite Konfigurationsoptionen.

Dies ist Teil 2 einer dreiteiligen Serie. Teil 1 behandelt die Anforderungen von FIPS 140-3 und die Änderungen gegenüber FIPS 140-2und warum die Frist am 21. September 2026 unmittelbare Bedeutung für die Einhaltung hat. Teil 3 ist die Schritt-für-Schritt-Anleitung.

So funktioniert es bei den meisten FIPS 140-3 Die Gespräche verlaufen wie gewohnt. Jemand bittet seine Lieferanten um Bestätigung der FIPS-140-3-Zertifizierung. Die Lieferanten bestätigen die Konformität. Das Unternehmen dokumentiert die Antwort, hakt das Kontrollkästchen ab und kann sich beruhigt zurücklehnen.

Dieser Ansatz erzeugt ein trügerisches Sicherheitsgefühl, das in mancher Hinsicht gefährlicher ist als gar keine Prüfung. Die Compliance-Lücken, die bei Audits und Untersuchungen von Sicherheitsvorfällen tatsächlich zutage treten, sind fast nie die, die ohnehin bekannt sind. Es handelt sich vielmehr um strukturelle Lücken: ein Produkt mit gültigem FIPS-Zertifikat, das jedoch in einer nicht FIPS-konformen Standardkonfiguration läuft; ein Cloud-Key-Management-Dienst, der auf einen Standardendpunkt verweist, obwohl die Compliance einen FIPS-Endpunkt erfordert; oder eine HSM-Firmware, deren Upgrade-Pfad gemäß FIPS 140-3 erst dann geprüft wurde, als es für einen Hardwareaustausch bereits zu spät war.

Herausforderung 1: Die Sprache leistet viel Arbeit.

Drei Formulierungen werden in Lieferantenantworten, Beschaffungsunterlagen und internen Compliance-Prüfungen synonym verwendet. Sie werden als gleichwertig behandelt. Das sind sie aber nicht, und genau diese Diskrepanz ist es, die die meisten Unternehmen überrascht.

FIPS-validiert Das bedeutet, dass ein unabhängiges, vom NIST akkreditiertes Labor das jeweilige Modul in einer bestimmten Version getestet hat und das NIST ein gültiges Zertifikat ausgestellt hat, das unter csrc.nist.gov verifiziert werden kann. Dies ist die tatsächliche Voraussetzung für die Einhaltung der Vorschriften.
FIPS-konform Es handelt sich um eine Selbsterklärung. Kein Labor, kein Zertifikat, keine externe Überprüfung.
FIPS-fähig Das Produkt enthält ein FIPS-validiertes Modul, das im FIPS-Modus ausgeführt werden kann, aktuell aber im Standardmodus (nicht FIPS) läuft. Selbsttests sind deaktiviert, algorithmische Beschränkungen werden nicht durchgesetzt. Das Zertifikat ist gültig, die Konformität jedoch nicht.

Produkte werden häufig in nicht FIPS-konformen Standardkonfigurationen ausgeliefert, da diese mehr Funktionalität bieten. Die Aktivierung des FIPS-Modus ist ein bewusster Konfigurationsschritt, der ohne ein spezielles Überprüfungsprogramm oft nicht durchgeführt wird. Diese Sicherheitslücke erzeugt keine Warnmeldungen, wird bei keinem Schwachstellenscan erkannt und bleibt bei Standard-Sicherheitsaudits unsichtbar. Sie lässt sich nur durch eine gezielte kryptografische Prüfung aufdecken, die die tatsächliche Laufzeitkonfiguration mit der Sicherheitsrichtlinie jedes Moduls vergleicht.

Herausforderung 2: Die CMVP-Warteschlange ist länger als Ihr Übergangszeitraum

Die Warteschlange des Programms zur Validierung kryptografischer Module hatte in der Vergangenheit eine Bearbeitungszeit von zwölf bis achtzehn Monaten von der Einreichung bis zur Aktivierung des Zertifikats. Dies ist kein vorübergehender Rückstand, sondern ein strukturelles Merkmal des Validierungsprozesses.

Die praktische Konsequenz: Ein Mitte 2025 zur FIPS-140-3-Validierung eingereichtes Modul eines Anbieters verfügt möglicherweise bis zum 21. September 2026 nicht über ein gültiges Zertifikat. Organisationen, die einen laufenden CMVP-Einreichungsantrag fälschlicherweise einer aktiven Zertifizierung gleichsetzen, gehen ein Compliance-Risiko ein, das sie nicht korrekt eingeschätzt haben. Weder eine FedRAMP-Bewertung noch ein OCR-Audit oder eine Prüfung durch einen Finanzprüfer akzeptieren den Status „in Bearbeitung“ als gültigen Compliance-Status.

Die Antwort: Überprüfen Sie die CMVP-Liste für laufende Projekte unter csrc.nist.gov für jedes relevante Anbietermodul, sprechen Sie direkt mit den Anbietern über realistische Fertigstellungstermine und erstellen Sie Notfallpläne für Module, deren Zeitpläne echte Unsicherheiten mit sich bringen. Diese Gespräche müssen jetzt parallel zur übrigen Bewertung stattfinden, da die Zeitpläne der Anbieter vollständig außerhalb Ihres Einflussbereichs liegen und nicht allein durch Dringlichkeit verkürzt werden können.

Herausforderung 3: Das Entfernen veralteter Algorithmen ist keine Konfigurationsänderung

FIPS 140-3 verbietet Algorithmen, die in veralteten Systemen aller regulierten Branchen vorhanden sind. Sie zu finden ist der einfache Teil. Sie zu entfernen ist eine ganz andere Herausforderung.

Triple-DES Es ist weiterhin in Zahlungsschnittstellen, veralteter Middleware und seit Jahren unveränderter Datenbankverschlüsselung vorhanden. In vielen Umgebungen ist es in herstellerkontrolliertem Code eingebettet, den das Unternehmen nicht ändern kann. Die Entfernung erfordert einen Abstimmungsprozess mit dem Hersteller, keine Konfigurationsänderung.
SHA-1 Die Zertifikate stammen aus PKI-Implementierungen, die vor Jahren eingerichtet und nie erneuert wurden. Ein Austausch würde bedeuten, jedes einzelne Zertifikat in der Kette – Stamm-, Zwischen- und Endzertifikate – zu ersetzen, was sich wiederum auf alle Systeme auswirkt, die von diesen Zertifikaten abhängen.
RSA-1024 Dieses Problem tritt bei älteren PKI-Konfigurationen, Smartcard-Systemen und Geräte-Firmware auf, bei denen nur der Hersteller den kryptografischen Stack aktualisieren kann. Sie haben die Wahl, sich an den Hersteller zu wenden und abzuwarten oder das Gerät auszutauschen.
TLS 1.0 und 1.1 Die Probleme bestehen weiterhin auf älteren Portalen und internen Endpunkten, wo die Koordination mit Plattformanbietern wiederholt vernachlässigt wurde. Um sie zu finden, ist ein aktives Scannen erforderlich; die Behebung erfordert mehrere Abstimmungszyklen mit den Anbietern, die proportional zur Anzahl der betroffenen Systeme sind.

Die Lösungsansätze variieren je nach Problem – von einer Konfigurationsänderung, die nur wenige Stunden dauert, bis hin zu einem monatelangen Austauschprogramm des Herstellers. Organisationen, die erst spät mit der Problemanalyse beginnen, haben schlichtweg nicht die Zeit, die längeren Lösungsansätze vor dem 21. September umzusetzen. Dies ist keine Warnung, sondern eine terminliche Einschränkung mit einem festen Stichtag.

Herausforderung 4: Ihre HSMs haben die längste Lieferzeit im Programm.

Hardware-Sicherheitsmodule bilden das kryptografische Rückgrat von PKI, Schlüsselverwaltung und Zahlungsabwicklung. Sie sind auch die Komponente mit der längsten Vorlaufzeit für die Fehlerbehebung und bergen die größten Risiken, wenn erstmals Fragen zur Firmware auftauchen.

Viele eingesetzte HSMs verfügen über FIPS 140-2-Zertifikate, die im September ihre Gültigkeit verlieren. Die Frage ist nicht nur, ob für das jeweilige Modell ein FIPS 140-3-Zertifikat existiert, sondern auch, ob die im Produktivbetrieb eingesetzte Firmware-Version dieses Zertifikat besitzt und ob der Hersteller ein unterstütztes Upgrade anbietet. Viele Unternehmen stellen fest, dass die Antwort auf die zweite Frage „Nein“ lautet.

Wenn kein Firmware-Upgrade möglich ist, bleibt nur der Hardwareaustausch: Beschaffung, Installation, Schlüsselmigration, Tests und Änderungsmanagement – in den meisten Umgebungen drei bis sechs Monate. Ein Unternehmen, das dies erst im Juni oder Juli 2026 feststellt, wird den Austausch mit hoher Wahrscheinlichkeit nicht vor dem 21. September abschließen können. Dieses Gespräch mit HSM-Anbietern sollte daher zu Beginn der Bewertung geführt werden, nicht erst, wenn alle anderen Schritte abgeschlossen sind.

Herausforderung 5: Ihr Cloud-KMS befindet sich mit ziemlicher Sicherheit nicht im FIPS-Modus.

Organisationen, die große Cloud Anbieter von Schlüsselverwaltungslösungen gehen üblicherweise davon aus, dass dies die FIPS-Konformität gewährleistet. Das kann zwar der Fall sein, aber nicht automatisch und nicht ohne spezifische Konfigurationseinstellungen, die bei keiner gängigen Cloud-Plattform standardmäßig aktiviert sind.

Provider	Was der FIPS-Modus tatsächlich erfordert
AWS-KMS	FIPS-Endpunkte (kms-fips.[region].amazonaws.com). Anwendungen, die Standard-Regionalendpunkte aufrufen, nutzen nicht den FIPS-validierten Pfad, unabhängig davon, wofür die zugrunde liegende Infrastruktur (FIPS 140-3 Level 3 HSMs) zertifiziert ist.
Azure Key Vault	Die hardwaregestützte Validierung gilt für die Premium-Stufe und Managed HSM, die beide jetzt nach FIPS 140-3 Level 3 validiert sind. Key Vault der Standard-Stufe speichert Schlüssel in Software, außerhalb dieser Hardwaregrenze.
Google Cloud KMS	Cloud-HSM-Schlüsselringe (FIPS 140-2 Level 3-validierte HSMs) müssen explizit bereitgestellt werden. Software-Schlüssel in Standard-Cloud-KMS verfügen lediglich über eine Level-1-Validierung; Workloads, die eine hardwaregestützte Sicherheit erfordern, benötigen Cloud-HSM.

Standardmäßige Cloud-Sicherheitsüberprüfungen untersuchen weder die KMS-Endpunktkonfiguration noch die Auswahl der Schlüsselebene auf kryptografischer Ebene. Diese Lücke tritt nur dann zutage, wenn gezielt danach gesucht wird, was in den meisten Cloud-Umgebungen bisher nicht der Fall war. Sie zählt zu den häufigsten Feststellungen in unseren Bewertungen.

Herausforderung 6: Ihre Lieferanten sind eine Abhängigkeit, die Sie nicht direkt kontrollieren können.

Die FIPS-140-3-Sicherheit einer Organisation ist nur so stark wie das schwächste kryptografische Modul in ihrem Anbieternetzwerk. Plattformen für elektronische Patientenakten (EHR), SaaS-Tools, Laborsysteme, Zahlungsabwickler, Schnittstellen zu Kostenträgernetzwerken: Sie alle enthalten kryptografische Module, und jedes Modul benötigt ein gültiges FIPS-140-3-Zertifikat, damit die Gesamtsicherheit gewährleistet ist.

Viele Anbieter haben noch nicht abgeschlossen FIPS Die Validierung nach Abschnitt 140-3 ist teilweise in Bearbeitung, teilweise noch nicht. Die Vorgehensweise, die dies ermöglicht, ist einfach: Von jedem Anbieter mit relevanten Modulen muss eine CMVP-Zertifikatsnummer angefordert und diese unter csrc.nist.gov verifiziert werden. Dadurch wird aus einer Vertrauensprüfung eine Verifizierungsprüfung – genau das, was Aufsichtsbehörden und Prüfer fordern.

Medizinprodukte stellen die größte Herausforderung in diesem Bereich dar. Da die kryptografischen Sicherheitsmechanismen nicht modifiziert werden können, kann nur der Hersteller Abhilfe schaffen, und dessen Zeitvorgaben liegen völlig außerhalb Ihres Einflussbereichs. Eine frühzeitige Kontaktaufnahme ist daher nicht verfrüht, sondern der einzige Ansatz, der genügend Zeit für eine Reaktion lässt, falls die Antwort nicht zufriedenstellend ausfällt.

Herausforderung 7: Ihr Bewertungsrahmen ist wahrscheinlich zu eng gefasst.

Organisationen, die interne FIPS-Bewertungen durchführen, konzentrieren sich in der Regel auf die ihnen bereits bekannte Infrastruktur: HSMs, TLS Endpunkte und VPN-Gateways. Dieser Umfang erfasst einen wesentlichen Teil der tatsächlichen kryptografischen Signatur nicht, und das ausgelassene Material ist nicht trivial.

SaaS-Plattformen Diese Kategorie wird am häufigsten übersprungen. Tools für den Umsatzzyklus, Plattformen zur Patienteneinbindung und Analyseanwendungen enthalten alle kryptografische Kontrollen, die Infrastrukturscans nicht erreichen können. Der einzige Weg führt über strukturierte Fragebögen der Anbieter mit direkter CMVP-Verifizierung.
Benutzerdefinierte Anwendungen Direkte Aufrufe kryptografischer Bibliotheken erfordern eine Codeanalyse. Netzwerkscans zeigen zwar eine bestehende TLS-Verbindung an, geben aber keine Auskunft darüber, welcher Algorithmus bei der Schlüsselerzeugung verwendet wird oder ob die verwendete Bibliothek über einen FIPS-validierten Modus verfügt, der tatsächlich aktiviert ist.
Vernetzte Geräte und OT-Ausrüstung Sie fallen fast immer nicht in Infrastrukturbewertungen. Die NIST-Dokumentation weist darauf hin, dass OT-Aktualisierungszyklen in Jahrzehnten gemessen werden, was bedeutet, dass veraltete Algorithmen jahrelang in Betriebsumgebungen verbleiben können, ohne dass ein Governance-Prozess sie jemals berührt hat.

Herausforderung 8: Der Zeitplan ist weniger nachsichtig als er aussieht.

Organisationen, die im Juni 2026 mit FIPS 140-3-Programmen beginnen, haben bis zum 21. September noch etwa vierzehn Wochen Zeit. Das klingt nach einem machbaren Zeitraum. Eine genauere Berechnung zeigt jedoch, dass es knapp ist.

Gründliche kryptographische Ermittlung und CBOM Die Entwicklung dauert zwei bis vier Wochen. Gap-Analyse und Risikoklassifizierung benötigen weitere zwei bis drei Wochen. Somit verbleiben sieben bis zehn Wochen für alle Abhilfemaßnahmen, die die Firmware-Upgrade-Zyklen des HSM von mindestens vier bis sechs Wochen sowie den Zertifikatsaustausch in großen Systemen berücksichtigen müssen. PKI Umgebungen, Cloud-KMS-Rekonfiguration mit Downstream-Kompatibilitätstests und Eskalationsfristen der Anbieter, die außerhalb Ihrer Kontrolle liegen.

Organisationen, die jetzt beginnen, führen ein strukturiertes Programm durch und erreichen den 21. September mit einer soliden Ausgangslage. Organisationen, die im Juli beginnen, priorisieren die dringendsten Probleme und tragen das Risiko für die übrigen. Organisationen, die im August beginnen, managen keinen Übergang, sondern einen … Compliance Spalt.

Wie Verschlüsselungsberatung helfen kann

Für jede dieser acht Herausforderungen gibt es eine bekannte Lösung. Ob Organisationen bis zum 21. September über eine rechtssichere Compliance-Strategie verfügen, hängt davon ab, ob sie die richtige Beratungsstruktur haben und genügend Zeit für die Umsetzung zur Verfügung steht.

FIPS 140-3 Konformitätsbewertung: Umfassende kryptografische Erkennung über HSMs, TLS-Endpunkte, Cloud-KMS, PKI, SaaS-Plattformen, kundenspezifische Anwendungen und verbundene Geräte hinweg, wodurch eine vollständige kryptografische Stückliste erstellt wird, wobei jede Lücke nach Risikostufe klassifiziert wird.
FIPS-Modusprüfung: Laufzeitkonfigurationsprüfung anhand der Sicherheitsrichtlinie jedes Moduls. Diese Prüfung deckt die Lücke auf, die durch Standardprüfungen nicht erkannt wird – also die Tatsache, dass Systeme zwar FIPS-fähig, aber nicht konform sind. Sie tritt in nahezu jeder von uns untersuchten Umgebung auf.
Lieferantenbindungsprogramm: Direkte CMVP-Zertifikatsprüfung für jedes im Geltungsbereich liegende Lieferantenmodul, Erfassung des Zertifizierungszeitplans, Charakterisierung des CMVP-Rückstandsrisikos und Unterstützung bei der Entscheidung über einen Ersatz, beginnend mit dem ersten Tag des Projekts.
FIPS 140-3 Übergangsstrategie: Ein nach Risiken priorisierter, sequenzieller Sanierungsfahrplan, der die tatsächlichen Einschränkungen in Ihrer Umgebung, HSM-Vorlaufzeiten, CMVP-Warteschlangenpositionen, Abhängigkeiten von der Cloud-Rekonfiguration und die Verfügbarkeit der Anbieter berücksichtigt und auf den Stichtag 21. September 2026 abgestimmt ist.

Häufig gestellte Fragen

Wie lange dauert die CMVP-Validierung?

In der Regel dauert es zwölf bis achtzehn Monate von der Einreichung bis zur Erteilung eines aktiven Zertifikats. Der Status „In Bearbeitung“ wird von FedRAMP-Gutachtern, OCR-Prüfern oder Finanzprüfern nicht als gültiger Konformitätsnachweis anerkannt.

Reicht die Behauptung eines Anbieters hinsichtlich der FIPS-Konformität aus?

Nein. Ohne eine verifizierte CMVP-Zertifikatsnummer auf csrc.nist.gov handelt es sich um eine nicht überprüfbare Selbsterklärung. Verlangen Sie die Nummer, bestätigen Sie den aktiven Status und gleichen Sie die Modulversion mit der tatsächlich eingesetzten Version ab.

Wie kann ich überprüfen, ob der FIPS-Modus tatsächlich aktiviert ist?

Prüfen Sie die Laufzeitkonfiguration anhand der Sicherheitsrichtlinie jedes Moduls: Stellen Sie sicher, dass die Selbsttests ausgeführt werden, die Algorithmusbeschränkungen eingehalten werden und die Konfiguration dem validierten Betriebsmodus entspricht. Der Besitz eines Zertifikats allein beweist nichts über den Laufzeitzustand.

Ist die Schlüsselverwaltung von AWS, Azure oder Google Cloud standardmäßig FIPS-konform?

Nicht auf dem Sicherheitsniveau, das die meisten Programme benötigen. AWS erfordert FIPS-Endpunkte (kms-fips.[region].amazonaws.com), Azure die HSM-gestützte Premium-Stufe oder Managed HSM, und Google Cloud Cloud HSM-Schlüsselringe für hardwarebasierte Schlüssel; Softwareschlüssel bieten lediglich Validierung der Stufe 1. Keine dieser Konfigurationen ist standardmäßig aktiviert.

Was passiert, wenn mein Lieferant die Zertifizierung nicht vor September 2026 ausstellen kann?

Die Entscheidung über die Notfallstrategie sollte frühzeitig getroffen werden: Risikoakzeptanz mit kompensierenden Kontrollmaßnahmen für Systeme mit geringem Risiko oder Beschaffung von Ersatzsystemen für Systeme, die regulierte Daten verarbeiten. Späte Entscheidungen über Notfallstrategien sind nicht mehr umsetzbar.

Fazit

Keine der acht Herausforderungen ist unlösbar. Der CMVP-Rückstand ist bewältigbar, wenn die Einbindung der Anbieter frühzeitig erfolgt. Die Lücke im FIPS-Modus lässt sich durch eine Laufzeitkonfigurationsanalyse identifizieren. Die Lieferzeiten für HSMs liegen innerhalb des verfügbaren Zeitfensters, wenn die Hardwarebewertung zu Beginn des Programms durchgeführt wird. Fehlkonfigurationen von Cloud-KMS lassen sich einmalig beheben, sobald sie gefunden werden.

Der rote Faden, der sich durch alle acht Herausforderungen zieht, ist Zeit. Jede einzelne erfordert mehr Zeit, als Organisationen zunächst erwarten, und keine lässt sich durch Dringlichkeit beschleunigen, sobald der Stichtag so nah ist, dass nur noch Eile zur Verfügung steht. Organisationen, die die Umstellung auf FIPS 140-3 fristgerecht abschließen, behandeln sie als strukturierte Programme mit definierten Phasen und realistischen Zeitplänen – nicht als Projekte, die sich im September, wenn dieser näher rückt, zu einem Sprint beschleunigen lassen.

Teil 3 dieser Serie ist der detaillierte Leitfaden: das vollständige vierphasige Migrationsmodell, der Ansatz für das Lieferantenmanagement, der darüber entscheidet, ob das Programm vor dem Stichtag abgeschlossen wird, und die acht Punkte umfassende Compliance-Checkliste, die definiert, wann die Arbeit tatsächlich abgeschlossen ist. Kontakt Verschlüsselungsberatung bei [E-Mail geschützt] Um Ihren persönlichen Beratungstermin zu buchen.