Krypto-Agilität erklärt: die NIST-Definition, eine anpassbare Richtlinie, was eine Krypto-Agilitäts-Plattform leisten muss, KPIs und ein Reifegradmodell.
Krypto-Agilität (kryptografische Agilität) ist die Fähigkeit einer Organisation, die kryptografischen Algorithmen, Schlüssel und Parameter in ihren Protokollen, Anwendungen, ihrer Hardware und Infrastruktur zu ersetzen und anzupassen, ohne die Sicherheit zu gefährden oder den Betrieb zu unterbrechen. In der Praxis heisst das: Sie wissen, wo jeder Algorithmus eingesetzt wird, Anwendungen beziehen Kryptografie über eine Richtlinie statt sie fest einzuprogrammieren, und der Wechsel eines Algorithmus über die gesamte IT-Landschaft ist eine geplante, messbare Änderung und kein mehrjähriges Neuentwicklungsprojekt.
Das geschäftliche Problem: Jede Organisation muss RSA und Elliptische-Kurven-Kryptografie durch Post-Quanten-Algorithmen ersetzen, und der Entwurf des NIST-Übergangsplans setzt für die quantenanfälligen Verfahren das Enddatum 2035. Tausende Anwendungen, Zertifikate und Geräte von Hand anzupassen, wird nicht rechtzeitig gelingen. Algorithmen per Richtlinienänderung zu wechseln, schon.
Dieser Leitfaden liefert die NIST-Definition, die fünf Bausteine und drei praktische Werkzeuge: eine Gliederung für eine Krypto-Agilitäts-Richtlinie mit Beispielregeln, eine Checkliste der Plattformfähigkeiten sowie KPIs mit einem fünfstufigen Reifegradmodell.
Die massgebliche Definition stammt vom NIST. Sein Cybersecurity White Paper 39, Considerations for Achieving Crypto Agility: Strategies and Practices, wurde am 19. Dezember 2025 erstmals als finale Fassung veröffentlicht. Die aktuelle Version, CSWP 39 upd1, enthält Aktualisierungen mit Stand 29. Juni 2026 und ersetzt die Fassung vom Dezember 2025. (Der Entwurf vom März 2025 trug den Titel Considerations for Achieving Cryptographic Agility, weshalb beide Schreibweisen im Umlauf sind.) Die Zusammenfassung beginnt mit:
"Cryptographic (crypto) agility refers to the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations."
Beachten Sie den Plural "capabilities" (Fähigkeiten): Krypto-Agilität umfasst Inventar, Architektur, Prozesse und Werkzeuge, nicht ein einzelnes Produkt. "Replace and adapt" (ersetzen und anpassen) deckt sowohl den Austausch von RSA durch ML-DSA ab als auch die Änderung von Parametern oder hybriden Kombinationen. Und eine Änderung, die einen Ausfall erfordert oder einen Downgrade-Pfad offenlässt, erfüllt die Anforderung "preserving security and ongoing operations" (Sicherheit und laufenden Betrieb wahren) nicht.
NIST IR 8547, Transition to Post-Quantum Cryptography Standards, wurde am 12. November 2024 als erster öffentlicher Entwurf veröffentlicht und ist auf csrc.nist.gov weiterhin als Entwurf gekennzeichnet. Der vorgeschlagene Zeitplan für quantenanfällige digitale Signaturen (RSA, ECDSA, EdDSA) und Schlüsselaustausch (Finite-Field- und Elliptic-Curve-Diffie-Hellman und MQV, RSA):
| Sicherheitsniveau | Vorgeschlagener Status |
|---|---|
| 112 Bit (z. B. RSA-2048) | Nach 2030 veraltet (deprecated), nach 2035 nicht mehr zulässig |
| 128 Bit und mehr (z. B. ECDSA P-256, RSA-3072) | Nach 2035 nicht mehr zulässig |
Der Entwurf orientiert sich am National Security Memorandum 10, das 2035 als primäres Zieljahr festlegt. Behandeln Sie die Daten als Planungsgrundlage, nicht als endgültig. So oder so sind neun Jahre knapp, wenn Algorithmen in Anwendungen einkompiliert und in Gerätefirmware eingebrannt sind.
Daten, die heute mit RSA- oder ECDH-Schlüsselaustausch verschlüsselt werden, können zudem jetzt aufgezeichnet und später entschlüsselt werden: siehe Store now, decrypt later.
PQC-Implementierungen werden Patches erhalten, Parameter können sich ändern, und hybride Kombinationen werden irgendwann reiner PQC weichen. Krypto-Agilität macht aus der nächsten Änderung Routine statt einer Krise.
Regulierer verlangen gesteuerte, überprüfbare Kryptografie statt eines bestimmten Algorithmus:
Der gemeinsame Nenner: Eine Prüferin oder ein Prüfer wird fragen, woher Sie wissen, welche Kryptografie Sie einsetzen, wer entscheidet, was erlaubt ist, und wie schnell Sie sie ändern können. Diese drei Fragen sind Krypto-Agilität.
Was man nicht findet, kann man nicht ersetzen. Das Inventar erfasst jedes Zertifikat, jeden Schlüssel, Algorithmus, jede Bibliothek und jeden Endpunkt, deren Verantwortliche und die geschützten Daten; in maschinenlesbarer Form ist es eine Cryptography Bill of Materials (siehe unseren CBOM-Leitfaden). Es muss laufend aktualisiert werden, nicht einmalig erstellt.
Der architektonische Kern. Ruft eine Anwendung RSA_sign() direkt auf, bedeutet jeder Algorithmuswechsel eine Codeänderung, einen Neubau und ein erneutes Deployment. Bittet sie dagegen einen Dienst, "diesen Kundendatensatz zu signieren", und der Algorithmus stammt aus einer zentralen Richtlinie, erfolgt die Änderung an einer einzigen Stelle. Die Abstraktion kann eine Krypto-Service-API sein, eine KMS- oder HSM-Schnittstelle (PKCS#11, KMIP), ein TLS-Gateway oder eine CA, die bei der Erneuerung den neuen Algorithmus ausstellt.
Eine schriftliche, versionierte Richtlinie legt fest, welche Algorithmen für welche Datenklassen und Zwecke zugelassen sind, wie die hybride Ausrichtung aussieht, was eine Ausserbetriebnahme auslöst und wie schnell Schlüssel rotiert werden müssen. Die Richtlinie ist das, was die Prüfer lesen. In einer agilen IT-Landschaft ist sie auch das, was die Abstraktionsschicht ausführt.
Ausstellung und Erneuerung von Zertifikaten (ACME, EST, SCEP, CMP), Schlüsselrotation, Deployment und Behebungstickets müssen ohne manuelle Schritte ablaufen. Handarbeit skaliert nicht auf eine Migration.
Grössere Post-Quanten-Schlüssel, Clients, die ML-DSA nicht verstehen, und Middleboxes, die grosse Handshakes verwerfen, führen zu Fehlern. Simulation, gestaffelter Rollout und Rollback sind Teil der Agilität, kein Zusatz.
Eine Krypto-Agilitäts-Richtlinie ist das Governance-Dokument, das festlegt, welche Kryptografie erlaubt ist, wer dafür verantwortlich ist und wie und wie schnell sie sich ändert. Nutzen Sie die folgende Gliederung als Ausgangspunkt. Die Beispielregeln dienen der Veranschaulichung; legen Sie die Werte passend zu Ihrer Risikobereitschaft, Ihren Regulierern und der Unterstützung durch Ihre Anbieter fest.
| Abschnitt | Beispielregel (Werte an Ihren Kontext anpassen) |
|---|---|
| Zugelassene Algorithmen | Neue Signaturen verwenden ML-DSA-65 oder ein hybrides Composite aus ML-DSA-65 + ECDSA P-256; neuer Schlüsselaustausch verwendet ML-KEM hybrid mit einer klassischen Gruppe, sofern das Protokoll dies unterstützt; symmetrische Verschlüsselung verwendet AES-256. |
| Hybrid-Ausrichtung | Daten mit Vertraulichkeitsanforderungen über 2035 hinaus (Kunden-PII, langfristige Verträge) sind standardmässig hybrid; interne Systeme, bei denen Sie beide Enden kontrollieren, können auf pqc_only wechseln; Legacy-Schnittstellen bleiben nur mit einer dokumentierten Ausnahme classical. |
| Verboten | Keine neuen RSA- oder ECC-Schlüssel unter 112 Bit Sicherheitsniveau; keine SHA-1-Signaturen; kein 3DES oder RC4. |
| Auslöser für die Ausserbetriebnahme | Die Ausserbetriebnahme beginnt, wenn NIST, BSI oder eine nationale Behörde einen Algorithmus als veraltet einstuft, ein praktischer Angriff veröffentlicht wird oder der Herstellersupport endet; innerhalb von 30 Tagen folgt ein Ablaufdatum, und neue Verwendungen werden sofort gestoppt. |
| Rotations-SLAs | TLS-Zertifikate werden vor Ablauf automatisch erneuert; Datenverschlüsselungsschlüssel werden mindestens jährlich rotiert; ein mutmasslich kompromittierter Schlüssel wird innerhalb von 24 Stunden widerrufen und ersetzt. |
| Verantwortlichkeit | Jeder Schlüssel und jedes Zertifikat hat im Inventar eine namentlich benannte verantwortliche Person und eine zugeordnete Anwendung; Assets ohne Verantwortliche werden innerhalb von 7 Tagen markiert. |
| Abstraktion | Neue Anwendungen müssen Kryptografie über den zugelassenen Krypto-Service oder die KMS-Schnittstelle anfordern; die direkte Verwendung eines Algorithmus im Code erfordert eine Ausnahme. |
| Ausnahmen und Überprüfung | Ausnahmen gelten höchstens 12 Monate, werden vom Crypto Review Board genehmigt und im Inventar erfasst; die Richtlinie wird jährlich und bei jedem Ausserbetriebnahme-Auslöser überprüft. |
Eine Krypto-Agilitäts-Plattform setzt die Richtlinie in laufende Kontrollen um: Sie findet Kryptografie, entscheidet, was erlaubt ist, setzt dies über eine Abstraktionsschicht durch und weist es gegenüber Prüfern nach. Bewerten Sie Fähigkeiten, nicht Etiketten.
| Fähigkeit | Was zu prüfen ist | Warum es wichtig ist |
|---|---|---|
| Discovery | Zertifikate, Schlüssel und Keystores auf Hosts; Inventare von Cloud-KMS; TLS-Endpunkte; Erkennung von Algorithmus und Schlüssellänge | Ein Inventar, das Sie nicht von Hand aufbauen müssen |
| Risikobewertung | Quanten- und klassisches Risiko je Asset; ein aggregierter Bereitschaftswert | Ermöglicht Priorisierung, statt alles auf einmal zu migrieren |
| Zentrale Richtlinie | Algorithmen werden aus einer Richtlinie nach Datenklasse und Zweck abgeleitet, mit Versionierung | Eine Stelle für Änderungen; ein Dokument für die Prüfung |
| PQC- und Hybrid-Unterstützung | ML-KEM, ML-DSA, SLH-DSA, hybride Composites; klassische, hybride und reine PQC-Ausrichtung | Der Algorithmuswechsel, auf den Sie sich tatsächlich vorbereiten |
| Abstraktion für Anwendungen | API oder SDK, bei dem der Code eine Absicht statt eines Algorithmus deklariert | Algorithmuswechsel ohne Codeänderungen |
| Backend-Unabhängigkeit | PKCS#11 und KMIP; HSMs, Cloud-KMS, Open-Source-Vaults | Vermeidet, einen Lock-in durch einen anderen zu ersetzen |
| Zertifikatsautomatisierung | ACME, EST, SCEP, CMP; PQC- und Hybrid-CAs; Deployment-Konnektoren | Die meisten Algorithmuswechsel erreichen Server über Zertifikate |
| Simulation | "Was bricht, wenn wir diese Richtlinie ändern?" vor dem Rollout | Wahrt den laufenden Betrieb, wie es die NIST-Definition verlangt |
| Behebungs-Workflow | Tickets oder Pull Requests an Verantwortliche; ITSM-Integration; menschliche Freigabe | Macht aus Befunden Änderungen |
| Audit-Trail | Manipulationssicheres Protokoll von Richtlinienänderungen und Schlüsseloperationen | Zeigt, was sich wann geändert hat und wer es genehmigt hat |
Eine Demo, die nur Discovery abdeckt, zeigt ein Inventarisierungswerkzeug; eine, die nur Schlüsselspeicherung abdeckt, zeigt ein KMS. Eine Krypto-Agilitäts-Plattform schliesst den Kreis von der Discovery bis zur durchgesetzten Änderung.
Die folgenden KPIs sind empfohlene Kennzahlen für Ihr eigenes Programm, keine Benchmarks. Erheben Sie jetzt eine Ausgangsbasis und verfolgen Sie den Trend vierteljährlich.
| KPI | Definition | Messung | Richtung |
|---|---|---|---|
| Zeit bis zum Ersatz eines Algorithmus in der gesamten IT-Landschaft | Verstrichene Zeit von einer Entscheidung zur Ausserbetriebnahme bis zur Entfernung der letzten produktiven Verwendung | Eine Übung für einen Algorithmus oder eine Datenklasse durchführen und Start- und Enddatum erfassen | Niedriger ist besser; dies ist die zentrale Kennzahl |
| % inventarisierte Assets | Entdeckte kryptografische Assets mit vollständigem Inventareintrag / geschätzte Gesamtzahl | Discovery-Abdeckung (Hosts, Cloud-Konten, Endpunkte) mit der CMDB vergleichen | Höher; Ziel ist die vollständige Abdeckung der Produktion |
| % Schlüssel und Zertifikate mit verantwortlicher Person | Assets mit namentlich benannter verantwortlicher Person und Anwendung / alle inventarisierten Assets | Inventarabfrage | Höher; verwaiste Schlüssel blockieren die Migration |
| % Dienste hinter einer Abstraktionsschicht | Dienste, die Algorithmen aus der Richtlinie beziehen (Krypto-API, KMS, Gateway) / alle Dienste, die Kryptografie nutzen | Architekturprüfung und Code-Scanning | Höher; der Frühindikator für künftige Geschwindigkeit |
| Mittlere Zeit bis zur Rotation | Durchschnittliche Zeit, um einen Schlüssel zu rotieren oder ein Zertifikat neu auszustellen, sobald eine Rotation erforderlich ist | Zeitstempel aus Tickets oder Automatisierung | Niedriger |
Die erste Kennzahl beantwortet die Frage der Geschäftsleitung: "Wenn wir diesen Algorithmus morgen ersetzen müssten, wie lange würde das dauern?" Die übrigen sind Hebel auf diese Zahl.
Legen Sie damit je Geschäftseinheit eine aktuelle und eine Zielstufe fest; die meisten Organisationen sind uneinheitlich aufgestellt, etwa Stufe 3 bei TLS-Zertifikaten und Stufe 1 bei Anwendungssignaturen.
| Stufe | Name | Inventar | Architektur | Richtlinie und Governance | Änderungsfähigkeit |
|---|---|---|---|---|---|
| 1 | Ad hoc | Keines oder unvollständige Tabellen | Algorithmen fest in Anwendungen und Geräte einprogrammiert | Keine Kryptografie-Richtlinie oder eine veraltete | Algorithmuswechsel sind Einzelprojekte, die Jahre dauern |
| 2 | Bewusst | Einmaliger Discovery-Scan; bekannte Lücken | Einige Zertifikate automatisiert; der meiste Code noch fest einprogrammiert | Schriftliche Richtlinie mit zugelassenen Algorithmen | Änderungen werden je System geplant; Verantwortliche oft unbekannt |
| 3 | Definiert | Kontinuierliche Discovery; CBOM für kritische Systeme | Neue Anwendungen nutzen einen Krypto-Service oder ein KMS; ACME/EST für Zertifikate | Richtlinie mit Ausserbetriebnahme-Auslösern, Rotations-SLAs und Ausnahmeprozess | Migrations-Roadmap mit Daten; KPI-Ausgangsbasis erhoben |
| 4 | Gesteuert | CBOM für die gesamte IT-Landschaft, mit Verantwortlichen und Datenklassen | Die meisten Dienste hinter einer Abstraktion; PQC und Hybrid in der Produktion verfügbar | Richtlinie durch Werkzeuge durchgesetzt; regulatorisches Mapping; regelmässige Überprüfungen | Richtlinienänderungen werden simuliert und gestaffelt ausgerollt; Zeit bis zum Ersatz wird gemessen |
| 5 | Agil | Echtzeit-Inventar mit Drift-Warnungen | Algorithmen werden zur Laufzeit aus der Richtlinie abgeleitet; Backend-unabhängig | Policy as Code, versioniert und auditiert | Ein Algorithmuswechsel ist eine geprüfte Richtlinienänderung ohne Codeänderung; die Behebung ist automatisiert mit menschlicher Freigabe |
Der Schritt von Stufe 2 zu 3 betrifft vor allem Prozesse und Inventar. Der Schritt von 3 zu 5 betrifft vor allem die Architektur: Algorithmen aus dem Anwendungscode herauszulösen.
Der Ansatz von DuoKey bildet die oben beschriebenen Bausteine ab. Die folgenden Angaben stammen aus der Produktdokumentation von DuoKey.
DuoKeys Cryptographic Posture Management durchläuft einen kontinuierlichen Kreislauf: entdecken → bewerten → simulieren → beheben. Die Discovery umfasst Zertifikats- und Schlüsseldateien, Keystores (einschliesslich des Windows-Zertifikatspeichers und TPM), KMS-Inventare von AWS, Azure und Google Cloud, TLS-Domains und von Cockpit verwaltete Vaults. Befunde erhalten eine Risikobewertung von P1 bis P4, jeder Scan einen Quantum Readiness Score (0-100), und das Ergebnis ist eine lebende CBOM mit Drift-Warnungen. Simulationsberichte zeigen die Auswirkung einer Änderung, bevor sie vorgenommen wird; Pull Requests zur Behebung werden von einem Agenten entworfen und von einem Menschen freigegeben, mit ServiceNow-Synchronisierung und Mapping auf DORA, NIS2, FINMA 05/2026, NIST IR 8547 und CNSA 2.0. Der kostenlose Quantum Readiness Score ist ein Einstiegspunkt, der keinen Zugriff auf interne Systeme benötigt.
Die Crypto Agility Plane (CAP) ist die Abstraktionsschicht von DuoKey. Entwickler deklarieren, was sie schützen und warum, zum Beispiel eine PII-Datenklasse mit dem Zweck Signieren, nicht welchen Algorithmus sie verwenden. Eine zentrale Mandantenrichtlinie leitet zur Laufzeit den Algorithmus, die Post-Quanten-Ausrichtung, die Schlüsselreferenz und das Backend ab:
| Entwickler deklariert | Ausrichtung der Richtlinie | Abgeleiteter Algorithmus (Beispiel) |
|---|---|---|
| PII + Signieren | hybrid | hybrid-ml-dsa65-ecdsa-p256 |
| PII + Signieren | pqc_only | ml-dsa65 |
| PII + Signieren | classical | klassischer Algorithmus gemäss Richtlinie |
Die drei Ausrichtungen sind classical, hybrid und pqc_only, wobei hybride Post-Quanten-Kryptografie (ML-KEM, ML-DSA) standardmässig verfügbar ist. Der Wechsel zu reiner PQC ist eine Richtlinienänderung: Der Anwendungscode ändert sich nicht, und die Ausserbetriebnahme eines Verschlüsselungsverfahrens erfordert keine Neukompilierung. Das entspricht der Architekturspalte von Stufe 5 im Reifegradmodell, für die Dienste, die CAP nutzen.
CAP ist heute auf DuoKey Cockpit über eine REST-API und Referenz-Clients für Java/Spring Boot und .NET/EF Core verfügbar, dazu eine KI/MCP-Steuerungsebene. Paketierte SDKs und Annotationen wie @Protect stehen auf der Roadmap. CAP speichert kein Schlüsselmaterial.
DuoKey Cockpit ist eine Konsole und API über Software-, MPC-, HSM- und Cloud-KMS-Backends. Über PKCS#11 und KMIP arbeitet CAP mit Securosys-HSMs, Azure Key Vault, AWS KMS, Google Cloud KMS, HashiCorp Vault und OpenBao. Mit MPC werden Schlüssel aufgeteilt, sodass kein einzelner Host einen vollständigen Schlüssel besitzt. Cockpit führt ein kryptografisch verkettetes Audit-Log, mit RBAC, ABAC und Mandantentrennung.
DuoKeys Zertifikatsverwaltung stellt RSA-, EC-, ML-DSA- (FIPS 204), SLH-DSA- (FIPS 205) und hybride Composite-Zertifikate ML-DSA-65 + ECDSA-P256 aus Vault-signierten CAs über ACME, EST, SCEP und CMP aus. Die Dokumentation von DuoKey empfiehlt PQC dort, wo Sie beide Enden kontrollieren, und das hybride Composite dort, wo Sie mit klassischen vertrauenden Parteien interoperieren müssen, da noch nicht jeder Client ML-DSA oder SLH-DSA versteht.
Für KI-Agenten, die selbstständig Schlüssel anfordern und signieren, siehe agentische Krypto-Agilität.
Q: Was ist Krypto-Agilität?
Krypto-Agilität ist die Fähigkeit, kryptografische Algorithmen in Protokollen, Anwendungen, Software, Hardware, Firmware und Infrastruktur zu ersetzen und anzupassen und dabei Sicherheit und laufenden Betrieb zu wahren. Das ist die Definition des NIST in CSWP 39. In der Praxis beruht sie auf einem Inventar, einer Abstraktionsschicht, einer Richtlinie, Automatisierung und Tests.
Q: Was ist eine Krypto-Agilitäts-Richtlinie?
Es ist das Governance-Dokument, das festlegt, welche Algorithmen für welche Datenklassen und Zwecke zugelassen sind, wie die Post-Quanten- und Hybrid-Ausrichtung aussieht, was eine Ausserbetriebnahme auslöst, welche Rotations-SLAs gelten, wer für Schlüssel und Zertifikate verantwortlich ist und wie Ausnahmen genehmigt werden und ablaufen. In einer agilen IT-Landschaft wird dieselbe Richtlinie auch von Werkzeugen ausgeführt, nicht nur von Prüfern gelesen.
Q: Was ist eine Krypto-Agilitäts-Plattform?
Es sind die Werkzeuge, die kryptografische Assets entdecken, ihr Risiko bewerten, Algorithmen über eine Abstraktionsschicht aus einer zentralen Richtlinie ableiten, Zertifikats- und Schlüsseländerungen automatisieren, Änderungen vor dem Rollout simulieren und einen Audit-Trail führen. Deckt ein Produkt nur Discovery oder nur Schlüsselspeicherung ab, löst es einen Teil des Problems, nicht den ganzen Kreislauf.
Q: Wie misst man Krypto-Agilität?
Die zentrale Kennzahl ist die Zeit bis zum Ersatz eines Algorithmus in der gesamten IT-Landschaft, von der Entscheidung bis zur Entfernung der letzten produktiven Verwendung. Ergänzende KPIs sind der Anteil inventarisierter Assets, der Anteil von Schlüsseln und Zertifikaten mit verantwortlicher Person, der Anteil von Diensten hinter einer Abstraktionsschicht und die mittlere Zeit bis zur Rotation.
Q: Verlangt NIS2 Krypto-Agilität?
Nicht unter diesem Namen und nicht für jede Einrichtung. Die NIS2-Richtlinie verlangt Konzepte und Verfahren für den Einsatz von Kryptografie. Für die spezifischen Arten von Einrichtungen, die unter die Durchführungsverordnung (EU) 2024/2690 fallen, fügt der Anhang einen eigenen Abschnitt zur Kryptografie mit einer dokumentierten Richtlinie und regelmässiger Überprüfung hinzu, was in der Praxis die Fähigkeit voraussetzt, Algorithmen zu wechseln. Andere Einrichtungen sollten ihre nationale Umsetzung prüfen. Details enthält unser Artikel zu NIS2 und Krypto-Agilität.
Q: Wann müssen RSA und ECC ersetzt werden?
Der Entwurf des NIST-Übergangsplans (IR 8547, erster öffentlicher Entwurf, November 2024) schlägt vor, quantenanfällige Algorithmen mit 112 Bit Sicherheitsniveau wie RSA-2048 nach 2030 als veraltet einzustufen und alle quantenanfälligen Signatur- und Schlüsselaustauschalgorithmen nach 2035 nicht mehr zuzulassen. Branchenregulierer können frühere Meilensteine setzen; siehe unseren Leitfaden zur PQC-Migrations-Roadmap.
Q: Ist hybride Kryptografie Teil der Krypto-Agilität?
Ja. Eine hybride Ausrichtung kombiniert einen klassischen und einen Post-Quanten-Algorithmus, fügt Quantenresistenz hinzu und bleibt zugleich interoperabel mit Systemen, die PQC noch nicht unterstützen. Eine agile IT-Landschaft bewegt eine Datenklasse von klassisch über hybrid zu reiner PQC, indem sie deren Richtlinie ändert.
Krypto-Agilität ist eine messbare Fähigkeit: wie schnell Sie Kryptografie ändern können, ohne etwas zu beschädigen. Die Post-Quanten-Frist gibt ihr ein Datum, und Regulierer machen sie zur Prüfungsfrage. Beginnen Sie damit, Algorithmen aus dem Code in die Richtlinie zu verlagern.
Um zu sehen, wo Sie heute stehen, beginnen Sie mit dem kostenlosen Quantum Readiness Score oder sprechen Sie mit DuoKey über Cryptographic Posture Management.
Geschrieben von
DuoKey Team
Verwandte Ressourcen
Sagen Sie uns, wo Kontrolle heute schwierig ist. Wir helfen Ihnen, den nächsten praktischen Schritt zu finden.
