Lisa Hartmann

Post-Quanten-Kryptografie ist kein Thema für übermorgen – sie ist das dringlichste Sicherheitsproblem, das Banken und FinTechs heute auf dem Tisch haben. Rechnen wir nach: Wer sensible Kundendaten schützen muss, die noch 2049 vertraulich sein sollen, und wer gleichzeitig weiß, dass ein kryptografisch relevanter Quantencomputer realistisch in zehn Jahren existieren könnte, der sitzt bereits jetzt in der Falle. Banking-Sicherheit auf Basis von RSA oder ECC läuft aus. Die Frage ist nicht ob – sondern wie schnell Ihre Institution reagiert.
Fangen wir konkret an. Aktuelle Banking-Sicherheit beruht zu einem erheblichen Teil auf asymmetrischer Kryptografie: RSA-2048, Elliptic Curve Cryptography (ECC), Diffie-Hellman-Schlüsselaustausch. Diese Verfahren sind sicher, solange kein Angreifer einen Shor-Algorithmus auf einem kryptografisch relevanten Quantencomputer ausführen kann. Das klingt abstrakt. Es ist es nicht. Semantisch passt dazu unser Hintergrund Quantencomputer für Verbraucher: Wann wird die Technologie Realität?.
Der Shor-Algorithmus, 1994 von Peter Shor entwickelt, löst das Faktorisierungsproblem – die mathematische Grundlage von RSA – in polynomialer statt exponentieller Zeit. Zum Vergleich: Ein klassischer Rechner würde für das Faktorisieren einer 2048-Bit-RSA-Zahl länger brauchen als das Universum alt ist. Ein ausreichend großer Quantencomputer schafft dasselbe in Stunden. Die Mastercard-Analyse zur Post-Quanten-Kryptografie bringt es auf den Punkt: Es geht nicht darum, ob dieser Moment kommt, sondern wann.
Auch symmetrische Verfahren wie AES sind betroffen, wenn auch weniger dramatisch. Der Grover-Algorithmus halbiert effektiv die Schlüssellänge – AES-128 würde damit auf das Sicherheitsniveau von AES-64 fallen. Das ist lösbar: AES-256 bleibt auch im Quantenzeitalter ausreichend sicher. Der eigentliche Sprengstoff liegt in der Public-Key-Infrastruktur, die Banking-Sicherheit weltweit trägt.
Meine persönliche Einschätzung: Wer jetzt noch sagt, das sei ein Problem für die nächste Amtszeit des IT-Leiters, ignoriert die Mathematik. Und die Mathematik wartet nicht auf Budgetzyklen.
Hier wird es für FinTech-Compliance-Verantwortliche richtig unangenehm. Das Angriffsszenario nennt sich „Harvest Now, Decrypt Later“ (HNDL) – und es läuft bereits. Staatliche Akteure und gut ausgestattete kriminelle Organisationen sammeln heute verschlüsselte Datenpakete, die sie noch nicht entschlüsseln können. Sie speichern sie. Und warten.
Rechnen wir nach: Sensible Bankkundendaten – Kontobewegungen, Kreditwürdigkeitsprüfungen, M&A-relevante Transaktionsdaten – unterliegen in Deutschland je nach Kontext Aufbewahrungsfristen von 6 bis 10 Jahren (§ 257 HGB, § 147 AO). Dazu kommt der faktische Schutzbedarf: Ein heute aufgenommener TLS-Handshake, der Zugangstoken und Transaktionsdaten transportiert, muss vertraulich bleiben, solange die betroffene Person oder Institution existiert. Das sind realistische 25 Jahre Schutzhorizont.
Konkret bedeutet das: Wenn ein Quantencomputer 2033 oder 2035 einsatzbereit ist – Schätzungen von IBM, Google und verschiedenen Geheimdiensten tendieren in diese Richtung –, dann sind heute abgefangene Daten ab diesem Zeitpunkt lesbar. Nicht theoretisch. Praktisch. Unter dem Strich heißt das: Die Post-Quanten-Kryptografie-Migration muss abgeschlossen sein, bevor der relevante Quantencomputer existiert – nicht danach.
Für einen mittelgroßen deutschen Zahlungsdienstleister, der täglich Transaktionsdaten im Millionenbereich verarbeitet, bedeutet das: Jede heute ungesichert übertragene Transaktion ist ein potenziell offenes Buch für 2035. Das ist keine Panikmache. Das ist Post-Quanten-Kryptografie-Grundwissen.
Nicht alle Daten sind gleich gefährdet. Im Banking sind es vor allem langlebige und hochwertige Datenkategorien: Kreditverträge mit Laufzeiten bis 30 Jahren, Wealth-Management-Informationen vermögender Privatkunden, interbankarische Kommunikation über SWIFT, biometrische Authentifizierungsdaten für Online-Banking sowie Schlüsselmaterial selbst, das für spätere Systeme verwendet wird.
Besonders heikel: Kryptowährungs-Wallets und digitale Assets, deren Private Keys heute mit ECC gesichert sind, sind bei einem leistungsfähigen Quantencomputer direkt angreifbar. Wer heute Bitcoin oder institutionelle digitale Assets hält, deren Adressen öffentlich bekannt sind, hat ein konkretes Post-Quanten-Kryptografie-Problem – auch wenn es sich erst in zehn Jahren materialisiert. Semantisch passt dazu unser Hintergrund Glücksspiel mit Kryptowährungen: Der komplette Guide für 2025.
Im August 2024 hat das National Institute of Standards and Technology (NIST) drei Post-Quanten-Kryptografie-Standards finalisiert. Das ist der Startschuss für die reguläre Migration. Konkret:
Ein vierter Standard, FN-DSA (FALCON), soll 2025 folgen. Diese Algorithmen basieren auf mathematischen Problemen – Gitterkryptografie (Lattice-based) und Hash-Funktionen – die auch für Quantencomputer keine bekannte effiziente Lösung haben. Banking-Sicherheit kann damit künftig auf einem stabilen Fundament stehen.
Der Haken: Diese Standards zu kennen und sie in produktive Kernbanksysteme zu integrieren, sind zwei fundamental verschiedene Aufgaben. ML-KEM erzeugt größere Schlüssel und Ciphertexte als ECC. Das klingt harmlos, ist aber für Protokolle mit engen Paketgrößen – etwa bestimmte HSM-Kommunikationen oder Legacy-Zahlungsprotokolle – ein ernstes Implementierungsproblem. Hier beginnen die echten Migrationskosten.
FinTech-Compliance-Verantwortliche haben seit Januar 2025 ein neues Wort im Alltag: DORA. Der Digital Operational Resilience Act ist seit dem 17. Januar 2025 vollständig in Kraft und definiert konkrete Anforderungen an die ICT-Sicherheit von Finanzinstituten im EU-Raum – einschließlich Kryptografie-Standards.
Artikel 9 DORA verpflichtet Finanzinstitute zu einem robusten ICT-Risikomanagement, das explizit Verschlüsselung als Schutzmaßnahme umfasst. Wer heute noch auf RSA-2048 setzt und keine dokumentierte Roadmap zur Post-Quanten-Kryptografie-Migration vorweisen kann, hat unter Umständen bereits ein Compliance-Problem – nicht erst 2030. Semantisch passt dazu unser Hintergrund Automatisierung im Finanzwesen: Schutz der Finanzlage in unsicheren Zeiten.
Konkret haben europäische Aufsichtsbehörden folgende Zeitachsen kommuniziert: Kritische Finanzsysteme (Kernbanksysteme, Zahlungsinfrastrukturen, Clearing-Systeme) sollen bis 2030 auf quantensichere Verfahren migriert sein. Alle übrigen Systeme bis 2035. G7, EBA, ESMA und EIOPA haben diese Fristen koordiniert – und sie klingen weniger dramatisch, als sie sind.
Rechnen wir nach: ENISA schätzt den Migrationszeitraum für komplexe Finanzinfrastrukturen auf fünf bis zehn Jahre. Wer also mit der kritischen Systeminfrastruktur bis 2030 fertig sein will und zehn Jahre braucht, hätte 2020 starten müssen. Wer fünf Jahre veranschlagt, muss jetzt starten. Nicht im nächsten Quartal. Jetzt.
DORA sieht Bußgelder von bis zu zwei Prozent des weltweiten Jahresumsatzes für schwerwiegende Verstöße vor – mit der Möglichkeit, bei wiederholten Verstößen höher zu gehen. Für eine mittelgroße deutsche Regionalbank mit 500 Millionen Euro Jahresumsatz wären das bis zu zehn Millionen Euro pro Verstoßtatbestand. Zum Vergleich: Ein externer PQC-Migrationsprojekt-Dienstleister kostet für ein mittelgroßes Institut typischerweise zwischen 800.000 und 3,5 Millionen Euro über drei bis fünf Jahre – je nach Systemkomplexität.
Die Rechnung ist eindeutig. Unter dem Strich ist Migration billiger als Compliance-Versagen. Und das, bevor man den Reputationsschaden eines quantenbasierten Datenlecks auch nur ansatzweise einpreist.
Zusätzlich zu DORA greifen je nach Kontext: NIS2 (Netz- und Informationssystemsicherheit, Umsetzungsfrist in Deutschland seit Oktober 2024), GDPR/DSGVO (Art. 32: angemessene technische Schutzmaßnahmen), und für systemrelevante Institute die Anforderungen aus BAIT (Bankaufsichtliche Anforderungen an die IT) der BaFin. Die Analyse des IT-Finanzmagazins macht deutlich: Viele Institute werden die 2030-Frist für Kernbanksysteme nicht einhalten – weil sie schlicht noch nicht begonnen haben.
Bevor eine Migration beginnen kann, braucht es ein vollständiges kryptografisches Inventar. Das klingt trivial. Es ist es nicht. In der Praxis kennen die wenigsten Finanzinstitute alle Stellen, an denen asymmetrische Kryptografie im Einsatz ist. Rechnen wir das durch:
Ein typisches mittelgroßes Finanzinstitut hat erfahrungsgemäß 200 bis 800 individuelle Anwendungen im Produktionsbetrieb. Davon nutzen schätzungsweise 60 bis 80 Prozent irgendeine Form von TLS, Zertifikaten oder Public-Key-Operationen. Das sind 120 bis 640 Systeme, die potenziell auf Post-Quanten-Kryptografie migriert werden müssen. Jedes davon hat eigene Abhängigkeiten, Wartungsverträge, Vendor-Roadmaps und Testzyklen.
TLS/HTTPS-Verbindungen: Jede Banking-App, jedes Online-Banking-Portal, jede API-Verbindung zu Drittanbietern läuft über TLS. Hier ist der Schlüsselaustausch das Angriffsziel. Gute Nachricht: Viele TLS-Bibliotheken (OpenSSL, BoringSSL) implementieren bereits ML-KEM-Unterstützung. Schlechte Nachricht: Die dahinterliegenden Infrastrukturkomponenten – Load Balancer, Hardware Security Module (HSM), Firewalls – müssen separat aktualisiert werden.
Zahlungsinfrastruktur: SWIFT-Kommunikation, SEPA-Clearing, PCI-DSS-konforme Zahlungsdaten-Übertragung – alles basiert auf Kryptografiestandards, die sich nicht über Nacht ändern lassen. Die internationale Abstimmung macht das besonders komplex. Ein deutsches Institut kann nicht einfach seinen Teil auf Post-Quanten-Kryptografie umstellen, wenn die Gegenseite – eine Bank in Singapur oder ein US-Clearing-Haus – noch klassische Algorithmen verwendet. Hybridlösungen sind hier der einzige praktikable Weg.
Hardware Security Module (HSM): HSMs sind die Herzstücke der Banking-Sicherheit für Schlüsselverwaltung. Viele im Einsatz befindliche Modelle unterstützen PQC-Algorithmen noch nicht – und können sie hardwarebedingt auch nicht per Firmware-Update nachrüsten. Hier sind Gerätewechsel unumgänglich. Zum Vergleich: Ein Enterprise-HSM kostet zwischen 20.000 und 80.000 Euro pro Einheit; ein mittelgroßes Institut betreibt typischerweise 10 bis 50 solcher Geräte. Allein der HSM-Austausch kann also zwei bis vier Millionen Euro kosten.
PKI und Zertifikatsinfrastruktur: Digitale Zertifikate für Mitarbeiterkarten, Serverzertifikate, Code-Signing-Zertifikate – alle müssen auf PQC-fähige Algorithmen migriert werden. Die Lebensdauer von Zertifikaten ist hier kritisch: Wer heute ein fünfjähriges Code-Signing-Zertifikat ausstellt, das 2029 abläuft, hat noch Zeit. Wer langlebige Root-CA-Zertifikate mit Laufzeiten bis 2040 betreibt, hat ein Problem.
Geldautomaten und Point-of-Sale-Terminals: Das unterschätzte Problem. ATMs und POS-Terminals haben Hardwarezyklen von zehn bis fünfzehn Jahren. Viele der heute im Einsatz befindlichen Geräte werden 2035 noch aktiv sein – mit kryptografischen Modulen, die 2010 designed wurden. Ein Banking-Sicherheits-Update für einen nationalen ATM-Park kann Hunderte Millionen Euro kosten und Jahre dauern.
Der pragmatischste Ansatz für FinTech-Compliance im Übergang ist die Hybridkryptografie. Das Prinzip: Klassische und Post-Quanten-Kryptografie-Algorithmen werden parallel betrieben. Ein TLS-Handshake kombiniert beispielsweise ECDH mit ML-KEM. Ein Angreifer müsste beide Algorithmen gleichzeitig brechen, um die Kommunikation zu kompromittieren – das macht Hybridansätze sowohl gegen klassische als auch gegen Quantenangriffe widerstandsfähig.
Konkrete Pilotprojekte zeigen, dass das funktioniert. Die Banque de France und die Monetary Authority of Singapore (MAS) haben Hybridverfahren erfolgreich in E-Mail-Kommunikation und VPN-Verbindungen getestet. Die Erste Group in Österreich arbeitet an einem PQC-Pilot für Zahlungssysteme. Das sind keine akademischen Übungen – das ist Banking-Sicherheit in der Praxis.
Der Haken an Hybridlösungen: Sie sind keine Dauerlösung. Sie kosten Performance. ML-KEM-Schlüssel sind größer als ECC-Schlüssel (typischerweise 800 Bytes vs. 32 Bytes für den öffentlichen Schlüssel). Das erhöht Latenz und Bandbreitenbedarf. Für hochfrequente Zahlungsabwicklung kann das relevant sein – und muss in Lasttests quantifiziert werden.
Das eigentlich Kluge an einer gut geplanten PQC-Migration ist nicht der Wechsel zu einem bestimmten Algorithmus, sondern die Einführung von Kryptoagilität: die Fähigkeit, Kryptografiealgorithmen schnell und ohne tiefgreifende Systemeingriffe zu wechseln. Das bedeutet in der Praxis: Abstraktionsschichten zwischen Anwendungslogik und kryptografischen Primitiven, zentrale Schlüsselverwaltung, klar dokumentierte Kryptografie-Policies und automatisiertes Zertifikatsmanagement.
Post-Quanten-Kryptografie ist womöglich nicht das letzte Mal, dass ein Kryptografiestandard gebrochen wird oder ausgetauscht werden muss. Wer Kryptoagilität heute baut, investiert nicht nur in Banking-Sicherheit gegen Quantencomputer – sondern in eine dauerhafte organisatorische Fähigkeit. Rendite auf mehreren Zeitskalen.
Die Analyse von FIRM zum Finanzsektor betont genau diesen Punkt: Kryptoagilität ist keine technische Spielerei, sondern Kernkompetenz für regulatorisch geforderte Resilienz.
Konkrete Planung schlägt abstrakte Warnung. Hier ist eine realistische Zeitachse für ein mittelgroßes Finanzinstitut, das heute startet:
Phase 1 (0–12 Monate): Inventarisierung und Risikoklassifikation. Vollständiges kryptografisches Inventar aller Systeme, Protokolle und Zertifikate. Klassifikation nach Risiko und Dringlichkeit: Welche Systeme übertragen langlebige sensible Daten? Welche Systeme haben die längsten Migrationszyklen? Welche Vendor-Roadmaps für PQC-Unterstützung existieren bereits? Budget für Phase 1: 150.000 bis 400.000 Euro für ein mittelgroßes Institut.
Phase 2 (6–24 Monate): Proof-of-Concept und Pilotmigration. Pilotierung von Post-Quanten-Kryptografie in nicht-kritischen aber repräsentativen Systemen. Typische Kandidaten: interne VPN-Verbindungen, E-Mail-Verschlüsselung, interne API-Gateways. Messung von Performance-Impact, Inkompatibilitäten, Schulungsbedarf. Budget: 300.000 bis 800.000 Euro.
Phase 3 (18–48 Monate): Migration kritischer Infrastruktur. HSM-Austausch, PKI-Migration, TLS-Update in Kernbank-APIs, Integration in Zahlungsinfrastruktur. Parallelbetrieb (Hybrid) für alle Systeme mit externen Gegenstellen, die noch nicht migriert sind. Budget: 1,5 bis 5 Millionen Euro je nach Systemkomplexität.
Phase 4 (36–84 Monate): ATM/POS-Infrastruktur und Legacy-Systeme. Hardwareintensive Migration von Endgeräte-Infrastruktur, Mainframe-Kryptografie, alten Core-Banking-Systemen. Budget: variiert stark, typischerweise 3 bis 20 Millionen Euro für größere Institute.
Unter dem Strich: Eine vollständige Migration kostet ein mittelgroßes deutsches Finanzinstitut realistisch zwischen 6 und 30 Millionen Euro über fünf bis acht Jahre. Das klingt viel. Aber rechnen wir dagegen: Der durchschnittliche Schaden eines schweren Datenlecks im Finanzsektor liegt laut IBM Cost of a Data Breach Report 2024 bei 6,08 Millionen US-Dollar – und das für ein einzelnes Ereignis ohne Quantenangriffs-Szenario.
Es gibt einen kritischen Punkt auf der Zeitachse, den ich als „Point of No Deferral“ bezeichnen möchte: den Moment, ab dem das Verschieben der Migration mehr kostet als das Starten. Dieser Punkt ist für die meisten mittelgroßen Finanzinstitute spätestens Ende 2025 erreicht – wenn man die ENISA-Schätzung von fünf Jahren für die Mindestmigrationszeit anlegt und 2030 als Zieltermin für kritische Systeme nimmt.
Wer Ende 2025 noch nicht zumindest in Phase 1 (Inventarisierung) ist, kann die regulatorische 2030-Frist für kritische Systeme mathematisch nicht mehr einhalten. Das ist keine Panikmache. Das ist schlichte Projektarithmetik.

