Post-Quantum-Kryptographie ist kein “spaeter”-Thema mehr fuer Architekturteams. NIST hat im August 2024 seine ersten drei Haupt-PQC-Standards finalisiert — FIPS 203 fuer ML-KEM (Schluesselkapselung), FIPS 204 fuer ML-DSA (digitale Signaturen) und FIPS 205 fuer SLH-DSA (zustandslose hashbasierte Signaturen) — und hat Organisationen gesagt, jetzt mit der Migration zu beginnen. NISTs Uebergangszeitplan deutet darauf hin, quantenanfaellige Public-Key-Algorithmen bis 2030 fuer die meisten foederalen Anwendungen abzulehnen und sie bis 2035 vollstaendig aus NIST-Standards zu entfernen, wobei Hochrisikosysteme voraussichtlich frueher umsteigen sollen.

Das macht PQC zu einem Migrationsproblem, nicht nur einem Forschungsthema. Das aktive NCCoE-Projekt “Migration to Post-Quantum Cryptography” konzentriert sich darauf, Praktiken zu demonstrieren, die Organisationen helfen zu entdecken, wo quantenanfaellige Algorithmen verwendet werden, Risiken zu priorisieren und die Interoperabilitaet mit standardisierten PQC-Ansaetzen zu testen. Der operationelle Punkt taucht in jedem NIST-Migrationsdokument auf: Die erste Phase dreht sich um Inventar, Priorisierung und Pilot-Bereitschaft, nicht um sofortigen Ersatz ueberall.

Dieses Tutorial gibt Ihnen ein realistisches First-Phase-Migrationsprogramm. Am Ende haben Sie ein funktionierendes Krypto-Inventarformat, ein risikobasiertes Priorisierungsmodell, eine Crypto-Agility-Review-Checkliste, eine Pilot-Definition, einen Anbieter-Fragebogen und eine phasenweise Roadmap, die Sie in die Enterprise-Architektur- oder Sicherheitsplanung einbringen koennen. Wenn Sie den strategischen Kontext vor der praktischen Arbeit wollen, lesen Sie den Begleitartikel zum Aufbau einer Post-Quantum-Kryptographie-Migrations-Roadmap.

Schritt 1: Inventarisieren, wo Kryptographie lebt

Ihre erste Aufgabe ist nicht die Algorithmuswahl. Es ist herauszufinden, wo Public-Key-Kryptographie tatsaechlich in Ihrer Umgebung existiert. Das NCCoE-Migrationsprojekt hat kryptographische Erkennung zu einem seiner beiden Kern-Arbeitsstraenge gemacht, weil die meisten Organisationen keinen vollstaendigen Ueberblick haben, wo quantenanfaellige Algorithmen in Hardware, Software, Diensten und Protokollen eingebettet sind.

Mit den offensichtlichen Protokoll- und PKI-Oberflaechen beginnen

Inventarisieren Sie mindestens diese Kategorien:

TLS-Terminierung und Mutual TLS
Interne und externe Zertifikate
VPNs und Fernzugriff
Code-Signierung und Artefakt-Signierung
E-Mail-Sicherheit und Dokumenten-Signierung
Identity-Provider und Foederation
SSH, S/MIME und andere Vertrauensinfrastruktur
HSM-gestuetzte und PKI-gestuetzte Workflows

Erstellen Sie eine Inventardatei statt dies ueber separate Notizen zu verteilen.

File: pqc-crypto-inventory.csv

system,owner,environment,category,public_key_usage,current_algorithms,certificate_or_key_source,external_facing,confidentiality_lifetime,notes
public-web-gateway,network-team,production,tls,key-establishment-and-server-auth,RSA-ECDHE,corp-pki,yes,medium,front-door internet traffic
idp-platform,identity-team,production,identity,tls-signing-and-federation,ECDSA-RSA,corp-pki,yes,high,sso and federation dependencies
site-to-site-vpn,infra-team,production,vpn,key-exchange-and-auth,ECDSA-ECDH,vendor-managed,yes,high,long-lived tunnel data
artifact-signing,platform-team,production,code-signing,digital-signatures,RSA,ci-key-store,no,high,software trust chain
internal-service-mesh,platform-team,production,mtls,key-establishment-and-auth,ECDSA,mesh-ca,no,medium,service-to-service identity

