Verschlüsselung ist eine der wichtigsten Grundlagen moderner IT. Sie schützt Kundenportale, Cloud-Zugänge, E-Mails, VPN-Verbindungen, APIs, Software-Updates, digitale Signaturen und sensible Unternehmensdaten.
Für viele Unternehmen wirkt Verschlüsselung deshalb wie ein gelöstes Thema: Zertifikat einrichten, TLS aktivieren, Schlüssel verwalten, fertig.
Doch diese Sicherheit basiert häufig auf mathematischen Verfahren, die durch leistungsfähige Quantencomputer künftig angreifbar werden könnten. Besonders betroffen sind weit verbreitete asymmetrische Verfahren wie RSA und ECC.
Das bedeutet nicht, dass heutige Verschlüsselung morgen wertlos ist. Aber es bedeutet: Unternehmen sollten jetzt prüfen, wo sie kryptografisch abhängig sind, welche Daten langfristig geschützt bleiben müssen und wie gut ihre Systeme auf einen Wechsel vorbereitet sind.
Warum Post-Quanten-Sicherheit jetzt relevant wird
Post-Quanten-Sicherheit beschreibt den Schutz von IT-Systemen gegen Angriffe, die mit zukünftigen Quantencomputern möglich werden könnten.
Dabei geht es nicht nur um neue Algorithmen. Es geht um einen strukturierten Übergang:
- Welche Verschlüsselungsverfahren nutzen wir heute?
- Wo stecken RSA, ECC oder andere asymmetrische Verfahren in unseren Systemen?
- Welche Daten müssen langfristig vertraulich bleiben?
- Welche Anwendungen, Schnittstellen und Cloud-Services lassen sich überhaupt schnell umstellen?
- Welche Systeme sind kritisch, aber schwer aktualisierbar?
Der Grund für die aktuelle Dynamik: Die Standardisierung ist deutlich vorangeschritten. Mit den ersten finalen Post-Quantum-Cryptography-Standards gibt es eine belastbarere Grundlage für Planung, Tests und Migrationsstrategien.
Für Unternehmen verschiebt sich die Frage deshalb von „Ist das überhaupt relevant?“ zu „Wie bereiten wir uns sinnvoll darauf vor?“
Praxispunkt
Post-Quanten-Sicherheit sollte nicht als isoliertes Security-Projekt verstanden werden. Sie betrifft Softwarearchitektur, Cloud-Infrastruktur, IT-Betrieb, Datenklassifizierung, Lieferantenmanagement und langfristige Digitalisierungsstrategie.
Welche Verschlüsselung ist besonders betroffen?
Nicht jede Verschlüsselung ist gleichermaßen gefährdet. Besonders im Fokus stehen asymmetrische Verfahren.
Diese werden unter anderem genutzt für:
- Schlüsselaustausch, zum Beispiel bei TLS-Verbindungen
- digitale Signaturen, etwa bei Software-Updates oder Dokumenten
- Authentifizierung und Identitätsprüfung
- Zertifikatsketten und Public-Key-Infrastrukturen
Vor allem RSA und ECC sind heute sehr verbreitet. Ihre Sicherheit basiert auf mathematischen Problemen, die klassische Computer praktisch nicht effizient lösen können. Leistungsfähige Quantencomputer könnten diese Annahme jedoch grundsätzlich verändern.
Symmetrische Verfahren wie AES sind anders zu bewerten. Sie gelten nicht im gleichen Sinn als gebrochen, benötigen aber je nach Schutzbedarf geeignete Schlüssellängen und eine saubere Umsetzung.
Wichtig ist daher: Unternehmen sollten nicht pauschal „alle Verschlüsselung“ austauschen. Sie sollten verstehen, welche Verfahren wo eingesetzt werden und welche Schutzdauer erforderlich ist.
Das eigentliche Risiko: „Harvest now, decrypt later“
Ein zentraler Begriff in der Debatte ist „Harvest now, decrypt later“.
Gemeint ist ein Angriffsmuster, bei dem verschlüsselte Daten heute abgefangen und gespeichert werden. Die Entschlüsselung erfolgt erst später, sobald geeignete technische Möglichkeiten verfügbar sind.
Das klingt zunächst theoretisch. Für viele Unternehmen ist es jedoch sehr praktisch relevant.
Besonders betroffen sind Daten, die langfristig vertraulich bleiben müssen, zum Beispiel:
- Forschungs- und Entwicklungsdaten
- Vertragsunterlagen
- Geschäftsgeheimnisse
- personenbezogene Daten
- Gesundheitsdaten
- technische Dokumentationen
- strategische Unternehmensinformationen
- Behörden- oder KRITIS-Kommunikation
Nicht jede Information muss in zehn oder zwanzig Jahren noch geschützt sein. Aber bei sensiblen Daten mit langer Schutzdauer entsteht schon heute ein Risiko.
Leitfrage für Unternehmen
Welche Daten wären problematisch, wenn sie nicht heute, sondern in fünf, zehn oder zwanzig Jahren entschlüsselt würden?
Diese Frage ist oft wichtiger als die Frage, wann genau ein kryptografisch relevanter Quantencomputer verfügbar sein wird.
Warum Post-Quanten-Kryptografie kein einfaches Update ist
Viele Unternehmen hoffen darauf, dass Betriebssysteme, Browser, Cloud-Anbieter oder Security-Produkte das Problem irgendwann automatisch lösen.
Teilweise wird das passieren. Große Plattformen und Standardsoftware werden Post-Quanten-Verfahren zunehmend integrieren. Trotzdem reicht reines Abwarten nicht aus.
Der Grund: Kryptografie steckt an vielen Stellen, häufig auch dort, wo sie nicht sofort sichtbar ist.
Typische Beispiele sind:
- Webserver und TLS-Zertifikate
- VPN-Zugänge
- E-Mail-Gateways
- Identity Provider
- API-Gateways
- Datenbankverbindungen
- mobile Apps
- IoT- und Embedded-Systeme
- CI/CD-Pipelines
- Container-Images
- Software-Update-Prozesse
- digitale Signaturen
- Drittanbieter-SDKs
- alte Java-, .NET- oder Legacy-Anwendungen
Einige dieser Komponenten lassen sich regelmäßig aktualisieren. Andere laufen seit Jahren stabil, sind aber nur schwer veränderbar. Genau dort entsteht Migrationsaufwand.
Hinzu kommt: Post-Quanten-Verfahren haben andere technische Eigenschaften. Schlüssel, Signaturen oder Zertifikate können größer sein. Protokolle müssen angepasst, Performance getestet und Kompatibilität geprüft werden.
Empfehlung
Unternehmen sollten Krypto-Agilität als Architekturziel definieren. Systeme sollten so gebaut sein, dass kryptografische Verfahren austauschbar bleiben, ohne die gesamte Anwendung neu entwickeln zu müssen.
Standards und Roadmaps: Orientierung ist vorhanden
Post-Quanten-Sicherheit ist greifbarer geworden, weil aus Forschung zunehmend Standards und Roadmaps entstehen.
Zu den wichtigsten Entwicklungen gehören:
- standardisierte Verfahren für quantensicheren Schlüsselaustausch
- standardisierte Verfahren für digitale Signaturen
- Empfehlungen von Behörden und Standardisierungsgremien
- Roadmaps für koordinierte Migrationen
- erste Integrationen in Plattformen, Bibliotheken und Cloud-Umgebungen
Für Unternehmen bedeutet das: Es gibt inzwischen eine realistische Grundlage für Planung. Gleichzeitig heißt Standardisierung nicht, dass jede bestehende Anwendung sofort bereit ist.
Die eigentliche Arbeit liegt in der eigenen IT-Landschaft.
Unternehmen müssen klären:
- Welche Systeme sind betroffen?
- Welche Hersteller liefern Updates?
- Welche Eigenentwicklungen müssen angepasst werden?
- Welche Datenflüsse sind besonders kritisch?
- Welche Anwendungen werden ohnehin modernisiert?
- Welche Systeme haben lange Lebenszyklen?
Post-Quanten-Sicherheit wird dadurch zu einer Roadmap-Aufgabe, nicht zu einem Einzelupdate.
Wo Unternehmen ihre Kryptografie finden müssen
Der schwierigste Teil einer PQC-Migration ist oft nicht die Auswahl eines Algorithmus. Schwieriger ist die Frage: Wo nutzen wir überhaupt Kryptografie?
Ein Krypto-Inventar hilft, diese Abhängigkeiten sichtbar zu machen.
Es sollte mindestens vier Perspektiven abdecken.
1. Technische Systeme
Dazu gehören Anwendungen, Server, Datenbanken, Zertifikate, Bibliotheken, APIs, Gateways und Cloud-Services.
Wichtig ist nicht nur, ob Verschlüsselung eingesetzt wird. Wichtig ist auch, welches Verfahren verwendet wird, wie es konfiguriert ist und wer es aktualisieren kann.
2. Datenflüsse
Unternehmen sollten verstehen, welche Daten wohin übertragen werden.
Besonders relevant sind Verbindungen zwischen:
- Kundenportalen und Backend-Systemen
- internen Fachanwendungen
- Cloud-Diensten
- externen Partnern
- mobilen Anwendungen
- Maschinen, Sensoren oder IoT-Komponenten
3. Schutzbedarf und Schutzdauer
Nicht alle Daten sind gleich kritisch. Entscheidend ist, wie lange sie vertraulich bleiben müssen.
Kurzlebige operative Daten haben ein anderes Risikoprofil als Geschäftsgeheimnisse, Forschungsdaten oder personenbezogene Informationen mit langfristiger Relevanz.
4. Lieferanten und Abhängigkeiten
Viele Unternehmen nutzen Software, Plattformen oder Geräte externer Anbieter. Deshalb gehört auch das Lieferantenmanagement zur Post-Quanten-Sicherheit.
Wichtige Fragen sind:
- Gibt es eine PQC-Roadmap?
- Welche kryptografischen Bibliotheken werden genutzt?
- Wann sind Updates geplant?
- Werden hybride Verfahren unterstützt?
- Welche Systeme sind nicht mehr updatefähig?
Ein Krypto-Inventar schafft damit nicht nur Transparenz für Post-Quanten-Sicherheit. Es zeigt oft auch technische Schulden, veraltete Abhängigkeiten und Modernisierungspotenzial.
Typische Missverständnisse in der Praxis
In Gesprächen über Post-Quanten-Sicherheit tauchen immer wieder ähnliche Einwände auf. Viele davon sind nachvollziehbar, greifen aber zu kurz.
„Quantencomputer sind noch nicht so weit.“
Das stimmt aus heutiger praktischer Sicht. Aber große IT-Migrationen brauchen Zeit. Außerdem betrifft das Risiko langfristig vertrauliche Daten bereits heute.
Die richtige Schlussfolgerung lautet daher nicht: „Wir müssen sofort alles austauschen.“
Sie lautet: „Wir sollten jetzt wissen, wo wir betroffen wären.“
„Unser Cloud-Anbieter wird das schon lösen.“
Cloud-Anbieter werden wichtige Bausteine bereitstellen. Aber sie kennen nicht automatisch alle individuellen Anwendungen, Datenflüsse, Schnittstellen, Compliance-Anforderungen und Fachprozesse eines Unternehmens.
Die Verantwortung für Risikoanalyse, Priorisierung und Architektur bleibt beim Unternehmen.
„Post-Quanten-Sicherheit ist nur ein Security-Thema.“
Post-Quanten-Sicherheit betrifft Security, aber nicht nur Security.
Sie betrifft auch:
- Softwareentwicklung
- Enterprise-Architektur
- IT-Betrieb
- Cloud-Strategie
- Datenschutz
- Einkauf
- Fachbereiche
- Produktentwicklung
- Compliance
Wer das Thema zu eng fasst, übersieht wichtige Abhängigkeiten.
„Wir ersetzen einfach RSA und ECC.“
Ein reiner Austausch einzelner Algorithmen kann neue Risiken schaffen, wenn Kompatibilität, Performance, Zertifikatsketten, Legacy-Systeme und Betriebsprozesse nicht mitgedacht werden.
Besser ist ein kontrollierter, getesteter und dokumentierter Übergang.
Vor- und Nachteile einer frühen Vorbereitung
Eine frühe Beschäftigung mit Post-Quanten-Sicherheit hat klare Vorteile. Sie bedeutet aber auch Aufwand.
Vorteile
Unternehmen gewinnen Transparenz über ihre kryptografischen Abhängigkeiten. Sie können Risiken priorisieren, Modernisierungen besser planen und neue Systeme krypto-agiler bauen.
Außerdem lassen sich Post-Quanten-Anforderungen gut mit ohnehin geplanten Projekten verbinden, etwa Cloud-Migration, Softwaremodernisierung, Zero-Trust-Architekturen oder Datenplattformen.
Herausforderungen
Der Aufwand liegt vor allem in der Bestandsaufnahme. Viele kryptografische Abhängigkeiten sind nicht sauber dokumentiert. Außerdem sind Standards, Produkte und Hersteller-Roadmaps noch nicht überall gleich weit.
Auch Tests sind wichtig. Neue Verfahren können andere Anforderungen an Performance, Paketgrößen, Speicher oder Kompatibilität stellen.
Realistische Einordnung
Frühe Vorbereitung heißt nicht, sofort eine vollständige Migration umzusetzen. Sie heißt, die eigene Ausgangslage zu kennen und zukünftige Entscheidungen bewusst zu treffen.
Best Practices für eine realistische PQC-Migration
Eine sinnvolle Post-Quanten-Roadmap beginnt nicht mit Aktionismus, sondern mit Struktur.
1. Verantwortung klären
Post-Quanten-Sicherheit braucht klare Zuständigkeiten. IT-Security, Architektur, Infrastruktur, Softwareentwicklung, Datenschutz, Einkauf und Fachbereiche sollten gemeinsam arbeiten.
Ohne Governance bleibt das Thema schnell abstrakt.
2. Krypto-Inventar erstellen
Der wichtigste erste Schritt ist Transparenz. Unternehmen sollten erfassen, wo kryptografische Verfahren eingesetzt werden und welche Systeme besonders kritisch sind.
Dabei helfen Kriterien wie:
- Kritikalität des Systems
- Schutzbedarf der Daten
- erforderliche Schutzdauer
- Änderbarkeit der Anwendung
- Abhängigkeit von Herstellern
- regulatorische Anforderungen
- geplante Modernisierungen
3. Daten nach Schutzdauer bewerten
Nicht jedes System muss sofort priorisiert werden. Besonders wichtig sind Daten, die lange vertraulich bleiben müssen.
Hier liegt der größte Bezug zu „Harvest now, decrypt later“.
4. Krypto-Agilität in neuen Projekten verankern
Neue Anwendungen sollten so entwickelt werden, dass Kryptografie nicht fest im Code verdrahtet ist.
Besser sind klare Abstraktionen, zentrale Konfigurationen, dokumentierte Bibliotheken und testbare Austauschmechanismen.
5. Pilotprojekte starten
Statt eine gesamte Landschaft auf einmal umzustellen, eignen sich abgegrenzte Pilotbereiche.
Mögliche Piloten sind:
- interne APIs
- neue Plattformmodule
- Testumgebungen
- Zertifikatsmanagement
- ausgewählte Cloud-Services
- Software-Signaturprozesse
So lassen sich technische und organisatorische Auswirkungen früh erkennen.
6. Lieferanten aktiv einbinden
Unternehmen sollten Anbieter gezielt nach Roadmaps fragen.
Relevant sind nicht nur große Plattformanbieter, sondern auch Fachsoftware, Embedded-Systeme, Maschinenhersteller, Security-Produkte und Integrationspartner.
7. Entscheidungen dokumentieren
Nicht jedes Risiko wird sofort beseitigt. Deshalb sollten Unternehmen dokumentieren, warum bestimmte Systeme priorisiert werden und andere zunächst nicht.
Das hilft bei Audits, Compliance-Fragen und späteren Migrationswellen.
Praxisbeispiel: Vom Krypto-Inventar zur Roadmap
Ein mittelständisches Unternehmen betreibt ein Kundenportal, mehrere interne Fachanwendungen, eine Cloud-Datenplattform und VPN-Zugänge für externe Dienstleister.
Auf den ersten Blick wirkt die Sicherheitslage solide:
- TLS-Zertifikate sind aktuell
- Zugriffe laufen über zentrale Identitäten
- Backups sind verschlüsselt
- Cloud-Services werden professionell betrieben
- Standardsoftware erhält regelmäßige Updates
Bei genauerer Analyse zeigt sich jedoch ein differenzierteres Bild.
Das Kundenportal verarbeitet personenbezogene Daten, die langfristig relevant sein können. Eine ältere Fachanwendung nutzt eine veraltete kryptografische Bibliothek. Software-Updates für ein internes Tool werden digital signiert, aber der Prozess ist kaum dokumentiert. Einige Schnittstellen zu Partnern verwenden Zertifikate, deren Erneuerung manuell erfolgt.
Eine realistische Roadmap würde hier nicht alles gleichzeitig anfassen.
Zuerst werden Datenflüsse und Schutzklassen bewertet. Danach werden besonders kritische Systeme priorisiert. Parallel prüft das Unternehmen, welche Softwarekomponenten aktualisierbar sind und welche Hersteller bereits PQC-Roadmaps anbieten.
Für neue Entwicklungen wird festgelegt, dass Kryptografie künftig austauschbar integriert wird. Bei geplanten Modernisierungen werden Post-Quanten-Anforderungen direkt mitberücksichtigt.
Das Ergebnis ist keine hektische Komplettmigration, sondern ein kontrollierter Übergang.
Was Unternehmen jetzt konkret tun sollten
Für den Einstieg braucht es kein Großprojekt. Sinnvoll ist ein klar begrenzter Startpunkt.
Ein praktikabler erster Schritt ist ein Workshop mit IT, Security, Architektur und ausgewählten Fachbereichen.
Ziel dieses Workshops:
- relevante Datenarten identifizieren
- Schutzdauer einschätzen
- kritische Systeme benennen
- bekannte kryptografische Abhängigkeiten sammeln
- Herstellerabhängigkeiten erfassen
- Modernisierungsprojekte mit Bezug zu Kryptografie erkennen
- nächste Analyse- und Pilotbereiche festlegen
Daraus entsteht eine erste Heatmap: Welche Systeme sind kritisch? Welche sind leicht anpassbar? Wo besteht Unsicherheit? Wo lohnt sich eine tiefere technische Analyse?
Diese Vorgehensweise schafft Orientierung, ohne vorschnell Technologieentscheidungen zu erzwingen.
Fazit: Post-Quanten-Sicherheit ist eine Architekturaufgabe
Post-Quanten-Sicherheit bedeutet nicht, dass heutige Verschlüsselung sofort versagt. Sie bedeutet aber, dass Unternehmen ihre kryptografischen Abhängigkeiten ernst nehmen sollten.
Besonders betroffen sind asymmetrische Verfahren, digitale Signaturen und Daten mit langer Vertraulichkeitsdauer. Das Risiko liegt weniger in einem plötzlichen Stichtag, sondern in langen IT-Lebenszyklen, unklaren Abhängigkeiten und fehlender Krypto-Agilität.
Der richtige Weg ist deshalb pragmatisch:
Erst Transparenz schaffen. Dann Risiken bewerten. Danach priorisieren, testen und schrittweise migrieren.
Für GECKO liegt der natürliche Beitrag genau an dieser Schnittstelle: individuelle Softwareentwicklung, Cloud- und IT-Services, Business Applications und strategische Technologieberatung müssen zusammengedacht werden. Wer Anwendungen modernisiert, Datenplattformen aufbaut oder Cloud-Architekturen weiterentwickelt, kann Post-Quanten-Sicherheit früh und sinnvoll berücksichtigen.
Call-to-Action:
Lassen Sie Ihre Software- und IT-Landschaft auf kryptografische Abhängigkeiten prüfen. GECKO unterstützt dabei, Risiken zu strukturieren, Migrationspfade zu priorisieren und Post-Quanten-Sicherheit in bestehende Modernisierungs- und Digitalisierungsprojekte einzubetten.
