Hardware-Sicherheitsmodule (HSM) sind die konservativsten Komponenten der meisten kryptografischen Architekturen. Sie sind teuer, zertifiziert und lassen sich nur langsam ändern – und das bewusst, denn sie enthalten die Schlüssel, denen alle anderen Systeme vertrauen. Doch 2026 zeichnet sich ein Jahr ungewöhnlicher Entwicklungen im HSM-Bereich ab, und der Grund dafür ist die Post-Quanten-Kryptografie . Führende Anbieter haben Firmware veröffentlicht, die die Post-Quanten-Algorithmen des NIST direkt in das Modul integriert. Diese Änderung veranlasst Unternehmen dazu, ihre Plattformen zu überprüfen, ihre IT-Infrastruktur zu konsolidieren und in manchen Fällen sogar zu einem anderen Anbieter zu wechseln.
Die Migration von Schlüsseln zwischen HSM-Plattformen gehört zu den kritischsten Aufgaben, die ein Kryptografie-Team bewältigen kann. Im Idealfall verläuft sie unmerklich. Im Fehlerfall kann sie Signaturdienste beeinträchtigen, eine Vertrauensankerstelle ungültig machen oder Schlüsselmaterial in einen nicht konformen Zustand versetzen. Dieser Artikel erläutert, warum die Aktualisierung des PQC (Physical Quality Code) derzeit HSM-Migrationen vorantreibt, was die Migration technisch konkret beinhaltet, welche spezifischen Risiken einzuplanen sind und wie die Arbeitsschritte so geplant werden sollten, dass Zuverlässigkeit und Verfügbarkeit durchgehend gewährleistet sind.
Warum ist das jetzt wichtig?
Drei Entwicklungen haben die Migration von HSM-Anbietern von einem seltenen und aufwendigen Projekt zu einer zentralen Frage für viele Teams im Jahr 2026 gemacht. Die Post-Quanten-Algorithmen sind mittlerweile standardisiert und in gängiger HSM-Firmware enthalten; der Zertifizierungsstatus dieser Firmware variiert stark zwischen den Anbietern; und die durch PQC bedingten Leistungs- und Schlüsselformatänderungen geben Unternehmen einen triftigen Grund, die Plattform, auf der ihr Root of Trust läuft, neu zu bewerten. Dies ist keine Zukunftsmusik mehr: Der ML-KEM-basierte hybride Schlüsselaustausch ist in gängigen Browsern und TLS-Stacks bereits standardmäßig aktiviert. Die Algorithmen, die ein HSM unterstützen muss, sind also diejenigen, die heute produktiv eingesetzt werden, und nicht mehr zukünftige Entwicklungen.
PQC ist in das Modul umgezogen.
Jahrelang bedeutete Post-Quanten-Unterstützung in HSMs lediglich ein Add-on oder ein experimentelles Optionspaket. Das änderte sich 2025. Entrust gab bekannt, dass die nShield 5 HSMs die Implementierung von Post-Quanten-Algorithmen in der Firmware abgeschlossen und die CAVP-Zertifizierung für ML-DSA , ML-KEM und SLH-DSA erhalten hatten. Dieser Meilenstein wurde mit der Firmware-Version 13.8.0 erreicht, die im August 2025 veröffentlicht wurde. Thales zog mit der Luna HSM-Firmware v7.9 nach, die nativ integriertes ML-KEM (FIPS 203) und ML-DSA ( FIPS 204 ) bietet und somit ein externes Funktionsmodul überflüssig macht. Wenn die beiden führenden Allzweck-HSM-Plattformen gleichzeitig ihre Serien-PQC-Versionen ausliefern, beschleunigt sich der Aktualisierungszyklus im gesamten Markt.
Der Standardkatalog wird stetig erweitert. Neben ML-KEM (FIPS 203), ML-DSA (FIPS 204) und SLH-DSA ( FIPS 205 ) wählte das NIST im März 2025 den codebasierten HQC als alternativen Schlüsselkapselungsmechanismus aus, der auf einer anderen mathematischen Grundlage als ML-KEM basiert. FN-DSA (FALCON) wird voraussichtlich als FIPS 206 eingeführt. Ein heute erworbenes Modul sollte daher nicht nur danach beurteilt werden, welche Algorithmen aktuell enthalten sind, sondern auch danach, wie einfach es später um weitere Algorithmen erweitert werden kann.
Aktualisierungszyklen erzwingen Plattformentscheidungen
Ein Firmware-Upgrade mit PQC ist selten ein Einzelfall. Es fällt oft mit dem Ende des Hardware-Lebenszyklus, der Kapazitätsplanung für größere Post-Quantum-Schlüsseldaten und Vertragsverlängerungen zusammen. Genau in diesen Momenten prüfen Unternehmen, ob sie auf ihrer aktuellen Plattform bleiben oder wechseln. PQC verändert auch die Leistungsberechnung: Post-Quantum-Algorithmen sind rechenintensiver als ihre klassischen Pendants, und sowohl ihre Schlüssel als auch Signaturen sind deutlich größer. Signier- und Schlüsselerzeugungsoperationen benötigen pro Vorgang mehr Rechenleistung als RSA oder ECC.
Der Größenzuwachs ist deutlich: Eine ML-DSA-65-Signatur umfasst etwa 3.3 KB und ein ML-KEM-768-Schlüssel etwa 1.2 KB, im Vergleich zu einer 64 Byte großen ECDSA -P-256-Signatur und einem 256 Byte großen RSA-2048-Schlüssel. Die veröffentlichten Durchsatz-Benchmarks variieren je nach Parametersatz und Plattform stark, die Richtung ist jedoch einheitlich: mehr Zyklen pro Operation und deutlich mehr Speicherplatz pro Schlüssel und Signatur. Ein für RSA- und ECC- Workloads dimensioniertes HSM muss möglicherweise für Post-Quantum-Workloads neu dimensioniert werden, was an sich schon einen Anschaffungsgrund darstellt. Daher ist das PQC-Upgrade ein natürlicher Entscheidungspunkt, ob die aktuelle Plattform erneuert oder ein kompletter Wechsel zu einem anderen Anbieter vorgenommen werden soll.
Die Zertifizierungslücke erschwert regulierte Migrationen.
Käufer in regulierten Branchen stehen vor einem komplexen Timing-Problem. Algorithmen- und Modulzertifizierung sind separate Prozesse und erfolgen nicht gleichzeitig. Ende 2025 verfügen mehrere Anbieter über die FIPS 140-3 Level 3 CMVP-Validierung für ihre HSMs und separat über die CAVP-Zertifizierung für die PQC-Algorithmen. Bislang hat jedoch keiner die kombinierte FIPS 140-3 Level 3-Validierung mit PQC-Unterstützung erreicht; alle befinden sich noch im Stadium „Module in Process“ oder „Implementation Under Test“. Thales hat seine Luna-Firmware v7.9.2 als nächsten FIPS-Kandidaten mit PQC angekündigt, und Entrust hat die nShield 5-Firmware zur aktualisierten FIPS 140-3 Level 3-Validierung über das CMVP eingereicht.
Für eine Organisation mit einem strikten FIPS 140-3 Level 3-Mandat bedeutet dies, dass PQC zwar jetzt getestet und pilotiert werden kann, aber möglicherweise außerhalb des validierten Bereichs betrieben werden muss, bis die kombinierte Zertifizierung vorliegt. Diese Nuance sollte den Migrationszeitpunkt beeinflussen. In der Praxis bedeutet dies, die kombinierte FIPS-Validierung als entscheidenden Meilenstein für die Produktionsumstellung zu betrachten und PQC-Pilotprojekte nur in einer klar gekennzeichneten, nicht validierten Umgebung zuzulassen. Zwei externe Zeitgeber verdeutlichen dies zusätzlich.
Erstens endet die Ära von FIPS 140-2: Am 21. September 2026 werden im Rahmen des CMVP des NIST alle verbleibenden FIPS-140-2-Zertifikate in die Liste der historischen Zertifikate aufgenommen. Danach dürfen Bundesbehörden diese nicht mehr für neue Beschaffungen verwenden. Viele Organisationen führen daher bereits eine Aktualisierung auf FIPS 140-3 durch, die gleichzeitig als Aktualisierung des PQC dient. Zweitens wird die Migration zunehmend verpflichtend und nicht mehr optional.
NSAs CNSA 2.0 verpflichtet National Security Systems zur Umstellung auf ML-KEM-1024 und ML-DSA-87. Neue Beschaffungen sollen die Software-Suite ab 2027 unterstützen, und die Unterzeichnung der Software- und Firmware-Lizenzen sieht frühestens 2030 eine exklusive Nutzungsfrist vor. Die Executive Order 14144 vom Januar 2025 bekräftigte diesen Zeitplan der Bundesregierung. Für betroffene Käufer ist die HSM-Entscheidung nicht mehr rein technischer Natur; sie stellt ein Problem hinsichtlich der Einhaltung von Beschaffungsfristen dar.
Wie funktioniert die HSM-Migration?
Der Transfer von Schlüsseln zwischen HSM-Anbietern ist durch die Funktionsweise eines HSM eingeschränkt, nämlich den Schutz privater Schlüssel vor unbefugtem Zugriff. Eine sichere Migration beginnt mit dem Verständnis, welche Daten tatsächlich übertragen werden, welche im Modul verbleiben und wie die beiden führenden Plattformen Post-Quanten-Algorithmen implementieren. Die folgenden Abschnitte behandeln diese Aspekte nacheinander.
Was die HSM-Migration tatsächlich bewegt
Die Migration zwischen HSMs ist kein einfaches Kopieren von Dateien. Schlüsseldaten in einem HSM lassen sich systembedingt in der Regel nicht im Klartext exportieren; sie verlassen das Modul entweder nur verschlüsselt oder gar nicht und werden neu generiert. Eine Migration muss daher die Schlüssel selbst, das zugehörige Zugriffs- und Authentifizierungsmodell (z. B. Partitionen, Rollen und Quorum- oder PED-Authentifizierung ), die Richtlinien zur Schlüsselverwendung sowie die von den Schlüsseln abhängigen Vertrauensbeziehungen berücksichtigen, einschließlich Zertifizierungsstellenhierarchien und Anwendungsintegrationen, die über PKCS#11 gebunden sind.
Das Anbietermigrationsmodell
Anbieter stellen strukturierte Migrationspfade bereit, und das Verständnis der zugrundeliegenden Mechanismen ist auch dann wichtig, wenn Sie zwischen verschiedenen Anbietern wechseln und nicht innerhalb eines Anbieters ein Upgrade durchführen. Thales dokumentiert drei Methoden zum Übertragen von Schlüsseln auf ein neues Luna HSM: Backup und Wiederherstellung, direktes Klonen von Steckplatz zu Steckplatz und Klonen über eine temporäre Hochverfügbarkeitsgruppe, die eigens für die Migration erstellt wird. Die Thales-Anleitung stellt ausdrücklich klar, dass alle drei Methoden die Klonprotokolle der ausgeführten Befehle nutzen und dass eine temporäre Hochverfügbarkeitsgruppe nach der Migration entfernt werden sollte, da ihre Mitglieder nicht dieselbe Softwareversion verwenden.
Das Detail, das Teams vor Herausforderungen stellt, ist die Protokollkompatibilität zwischen Firmware-Generationen. Im Luna-Modell verwenden ältere HSMs vor Firmware-Version 7.8.0 ein älteres Klonprotokoll, das mehrere Domänen nicht unterstützt. Daher kann das ältere HSM nur mit der festgelegten primären Domäne eines neueren HSMs interagieren. Laut Thales bedeutet dies in der Praxis, dass die gemeinsame Domäne von Quelle und Ziel auf jedem HSM ab Firmware-Version 7.8.0 vor dem Klonen als primäre Domäne festgelegt werden muss. Generations- und herstellerübergreifende Migrationen hängen genau von diesen Kompatibilitätsbedingungen ab.
Rollen und Authentifizierung werden ebenfalls übernommen.
Bei der Migration geht es nicht nur um Schlüssel, sondern auch darum, wer sie kontrolliert. Die Luna-Prozeduren erfordern spezifische Partitionsrollen: Der Partition Security Officer führt Hochverfügbarkeitsoperationen durch und erstellt den Crypto Officer, während der Partition Crypto Officer für Backup-, Wiederherstellungs- und Klonvorgänge zuständig ist. Nutzt die Quelle Multi-Faktor-Quorum-Authentifizierung (PED) und das Ziel passwortgeschützt, weist die Dokumentation darauf hin, dass passwortgeschützte HSMs kein Remote-PED verwenden können. Daher muss ein PED lokal angeschlossen sein. Diese betrieblichen Details sind integraler Bestandteil des Migrationsdesigns und keine nachträglichen Überlegungen.
Die Migration zu einem anderen Hersteller ist schwieriger als ein Upgrade innerhalb desselben Herstellers.
Wenn Quelle und Ziel von unterschiedlichen Herstellern stammen, gibt es in der Regel keine komfortablen Klon- und Hochverfügbarkeitspfade, da die Klonprotokolle herstellerspezifisch sind. Diese Pfade basieren auf einem gemeinsamen, proprietären Klonprotokoll und einer gemeinsamen Sicherheitsdomäne, die nur innerhalb des Ökosystems eines einzelnen Herstellers existieren. Daher kann eine Luna-Partition nicht auf ein nShield geklont werden und umgekehrt. Die einzigen Verbindungen zwischen Herstellern sind standardbasierte Mechanismen wie PKCS#11 Key Wrapping. Selbst diese funktionieren jedoch nur, wenn die Schlüsselrichtlinie den Export zulässt und beide Plattformen einen kompatiblen Wrapping-Mechanismus implementieren.
Die Migration zwischen verschiedenen Anbietern erfolgt üblicherweise auf drei Arten: Erstens durch Regenerieren der Schlüssel auf der neuen Plattform und Neuausstellung der zugehörigen Zertifikate oder Anmeldeinformationen (die sauberste Methode, wenn die Schlüssel rotiert werden können); zweitens durch Verpacken und Importieren der Schlüssel, sofern beide Plattformen einen kompatiblen Schlüsselverpackungsmechanismus unterstützen und die Richtlinien den Export zulassen; oder drittens, für eine Zertifizierungsstelle, durch Einrichten einer neuen, auf dem neuen HSM basierenden Zertifizierungsstelle und anschließendes Übertragen oder Migrieren der untergeordneten Vertrauensstellungen. Die richtige Wahl hängt davon ab, ob die Schlüssel rotiert werden können, ob sie durchgehend innerhalb eines FIPS-Bereichs bleiben müssen und wie lange die abhängigen Dienste ausfallen können.
Risiken und Fallstricke
Bei HSM-Migrationen werden mehrere Risikokategorien in einem einzigen Änderungsfenster konzentriert.
| Risiko | Verursachen | Folge |
|---|---|---|
| Verlust der Vertrauensbasis | Die CA-Signaturschlüssel wurden falsch behandelt oder nicht korrekt migriert. | Ausgestellte Zertifikate können nicht mehr validiert oder erneuert werden. |
| Nicht konformer Schlüsselzustand | Schlüssel, die in eine Konfiguration außerhalb des validierten Bereichs importiert wurden. | Verlust der FIPS 140-3 Level 3-Konformität für regulierte Workloads. |
| Protokollinkompatibilität | Quell- und Ziel-Firmware verwenden nicht übereinstimmende Klonprotokolle. | Die Migration schlägt fehl oder nutzt stillschweigend einen schwächeren Pfad. |
| Dienstausfallzeit | Signierungs- oder TLS-Dienste sind während der Migration auf Schlüssel angewiesen. | Ausfälle in PKI, Codesignaturoder Transaktionsverarbeitung. |
| Kapazitätsengpass | HSM ist für klassische Workloads ausgelegt, nicht für PQC. | Durchsatzverschlechterung nach der Inbetriebnahme von Post-Quanten-Algorithmen. |
| Authentifizierungsfehler | PED-authentifizierte Quelle wurde zu passwortauthentifiziertem Ziel verschoben. | Betriebssperrung oder unsichere Umgehungslösungen. |
Das Zeitfenster für die Einhaltung der Vorschriften stellt die größte Herausforderung dar.
Für regulierte Käufer ist die wichtigste Planungsgrundlage die zuvor beschriebene Zertifizierungslücke. Der Betrieb von PQC-Schlüsseln in einer Konfiguration, die noch nicht durch eine FIPS 140-3 Level 3 CMVP-Validierung abgedeckt ist, mag für Tests und Pilotprojekte akzeptabel sein, ist aber nicht gleichzusetzen mit dem Betrieb innerhalb des validierten Bereichs. Organisationen, die FedRAMP, FISMA oder ähnlichen Regimen unterliegen, sollten ihren Migrationszeitplan mit dem CMVP-Fortschritt der Anbieter abgleichen und sorgfältig entscheiden, ob sie PQC jetzt, außerhalb der kombinierten Validierung, produktiv einsetzen oder bis zum Erhalt der Zertifizierung schrittweise implementieren. Dies ist eine dokumentierte Risikoentscheidung und kein Detail, das erst im Rahmen eines Audits entdeckt wird.
Wichtige Exportrichtlinien können den offensichtlichen Weg blockieren
Teams gehen mitunter fälschlicherweise davon aus, dass Schlüssel einfach verschlüsselt und verschoben werden können. In einer Umgebung mit strengen FIPS 140-3-Sicherheitsstandards der Stufe 3 unterstützt das HSM jedoch ausschließlich zugelassene Algorithmen und Schlüsseltypen. Nicht exportierbare Schlüssel können nicht extrahiert werden. Thales weist zudem auf eine aktuelle Einschränkung von Luna hin: In Version 7.9.0 wird das Verschlüsseln von ML-DSA- und ML-KEM-Schlüsseln nicht unterstützt, was sich direkt auf die Verschiebung von Post-Quantum-Schlüsseln auswirkt. Prüfen Sie daher die Export- und Verschlüsselungsrichtlinien für jede Schlüsselklasse, bevor Sie sich für eine Migrationsmethode entscheiden.
Best Practices für die Implementierung
Eine disziplinierte HSM- Migration sequenziert Erkennung, Design und Umstellung, sodass die Vertrauensbasis niemals gefährdet ist. Die folgenden Schritte werden nacheinander ausgeführt, wobei jeder Schritt die vollständige Ausführung des vorherigen voraussetzt. Denn das Überspringen von Erkennungs- oder Kompatibilitätsprüfungen führt dazu, dass ein Schlüssel bei der Migration nicht verschoben werden kann.
- Inventarisieren Sie jeden Schlüssel und seine Abhängigkeiten: Katalogschlüssel nach Typ, Exportierbarkeit, Richtlinie, Eigentümer und den davon abhängigen Diensten. Zertifizierungsstelle Signaturschlüssel, Codesignaturschlüssel und TLS-Schlüssel erfordern jeweils eine unterschiedliche Handhabung. Ohne zu wissen, welche Schlüssel rotierbar sind und welche nicht, lässt sich keine Migrationsmethode planen. Schlüssel, die durch Hardware-Nichtexportierbarkeit geschützt sind, wie beispielsweise ein CA-Root-Schlüssel, benötigen eine andere Strategie als Schlüssel, die einfach neu ausgestellt werden können. (Encryption Consulting) CBOM Secure automatisiert diese Ermittlung und erstellt eine kryptografische Stückliste, die jeden Schlüssel seinem Besitzer, seinen Richtlinien und den abhängigen Systemen zuordnet.
- Legen Sie die Migrationsmethode pro Schlüsselklasse fest: Nutzen Sie Rotation und Neuausstellung, wenn sich Schlüssel ändern können, herstellerspezifisches Klonen oder Backup und Wiederherstellung für herstellerinterne Upgrades und Key Wrapping nur dann, wenn beide Plattformen und Richtlinien dies unterstützen. Gehen Sie nicht davon aus, dass eine Methode für alle Systeme geeignet ist, und dokumentieren Sie die gewählte Methode für jede Schlüsselklasse, damit der Umstellungsplan nachvollziehbar ist.
- Zuerst die Firmware- und Protokollkompatibilität prüfen: Bei Upgrades innerhalb des Herstellers sollten Sie vor allen wichtigen Änderungen die Versionen des Klonprotokolls und die Domäneneinstellungen überprüfen. Dies schließt gegebenenfalls auch die Festlegung der gemeinsam genutzten Domäne als primäre Domäne auf neueren Firmware-Versionen ein.
- Die Haltung zur Einhaltung der Vorschriften festlegen: Ordnen Sie die Migration dem CMVP-Fortschritt des Anbieters zu und dokumentieren Sie explizit, ob PQC während der Übergangsphase innerhalb oder außerhalb des validierten Bereichs ausgeführt wird. Lassen Sie sich diese Entscheidung vor der Bereitstellung bestätigen. Die PQC-Beratungsdienste lesen das CMVP-Zertifikat und die Sicherheitsrichtlinie und nicht nur die Broschüre; die Vorgehensweise basiert daher auf dem tatsächlichen Umfang der Validierung.
- Größe für die postquantenmechanische Belastung: Validieren Sie den HSM-Durchsatz in einem Pilotprojekt anhand der rechenintensiveren PQC-Algorithmen und planen Sie gegebenenfalls eine herstellerseitige Beschleunigung ein. Entrust weist beispielsweise darauf hin, dass nShield 5 einen FPGA-basierten Sicherheitsprozessor verwendet, dessen PQC-Beschleunigung über ein späteres Firmware-Upgrade bereitgestellt werden kann. Die Überprüfung, ob die zu validierende Firmware über eine Beschleunigung verfügt, vermeidet unangenehme Überraschungen bei der Durchsatzmessung unter Last. Wenn die Bereitstellung validierter, PQC-fähiger Hardware im eigenen Haus nicht praktikabel ist, bietet HSM-as-a-Service diese bedarfsgerecht an.
- Verfügbarkeit durch parallele Ausführung erhalten: Richten Sie die neue Plattform parallel zur alten ein, migrieren oder generieren Sie die Schlüssel neu, validieren Sie abhängige Dienste anhand des neuen HSM und stellen Sie erst dann um. Bei CA-Hierarchien empfiehlt sich eine Cross-Zertifizierung, um einen schrittweisen Übergang der Vertrauensstellungen zu gewährleisten.
- Üben, dann einen Rollback beibehalten: Testen Sie den gesamten Vorgang in einer Nicht-Produktionsumgebung. Halten Sie die Quell-HSMs verfügbar und gesichert, bis die Migration verifiziert ist, und nehmen Sie sie erst außer Betrieb, nachdem die abhängigen Dienste auf der neuen Plattform als stabil bestätigt wurden. Eine Migration ist nicht abgeschlossen, sobald die Schlüssel auf dem neuen HSM eintreffen; sie ist erst dann abgeschlossen, wenn die alte Plattform unbemerkt außer Betrieb genommen werden kann.
Was bedeutet das für Sicherheitsteams?
Eine HSM-Migration im Rahmen der PQC-Aktualisierung ist kein Projekt eines einzelnen Teams; sie betrifft alle, die auf die Vertrauensbasis angewiesen sind. Die Verantwortlichkeiten variieren je nach Rolle, doch die Kombination aus Anbieterwechsel und kryptografischer Umstellung erhöht das Risiko für alle Beteiligten.
CISOs tragen das Risiko einer Migration, die das Vertrauen in die Organisation grundlegend erschüttert, und benötigen die Gewissheit, dass die Compliance-Standards während des gesamten Prozesses gewahrt bleiben, da ein Mangel an validierter Abdeckung während der Migration selbst einen Prüfbefund darstellt. Ein Beratungsauftrag von PQC liefert ihnen einen nachvollziehbaren, dokumentierten Migrationsplan.
Die Teams für Kryptografie und PKI sind für die technischen Details verantwortlich: Schlüsselverwaltung, Kontinuität der CA-Hierarchie und die für den Erfolg entscheidenden Entscheidungen bei der Schlüsselmigration. PKI-as-a-Service ermöglicht die nahtlose Migration der CA-Hierarchie.
Sicherheitsarchitekten entscheiden, ob die Aktualisierung auch der richtige Zeitpunkt ist, um Anbieter zu konsolidieren, Krypto-Agilität einzuführen und die Plattform im Hinblick auf die Post-Quanten-Technologie neu auszurichten. Eine CBOM Secure- Inventarisierung zeigt ihnen, was tatsächlich Priorität hat.
Infrastruktur-Ingenieure planen die Umgebung für den Parallelbetrieb, HA-Gruppen und die Kapazität für höhere PQC-Workloads. HSM-as-a-Service kann diese Last ohne Hardware-Anschaffung bewältigen.
Die Compliance- und Audit-Teams benötigen die dokumentierte Aufzeichnung darüber, wie die Schlüssel migriert wurden und ob sie sich durchgehend innerhalb eines validierten Bereichs befanden. Diese Nachweiskette ist ein direktes Ergebnis desselben Beratungsauftrags.
Wie kann Verschlüsselungsberatung helfen?
Die HSM-Migration im Rahmen der PQC-Aktualisierung ist selten ein isolierter Hardware-Austausch; sie ist vielmehr Teil eines umfassenderen kryptografischen Modernisierungsprozesses. Die größten Herausforderungen liegen in den komplexen Entscheidungssituationen: Welche Schlüssel können migriert werden? Was genau deckt das CMVP-Zertifikat ab? Und wie lässt sich die Umstellung stufenweise durchführen, ohne die Vertrauensbasis zu gefährden? Genau hier setzt die Post-Quantum Cryptographic Advisory Services von Encryption Consulting an. Das Team analysiert Ihr Quantenrisiko, betrachtet Zertifikat und Sicherheitsrichtlinie – und nicht nur die Herstellerbroschüre – und entwickelt einen Migrationsplan, der Ihren Compliance-Anforderungen entspricht. Dieser umfasst die kryptografische Analyse, die HSM-Vorbereitung, die Algorithmusauswahl, den hybriden Einsatz und die schrittweise Umstellung.
Wo für die Umsetzung des Plans Tools benötigt werden, greift dasselbe Projekt auf CBOM Secure für die kryptografische Erkennung und eine dynamische Stückliste für Kryptografie zurück, auf HSM-as-a-Service für FIPS-validierten, PQC-fähigen Schlüsselschutz ohne eigene Hardwareinstallation sowie auf PKI-as-a-Service, wenn die Migration den Wiederaufbau oder die Kreuzzertifizierung von CA-Hierarchien erfordert. Das Ergebnis ist ein einziges, von Experten geleitetes Programm, das die Migration eines HSM-Anbieters von einem riskanten Einzelprojekt in einen kontrollierten Schritt hin zu kryptografischer Agilität verwandelt. Um Ihren Bedarf zu ermitteln, sprechen Sie mit Encryption Consulting über eine Post-Quantum-Readiness-Analyse und einen Fahrplan für die HSM-Migration.
Fazit
Die Einführung nativer Post-Quanten-Kryptographie in nShield 5 und Luna 7.9 Firmware hat das HSM vom statischsten Teil des Stacks zu einem aktiven Migrationsziel gemacht. Dies bietet die Chance zur Modernisierung, birgt aber auch erhebliche Risiken: Vertrauensbasis, Einhaltung regulatorischer Vorgaben, Serviceverfügbarkeit und Schlüsselgeheimnis hängen maßgeblich von einer korrekten Migration ab. Die Zertifizierungslücke – PQC-Algorithmen sind CAVP-validiert und Module FIPS 140-3 Level 3-validiert, die beiden jedoch noch nicht kombiniert – stellt die entscheidende Hürde für regulierte Käufer dar und sollte den Zeitplan maßgeblich beeinflussen.
Die Migration zwischen HSM-Anbietern während des PQC-Refreshs erfordert vor allem eine sorgfältige Vorbereitung. Erfassen Sie jeden Schlüssel und seine Abhängigkeiten, wählen Sie für jede Schlüsselklasse eine Migrationsmethode, klären Sie die Firmware- und Protokollkompatibilität, bevor Sie etwas verschieben, legen Sie Ihre Compliance-Strategie bewusst fest und führen Sie die Migration parallel mit einem getesteten Rollback durch. Behandeln Sie die HSM-Migration als die sorgfältige Verlagerung einer Vertrauensankerstelle und nicht als Hardware-Upgrade. So wird der Post-Quantum-Refresh zu einem kontrollierten Schritt hin zu kryptografischer Agilität und nicht zu einer Bedrohung für die Schlüssel, von denen alles andere abhängt.