Code, Bibliotheken und eingebettete Nutzung einschliessen

Inventar ist nicht nur ein Zertifikatsbericht. Sie muessen auch Kryptographie finden in:

Anwendungsbibliotheken
SDKs und Sprach-Runtimes
Mobile Apps und eingebetteter Firmware
Load Balancern und API-Gateways
HSM-Integrationen
Smartcards, Token oder Secure Elements
Anbieter-Appliances und verwalteten SaaS-Produkten

Eine einfache Quellcode-Suche kann Ihnen beim ersten Durchgang helfen:

grep -rI \
  "RSA\|ECDSA\|ECDH\|X25519\|secp256r1\|Ed25519\|PKCS#11\|OpenSSL\|BoringSSL\|wolfSSL" \
  ./services ./infra ./scripts

Anbieterprodukte und Blackboxes nicht vergessen

Das NCCoE-Migrationsmaterial schliesst explizit Hardware, Software und Dienste ein, nicht nur Code, den Sie selbst geschrieben haben.

Erstellen Sie ein separates Produkt-Arbeitsblatt:

File: vendor-product-crypto-tracker.yaml

products:
  - name: edge-load-balancer
    owner: network-team
    pqc_visibility: low
    crypto_usage:
      - tls-termination
      - certificate-management
    vendor_contact: account-team
    roadmap_status: unknown

  - name: remote-access-vpn
    owner: infra-team
    pqc_visibility: low
    crypto_usage:
      - tunnel-key-exchange
      - device-authentication
    vendor_contact: support-escalation
    roadmap_status: unknown

Tipp

Ein kryptographisches Inventar ist nur nuetzlich, wenn es Kontext erfasst. “Verwendet TLS” reicht nicht. Sie muessen wissen, wo, warum und wie schwer es zu aendern sein wird.

Sie sollten nun ein First-Pass-Inventar haben, das Protokolle, PKI, Code, Hardware und Anbieterprodukte abdeckt, in denen Public-Key-Kryptographie vorkommt.

Schritt 2: Nach Risiko priorisieren

NISTs Guidance ist klar, dass nicht jedes System zum selben Zeitpunkt umsteigen sollte. Die Priorisierung basiert auf Risiko, besonders fuer Systeme, die langlebige sensible Daten schuetzen und breit deployte Vertrauensinfrastruktur.

Langlebige sensible Daten zuerst priorisieren

Die dringendsten PQC-Migrationskandidaten sind oft die Systeme, die Informationen schuetzen, die viele Jahre lang vertraulich bleiben muessen. NCCoEs Migrationsdokumente heben explizit das “Harvest now, decrypt later”-Risiko als Hauptgrund hervor, jetzt zu beginnen.

Breite Vertrauensinfrastruktur priorisieren

NISTs PQC-Uebergangszeitplan von 2025 hebt langlebige und breit deployte Infrastruktur wie PKI, Code-Signierung, TLS und VPN als fruehe Prioritaeten hervor.

Schwer zu aktualisierende Systeme priorisieren

Einige Systeme sind riskant, weil sie bruechig sind, nicht weil sie am staerksten exponiert sind. Beispiele umfassen:

Hardware-Appliances
Eingebettete Produkte
Industrielle oder operationelle Systeme
Remote-Standorte mit langen Ersatzzyklen
Partner-Integrationen, die protokollsensitiv sind

Ein Risikobewertungs-Arbeitsblatt erstellen

File: pqc-prioritization.yaml