FinTech-Compliance im PQC-Kontext ist kein Graubereich mehr. Die regulatorische Lage verdichtet sich schnell. Hier der aktuelle Stand nach Behörde:
BaFin: Die BAIT-Anforderungen, insbesondere zu Kryptografie und Schlüsselmanagement (Abschnitt 4.2), erfordern bereits heute dokumentierte Kryptografie-Standards und Verfallspläne. Eine BaFin-Prüfung kann konkret fragen: Welchen Algorithmus nutzen Sie? Wann läuft der ab? Was ist Ihre Migrationsplanung? Wer hier keine Antwort hat, hat ein Problem.
EBA (European Banking Authority): Im Rahmen des Digital Finance-Pakets hat die EBA PQC-Migration explizit als Teil der ICT-Risikomanagement-Anforderungen adressiert. EBA-Leitlinien zu ICT-Risiken (EBA/GL/2019/04, derzeit überarbeitet im DORA-Kontext) werden PQC-Anforderungen sukzessive integrieren.
ESMA und EIOPA: Für Wertpapierfirmen und Versicherungen gelten analoge Anforderungen. Wer elektronische Signaturverfahren für Vertragsabschlüsse nutzt – heute Standard in der digitalen Vermittlung – braucht eine PQC-sichere Signaturinfrastruktur.
BSI (Bundesamt für Sicherheit in der Informationstechnik): Das BSI hat in seiner Technischen Richtlinie TR-02102 bereits Empfehlungen zu Post-Quanten-Kryptografie aufgenommen und aktualisiert diese laufend. Die BSI-Empfehlungen sind zwar nicht direkt rechtsverbindlich, werden aber regelmäßig als Referenz in aufsichtsrechtlichen Prüfungen herangezogen.
Konkret in Euro: Ein Finanzinstitut, das in einer BaFin-Sonderprüfung nach § 44 KWG nachweislich unzureichende Kryptografie-Dokumentation aufweist, riskiert Maßnahmen bis hin zur Anordnung eines Besonderen Beauftragten – mit Kosten im siebenstelligen Bereich allein für den externen Prüfer. Das ist die härtere Variante. Die weichere: reputationsschädigende öffentliche Bekanntmachung von Mängeln.
Eine Migration kann nur so schnell gehen wie die langsamste Komponente im System – und das ist oft der Vendor. Hier ist der aktuelle Stand für Banking-relevante Technologieanbieter:
Cloud-Provider: AWS, Microsoft Azure und Google Cloud haben ML-KEM bereits in ihre TLS-Implementierungen integriert oder kündigen dies für 2025 an. Wer Bankinfrastruktur in der Cloud betreibt, hat hier einen Vorteil.
HSM-Hersteller: Thales (Luna HSM), Utimaco und Entrust haben PQC-fähige HSM-Generationen angekündigt oder bereits verfügbar. Die Frage ist, ob Bestandsgeräte per Firmware-Update aufrüstbar sind – meistens nein.
Kernbanksystem-Anbieter: Temenos, Finastra, SAP Banking und andere große Kernbankanbieter haben PQC auf ihren Roadmaps, aber konkrete Verfügbarkeitsdaten sind oft vage. Hier brauchen Finanzinstitute vertraglich gesicherte Commitments – und sollten diese bei aktuellen Ausschreibungen als Bewertungskriterium einfordern.
Netzwerkinfrastruktur: Cisco, Palo Alto Networks und Juniper haben PQC-Unterstützung in VPN- und Firewall-Produkten angekündigt. Die Implementierung in produktiven Systemen erfordert trotzdem sorgfältige Tests auf Kompatibilität und Performance.
Der Haken: „Roadmap“ ist kein Lieferdatum. Post-Quanten-Kryptografie-Verantwortliche in Finanzinstituten müssen von ihren Vendoren konkrete Verfügbarkeitsdaten, Testzugänge und vertragliche SLAs einfordern. Wer das nicht tut, wird 2028 feststellen, dass sein Kernbankanbieter immer noch „evaluiert“.
Lassen Sie uns ein konkretes Szenario durchrechnen. Angenommen: Eine deutsche Direktbank mit 800.000 Kunden, 2 Milliarden Euro verwaltetem Vermögen, und einer IT-Infrastruktur von 350 Anwendungen startet ihre PQC-Migration erst 2028 statt heute.
Szenario A: Migration startet 2025.
Szenario B: Migration startet erst 2028.
Konkret: Der Unterschied ist überschaubar in absoluten Zahlen, aber enorm im Risikoprofil. Wer wartet, zahlt ähnlich viel – aber unter deutlich schlechteren Bedingungen, mit weniger erfahrenen Projektteams und mit dem Damoklesschwert regulatorischer Maßnahmen. Die Rendite früher Migration liegt nicht primär in Kosteneinsparung, sondern in Risikoreduktion und Planbarkeit.
Kommen wir zu dem, was ich als nützlichsten Teil dieses Textes betrachte: eine handlungsorientierende Checkliste für FinTech-Compliance- und IT-Sicherheitsteams in Finanzinstituten. Keine Theorie. Konkrete Schritte.
Banking-Sicherheit endet nicht an der Grenze. Wer SWIFT nutzt, mit US-amerikanischen Korrespondenzbanken kommuniziert oder europäische Zahlungsnetzwerke betreibt, ist in ein globales kryptografisches Ökosystem eingebettet. Die Migration auf Post-Quanten-Kryptografie muss daher international koordiniert werden.
SWIFT selbst hat eine PQC-Arbeitsgruppe und plant die schrittweise Integration quantensicherer Algorithmen in das SWIFT-Netzwerk. Konkrete Zeitpläne sind noch nicht öffentlich, aber die Richtung ist klar. Ein Institut, das sein internes System auf Post-Quanten-Kryptografie migriert hat, die SWIFT-Verbindung aber nicht, hat eine klaffende Lücke in seiner Banking-Sicherheitsarchitektur.
Ähnliches gilt für PCI-DSS: Der Payment Card Industry Data Security Standard wird in seiner nächsten Hauptversion (PCI-DSS 5.0, erwartet ab 2026/2027) voraussichtlich explizite PQC-Anforderungen enthalten. Wer Kartenzahlungen verarbeitet, hat hier einen weiteren regulatorischen Countdown laufen.
Die internationale Dimension macht auch den Hybridansatz zwingend: Bis alle Beteiligten einer Kommunikationsbeziehung auf Post-Quanten-Kryptografie migriert haben, muss Kompatibilität zu klassischen Systemen erhalten bleiben. Das ist kein Makel – das ist realistische Übergangsstrategie.
Technik ist lösbar. Das Inventar kann erstellt werden, die Algorithmen sind standardisiert, die Vendor-Roadmaps entwickeln sich. Der eigentliche Engpass in der PQC-Migration von Finanzinstituten ist der Mensch.
Konkret: Es gibt in Deutschland heute nicht annähernd genug Fachleute mit PQC-spezifischem Wissen, um alle Migrationen der nächsten zehn Jahre zu begleiten. Das Fraunhofer IAO und andere Forschungseinrichtungen bilden aus, Universitäten beginnen, PQC in Kryptografie-Curricula zu integrieren – aber der Markt für PQC-erfahrene Berater und Implementierungsexperten ist bereits jetzt eng. Und wird enger werden, je näher 2030 rückt.
Meine persönliche Beobachtung aus Gesprächen mit CISO-Funktionen in Finanzinstituten: Das Thema Post-Quanten-Kryptografie landet in der zweiten oder dritten Prioritätsebene, hinter akuten Bedrohungen wie Ransomware, Phishing und Insider-Threats. Das ist menschlich nachvollziehbar. Die Herausforderung ist abstrakt, der Quantencomputer noch nicht sichtbar. Aber Banking-Sicherheit gegen nicht-sichtbare Bedrohungen zu vernachlässigen ist die Definition von strategischem Versagen.
Was hilft: Interne Champions, die PQC als messbare OKR-Größe verankern. Externe Awareness durch Regulatoren – und die wächst schnell. Und konkrete Kosten-Nutzen-Rechnungen, die zeigen, dass frühe Migration günstiger ist als späte.
FinTech-Compliance-Teams brauchen nicht zwingend tiefes kryptografisches Know-how. Was sie brauchen: das Verständnis der regulatorischen Anforderungen, die Fähigkeit, Vendor-Commitments zu bewerten, und das Bewusstsein für die Risikodimension des HNDL-Angriffsszenarios. Das ist in einem zweitägigen Workshop vermittelbar.
Technische Teams brauchen mehr: grundlegendes Verständnis von Gitterkryptografie, praktische Erfahrung mit NIST-Referenzimplementierungen, Test-Tooling für PQC-Performance-Benchmarks. Hier empfiehlt sich die Investition in gezielte Weiterbildung – ISACA, (ISC)², BSI und Fraunhofer bieten bereits entsprechende Formate an.
Rechnen wir nach: 5 technische Fachleute, je drei Tage PQC-Schulung bei einem spezialisierten Anbieter, kostet typischerweise 15.000 bis 25.000 Euro. Verglichen mit dem Risiko einer fehlgeschlagenen Migration: eine der rentabelsten Einzelinvestitionen der nächsten Jahre. Die Rendite ist hier besonders greifbar.
Wie nah ist der kryptografisch relevante Quantencomputer wirklich? Das ist die entscheidende Frage – und ehrlich gesagt die mit der größten Unsicherheit. Ein kryptografisch relevanter Quantencomputer für RSA-2048 würde etwa vier Millionen fehlerkorrigierte logische Qubits benötigen. Heute haben die besten Systeme einige hundert bis wenige tausend physische Qubits mit begrenzter Fehlerkorrektur.
Google, IBM und Microsoft haben in den letzten zwei Jahren erhebliche Fortschritte bei der Fehlerkorrektur gezeigt – Googles Willow-Chip Ende 2024 war ein Meilenstein bei fehlerkorrigierten Qubits. Die Schätzungen für einen kryptografisch relevanten Quantencomputer variieren zwischen 2030 und 2040, mit einigen Experten, die 2035 als wahrscheinlichsten Zeitpunkt nennen.
Zum Vergleich: In den frühen 2000ern hätte niemand erwartet, dass 2024 für 20 Euro im Monat unbegrenzte Cloud-Rechenkapazität verfügbar ist. Technologiesprünge passieren nicht linear. Das ist der Grund, warum Sicherheitsexperten zu Recht betonen: Der Zeitpunkt, an dem Post-Quanten-Kryptografie gebraucht wird, könnte früher eintreten als die Mainstream-Schätzungen suggerieren.
Unter dem Strich gilt: Die Migrationsdauer (5–10 Jahre) ist länger als die Zeit bis zum wahrscheinlichen Eintritt der Bedrohung (10–15 Jahre). Das Fenster ist eng. Wer jetzt nicht beginnt, verliert die Chance, geordnet zu migrieren – und wird stattdessen in einer Notoperation agieren. Notoperationen kosten mehr, funktionieren schlechter, und schaffen Sicherheitslücken durch Zeitdruck.
Post-Quanten-Kryptografie ist kein abstraktes Zukunftsszenario mehr. Es ist ein konkretes, messbares, regulatorisch adressiertes Risiko mit einer Zeitachse, die für die meisten Finanzinstitute bereits eng ist. Banking-Sicherheit, die heute auf RSA und ECC beruht, hat ein Verfallsdatum. FinTech-Compliance, die DORA, NIS2 und BSI-Anforderungen ernst nimmt, kommt an Post-Quanten-Kryptografie nicht vorbei.
Die gute Nachricht: Die Standardisierung ist abgeschlossen, Hybridansätze funktionieren in der Praxis, erste Piloten in Finanzinstituten zeigen den Weg. Wer heute beginnt – mit Inventarisierung, Risikoklassifikation und einer dokumentierten Roadmap – kann die regulatorischen Fristen einhalten und die Migration geordnet durchführen.
Die unbequeme Wahrheit: Die meisten deutschen Finanzinstitute haben noch nicht begonnen. Und die Analyse von Novalnet zum zukunftssicheren Zahlungsverkehr macht deutlich, wie konkret die Bedrohung bereits heute ist – nicht erst wenn der erste kryptografisch relevante Quantencomputer online geht, sondern jetzt, durch laufende Harvest-Now-Decrypt-Later-Operationen.
Also: Wo steht Ihr Institut? Gibt es ein vollständiges kryptografisches Inventar? Einen benannten Verantwortlichen? Eine dokumentierte Roadmap, die einem BaFin-Prüfer standhalten würde? Und falls nicht – welches konkrete Datum haben Sie für den Start der Inventarisierung in Ihrer Projektplanung stehen?
Um Ihnen ein optimales Erlebnis zu bieten, verwenden wir Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wenn Sie diesen Technologien zustimmen, können wir Daten wie Ihr Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn Sie Ihre Zustimmung nicht erteilen oder widerrufen, können bestimmte Merkmale und Funktionen beeinträchtigt werden.