Post-Quantum Cryptography 2026: Readiness für Admins

Warum PQC jetzt auf Deine Admin-Roadmap gehört

Die post-quantum cryptography migration betrifft vor allem Public-Key-Verfahren wie RSA, ECDSA, ECDH und klassische Schlüsselaustauschverfahren. Für Dich als Admin geht es nicht darum, Quantencomputer zu bewerten, sondern kryptografische Abhängigkeiten in produktiven Systemen sichtbar zu machen und Änderungen ohne Ausfall, Compliance-Lücken oder Kontrollverlust vorzubereiten.

Der operative Treiber ist Harvest now, decrypt later. Angreifer können heute verschlüsselte Kommunikationsdaten mitschneiden und später entschlüsseln, wenn dafür geeignete Quantencomputer verfügbar sind. Kritisch ist das für Daten mit langer Vertraulichkeitsdauer: personenbezogene Daten, Gesundheitsdaten, Vertragsarchive, Entwicklungsunterlagen, Regierungsdaten, Schlüsselmaterial, Backups und M&A-Dokumente.

PQC ist deshalb ein mehrjähriges Programm. Betroffen sind PKI, TLS, SSH, VPNs, Zertifikate, S/MIME, Code-Signing, Paketsignaturen, HSMs, Cloud-Services, Appliances, Betriebssysteme und Software-Supply-Chains. Gute Vorbereitung beginnt nicht mit dem Algorithmuswechsel, sondern mit Sichtbarkeit.

Was NIST, NCSC, CISA und NSA aktuell empfehlen

NIST veröffentlichte im August 2024 die ersten drei finalisierten PQC-Standards: FIPS 203 mit ML-KEM für Key Encapsulation, FIPS 204 mit ML-DSA für digitale Signaturen und FIPS 205 mit SLH-DSA als weiteres Signaturverfahren. Diese Standards sind der fachliche Ausgangspunkt, aber keine Einladung zu unkoordinierten Änderungen in Produktivumgebungen.

NIST, CISA und NSA betonen denselben ersten Schritt: Organisationen sollen identifizieren, wo quantenanfällige Public-Key-Algorithmen in Hardware, Software und Services genutzt werden. NISTs aktuelle Übergangsplanung sieht vor, quantenverwundbare Verfahren in den kommenden Jahren auslaufen zu lassen und sie für viele Einsatzzwecke spätestens ab 2035 nicht mehr zuzulassen. Systeme mit hohem Risiko sollten deutlich früher migriert werden.

Das britische NCSC liefert dafür eine praktikable Orientierung: Discovery und initiale Planung bis 2028, größere Migrationen hochpriorisierter Assets bis 2031 und Abschluss der Migration bis 2035. Diese Daten sind kein Grund zum Abwarten, sondern helfen Dir, Roadmaps, Budgets, Testumgebungen und Vendor-Gespräche rechtzeitig zu strukturieren.

Ein weiteres Signal für Crypto-Agility ist die NIST-Auswahl von HQC im März 2025 als Backup-Algorithmus für ML-KEM. Der Punkt ist nicht, heute jedes Detail final zu kennen. Entscheidend ist, Algorithmen, Bibliotheken, Policies und Konfigurationen austauschbar zu halten, ohne die Architektur neu zu bauen. Genau hier überschneiden sich PQC, IT-Security, Betrieb und Governance.

Crypto Inventory: diese Systeme und Protokolle solltest Du prüfen

Ein belastbares Crypto Inventory ist der Kern Deines PQC Readiness Check. Suche nicht nur nach Zertifikaten im Webserver. Erfasse, wo RSA, ECDSA, ECDH, TLS, SSH, VPNs, S/MIME, Code-Signing, Paketsignaturen und interne Zertifikatsketten genutzt werden.