systems:
  - name: public-web-gateway
    data_lifetime: medium
    external_exposure: high
    upgrade_difficulty: medium
    trust_infrastructure: high
    pqc_priority: high

  - name: artifact-signing
    data_lifetime: high
    external_exposure: medium
    upgrade_difficulty: medium
    trust_infrastructure: critical
    pqc_priority: critical

  - name: site-to-site-vpn
    data_lifetime: high
    external_exposure: high
    upgrade_difficulty: high
    trust_infrastructure: high
    pqc_priority: critical

  - name: internal-service-mesh
    data_lifetime: medium
    external_exposure: low
    upgrade_difficulty: medium
    trust_infrastructure: medium
    pqc_priority: medium

Warnung

Priorisieren Sie nicht nur nach Internet-Exposition. Ein schwer zu ersetzendes internes Vertrauenssystem, das langlebige sensible Daten schuetzt, kann wichtiger sein als ein einfacherer oeffentlicher Web-Rand.

Sie sollten nun eine nach Rangfolge sortierte Systemliste haben, die Ihnen sagt, wo Sie sich zuerst konzentrieren sollen, statt zu versuchen, alles auf einmal zu migrieren.

Schritt 3: Crypto-Agility bewerten

NISTs Guidance rahmt die PQC-Transition als groesser als fruehere kryptographische Transitionen ein, weil alle Public-Key-Algorithmen ersetzt werden muessen, nicht nur eine Familie. Crypto-Agility ist definiert als die Faehigkeit, Algorithmen ueber Protokolle, Anwendungen, Software, Hardware, Firmware und Infrastruktur hinweg zu ersetzen, waehrend der Betrieb aufrechterhalten wird.

Fragen, ob das System Algorithmen ohne Redesign tauschen kann

Beantworten Sie fuer jedes System:

Ist der kryptographische Algorithmus hartkodiert?
Wird er ueber Konfiguration oder Policy gewaehlt?
Koennen Zertifikatsketten und Trust-Stores sauber geaendert werden?
Koennen Schluessel, Signaturen und Zertifikatsgroessen wachsen, ohne Integrationen zu brechen?
Erlaubt das Protokoll mehrere oder hybride Algorithmen?

Fragen, ob Hybrid-Modus moeglich ist

Fuer viele fruehe Piloten ist die praktische Frage nicht “kann dieses System jetzt PQC-only sein?” Es ist “kann dieses System in einer hybriden oder Dual-Stack-Haltung interoperieren, waehrend das Oekosystem aufholt?”

Fragen, was bricht, wenn sich Kryptographie aendert

Verwenden Sie eine Crypto-Agility-Checkliste:

File: crypto-agility-checklist.md

# Crypto Agility Checklist

- [ ] Are algorithm identifiers configurable?
- [ ] Are key sizes and signature sizes assumed in code?
- [ ] Are certificates parsed with rigid size or field expectations?
- [ ] Can trust stores hold both current and PQC-related artifacts during transition?
- [ ] Can APIs, protocols, or appliances tolerate hybrid negotiation?
- [ ] Can HSMs, smart cards, or firmware be updated?
- [ ] Are there performance or packet-size assumptions tied to current crypto?

Anbieter-Roadmap-Sicherheit verfolgen

File: vendor-agility-matrix.csv

product,owner,pqc_roadmap_known,hybrid_support,field_upgradeable,blocking_risk,notes
edge-load-balancer,network-team,no,unknown,yes,high,needs vendor escalation
remote-access-vpn,infra-team,partial,unknown,partial,high,awaiting protocol guidance
artifact-signing-service,platform-team,yes,no,yes,medium,can pilot sooner

Info

“Unterstuetzt PQC” ist nicht dasselbe wie “ist crypto-agil.” Die bessere Frage ist, ob das System sich ohne Plattform-Rewrite oder Produktionsausfall weiterentwickeln kann.

Sie sollten nun wissen, welche Systeme konfigurierbar sind, welche hybride Migrationsmuster unterstuetzen koennen und welche wahrscheinlich Blockierer werden.

