In jedem Post-Quanten-Projekt gibt es einen beruhigenden Moment. Die Bibliothek ist aktualisiert, der Schlüsselaustausch meldet ML-KEM-768, das Ticket ist geschlossen. Fertig.

Nur eben nicht. Sie haben ein Schloss ausgetauscht. Sie haben weder die Fenster geprüft, noch das Siegel auf den Briefen, noch ob überhaupt jemand eine Liste der anderen Schlösser geführt hat.

In der Branche nennt man das inzwischen den Unterschied zwischen PQC-Migration und PQC-Transformation. Migration tauscht Algorithmen. Transformation tauscht Algorithmen und baut Verifikation, Sichtbarkeit und Vertrauen darum herum neu auf. Die meisten Anbieter bleiben beim Ersten stehen.

Migration ist der Algorithmus. Transformation ist alles darum herum.

Migration ist notwendig, und wir reden sie nicht klein. RSA und ECC werden einem kryptografisch relevanten Quantencomputer nicht standhalten, und NISTs FIPS 203 (ML-KEM) und FIPS 204 (ML-DSA) sind der Ersatz. Wer noch nicht angefangen hat, sollte anfangen.

Aber ein Algorithmus ist ein Baustein, keine Sicherheitsstrategie. Ein quantensicherer Schlüsselaustausch schützt die Vertraulichkeit einer Nachricht. Er sagt nichts darüber, ob die Nachricht echt ist, ob das Token, das die Anfrage autorisiert hat, gefälscht war, oder ob das Zertifikat am anderen Ende der Verbindung von jemandem stammt, der letztes Jahr ECDSA gebrochen hat.

Transformation stellt vier Fragen statt einer: Ist es vertraulich? Ist es überprüfbar? Weiß ich, wo überall meine Kryptografie steckt? Und wem vertraue ich am Ende?

Verschlüsselung stoppt keinen Man-in-the-Middle. Verifikation schon.

Bei Harvest Now, Decrypt Later geht es um Vertraulichkeit: Ein Angreifer zeichnet heute Chiffretext auf und liest ihn, sobald die Hardware nachgezogen hat. ML-KEM schließt diese Tür. Wir haben schon darüber geschrieben, und es bleibt das dringendste Problem für alle, die Daten mit langer Lebensdauer halten.

Aber derselbe Quantencomputer, der RSA-Verschlüsselung bricht, bricht auch RSA- und ECDSA-Signaturen. Das ist ein anderer Angriff mit einer anderen Folge. Statt Ihre Daten später zu lesen, gibt sich der Angreifer jetzt als Sie aus. Überlegen Sie, was in einem typischen Stack nur durch eine klassische Signatur geschützt ist:

Access-Tokens und JWTs — eines gefälscht, und kein Passwort muss mehr gestohlen werden.
TLS-Zertifikate — ein gefälschtes Zertifikat ist ein Man-in-the-Middle mit gültigem Schloss-Symbol.
Code- und Firmware-Signierung — eine gefälschte Signatur liefert Malware als offizielles Update aus.
Webhooks, API-Antworten und Audit-Logs — die Integrität von allem, was danach kommt.

Wer die Verschlüsselung aufgerüstet und die Signaturen auf ECDSA gelassen hat, hat den Umschlag versiegelt und das Wachssiegel fälschbar gelassen. ML-DSA (FIPS 204) und SLH-DSA (FIPS 205) existieren genau für diese Seite des Problems. Eine echte Transformation schützt beide Seiten.

Man kann nicht migrieren, was man nicht sieht

Fragen Sie einen CISO, wo RSA in seiner Organisation eingesetzt wird, und die ehrliche Antwort lautet: „An mehr Stellen, als wir wissen.“ Es steckt in JWT-Headern, SSH-Schlüsseln, Cloud-KMS-Schlüsseln, PDF-Signaturen, Container-Registries, Hersteller-SDKs und in diesem internen Tool von 2017.

Deshalb setzt jede ernsthafte PQC-Roadmap — auch die koordinierte Roadmap der EU vom Juni 2025 — das Inventar vor die Migration. Der erste Meilenstein heißt nicht „quantensicher sein“. Er heißt „den eigenen Krypto-Bestand kennen“: welche Algorithmen, welche Schlüssellängen, welche Systeme, welche Datenlebensdauern. Ohne das migrieren Sie die sichtbaren 60 % und werden über die 40 % kompromittiert, die niemand aufgeschrieben hat.

Ein Krypto-Inventar ist nicht glamourös. Es ist aber der Schritt, der entscheidet, ob eine Transformation echt oder kosmetisch ist.

Wie eine vollständige Transformation aussieht

Zusammengenommen sind es vier Schichten — jede ist notwendig, keine reicht allein:

Vertraulichkeit — ML-KEM-Schlüsselkapselung um AES-256-GCM für Daten im Ruhezustand und in Übertragung. Das ist die Verteidigung gegen HNDL.
Verifikation — ML-DSA- oder SLH-DSA-Signaturen auf Tokens, Dokumenten, Artefakten und Nachrichten, damit Manipulation und Identitätsdiebstahl selbst gegen einen Quantenangreifer scheitern.
Vertrauensanker — Schlüssel aus echter Quantenentropie, ausgestellt und verifiziert von Infrastruktur unter einer Rechtsordnung, auf die Sie sich verlassen können. Zero-Trust heißt: jede Schicht ist Post-Quantum, nicht nur der Transport.
Inventar — eine lebendige Übersicht, welche Algorithmen, Schlüssel und Systeme im Einsatz sind, damit die Migration messbar bleibt und nichts übersehen wird.

Wo QuantumAPI steht — ehrlich

Das ist heute in Produktion: QuantumAPI verschlüsselt und entschlüsselt mit ML-KEM-512/768/1024 um AES-256-GCM und signiert und verifiziert mit ML-DSA-44/65/87 und SLH-DSA. QuantumID stellt Access-Tokens aus, die neben der klassischen Signatur einen ML-DSA-65-Nachweis tragen, sodass PQC-fähige Clients beides prüfen können. QuantumVault speichert Secrets, Schlüssel und Zertifikate unter derselben hybriden ML-KEM-Verschlüsselung, und seine Transit-Engine signiert mit ML-DSA. Schlüssel werden aus echter Quantenhardware gespeist, mit automatischem Fallback. Alles läuft auf europäischer Infrastruktur, unter EU-Recht, abgerechnet nach Nutzung — nie pro Nutzer.

Und das ist noch nicht ausgeliefert: Ein Krypto-Inventar-Dashboard, mit dem Sie Ihren Algorithmus-Bestand auf einen Blick sehen, steht auf unserer Roadmap und nicht im Produkt. Signierte API-Antworten sind geplant, nicht live. Wir sagen Ihnen das lieber, als ein Häkchen in eine Tabelle zu setzen.

Wenn Sie ein Post-Quanten-Projekt planen, planen Sie eine Transformation, keine Migration. Beginnen Sie mit beiden Seiten — Verschlüsselung und Verifikation — und verlangen Sie ein Inventar von jedem, mit dem Sie arbeiten. Die Verschlüsselungs- und Signatur-Endpunkte können Sie heute im kostenlosen Plan auf quantumapi.eu ausprobieren, und die Dokumentation auf docs.quantumapi.eu zeigt genau, was jeder Algorithmus tut.