• Server und Clients: Linux, Windows, Container-Hosts, Datenbanken, Middleware, Webserver und Mail-Gateways.
• Netzwerk und Appliances: Load Balancer, Firewalls, VPN-Gateways, Proxies, WAFs, Storage-Systeme und Monitoring-Appliances.
• Identität und PKI: Active Directory Certificate Services, interne CAs, HSMs, Trust-Stores, SSO, IdPs, MDM und PAM.
• Lieferketten: CI/CD-Pipelines, Git-Repositories, Container-Registries, Paketquellen, Signierdienste und Update-Mechanismen.
• Cloud und Managed Services: TLS-Endpunkte, KMS, HSM-Dienste, API-Gateways, SaaS-Integrationen und Backup-Ziele.

Dokumentiere mindestens Algorithmus, Schlüssellänge, Bibliothek, Produktversion, Product Owner, Zertifikatskette, Trust-Store, Lebenszyklus, technische Abhängigkeiten, Change-Fenster und Rollback-Option. Für Windows-orientierte Prüfungen, Zertifikatsreports und wiederholbare Auswertungen sind Skripte oft unverzichtbar, etwa mit PowerShell. Grundlagen findest Du im PowerShell-Grundkurs.

Behandle das Inventory nicht als einmalige Tabelle. Es sollte ein operatives Asset sein, das mit CMDB, Zertifikatsmanagement, Schwachstellenmanagement, Cloud-Inventar und Change-Prozessen verbunden ist.

Priorisierung: welche Daten und Systeme zuerst kommen

Nicht jedes System muss gleichzeitig migriert werden. Beginne mit Daten und Diensten, die lange vertraulich bleiben müssen, geschäftskritisch, regulatorisch relevant oder extern erreichbar sind. Unterscheide Daten in Transit, Schlüsselmanagement für Daten at Rest, Identitätssysteme, Signatursysteme und Software-Update-Ketten.

Hochrisikosysteme können früher dran sein als allgemeine Infrastruktur: externe APIs mit sensiblen Daten, VPN-Zugänge, zentrale PKI, HSM-gestützte Signaturdienste, Identitätsplattformen, Update-Server und Backup-Transportwege. In Cloud- und Hybridumgebungen ist PQC Readiness auch Blue-Team-Aufgabe: Monitoring, Governance, Incident Response und technische Kontrollen müssen zusammenpassen. Wenn Du diese Rollen und Kontrollen vertiefen willst, passt der Blue Team Cloud Spezialist thematisch dazu.

RHEL 10 als Testfeld: TEST-PQ richtig einordnen

Für Tests rund um RHEL 10 post-quantum cryptography ist RHEL 10 ein sinnvolles Laborfeld. Red Hat stellt PQC-Funktionen systemweit als Technology Preview bereit; je nach Release-Stand erfolgt das über das Paket crypto-policies-pq-preview und die Subpolicy TEST-PQ. Prüfe Paketnamen, Supportstatus und Einschränkungen immer in den Release Notes Deiner konkreten RHEL-10-Version.

In der Dokumentation werden für die PQC-Unterstützung unter anderem Komponenten wie liboqs, oqsprovider, NSS, OpenSSH und GnuTLS genannt. Technology Preview bedeutet: nützlich für Labs, Kompatibilitätsprüfungen und operatives Lernen, aber kein Produktionsfreibrief. Gerade bei systemweiten Crypto-Policies musst Du verstehen, welche Dienste betroffen sind, wie Policies vererbt werden und wie Patch-Management, Hardening und Upgrade-Planung zusammenspielen. Für Teams, die RHEL 10 strukturiert einführen, ist das RHEL 10: Upgrade Training ein passender Kontext, ebenso die breitere Red Hat-Themenwelt.

Beispiel für Lab-Umgebungen, sofern Paket und Policy in Deinem Release verfügbar sind:

sudo dnf install crypto-policies-pq-preview
sudo update-crypto-policies --set DEFAULT:TEST-PQ
sudo update-crypto-policies --show

Teste bewusst klein: TLS-Endpunkte mit unterschiedlichen Clients, SSH-Zugriffe für Admins und Automation, Paket- und Repository-Workflows, Monitoring-Checks, Logauswertung, Backup-Jobs, Konfigurationsmanagement und Rollback-Verhalten. Ein Lab-Ziel kann quantum-safe TLS und SSH sein; die eigentliche Messgröße ist Betriebsfähigkeit unter realistischen Abhängigkeiten.