Schritt 4: Einen Pilot-Umfang aufbauen

Der beste erste PQC-Pilot ist eng, bedeutsam und messbar.

Ein handhabbares System waehlen

Waehlen Sie etwas, das:

wichtig genug ist, um relevant zu sein
kontrolliert genug ist, um sicher zu testen
eng genug ist, um abzuschliessen
repraesentativ genug ist, um etwas zu lehren

Gute erste Piloten umfassen oft:

einen internen TLS-geschuetzten Dienst
einen begrenzten Code-Signing-Workflow
eine Lab-VPN-Verbindung
einen kleinen PKI-abhaengigen Anwendungspfad

Interoperabilitaetsanforderungen definieren

Ihr Pilot sollte konkrete Fragen beantworten wie:

Verhandelt der Endpunkt erfolgreich mit der gewaehlten Implementierung?
Funktionieren Client-Bibliotheken weiterhin?
Erzeugen Zertifikate, Signaturen oder Schluesselmaterial Tooling-Probleme?
Was ist die Performance-Auswirkung?
Welche Monitoring-Aenderungen sind noetig?

Rollback-Kriterien definieren

Fuehren Sie keinen Piloten ohne Ausstiegsregeln durch.

File: pqc-pilot-plan.yaml

pilot_name: internal-artifact-signing-lab
scope:
  system: artifact-signing-service
  environment: staging
  protocols:
    - signing
    - verification
goals:
  - validate interoperability with selected pqc-capable components
  - measure signing and verification performance
  - identify tooling or certificate-chain breakage
rollback_criteria:
  - verification failures exceed 1 percent
  - downstream tooling cannot validate artifacts
  - operational latency exceeds agreed threshold
success_metrics:
  - 100 percent successful signing in pilot path
  - 100 percent successful verification in pilot path
  - no undocumented integration failures

Tipp

Ein erster PQC-Pilot sollte Ihnen etwas ueber Kompatibilitaet, Betrieb und Eigentum beibringen. Er sollte nicht zu einem Stealth-Infrastruktur-Transformationsprojekt werden.

Sie sollten nun eine Pilot-Definition mit Scope, Interoperabilitaetszielen, Rollback-Regeln und messbaren Erfolgskriterien haben.

Schritt 5: Anbieter und interne Eigentuemer einbeziehen

PQC-Migration ist kein reines Sicherheitsprogramm. NISTs Migrationsdokumente richten sich explizit an Bundesbehoerden, Technologieanbieter, Standardisierungsorganisationen und Labore, weil die Transition von koordiniertem Produkt- und Protokollwechsel abhaengt, nicht nur von lokaler Konfiguration.

Anbietern direkte Migrationsfragen stellen

Senden Sie einen strukturierten Fragebogen statt vager “Was ist Ihr PQC-Plan?”-E-Mails.

File: vendor-pqc-questionnaire.md

# Vendor PQC Questionnaire

1. Which NIST-standardized PQC algorithms do you support or plan to support first?
2. What is your expected timeline for production support?
3. Do you support hybrid deployment modes?
4. Which protocols or product features will gain PQC support first?
5. What interoperability testing have you completed?
6. What hardware, firmware, or software versions are required?
7. What logging and monitoring changes should we expect?
8. What are the rollback or downgrade considerations?
9. Are there licensing, hardware refresh, or contract impacts?
10. What is the documented roadmap and who owns it on your side?

Interne Eigentuemerschaft klaeren

Weisen Sie mindestens Eigentuemer zu fuer:

PKI und Zertifikats-Lebenszyklus
Netzwerk- und TLS-Endpunkte
Fernzugriff und VPN
Anwendungsbibliotheken und Runtime-Upgrades
HSM- oder Hardware-gestuetztes Vertrauen
Beschaffung und Anbieterverwaltung
Enterprise-Architecture-Governance

Beschaffung frueh einbeziehen

