Vorbereitung auf die Post-Quanten-Ära für Anbieter von „ Software “-Lösungen: Der Zeitplan steht nun fest
Jahrelang war das Quantenrisiko nur Zukunftsmusik. Die Botschaft an die Sicherheitsteams lautete: „Eines Tages wird die Quantentechnologie kommen“, doch dieser „ein Tag“ tauchte nie im Kalender auf. Das hat sich geändert. Die Vorbereitung auf die Post-Quanten-Ära ist nicht länger nur eine Folie in einer Strategiepräsentation über eine ferne Bedrohung. Es handelt sich um eine Reihe von terminierten Verpflichtungen, und für die „ software “ sowie die IT-Anbieter rücken diese Termine nun aus zwei Richtungen gleichzeitig näher.
Drei Meilensteine verdeutlichen dies. Am 21. September 2026 läuft das FIPS-140-2-Validierungsverfahren aus. Ab dem 1. Januar 2027 erwartet die National Security Agency, dass neue Anschaffungen im Rahmen des National Security System (NSS) standardmäßig CNSA-2.0-konform sind. Schließlich am 22. Juni 2026 legte die Executive Order 14412 den 31. Dezember 2030 für die postquantum-sichere Schlüsselerstellung und den 31. Dezember 2031 für postquantum-sichere Signaturen in hochwertigen und hochkritischen Systemen der Bundesregierung fest und wies eine FAR-Vorschrift an, wonach betroffene Auftragnehmer bis zum 31. Dezember 2030 FIPS-Standards mit PQC-Integration einhalten müssen. Wenn Sie „ software “ entwickeln, signieren oder ausliefern, spielen diese beiden Termine in Ihrer Roadmap eine Rolle. Die Frage ist nicht mehr, ob Sie handeln sollen, sondern ob Sie damit beginnen, bevor die Fristen das Tempo vorgeben.
Die beiden Zeitpläne, an die sich mittlerweile jeder Anbieter von „ software “ hält
Die Umstellung auf Post-Quantum-Verschlüsselung wird oft als ein einziger Übergang beschrieben. In der Praxis werden Anbieter von „ software “-Lösungen jedoch auf zwei verschiedene Wege gelenkt, die sich durch unterschiedliche Träger, unterschiedliche Algorithmen und unterschiedliche Fristen auszeichnen. Der eine Weg ist zivil und breit angelegt. Der andere dient der nationalen Sicherheit und ist aggressiv ausgerichtet. Beide Wege zu verstehen, ist der erste Schritt hin zu einem tragfähigen Plan.
Der zivile Bereich: NIST IR 8547 und die endgültigen Normen
Der zivile Weg verläuft über das NIST. Im August 2024 hat das NIST seine ersten Post-Quanten-Standards fertiggestellt: FIPS 203 (ML-KEM) für die Schlüsselaufbau, FIPS 204 (ML-DSA) für Allzweck-Signaturen und FIPS 205 (SLH-DSA) für Hash-basierte Signaturen. Dabei handelt es sich um einsatzbereite Algorithmen und nicht um Forschungsvorschläge.
Die Termine stammen aus einem Begleitdokument. NIST IR 8547, „Transition to Post-Quantum Cryptography Standards“ (Übergang zu postquantenkryptografischen Standards), legt den Zeitplan für die Ausmusterung der heutigen Algorithmen für öffentliche Schlüssel fest. Gemäß diesem Plan werden RSA, ECDSA, EdDSA sowie Diffie-Hellman mit endlichem Körper und elliptischer Kurve auf der 112-Bit-Sicherheitsstufe nach 2030 als veraltet eingestuft und ab 2035 nicht mehr zugelassen. Dieser Zeitplan gilt allgemein für alle Systeme der US-Bundesbehörden und die Anbieter, die diese betreuen. Die EO 14412 und das OMB-Memorandum M-26-15 enthalten nun die maßgeblichen Termine für den zivilen Bereich. M-26-15 legt einen fünfphasigen Migrationsplan für den Zeitraum von 2026 bis 2035 fest und verlangt von den Behörden die Erstellung von Migrationsplänen.
Der Bereich Nationale Sicherheit: CNSA 2.0
Der Weg zur nationalen Sicherheit ist steiler. Die „Commercial National Security Algorithm Suite 2.0“ (CNSA 2.0) der NSA, die im Dezember 2024 in Version 2.1 veröffentlicht wurde, legt für NSS kategoriebezogene Fristen fest. Das für Lieferanten wichtigste Datum ist der 1. Januar 2027, ab dem neue NSS-Anschaffungen standardmäßig CNSA 2.0-konform sein müssen. CNSSP 15 legt die Beschaffungsanforderung zum 1. Januar 2027 fest. Geräte und Dienstleistungen, die CNSA 2.0 nicht unterstützen, müssen bis zum 31. Dezember 2030 ausgemustert werden, und die Verwendung von CNSA 2.0-Algorithmen ist bis zum 31. Dezember 2031 vorgeschrieben.
CNSA 2.0 ist zudem in Bezug auf die zugelassenen Anwendungen enger gefasst. Es erlaubt ML-KEM und ML-DSA, während SLH-DSA für keinerlei Verwendung in nationalen Sicherheitssystemen zugelassen ist. CNSSP 15 wurde aktualisiert, um CNSA 2.0 zu integrieren; NIAP validiert Produkte anhand veröffentlichter Schutzprofile, und CSfC-Lösungen werden anhand der NSA-Fähigkeitspakete registriert. Wenn Sie an Bundesbehörden oder die Verteidigungsindustrie verkaufen, legt dieser Weg Ihre kurzfristigen Anforderungen fest.
Die konkreteste Aufgabe in naher Zukunft: Ihre Pipeline für Vertragsabschlüsse
Für Anbieter von „ software “-Lösungen stellt die Signaturpflicht die konkreteste kurzfristige Verpflichtung dar. Firmware- und „ software “-Signaturen haben eine lange Lebensdauer, lassen sich im Einsatz nur schwer neu ausstellen und sind genau das, was ein Angreifer fälschen möchte. Damit sind sie der erste praktische Bereich, in dem die Vorbereitung auf die Post-Quanten-Ära konkrete Gestalt annimmt.
Das Signieren erfordert zudem die Unterstützung neuer Algorithmen und nicht lediglich größere Schlüssel. CNSA 2.0 legt zustandsbehaftete, hashbasierte Verfahren – LMS oder XMSS gemäß der Definition in NIST SP 800-208 – für die Signierung von „ software “ und Firmware fest. Diese unterscheiden sich vom universell einsetzbaren ML-DSA und bringen eigene Anforderungen an die Zustandsverwaltung mit sich. Eine Signatur-Pipeline, die ausschließlich auf größeren RSA- oder ECDSA-Schlüsseln basiert, erfüllt diese Anforderung nicht. Sie benötigt die richtigen quantensicheren Algorithmen, die korrekt implementiert sind.
Der CMVP-Engpass: zwei Schalter, eine Warteschlange
Hinter dem algorithmischen Problem verbirgt sich ein logistisches Problem. Die Post-Quanten-Validierung kommt nicht auf einer leeren Startbahn an. Sie kollidiert mit dem regulären Übergang von FIPS 140-2 zu FIPS 140-3, sodass eine einzige überfüllte Validierungswarteschlange nun zwei Hürden gleichzeitig nehmen muss.
Die Zeitplanung lässt keinen Spielraum. Die Validierungen nach FIPS 140-3 dauerten im Durchschnitt etwa 18 Monate, und die Warteliste ist seitdem gewachsen, sodass 18 bis 30 Monate ein realistischer Planungszeitraum sind. Seit August 2026 stehen PQC-Module auf der CMVP-Warteliste, wobei mehrere Anbieter Zertifikate ab Ende 2026 anstreben.
Die Auslaufphase von FIPS 140-2 erhöht den Druck. Am 21. September 2026 werden die verbleibenden aktiven FIPS-140-2-Zertifikate in die historische Liste des CMVP übernommen. Bestehende Installationen dürfen weiterhin betrieben werden, doch Bundesbehörden sollten bei neuen Beschaffungen keine historischen Module mehr berücksichtigen. Oftmals muss ein einziger Antrag beide Hürden nehmen, weshalb es wichtiger ist, sich frühzeitig in die Warteschlange einzureihen, als es auf den ersten Blick erscheint.
Jetzt ernten, später entschlüsseln: Warum das Warten bereits eine Entscheidung ist
Das stärkste Argument dafür, jetzt zu handeln, hat nichts mit dem Zeitpunkt der Markteinführung eines funktionsfähigen Quantencomputers zu tun. Es handelt sich um das Problem „Jetzt erfassen – später entschlüsseln“. Ein Angreifer kann verschlüsselten Datenverkehr bereits heute abfangen und speichern, um ihn dann zu entschlüsseln, sobald ein für die Kryptografie relevanter Quantencomputer verfügbar ist.
Dadurch wird die Frist unter dem Gesichtspunkt der Datensensibilität neu definiert, nicht unter dem von „ hardware “. Wenn Ihr Produkt Informationen schützt, die länger als 10 bis 15 Jahre vertraulich bleiben müssen, können diese Daten bereits als offengelegt betrachtet werden. Abwarten ist keine neutrale Haltung. Es ist eine Entscheidung, diese Offenlegung zu akzeptieren, und Ihre Kunden werden Sie zunehmend auffordern, diese Entscheidung zu begründen.
Was eine kontrollierte Migration tatsächlich erfordert
Eine kontrollierte Migration hängt letztlich von vier Fähigkeiten ab, die ein Anbieter von „ software “-Lösungen bereitstellen muss. Die Beantwortung jeder dieser Fragen zur Bereitschaft erfordert eine operative Steuerung und ist kein einmaliges Projekt. Hier erfahren Sie, was die einzelnen Punkte erfordern.
Erstellen Sie eine vollständige Übersicht über die kryptografischen Ressourcen
Was man nicht sieht, kann man auch nicht migrieren. Eine vollständige Bestandsaufnahme erfasst jedes Zertifikat, jeden Schlüssel, jeden Algorithmus und jede Bibliothek in Ihren Produkten, Build-Pipelines und Cloud-Umgebungen. Entscheidend ist, dass dabei auch vererbte open-source -Abhängigkeiten berücksichtigt werden, denn auch Kryptografie, die Sie nicht selbst geschrieben haben, ist dennoch Kryptografie, die Sie ausliefern.
Klassifizieren Sie quantenanfällige Vermögenswerte nach Sensibilität und Lebensdauer
Nicht alle Ressourcen sind gleichermaßen dringend. Sobald quantenanfällige Ressourcen identifiziert wurden, sollten sie anhand des NIST IR 8547-Auslaufplans sowie anhand der erforderlichen Lebensdauer ihrer Daten oder ihres Vertrauens eingestuft werden. Diese Einstufung verwandelt eine einfache Liste in eine nach Prioritäten geordnete Migrationsreihenfolge.
Zertifikate und Schlüssel auf Flottenebene agil gestalten
Eine Migration ist kein einmaliger Umstellungsvorgang. Sie benötigen die Möglichkeit, Zertifikate in großem Maßstab zu rotieren, neu auszustellen und neu zu verschlüsseln, sowie die Fähigkeit, PQC-fähige und hybride Zertifikate für einen schrittweisen Übergang auszustellen. Kryptografische Flexibilität ermöglicht es Ihnen, Umstellungen vorzunehmen, ohne den Betrieb zu unterbrechen, und diese bei Weiterentwicklung der Standards erneut anzupassen.
Bewertung der Lage der Lieferanten und der Abhängigkeiten
Ihr Risiko beschränkt sich nicht nur auf Ihren eigenen Code. Die Bewertung der PQC-Sicherheit von Lieferanten und Abhängigkeiten ist wichtig, da die von ihnen verwendete Kryptografie in dem Moment zu Ihrem Risiko wird, in dem Sie sie einbinden. Ein Anbieter, der seine Lieferkette vernachlässigt, übernimmt jede Schwachstelle darin.
Wie Keyfactor helfen Keyfactor
Diese vier Fähigkeiten lassen sich direkt auf die „ Keyfactor “-Plattform abbilden, sodass die oben genannten Fragen zur Einsatzbereitschaft zu operativen Kontrollmechanismen werden und keine offenen Risiken mehr darstellen.
- Kryptografische Bestandsaufnahme und Schwachstellenanalyse. Keyfactor AgileSec ermittelt kryptografische Ressourcen in Produkten, Build-Pipelines und der Cloud-Infrastruktur und unterstützt anschließend die Bewertung von Quanten-Schwachstellen, damit Sie Prioritäten setzen können.
- Ausstellung von PQC-fähigen und hybriden Zertifikaten. EJBCA Stellt Zertifikate unter Verwendung von NIST-standardisierten PQC-Algorithmen aus, einschließlich Hybridzertifikaten, die eine schrittweise Migration unterstützen.
- Krypto-Agilität auf Flottenebene. Keyfactor Command Automatisiert die Verwaltung des Lebenszyklus von Zertifikaten und Schlüsseln, sodass Rotation und Schlüsselneugenerierung skalierbar sind, ohne dass manuelle Arbeiten pro Endpunkt erforderlich sind.
- Quantum-sichere Signatur. Keyfactor SignServer sowie Keyfactor Signum Unterstützung für die Signierung v software en und Firmware, einschließlich der von CNSA 2.0 geforderten LMS- und XMSS-Verfahren.
Zusammen bilden diese Produkte die „Trust Control Plane“ v Keyfactor: ein zentrales System, das kryptografische Ressourcen überwacht, analysiert, bereitstellt, koordiniert und verwaltet. Anstatt Zertifikate in voneinander getrennten Tools nachverfolgen zu müssen, verwalten Sicherheitsteams die Vertrauenswürdigkeit als einen einzigen, durchgängigen Prozess. Genau das ist erforderlich, um die FIPS 140-3-Validierung von PQC-Algorithmen und alle anderen Vorgänge auf diesen Zeitachsen zu verfolgen.
Die Vorbereitung auf die Post-Quanten-Ära ist ein Programm, kein Projekt
Die beiden Fristen stehen fest, doch die damit verbundene Arbeit endet nicht, sobald ein Datum verstrichen ist. Standards werden sich weiterentwickeln, Algorithmen werden hinzukommen und wieder außer Gebrauch kommen, und Ihr kryptografischer Fußabdruck wird sich ständig verändern. Die Post-Quanten-Bereitschaft ist eine Betriebsfähigkeit, die Sie kontinuierlich aufrechterhalten müssen, und kein Meilenstein, den Sie einfach abhaken können.
Praktisch gesehen sollten Sie jetzt mit den beiden Aufgaben beginnen, die am meisten Zeit in Anspruch nehmen. Erstellen Sie eine Bestandsaufnahme Ihrer kryptografischen Komponenten, damit Sie wissen, was Sie migrieren müssen, und stellen Sie Ihre Module frühzeitig in die Validierungswarteschlange, damit der CMVP-Engpass nicht Ihren Auslieferungstermin bestimmt. Die Anbieter, die vor Ablauf der Fristen handeln, werden diese als Routineangelegenheit betrachten. Diejenigen, die abwarten, werden sie als Notfälle erleben.
Sind Sie bereit herauszufinden, wo Sie stehen? Fordern Sie eine Demo an, um Ihren kryptografischen Bestand zu erfassen und Ihren Weg zur Quantensicherheit zu planen.
Haben Sie Fragen zur Post-Quanten-Bereitschaft? Wir haben die Antworten.
What is post-quantum readiness for a software vendor?
It is the ongoing ability to discover, classify, and migrate cryptography to quantum-safe standards. For vendors, it centers on signing pipelines, certificate issuance, and validated modules. It is an operating capability, not a one-time upgrade.
When are the key post-quantum deadlines?
Two dates matter most. FIPS 140-2 validations move to the CMVP Historical list on September 21, 2026, and new NSS acquisitions are expected to be CNSA 2.0-compliant by default from January 1, 2027. NIST IR 8547, still an initial public draft, proposes deprecation after 2030 and disallowance after 2035. EO 14412 sets December 31, 2030 for key establishment and December 31, 2031 for digital signatures on federal high-value and high-impact systems.
Which post-quantum algorithms did NIST finalize?
NIST finalized three standards in August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for signatures, and FIPS 205 (SLH-DSA) for hash-based signatures. Of those three, CNSA 2.0 includes ML-KEM and ML-DSA. It also approves LMS and XMSS from SP 800-208 for firmware and software signing, and does not approve SLH-DSA for any use in NSS.
Why is software signing the first priority?
Signatures have long lifetimes and are hard to re-issue once deployed. CNSA 2.0 approves ML-DSA-87 as well as LMS and XMSS for firmware and software signing. Larger RSA or ECDSA keys satisfy none of these. That makes signing the most concrete near-term obligation.
What is the CMVP bottleneck?
Post-quantum validation overlaps with the ordinary FIPS 140-3 transition, creating one crowded queue. Validations have averaged roughly 18 months, so 18 to 30 months is a realistic planning range. Submitting early is the main way to protect your timeline.
What does harvest-now-decrypt-later mean for my product?
Attackers can capture encrypted data today and decrypt it once quantum computers mature. If your product protects data that must stay confidential beyond 10 to 15 years, that data is already exposed. Waiting to migrate is effectively accepting that risk.
How do I start a post-quantum migration?
Begin with a complete cryptographic inventory across products, pipelines, and dependencies. Classify assets by sensitivity and lifespan against the NIST IR 8547 schedule, then build agility to rotate and reissue at scale. Assess your suppliers, since inherited cryptography becomes your exposure.
How does Keyfactor support post-quantum readiness?
Keyfactor AgileSec handles discovery and quantum-vulnerability assessment, EJBCA issues PQC and hybrid certificates, and Keyfactor Command automates lifecycle at scale. SignServer and Signum support quantum-safe signing, all unified in the Trust Control Plane.
Die Quelle abonnieren
Stay secure with Keyfactor's monthly newsletter, packed with expert insights and practical steps for quantum-readiness.