Typische Stolperfallen bei TLS, SSH, PKI, VPNs und Herstellern

Der häufigste Fehler ist der direkte Algorithmuswechsel ohne Interoperabilitätstest. TLS funktioniert nur, wenn Server, Client, Zertifikatskette, Trust-Store, Middleboxes, Load Balancer, Proxies und Monitoring zusammenpassen. Bei SSH musst Du Host-Keys, User-Keys, Bastion-Hosts, Automationskonten und alte Clients prüfen. Bei VPNs kommen IKE, Zertifikate, Appliances, Mobile Clients und externe Partner hinzu.

• Hybride Verfahren: Sie kombinieren klassische und Post-Quantum-Verfahren, erhöhen aber die Komplexität und müssen genau dokumentiert werden.
• Größere Schlüssel und Signaturen: Prüfe Paketgrößen, Handshake-Verhalten, MTU-Themen, CPU-Last, Speicherbedarf und Log-Volumen.
• PKI-Folgen: Zertifikatsprofile, Zertifikatsketten, OCSP, CRL, Enrollment, Renewal und Trust-Stores können sich ändern.
• Hersteller-Roadmaps: Frage konkret nach Appliances, HSMs, Endpoint Security, Cloud-Plattformen, IdPs und Managed Services.
• Ausnahmen: Legacy-Systeme brauchen dokumentierte Risikobewertung, Kompensationsmaßnahmen und feste Review-Termine.

Plane Rollback nicht als Nachgedanken. Lege vor jedem Test fest, welche Policy, welches Zertifikat, welcher Client und welche Routing- oder Firewall-Regel zurückgesetzt werden kann. Ergänze Logs und Metriken, damit Du erkennst, ob Fehler durch Kryptografie, Zertifikate, Netzwerkpfade oder Anwendungen entstehen.

Checkliste: Deine nächsten 10 Schritte zur PQC Readiness

1. Baue ein Crypto Inventory auf und weise für jedes Asset einen fachlichen und technischen Owner zu.
2. Identifiziere langlebige sensible Daten und Systeme mit hohem Risiko durch Harvest now, decrypt later.
3. Sprich mit Herstellern über PQC-Support, hybride Modi, Roadmaps, Supportgrenzen und Migrationspfade.
4. Richte ein Lab mit RHEL 10, relevanten Clients, Testzertifikaten und kontrollierten Policies ein.
5. Teste TLS, SSH, VPN, PKI, Signing, Paketquellen, CI/CD und Automationspfade Ende-zu-Ende.
6. Dokumentiere Zertifikatsketten, Trust-Stores, Algorithmen, Bibliotheken, Versionen und Abhängigkeiten.
7. Definiere Priorisierungsregeln und Migrationswellen nach Sensitivität, Exposition und Betriebsrisiko.
8. Erstelle Rollback-Pläne, Change-Fenster, Monitoring-Checks und klare Abbruchkriterien.
9. Aktualisiere Security-Policies, Betriebsverfahren, Härtungsstandards und Ausnahmeprozesse.
10. Überprüfe den Fortschritt regelmäßig, weil Standards, Bibliotheken und Herstellerimplementierungen weiter reifen.

Fazit: Crypto-Agility wird zur Betriebsdisziplin

PQC Readiness ist kein einzelnes Migrationsprojekt, das Du einmal abschließt. Es ist eine neue Betriebsfähigkeit: Kryptografie sichtbar machen, Änderungen testen, Abhängigkeiten dokumentieren, Hersteller steuern und Risiken nachvollziehbar priorisieren.

Wenn Du jetzt beginnst, schaffst Du die Grundlagen für eine kontrollierte post-quantum cryptography migration: ein lebendes Inventory, belastbare Labs, klare Verantwortlichkeiten, dokumentierte Rollback-Pfade und realistische Migrationswellen. Für Linux-Administration, RHEL-Upgrades, Cloud Security, Blue-Team-Arbeit, Automation und Compliance wird Crypto-Agility damit zu einer dauerhaften Disziplin im Betrieb.