Wenn ein strategisches Produkt keine glaubwuerdige PQC-Roadmap hat, ist das ein Beschaffungsproblem ebenso wie ein Engineering-Problem. Setzen Sie Roadmap-Zusagen in Verlaengerungen und Neueinkaufe, wo angemessen.

Warnung

Eine PQC-Migration stagniert schnell, wenn jedes Team annimmt, jemand anderes besitze das Protokoll-, Zertifikats-, Hardware- oder Anbietergespraech.

Sie sollten nun benannte interne Eigentuemer und eine strukturierte Moeglichkeit haben, Anbieter unter Druck zu setzen fuer echte Migrationsinformationen.

Schritt 6: Eine phasenweise Roadmap erstellen

NISTs aktuelle Guidance unterstuetzt eine phasenweise Transition, keinen einzelnen Cutover.

Eine Vier-Phasen-Roadmap verwenden

File: pqc-roadmap.yaml

phase_1_discovery:
  target: now
  objectives:
    - complete cryptographic inventory
    - identify critical quantum-vulnerable systems
    - map owners and vendor dependencies

phase_2_pilot:
  target: within_6_months
  objectives:
    - complete one bounded interoperability pilot
    - document operational and compatibility findings
    - refine success and rollback criteria

phase_3_hybrid_transition:
  target: 6_to_18_months
  objectives:
    - deploy selected systems in dual-stack or hybrid-compatible patterns
    - update monitoring and operational runbooks
    - validate broader ecosystem interoperability

phase_4_broader_migration:
  target: 18_months_and_beyond
  objectives:
    - expand to prioritized production systems
    - retire or reduce dependence on quantum-vulnerable public-key algorithms
    - fold pqc planning into normal architecture and procurement cycles

Schritt 7: Dokumentieren und steuern

Ein Migrationsprogramm scheitert leise, wenn das Inventar veraltet, Ausnahmen sich aufhaeufen und niemand die Arbeit mit der Unternehmensplanung verbindet.

Das Krypto-Inventar am Leben halten

Machen Sie das Inventar zu einem verwalteten Artefakt, nicht zu einer einmaligen Tabelle.

File: crypto-governance-checklist.md

# Crypto Governance Checklist

- [ ] Inventory owner assigned
- [ ] Quarterly review scheduled
- [ ] New systems must declare public-key crypto usage
- [ ] Vendor roadmap status reviewed at renewal
- [ ] Exceptions tracked with expiry dates
- [ ] Pilot findings fed back into architecture standards

Ausnahmen bewusst verfolgen

File: pqc-exceptions.csv

system,owner,reason,blocking_dependency,review_date,expiry_date
legacy-vpn-appliance,infra-team,vendor-roadmap-missing,hardware-refresh,2026-06-01,2026-12-01
partner-b2b-gateway,bizops-team,partner-protocol-constraint,external-counterparty,2026-05-15,2026-11-15

Das Programm an Enterprise-Architecture anbinden

Machen Sie PQC zum Teil von:

Architecture Review
Zertifikats- und PKI-Planung
Anbieter-Review und Beschaffung
Sicherheits-Roadmap-Reviews
Lebenszyklus- und Refresh-Planung
Groesseren Protokoll- oder Vertrauensinfrastruktur-Aenderungen

Hinweis

PQC-Governance geht nicht darum, jedes Team zum Kryptographie-Experten zu machen. Es geht darum sicherzustellen, dass Krypto-Abhaengigkeiten sichtbar, zugeordnet und ueberprueft werden, bevor sie zu Notfallprojekten werden.

Sie sollten nun ein Governance-Muster haben, das das Inventar aktuell haelt, Ausnahmen verfolgt und PQC-Arbeit mit breiterer Unternehmensentscheidungsfindung verbindet.

Haeufige Einrichtungsprobleme

Inventar sieht vollstaendig aus, uebersieht aber eingebettete Kryptographie

