Max Schreiber 
Red Hat liefert mit RHEL 10.2 und 9.8 das, worüber andere noch reden: quantenresistente Kryptografie im Enterprise-Linux, KI-gestützte Automatisierung in der Hybrid Cloud, und das alles unter echtem Compliance-Druck. Klingt nach Marketing? Ist es nicht. Klartext: Hier steckt echter Admin-Aufwand drin, echter Plattformnutzen — und eine Deadline, die die meisten Unternehmen noch nicht ernst nehmen.
Seien wir ehrlich: Versionsnummern interessieren niemanden. Was zählt, ist der Inhalt. Mit RHEL 10.2 und 9.8 liefert Red Hat zwei Dinge gleichzeitig, die im Enterprise-Umfeld selten zusammen ankommen — Post-Quantum-Kryptografie (PQC) als produktionsreifes Feature und KI-gestützte Automatisierung für Upgrade-Workflows in der Hybrid Cloud.
Die Grundlage legte bereits RHEL 10, vorgestellt auf dem Red Hat Summit 2025 in Boston. Damals war RHEL 10 die erste Unternehmens-Linux-Distribution mit integrierter Post-Quantum-Kryptografie nach FIPS-Standards. Jetzt, mit den Minor-Releases 10.2 und 9.8, wandert das in die breite Verfügbarkeit. Das ist kein Pilotprojekt mehr. Wer tiefer einsteigen möchte, findet in NIST-Triage: Neues Modell für IoT-Sicherheit weiteren Hintergrund.
Konkret bedeutet das: RHEL integriert den ML-KEM-Algorithmus (Module-Lattice-Based Key Encapsulation Mechanism) für den Schlüsselaustausch — einen der vier Standards, die das NIST im August 2024 erstmals veröffentlicht hat. Zusätzlich kommen quantenresistente Signaturschemata zum Einsatz, die Softwareintegrität und TLS-Zertifikate absichern. Der Angriff, gegen den das schützen soll, hat einen Namen: „Harvest now, decrypt later“.
Klartext: Kein Quantencomputer bricht heute RSA-Schlüssel. Aber staatliche Akteure sammeln verschlüsselte Kommunikation jetzt, um sie zu entschlüsseln, sobald leistungsfähige Quantencomputer existieren. Das ist keine Science-Fiction — das ist eine dokumentierte Angriffsstrategie, gegen die klassische Kryptografie strukturell versagt. Geheimdienstberichte aus den USA und Europa bestätigen, dass gezieltes Abgreifen von Behördenkommunikation und Finanzdaten schon seit Jahren im Gange ist — in der Erwartung, diese Daten später auswerten zu können. Die Zeitspanne zwischen heute und dem ersten kryptografisch relevanten Quantencomputer wird in der Fachwelt auf fünf bis fünfzehn Jahre geschätzt. Das klingt nach viel Zeit. Es ist es nicht, wenn man die Komplexität unternehmensweiter Kryptografie-Migrationen kennt.
Zum Vergleich: Die Migration von SHA-1 auf SHA-256 hat in vielen Unternehmen fünf bis sieben Jahre gedauert — und SHA-1 war kein Quantenproblem, sondern ein klassisch bekanntes Schwächeproblem. PQC-Migration ist strukturell komplexer, weil sie Schlüsselaustausch, Signaturen und Zertifikatsinfrastruktur gleichzeitig betrifft. Red Hat verkürzt diesen Weg, indem es die Algorithmen direkt ins Betriebssystem integriert — aber der Weg ist trotzdem kein Selbstläufer.
Hier wird oft zu viel versprochen. PQC schützt nicht retroaktiv. Daten, die heute abgegriffen werden, bleiben gefährdet, solange der Angreifer sie entschlüsseln kann. PQC sichert nur, was ab jetzt verschlüsselt wird. Wer also mit Migration wartet, verschlechtert seine Position täglich.
Außerdem: RHEL 10 implementiert die erste Generation der NIST-PQC-Standards. Das NIST arbeitet bereits an Weiterentwicklungen, und es ist realistisch, dass einzelne Algorithmen in zukünftigen Runden angepasst werden. Red Hat setzt deshalb auf hybride Implementierungen — ML-KEM kombiniert mit klassischen Verfahren im FIPS-Modus. Das gibt Spielraum, ohne auf klassischen Schutz zu verzichten.
RHEL 9.7, das bereits 2025 erschien, war dabei der erste Schritt: erste FIPS 140-3-zertifizierte RHEL-Version seit 2022, mit hybriden ML-KEM-Algorithmen als Vorbereitung. RHEL 9.8 baut darauf auf. Auf der offiziellen Red Hat-Seite zu Post-Quantum-Kryptografie in RHEL 10 ist dokumentiert, welche Algorithmen konkret implementiert sind und welche Workloads davon profitieren.
Was regulierte Branchen — Finanzen, Gesundheitswesen, Behörden — wissen müssen: Bis 2030 wird in diesen Sektoren die Pflichtumstellung auf PQC-konforme Systeme erwartet. Wer jetzt anfängt, hat sechs Jahre Vorlauf. Wer wartet, bekommt ein Compliance-Problem, das sich nicht über Nacht lösen lässt. Eine vertiefende Einordnung bietet MWC 2026: Diese App-Trends erwarten uns im März.
Es gibt ein weiteres, selten diskutiertes Risiko: Lieferkettensicherheit. Wer Softwarepakete signiert und verteilt — ob intern oder als Hersteller — setzt auf digitale Signaturen, die heute auf RSA oder ECDSA basieren. Wenn ein Angreifer in zehn Jahren die Signatur einer alten Softwareversion fälschen kann, verliert rückwirkend jede damalige Integritätsprüfung ihre Aussagekraft. Red Hats Entscheidung, auch Softwaresignaturen quantenresistent zu gestalten, adressiert genau dieses Problem — nicht nur den Schlüsselaustausch.
Gegenargument, das man kennen muss: Einige Sicherheitsexperten warnen vor zu frühem Ausrollen von PQC-Standards, da die mathematischen Grundlagen der neuen Algorithmen weniger erprobt sind als die klassischer Verfahren wie RSA oder ECDH. Ein Fehler in ML-KEM könnte theoretisch breiter ausgenutzt werden als ein Fehler in einem 30 Jahre lang geprüften Verfahren. Red Hats hybride Implementierung — PQC kombiniert mit klassischen Algorithmen — ist die direkte Antwort auf dieses Risiko. Wenn einer der beiden Teile bricht, hält der andere. Das ist keine Schwäche des Ansatzes, sondern sein wichtigstes Sicherheitsmerkmal.
Der zweite große Pfeiler von RHEL 10.2 und 9.8 ist die KI-gestützte Automatisierung — speziell für Upgrade-Prozesse und imagebasierte Workflows in Hybrid-Cloud-Umgebungen. Das klingt nach Buzzword-Bingo. Ist es nicht.
Wer schon einmal ein Major-Upgrade auf einem produktiven RHEL-System durchgeführt hat, kennt den Aufwand: Kompatibilitätsprüfungen, Paketkonflikt-Analysen, manuelle Rollback-Planung, Test auf verschiedenen Hardware-Plattformen. Genau hier greift die KI-Automatisierung an. Die neuen Features analysieren die bestehende System-Konfiguration, identifizieren Upgrade-Risiken und schlagen Migrationspfade vor — ohne dass ein Admin jeden Schritt von Hand durchdenken muss.
Das ist meine persönliche Einschätzung: Enterprise-Linux lebt nicht vom Feature-Sheet, sondern davon, wie viel Admin-Aufwand es wegnimmt. Und der ist bei manuellen Upgrades in Hybrid-Cloud-Setups mit Dutzenden Nodes schlicht nicht mehr skalierbar. KI-gestützte Automatisierung ist hier kein Nice-to-have — sie ist strukturell notwendig.
Ein konkretes Beispiel verdeutlicht das: Ein mittelgroßes Unternehmen mit 80 RHEL-Nodes in einer Hybrid-Cloud-Umgebung — 40 On-Premises, 40 auf AWS — plant den Wechsel von RHEL 9.6 auf 10.x. Klassisch würde ein erfahrener Admin pro Node zwei bis vier Stunden Analyse-, Test- und Rollback-Zeit einplanen. Bei 80 Nodes sind das 160 bis 320 Stunden reiner Planungsaufwand, bevor die erste Migration läuft. Die imagebasierten Upgrade-Workflows in RHEL 10.2 reduzieren diesen Aufwand, indem sie Konfigurationsanalyse und Risikoerkennung automatisieren und standardisierte Images als Ausgangspunkt liefern. Ob das in der Praxis 50 oder 70 Prozent Zeitersparnis bedeutet, hängt von der Heterogenität der Umgebung ab — aber die Richtung ist klar.
Hinzu kommen optimierte Cloud-Images für AWS, Google Cloud und Azure. Das bedeutet: Wer RHEL in Multi-Cloud-Setups betreibt, bekommt abgestimmte Basis-Images, die direkt mit den Diensten der jeweiligen Plattform interagieren — ohne aufwendige manuelle Anpassungen. Dazu kommt Unterstützung für KI-Hardware und die RISC-V-Architektur, entwickelt in Kooperation mit SiFive.
Praktisch bedeutet die KI-Hardware-Unterstützung: RHEL 10.2 optimiert Treiber-Stacks und Kernel-Parameter für GPU-intensive Workloads, wie sie im KI-Training und Inferenz anfallen. Wer heute KI-Modelle auf RHEL-Systemen mit NVIDIA- oder AMD-Beschleunigern betreibt, profitiert von geringerem manuellen Tuningaufwand. Das ist besonders für Unternehmen relevant, die KI-Workloads aus der Public Cloud zurück in selbst verwaltete Infrastruktur holen wollen — ein Trend, der unter dem Stichwort Repatriation gerade an Fahrt gewinnt.
Red Hat positioniert RHEL nicht als reines Betriebssystem. Die Strategie ist klarer: RHEL soll die einheitliche Plattformebene für Hybrid-Cloud-Umgebungen werden — von On-Premises-Servern bis zu Public-Cloud-Instanzen auf AWS, Azure oder Google Cloud.
Dafür kombiniert Red Hat drei Elemente: Container-Management über Podman Desktop, Zero-Trust-Sicherheit mit Mikrosegmentierung und kontinuierlicher Validierung, sowie die neuen PQC-Features auf der Kryptografie-Ebene. Das ist keine Einzellösung — das ist ein Sicherheitskonzept für Hybrid-Cloud-Umgebungen, das von der Infrastruktur-Ebene bis zur Anwendungsschicht reicht.
Die Frage, die Entscheider stellen sollten: Wie viele verschiedene Sicherheits- und Automatisierungstools setzen Sie heute in Ihrer Hybrid Cloud ein? Jedes zusätzliche Tool ist eine Integrationsaufgabe, eine Schulungsanforderung, eine potenzielle Sicherheitslücke. Red Hat verkauft hier Konsolidierung — und die hat einen echten betriebswirtschaftlichen Wert.
Das Gegenargument verdient aber Raum: Konsolidierung auf eine einzige Plattform schafft auch Abhängigkeit. Wer seine gesamte Hybrid-Cloud-Infrastruktur auf RHEL vereinheitlicht, ist tief im Red-Hat-Ökosystem verankert — und damit auch in Ibms Ökosystem, seit der Übernahme 2019. Lizenzkosten, Support-Verträge und Release-Zyklen liegen dann bei einem einzigen Anbieter. Das ist kein Argument gegen RHEL — aber es ist ein Argument dafür, die Strategieentscheidung bewusst zu treffen und nicht nur aus Bequemlichkeit in die Plattformkonsolidierung zu gleiten.
All-about-security.de hat die technischen Details zu RHEL 10.2 und 9.8 ausführlich dokumentiert, inklusive der konkreten Automatisierungs-Features und der PQC-Implementierung.
Schluss damit, PQC als Zukunftsthema abzuhaken. Hier sind die konkreten Handlungsschritte, die sich aus den neuen RHEL-Releases ergeben.
Schritt 1 — Bestandsaufnahme: Welche Systeme laufen auf RHEL 9.x? Dort ist der hybride ML-KEM-Algorithmus im FIPS-Modus bereits ab 9.7 verfügbar. Testen Sie die Aktivierung in Ihrer Entwicklungsumgebung, bevor Sie auf Produktion gehen. Red Hat empfiehlt explizit, hybride ML-KEM für Schlüsselaustausch in regulierten Umgebungen sofort zu testen. Beginnen Sie mit nicht-kritischen Diensten wie internen Monitoring-Systemen oder Test-Proxys, bevor Sie produktive TLS-Verbindungen umstellen. Das gibt Ihrem Team Zeit, mit dem neuen Verfahren vertraut zu werden, ohne Ausfallrisiko.
Schritt 2 — Upgrade-Planung mit KI-Unterstützung: Die neuen Automatisierungs-Features in RHEL 10.2 sind keine schwarze Box. Nutzen Sie die imagebasierten Workflows, um Upgrade-Pfade von RHEL 9.x auf 10.x systematisch zu analysieren. Das reduziert manuelle Fehlerquellen, besonders in großen Hybrid-Cloud-Setups mit heterogener Hardware. Planen Sie trotzdem manuelle Validierungspunkte ein — speziell für Anwendungen, die direkt auf Kernel-Schnittstellen zugreifen oder undokumentierte Abhängigkeiten zu bestimmten Bibliotheksversionen haben.
Schritt 3 — Compliance-Readiness prüfen: Wenn Ihr Unternehmen in regulierten Branchen operiert, beginnen Sie jetzt mit der Dokumentation Ihrer Kryptografie-Inventur. Welche Systeme verwenden RSA oder ECDH? Welche davon übertragen sensible Daten? Das ist die Grundlage jeder PQC-Migration. In der Praxis unterschätzen viele Teams, wie viele interne Dienste implizit auf klassischer Kryptografie aufbauen — VPNs, interne APIs, Datenbankverbindungen, Backup-Verschlüsselung. Eine vollständige Inventur dauert in mittelgroßen Unternehmen typischerweise zwei bis vier Wochen und sollte extern validiert werden.
Schritt 4 — Cloud-Images aktualisieren: Die optimierten Cloud-Images für AWS, Azure und Google Cloud in RHEL 10.2 sind der schnellste Weg, PQC in Public-Cloud-Workloads zu bringen. Prüfen Sie Ihre bestehenden AMIs und Cloud-Deployment-Skripte auf Kompatibilität. Achten Sie besonders auf Infrastructure-as-Code-Templates in Terraform oder CloudFormation — diese referenzieren häufig hart kodierte AMI-IDs, die bei einem Image-Update manuell angepasst werden müssen. Automatisieren Sie diesen Prozess frühzeitig, um bei künftigen Updates nicht wieder in denselben Engpass zu laufen.
Schritt 5 — Schulung und Wissenstransfer: PQC ist für viele Linux-Admins konzeptionell neu. Die Algorithmen unterscheiden sich grundlegend von klassischen Verfahren, und das Debugging von Verbindungsproblemen in hybriden ML-KEM-Setups erfordert anderes Werkzeug als bei klassischem TLS. Planen Sie Schulungszeit ein — nicht als einmaligen Workshop, sondern als kontinuierlichen Prozess, der mit den NIST-Standards Schritt hält. Red Hat bietet entsprechende Trainingsmodule über die Red Hat Learning Platform an.
KI-gestützte Automatisierung in der Hybrid Cloud ist kein Ersatz für Architekturentscheidungen. Das muss klar gesagt werden.
Automatisierte Upgrade-Analysen liefern Empfehlungen auf Basis der erkannten Konfiguration — sie können nicht wissen, welche Legacy-Applikationen interne Abhängigkeiten zu bestimmten Kernel-Versionen haben. Sie können keine Compliance-Anforderungen kennen, die nicht in der Systemkonfiguration abgebildet sind. Und sie können keine Business-Entscheidung treffen, ob eine Migration jetzt oder in sechs Monaten sinnvoller ist.
Das ist keine Kritik an Red Hats Ansatz — das ist die realistische Einordnung. KI-Automatisierung in RHEL 10.2 reduziert den operativen Aufwand erheblich. Sie ersetzt aber weder erfahrene Linux-Admins noch durchdachte Migrationsplanung. Wer das erwartet, wird enttäuscht.
Ein oft übersehenes Risiko bei automatisierten Upgrade-Empfehlungen: False Confidence. Wenn ein System nach der KI-Analyse als „upgrade-ready“ eingestuft wird, sinkt die manuelle Prüfbereitschaft. Genau in diesem Moment schleichen sich Fehler ein, die bei sorgfältiger manueller Prüfung aufgefallen wären. Die Automatisierung ist ein Werkzeug zur Effizienzsteigerung — kein Sicherheitsnetz, das menschliches Urteilsvermögen ersetzt. Gute Migrationsplanung kombiniert beides: KI-Analyse als ersten Filter, erfahrener Admin als finale Entscheidungsinstanz.
Gleichzeitig: Wer in der Hybrid Cloud heute noch jeden Upgrade-Schritt manuell plant, wird mit wachsenden Infrastrukturen schlicht nicht mehr mithalten. Die Frage ist nicht ob Automatisierung, sondern welche und mit welchem Werkzeug.
PQC und KI-Automatisierung sind zwei Bausteine. Red Hat denkt das aber als Gesamtarchitektur — und das ist der eigentliche Punkt, den Entscheider verstehen müssen.
Die Hybrid-Cloud-Sicherheit bei RHEL 10.2 arbeitet auf drei Ebenen: Design (sichere Basis-Images, PQC-Kryptografie, signierte Software-Lieferketten), Entwickeln (Container-Isolation über Podman, Zero-Trust-Policies schon im Build-Prozess) und Ausführen (Mikrosegmentierung, kontinuierliche Validierung, Anomalie-Erkennung im Betrieb). Das ist kein neuer Ansatz — aber erstmals ist er in einer einzigen Linux-Distribution gebündelt, die gleichzeitig On-Premises, in Public Clouds und auf KI-spezifischer Hardware läuft.
Die Mikrosegmentierung verdient dabei besondere Aufmerksamkeit. Klassische Perimeter-Sicherheit — Firewall am Netzwerkrand, Vertrauen nach innen — funktioniert in Hybrid-Cloud-Umgebungen strukturell nicht mehr. Wenn Workloads dynamisch zwischen On-Premises und Cloud verschoben werden, gibt es keinen stabilen Perimeter. Zero-Trust mit Mikrosegmentierung behandelt stattdessen jede Verbindung als potenziell nicht vertrauenswürdig — unabhängig davon, ob sie intern oder extern ist. RHEL 10.2 integriert dieses Konzept auf Betriebssystemebene, was den Implementierungsaufwand gegenüber nachträglich eingefügten Netzwerk-Tools deutlich reduziert.
Die Kooperation mit SiFive für RISC-V-Unterstützung ist dabei ein interessantes Signal. RISC-V ist bisher vor allem in eingebetteten Systemen und Forschung präsent — aber das Interesse großer Unternehmen an offenen Befehlssatzarchitekturen wächst. Red Hat positioniert RHEL damit für Workloads, die in drei bis fünf Jahren erst relevant werden. Für Unternehmen, die heute noch keine RISC-V-Hardware betreiben, ist das kein unmittelbar relevantes Feature — aber ein Indikator dafür, dass Red Hat die Architektur langfristig denkt und nicht nur den aktuellen x86-Mainstream bedient.
Signierte Software-Lieferketten sind ein weiterer Baustein, der in der Berichterstattung oft untergeht. Nach dem SolarWinds-Angriff 2020 und ähnlichen Supply-Chain-Kompromittierungen hat die Branche verstanden, dass Angreifer zunehmend auf Software-Lieferketten zielen statt auf direkte Systeme. RHEL 10.2 stärkt die Signierungskette von der Paketauslieferung bis zur Laufzeit — kombiniert mit PQC-Signaturen ein deutlich robusteres Schutzkonzept als das, was vor fünf Jahren State of the Art war.
ITT Business hat das umfassend eingeordnet: Red Hat setzt neue Maßstäbe bei der Betriebssystemunterstützung für hybride IT-Landschaften — nicht durch einzelne Features, sondern durch ihre Integration.
Direkt. Keine Ausweichmanöver.
Relevant ist RHEL 10.2 mit PQC und KI-Automatisierung für: Unternehmen in regulierten Branchen mit Compliance-Anforderungen an Kryptografie, IT-Teams, die Hybrid-Cloud-Infrastrukturen mit mehr als zwanzig Nodes verwalten, Organisationen, die bereits auf RHEL 9.x laufen und einen klaren Upgrade-Pfad brauchen, sowie alle, die Public-Cloud-Workloads auf AWS, Azure oder Google Cloud mit kontrollierbaren Basis-Images betreiben wollen. Besonders relevant ist das Release für Behörden und öffentliche Einrichtungen in Deutschland, die unter der NIS-2-Richtlinie stehen — dort werden Anforderungen an kryptografische Standards künftig explizit auditiert.
Weniger relevant — im Klartext: Sie brauchen das jetzt nicht, wenn Sie ein kleines Team sind, das eine Handvoll Server mit Standardsoftware betreibt und keine regulatorischen Anforderungen an Kryptografie hat. Dann ist der Aufwand der Migration höher als der Nutzen in den nächsten zwölf bis achtzehn Monaten. Mehr Kontext liefert Die SaaSpocalypse und die Stunde der Industriesoftware: Warum der KI-Ausverkauf für den deutschen Mittelstand eine Chance ist.
Aber: Die Deadline für regulierte Branchen kommt. Und wer jetzt anfängt, die PQC-Migration zu planen, hat einen messbaren Vorteil gegenüber denen, die 2028 unter Druck stehen. In der Praxis bedeutet das: Unternehmen, die 2025 mit Tests beginnen, können bis 2027 produktive PQC-Infrastruktur betreiben — mit zwei Jahren Puffer, um Kinderkrankheiten zu beheben und Erfahrungen zu dokumentieren, bevor die Compliance-Uhr tickt. Wer 2028 anfängt, hat diesen Puffer nicht.
Mittelständische Unternehmen stehen vor einer besonderen Abwägung: Sie haben oft keine dedizierten Kryptografie-Experten im Haus, profitieren aber gleichzeitig davon, dass Red Hat die Komplexität kapselt. Wenn PQC als Betriebssystemfeature kommt, das über Konfigurationsparameter aktiviert wird, sinkt die Einstiegshürde gegenüber einer selbst zusammengestellten Lösung erheblich. Das ist der strategische Wert von Plattform-Integration — nicht als Bequemlichkeit, sondern als Demokratisierung von Sicherheitstechnologie.
Red Hat liefert hier keine Ankündigung, sondern produktionsreife Infrastruktur. RHEL 10.2 und 9.8 bringen quantenresistente Kryptografie und KI-gestützte Automatisierung aus dem Lab in den Produktionsbetrieb — mit klarer Compliance-Relevanz und konkretem Admin-Nutzen. Das ist die harte Wahrheit hinter dem Versionsupdate.
Die Integration von PQC auf Betriebssystemebene, kombiniert mit hybriden Algorithmen als Sicherheitsnetz und KI-Automatisierung für skalierbare Upgrades, ist kein inkrementelles Update. Es ist eine Positionierung für die nächste Dekade der Enterprise-IT — eine Dekade, in der Quantencomputing von einer akademischen Randnotiz zu einem operativen Sicherheitsrisiko werden wird. Ob das in sieben oder in dreizehn Jahren der Fall ist, ändert nichts daran, dass die Migration-Infrastruktur jetzt aufgebaut werden muss.
Wer RHEL 10.2 und 9.8 auf technischer Ebene bewertet, sieht gut durchdachte Algorithmen-Auswahl, pragmatische hybride Implementierungen und sinnvolle Automatisierung. Wer es auf strategischer Ebene bewertet, sieht einen Anbieter, der Compliance-Anforderungen antizipiert und Infrastruktur so aufbaut, dass Kunden nicht überrumpelt werden, wenn die regulatorischen Fristen kommen. Beides ist richtig — und beides zusammen erklärt, warum diese Minor-Releases mehr Aufmerksamkeit verdienen, als Versionsnummern typischerweise bekommen.
Die eigentliche Frage ist keine technische: Wann beginnen Ihre IT-Verantwortlichen mit der Kryptografie-Inventur? Und wie lange wollen Sie mit der Antwort warten?
