Wenn man sich lange genug mit dem Umfang der Migration auf Post-Quanten-Kryptografie (PQC) beschäftigt, kommt man leicht zu einem Schluss: Das wird schwierig werden.
Kryptografie ist in Unternehmenstechnologien aus mehreren Jahrzehnten fest verankert. Sie schützt Webtransaktionen, Netzwerkverbindungen, VPN-Tunnel, Zertifikate, Anwendungen, Infrastruktur und Daten. Bei einigen Systemen wird ein Software-Upgrade letztlich nicht ausreichen. Sie müssen möglicherweise ersetzt werden. In einem großen Unternehmen wird die PQC-Migration dadurch zu einem umfangreichen, mehrjährigen Vorhaben.
Als Ingenieur frage ich mich jedoch nicht als Nächstes, ob das Problem schwierig ist, sondern ob wir das Problem richtig definieren.
Nicht alles muss auf einmal erledigt werden
Einer der größten Fehler, den Unternehmen bei der Vorbereitung auf PQC machen können, besteht darin, ihre gesamte Technologielandschaft zu betrachten und daraus zu schließen, dass alles auf einmal geändert werden muss. Das ist nicht der Fall.
Die Bedrohung durch Quantencomputer wirkt sich auf verschiedene Formen der Kryptografie unterschiedlich aus. Diese Unterscheidung ist wichtig, da Unternehmen so ihre unmittelbaren Risiken gezielt eingrenzen können, anstatt PQC als undifferenzierten Komplettaustausch anzugehen.
“Unternehmen sollten nicht erst Gewissheit über den Zeitpunkt des Q-Day abwarten, bevor sie sich mit der Architektur befassen.”
Die Eingrenzung des Problems lässt bestehende technische Schulden jedoch nicht verschwinden. Tatsächlich kann PQC offenlegen, wie schwerwiegend diese Schulden inzwischen sind. Darauf gehe ich in meinem Vortrag „PQC-Bereitschaft beginnt jetzt“ beim On-Demand-F5 Post Mythos Security Summit näher ein.
Nehmen wir TLS 1.3. F5 Labs’ Forschung aus dem Jahr 2026 ergab, dass 10 % der führenden Websites TLS 1.3 noch immer nicht unterstützen. Das ist mehr als nur ein Modernisierungsproblem. PQC-Verschlüsselungsverfahren können nicht über TLS 1.2 ausgehandelt werden, weshalb TLS 1.3 eine grundlegende Voraussetzung für die PQC-Bereitschaft ist. Unternehmen, die noch immer auf veraltete TLS-Versionen angewiesen sind, müssen daher zunächst entsprechende Vorarbeiten leisten, bevor sie überhaupt den nächsten kryptografischen Übergang vollziehen können.
Der heutige Modernisierungsrückstand kann morgen zum Sicherheitsrisiko werden.
Die Migrationsdauer ist Teil des Risikos
Es gibt noch einen weiteren Grund, das Problem jetzt einzugrenzen, anstatt abzuwarten, bis größere Gewissheit darüber besteht, wann der Q-Day eintreten wird: Nicht nur dieses Datum ist für den Zeitplan entscheidend.
Das Mosca-Theorem bietet einen hilfreichen Ansatz zur zeitlichen Einordnung: Es stellt der verbleibenden Zeit, bis ausreichend leistungsfähige Quantencomputer die heutige Public-Key-Kryptografie gefährden könnten, gegenüber, wie lange Informationen geschützt bleiben müssen und wie lange die Umstellung auf quantensichere Kryptografie dauern wird. Übersteigt die Summe der ersten beiden Zeiträume den dritten, hat die Organisation ein Problem.
Das verändert die Art und Weise, wie wir über die PQC-Bereitschaft denken sollten. Die Migrationsdauer ist nicht nur ein Aspekt der Projektplanung, sondern Teil des Risikos.
Und die Unternehmensarchitektur kann einen enormen Einfluss auf diesen Zeitaufwand haben.
Je enger die Kryptografie mit einzelnen Anwendungen und Systemen verknüpft ist, desto mehr Komponenten muss ein Unternehmen unter Umständen anpassen, testen, validieren und warten. Kommen noch Altsysteme und Abhängigkeiten von Drittanbietern hinzu, kann sich ein vermeintliches Kryptografie-Upgrade schnell zu einer weitreichenden Unternehmenstransformation entwickeln.
Deshalb sollten Unternehmen nicht abwarten, bis Gewissheit über den Zeitpunkt des Q-Day besteht, bevor sie sich mit der Architektur befassen. Man muss nicht genau wissen, wann Quantencomputer die entscheidende Schwelle überschreiten werden, um zu erkennen, dass es von Vorteil ist, die erforderliche Reaktionszeit zu verkürzen.
Für kryptografischen Wandel konzipieren
Letztlich besteht das Ziel nicht nur darin, die heute zugelassenen PQC-Algorithmen einzusetzen, sondern auch die Fähigkeit zu schaffen, sich an die fortlaufende Weiterentwicklung der kryptografischen Anforderungen anzupassen.
Genau das bedeutet für mich Kryptoagilität: die Fähigkeit, kryptografische Algorithmen auszutauschen und anzupassen, ohne den Betrieb laufender Systeme zu unterbrechen.
Eine hilfreiche Frage, die sich Technologieverantwortliche stellen sollten, lautet: Wenn morgen ein kryptografischer Algorithmus geändert werden müsste, wie viele Anwendungen müssten wir dann anfassen?
Wenn die Antwort Hunderte oder Tausende lautet, ist PQC nicht nur ein kryptografisches Problem, sondern ein Architekturproblem.
Und der Versuch, dieses Problem zu lösen, indem eine Anwendung nach der anderen manuell umgeschrieben wird, ist keine attraktive Lösung. In einem großen Unternehmen kann dieser Ansatz langsam und kostspielig werden, den Betrieb beeinträchtigen und die Infrastruktur stark belasten.
Glücklicherweise ist das nicht die einzige Lösung.
Die bevorstehende Herausforderung ist beträchtlich. Unternehmen können sie jedoch besser bewältigen, indem sie ermitteln, wo ihre tatsächlichen Risiken liegen, verstehen, welche Abhängigkeiten sie kontrollieren, und ihre Infrastruktur so gestalten, dass kryptografische Änderungen nicht zum Problem jedes einzelnen Anwendungsteams werden.
Summit-Session: Jetzt mit der Vorbereitung auf PQC beginnen
Beim On-Demand-F5 Post-Mythos Security Summit gehe ich in meiner Session „Jetzt mit der Vorbereitung auf PQC beginnen“ genau auf diese Herausforderung ein. Erfahren Sie, wie Sie mit einem praxisnahen dreistufigen Ansatz unmittelbare Risiken erfassen, den Übergang steuern und Ihre Infrastruktur schützen können, ohne den laufenden Betrieb unnötig zu beeinträchtigen.
Über den Autor
Ähnliche Blogbeiträge
Vier Gründe, warum Sie den F5 Post-Mythos Security Summit nicht verpassen sollten
Holen Sie sich Expertenrat, um Ihre Apps, APIs und Modelle in der Post-Mythos-Welt zu schützen.
Von einer App zu einer ganzen Agentenflotte: Ein 90-Tage-Framework für KI-Sicherheit
Vermeiden Sie den kostspieligen Ansatz „Jetzt bereitstellen, später absichern“ – mit einem umfassenden Framework zum Schutz von KI-Modellen, Anwendungen und autonomen Agenten.
Fünf Stufen antifragiler Cyberresilienz verwandeln Praxis in Ergebnisse
Erfahren Sie, wie fünf Stufen antifragiler Resilienz Störungen in adaptive Verhaltensweisen überführen, die Ausfälle begrenzen und hybride Multicloud-Architekturen stärken.
Warum Ihre KI-Richtlinien, Governance und Leitplanken nicht warten können
KI-Richtlinien und -Governance dürfen nicht länger als reine Formalitäten oder Zukunftsthemen betrachtet werden. Sie müssen durch praktische, durchsetzbare Leitplanken ergänzt werden.
Wenn „privat“ nicht privat ist: Wie ChatGPT-Unterhaltungen öffentlich wurden
KI verändert die Arbeitsabläufe in Unternehmen, doch eine übersehene Einstellung hat bereits Tausende vertraulicher Unterhaltungen öffentlich zugänglich gemacht
KI-Nutzung verstehen: Warum Unternehmen Transparenz brauchen
Anstatt einen zu laxen oder zu strengen Ansatz zu verfolgen, können Unternehmen durch mehr Transparenz bei der KI-Nutzung fundierte und durchsetzbare Entscheidungen treffen.