Zertifikats- und PKI-Berichte decken nur Infrastruktur ab, die Sie zentral verwalten. Viele Anwendungen betten Krypto-Bibliotheken direkt ein. Fuehren Sie Quellcode-Suchen und Abhaengigkeitsscans ueber Anwendungs-Repos aus, nicht nur Infrastruktur-Docs.

Anbieter sagt “wir unterstuetzen PQC”, meint aber etwas anderes

“Unterstuetzt PQC” kann alles bedeuten von “wir haben einen Lab-Prototyp” bis “unser naechstes Release liefert ML-KEM in Produktion.” Fragen Sie immer nach spezifischen Algorithmusnamen, Protokollversionen, Release-Daten und Interoperabilitaetstestergebnissen.

Pilot-Umfang waechst in eine volle Migration

Ein Pilot, der neue Algorithmen, neue PKI, neue Hardware und neue Anbietervertraege gleichzeitig abzudecken versucht, ist kein Pilot. Er ist eine Migration. Beschraenken Sie Ihren ersten Piloten auf ein System, eine Umgebung und die wenigsten moeglichen Variablenaenderungen.

Teams streiten ueber Prioritaet, weil das Risikomodell subjektiv ist

Verankern Sie die Priorisierung an konkreten Faktoren: Daten-Vertraulichkeitslebensdauer, externe Exposition, Vertrauensinfrastruktur-Breite und Upgrade-Schwierigkeit. Subjektive “Wichtigkeits”-Rankings laden zu politischen Argumenten ein.

Governance-Artefakte werden einmal erstellt und nie aktualisiert

Ein Krypto-Inventar, das vor sechs Monaten korrekt war, ist fuer die Migrationsplanung heute nicht nuetzlich. Weisen Sie einen benannten Eigentuemer zu, planen Sie quartalsmaessige Reviews und verlangen Sie, dass neue Systemdeployments Public-Key-Krypto-Nutzung als Teil des Architecture-Reviews deklarieren.

Zusammenfassung

Ein realistisches First-Phase-PQC-Migrationsprogramm sollte vier Dinge erreichen: ein glaubwuerdiges Inventar, wo Public-Key-Kryptographie lebt, ein risikobasiertes Priorisierungsmodell, eine Crypto-Agility-Bewertung fuer Schluesselsysteme und mindestens einen begrenzten Piloten mit Rollback- und Erfolgskriterien. Das stimmt eng mit NISTs aktueller Richtung ueberein: standardisierte Algorithmen sind jetzt verfuegbar, das NCCoE-Migrationsprojekt demonstriert aktiv Erkennungs- und Interoperabilitaetspraktiken, und NIST sagt Organisationen, mit der Migration zu beginnen, statt auf einen perfekten zukuenftigen Zustand zu warten.

Was man noch nicht tun sollte: Erzwingen Sie keinen Big-Bang-Algorithmuswechsel ueber jedes Protokoll, nehmen Sie nicht an, dass jedes Produkt crypto-agil ist, und behandeln Sie Anbieter-Roadmaps nicht als anderer Leute Problem. Was sofort zu beginnen ist: das Inventar aufbauen, Hochrisikosysteme einordnen, Anbietergespraeche eroeffnen, einen Piloten definieren und Crypto-Agility zum Teil von Architektur- und Beschaffungsreview machen.

Fuer den strategischen Business Case und die Architektur-Level-Rahmung hinter dieser Arbeit, siehe Post-Quantum Cryptography Migration Roadmap. Fuer verwandte Infrastruktur-Haertung decken die Tutorials zum Haerten Ihrer CI/CD-Pipeline mit Sigstore, SLSA und SBOMs und zum Ausrollen von Enterprise Passkeys ergaenzende Vertrauensinfrastruktur-Themen ab.

Eine Post-Quantum-Kryptographie-Migration starten: Inventar, Priorisierung, Pilot

Bevor du beginnst

Was du lernen wirst