Die meisten Texte zum Thema Maschinenidentität folgen demselben Schema: Maschinen sind im Netzwerk mittlerweile zahlreicher als Menschen, Zero Trust fordert die Überprüfung aller Daten, und Quantencomputer drohen, die zugrundeliegende Kryptografie zu revolutionieren. Das alles stimmt, und wir werden es behandeln. Die gängige Schlussfolgerung, dass man jedes Zertifikat umgehend durch ein quantensicheres ersetzen müsse, geht jedoch an der falschen Stelle vorbei.
Maschinenidentitäten sind nicht nur einer, sondern gleich zwei existenziellen Bedrohungen ausgesetzt, die sich zeitlich stark unterscheiden. Die meisten Ihrer Identitäten befinden sich auf der Seite, die weit weniger dringlich ist, als die Schlagzeilen vermuten lassen. Die eigentliche Gefahr lauert in einer kleinen Gruppe langlebiger Identitäten, die selten in Migrationsplänen berücksichtigt werden. Der positive Aspekt dabei ist, dass die kurzlebigen, automatisierten Identitäten, zu denen Zero Trust ohnehin drängt, den Großteil Ihrer Verteidigung gegen existenzielle Bedrohungen darstellen. Dieser Blog zeigt, wie diese Bausteine zusammenwirken und wo Sie Ihre Anstrengungen am besten investieren. Er beginnt mit der Definition einer Maschinenidentität und der entscheidenden Unterscheidung, die später alles verändern wird.
Maschinenidentitäten verstehen
Eine Maschinenidentität ist die Art und Weise, wie ein nicht-menschliches System seine Identität nachweist. Menschen verwenden einen Benutzernamen und ein Passwort. Eine Maschine verwendet üblicherweise ein digitales Zertifikat mit zugehörigem privaten Schlüssel und manchmal einen SSH-Schlüssel , einen API-Schlüssel, eine Cloud-Zugriffsrolle oder ein kurzlebiges Token. Man kann sich ein Zertifikat wie einen Ausweis für Software vorstellen: Es wird von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt und ermöglicht es zwei Maschinen, die Identität des jeweils anderen zu überprüfen, bevor sie Daten austauschen.
Die Schwierigkeit liegt in der Vielzahl der Identitäten und der Geschwindigkeit ihrer Veränderung. Eine Anwendung kann aus Dutzenden kleiner Dienste bestehen, von denen jeder seine eigene Identität besitzt. Cloud-Systeme erstellen und löschen diese Workloads ständig. Ein einzelner Workload kann erscheinen, seine Aufgabe für einige Sekunden erledigen und wieder verschwinden. Multipliziert man dies mit einer stark ausgelasteten Umgebung, ergeben sich täglich Tausende von Identitäten, die erstellt, verwendet und wieder gelöscht werden.
Eine Unterscheidung ist wichtiger als jeder gewählte Algorithmus: Eine Maschinenidentität erfüllt zwei verschiedene Aufgaben. Die erste ist die Authentifizierung, also der Nachweis der eigenen Identität beim Verbindungsaufbau zwischen zwei Systemen. Die zweite ist die Vertraulichkeit, bei der die Identität den Schlüsselaustausch authentifiziert, der die ausgetauschten Daten oft jahrelang geheim hält. Beide basieren auf Kryptografie und erscheinen daher wie ein einziges Problem, verhalten sich aber mit dem Einsatz von Quantencomputern völlig anders.
Die Art und Weise, wie diese Identitäten im Alltag verwaltet werden, ist genauso wichtig wie die zugrundeliegende Kryptografie. Hier setzt Zero Trust an: Die damit einhergehenden Gewohnheiten, wie kurze Lebensdauern und ständige Rotation, übernehmen im Hintergrund einen Großteil der Vorbereitung auf die Quantenidentität.
Wie Zero Trust die Hälfte der Arbeit erledigt
Lange Zeit folgte die IT-Sicherheit einem simplen Prinzip: Man errichtete einen starken Perimeter um das Netzwerk und vertraute nahezu allem darin. Der Schwachpunkt liegt auf der Hand: Sobald ein Angreifer eingedrungen ist, kann er sich frei bewegen. Zero Trust ersetzt dies durch eine einfachere Regel: Man vertraut nichts automatisch und prüft jede Anfrage individuell, unabhängig von ihrer Herkunft. Das NIST beschreibt diesen Ansatz in SP 800-207 , seinem Leitfaden für Zero-Trust-Architekturen, und er hat sich zum Standard für moderne IT-Sicherheit entwickelt.
Für Maschinen wird diese Regel zu einigen praktischen Gewohnheiten. Jede Verbindung weist ihre Identität nach, daher legen beide Seiten ihr Zertifikat vor und bestätigen sich gegenseitig, bevor Daten übertragen werden. Zugangsdaten sind nur kurzlebig, sodass gestohlene Zugangsdaten schnell ungültig werden. Jede Maschine erhält nur Zugriff auf die Ressourcen, die sie für ihre Aufgabe benötigt. Und in Cloud-Systemen hat jede Arbeitslast ihre eigene Identität, die sie begleitet, sodass dieselben Prüfungen überall dort gelten, wo sie ausgeführt wird.
Beachten Sie Folgendes: Kurze Lebensdauer, automatische Rotation, enger Geltungsbereich und Identitäten, die beliebig neu ausgestellt werden können. All dies erschwert es einem potenziellen Quantenangreifer, mit einer Identität etwas Sinnvolles anzufangen. Zero Trust ist vor allem für die Begrenzung von Sicherheitslücken bekannt und erfüllt diese Aufgabe hervorragend. Dieselbe Investition stellt auch den Großteil Ihrer Vorbereitung auf Quantenangriffe dar. Um zu verstehen, warum, müssen wir uns ansehen, wie Quanten die Identität tatsächlich bedrohen, denn dies geschieht auf zwei sehr unterschiedliche Arten.
Zwei Quantenbedrohungen, zwei Zeitebenen
Heutige Maschinenidentitäten basieren auf Public-Key-Kryptographie , die aus einem praktischen Grund sicher ist: Herkömmliche Computer bräuchten viel zu lange, um sie zu knacken. Ein ausreichend leistungsstarker Quantencomputer könnte diese Berechnungen jedoch blitzschnell durchführen, und genau diese Bedrohung ist es, über die alle sprechen. Was dabei meist übersehen wird, ist, dass diese Bedrohung nicht plötzlich eintritt. Sie verläuft parallel zu zwei verschiedenen Zeitebenen.
Das erste Risiko ist die Vertraulichkeitsuhr, und sie tickt bereits. Ein Angreifer kann heute verschlüsselte Daten aufzeichnen, speichern und Jahre später entschlüsseln, sobald Quantencomputer einsatzbereit sind. Dies wird als „ Ernten jetzt, Entschlüsseln später“ bezeichnet . Alles, was lange geheim bleiben muss, wie medizinische oder finanzielle Daten, ist in dem Moment offengelegt, in dem es das Netzwerk durchläuft, selbst wenn der eigentliche Datenverlust noch nicht stattgefunden hat. Bei solchen Daten beginnt das Risiko also nicht erst mit der Verfügbarkeit von Quantencomputern. Es beginnt bereits mit dem Senden der Daten, denn ein Angreifer könnte sie dann kopieren und einfach abwarten.
Der zweite Mechanismus ist die Authentifizierungsuhr, und sie funktioniert genau umgekehrt. Um eine Identität oder Signatur zu fälschen, benötigt ein Angreifer zum jeweiligen Zeitpunkt einen funktionsfähigen Quantencomputer. Er kann eine bereits bestehende Verbindung nicht nachträglich unterbrechen. Daher ist ein Zertifikat, dessen Gültigkeit vor der Entwicklung von Quantencomputern abläuft, vor dieser Bedrohung sicher. Ein Zertifikat, das 90 Sekunden lang gültig war – Jahre bevor es Quantencomputer gab –, war nie wirklich gefährdet. Es lief lange vor dem Auftreten der Bedrohung ab.
Ein Beispiel verdeutlicht den Unterschied. Stellen Sie sich einen Angreifer vor, der heute Ihren verschlüsselten Datenverkehr kopiert und speichert. Enthält dieser Datenverkehr die Krankengeschichte eines Patienten, muss er nur auf die Entwicklung von Quantencomputern warten, und das Geheimnis wird Jahre später enthüllt. Stellen Sie sich nun vor, derselbe Angreifer versucht, einen Ihrer Dienste zu imitieren. Um Ihr Zertifikat zu fälschen, ist ein Quantencomputer erforderlich, und bis ein solcher existiert, ist das Zertifikat längst abgelaufen. Es handelt sich um denselben Angreifer und dieselbe Kryptografie, aber die Dringlichkeit ist völlig anders.
Die Zusammenführung der beiden Uhren führt zu einer nützlichen Schlussfolgerung. Da Maschinenidentität meist nur kurzlebige Authentifizierung darstellt, ist ihre Dringlichkeit gering, weshalb ein überstürzter Austausch nicht notwendig ist. Das bedeutet jedoch nicht, dass die Standards ignoriert werden können. Sie benötigen weiterhin den richtigen Standard für die Vertraulichkeit, die heute dringlich ist, und später auch für die langlebigen Identitäten, die Sie schließlich migrieren werden. Die neuen Standards , die das NIST 2024 finalisiert hat, decken sich nahtlos mit den beiden Uhren: Eine schützt den privaten Kanal, die anderen verwalten Identität und Signaturen. Hier die Veranschaulichung:
| Algorithmus | Was es schützt | Welche Uhr | Status |
|---|---|---|---|
| ML-KEM (FIPS203) | Erzeugt und kapselt ein gemeinsames Geheimnis zur Ableitung symmetrischer Schlüssel (ersetzt den RSA/ECDH-Schlüsselaustausch) | Vertraulichkeit (wirkt jetzt) | Finale, 2024 |
| ML-DSA (FIPS204) | Authentizität und Integrität durch digitale Signaturen | Authentifizierung | Finale, 2024 |
| SLH-DSA (FIPS205) | Authentizität und Integrität durch hashbasierte digitale Signaturen | Authentifizierung | Finale, 2024 |
| Hauptquartier | Bietet Schlüsselkapselung auf Basis der Codierungstheorie und bietet kryptographische Diversität als Alternative zum gitterbasierten Ansatz von ML-KEM. | Vertraulichkeit | Ausgewählt im März 2025; Entwurf 2026, endgültig 2027 |
| FN-DSA | Authentizität und Integrität durch kompakte digitale Signaturen | Authentifizierung | Erster öffentlicher Entwurf veröffentlicht im September 2025; derzeit öffentlich geprüft; endgültige Fassung voraussichtlich Ende 2026 oder Anfang 2027 |
Es gibt jedoch eine wichtige Ausnahme, und genau darauf konzentriert sich der Rest dieses Blogbeitrags. Manche Signaturen müssen über viele Jahre gültig bleiben, und manche Geheimnisse müssen ebenso lange vertraulich bleiben. Für diese Fälle ist die Authentifizierung genauso dringlich wie die Wahrung der Vertraulichkeit. Genau darin liegt das eigentliche Risiko.
Risikofaktoren
Beginnen Sie mit den langlebigen Vertrauensankern. Die Stammzertifizierungsstelle kann zwanzig Jahre oder länger gültig sein. Code- und Firmware-Signaturschlüssel signieren Daten, deren Echtheit auch in ferner Zukunft immer wieder überprüft werden muss. So muss beispielsweise ein heute ausgeliefertes Firmware-Image möglicherweise noch in fünfzehn Jahren seine Echtheit beweisen. Wurde diese Signatur mit heutigen Algorithmen erstellt, könnte ein zukünftiger Quantencomputer sie fälschen, lange bevor das Gerät außer Betrieb genommen wird. Außerdem lässt sich eine Stammzertifizierungsstelle, die in Millionen von Geräten und Vertrauensspeichern integriert ist, nicht einfach austauschen. Aus diesem Grund räumen nationale Sicherheitsrichtlinien der Signierung von Software und Firmware einen sehr frühen Stichtag ein – noch vor fast allen anderen Prioritäten.
Dann gibt es da noch den Aspekt, den die meisten Quantenmigrationspläne komplett auslassen. Ein Großteil der Maschinenidentität besteht gar nicht aus Zertifikaten. Es sind SSH-Schlüssel , API-Schlüssel, Cloud-Zugriffsrollen, Geheimnisse in Konfigurationsdateien und Dienstkonten – viele davon ohne Ablaufdatum, ohne eindeutigen Besitzer und ohne Inventarisierung. Sie sind die ungenutzten Schlüssel, die man einfach liegen lässt. Unabhängig von Quantenmigrationen entstehen hier viele echte Sicherheitslücken, die in Migrationsplänen nach der Umstellung fast nie auftauchen.
Es hilft, sich vorzustellen, wie so etwas schiefgehen kann. Ein Entwickler erstellt einen SSH-Schlüssel für den Zugriff auf einen Server, verlässt später das Unternehmen, und der Schlüssel bleibt jahrelang ohne Ablaufdatum und ohne Nachweis seiner Existenz bestehen. Oder ein Build-Server signiert Software mit einem Schlüssel, der nie rotiert, sodass ein einziges unbemerktes Datenleck jede nachfolgende Version gefährdet. Für keines dieser Probleme ist ein Quantencomputer nötig, um Schaden anzurichten, und keines lässt sich durch den Austausch eines Webzertifikats gegen einen neuen Algorithmus beheben. Die Lösung liegt darin, die Identität des Zertifikats von vornherein zu erkennen und ihr dann eine Gültigkeitsdauer und einen Inhaber zuzuweisen.
Ein Plan, der lediglich öffentliche Zertifikate durch einen neuen Algorithmus ersetzt, vernachlässigt die beiden wirklichen Risikofaktoren: die langlebigen, durch Quantencomputer bedrohten Datenstrukturen und die unkontrollierten Identitäten, die Angreifer bereits heute ausnutzen. Eine gute Strategie für maschinelle Identitäten muss all dies berücksichtigen, nicht nur die leicht zu zählenden Zertifikate. Diese neue Herangehensweise deutet auf eine sinnvollere Vorgehensweise hin als die übliche Eile.
Planen der Migration
Beginnen Sie damit, möglichst viele Identitäten kurzlebig und automatisch zu verwalten. Wahrscheinlich tun Sie dies bereits, sowohl im Sinne von Zero Trust als auch weil die Gültigkeitsdauer öffentlicher Zertifikate bis 2029 auf maximal 47 Tage sinkt . Wenn Sie dies erfolgreich umsetzen, reduziert sich der Anteil der kritischen Bedrohungen in Ihrer Umgebung auf einen Bruchteil, da kurzlebige Identitäten lange vor dem Eintritt einer realen Bedrohung ablaufen.
In der Praxis bedeutet dies zweierlei. Erstens werden Zertifikate über dieselben Systeme, auf denen Ihre Anwendungen laufen, automatisch erneuert. Zweitens werden Zugangsdaten bei jedem Start einer Arbeitslast neu vergeben, anstatt gespeichert und wiederverwendet zu werden. Je kürzer die Gültigkeitsdauer und je weniger manuelle Eingriffe erforderlich sind, desto weniger Daten können gestohlen, verfolgt oder bei Algorithmusänderungen manuell migriert werden.
Als Nächstes sollten Sie die langlebigen Komponenten identifizieren und beheben. Ermitteln Sie Ihre Vertrauensanker und Ihre langlebigen Signaturen, die Wurzeln sowie die Code- und Firmware-Signatur und planen Sie deren Umstellung auf quantensichere Algorithmen als erstes. Sie bieten die geringsten Sicherheitsreserven und die größte Reichweite und verdienen daher die gleiche Aufmerksamkeit, die in den Medien üblicherweise herkömmlichen Zertifikaten zuteilwird.
Erstellen Sie das Inventar fortlaufend und stellen Sie sicher, dass es auch Identitäten umfasst, die keine Zertifikate sind. Was man nicht sieht, kann man nicht schützen, und SSH-Schlüssel sowie vergessene Geheimnisse sind in der Regel am wenigsten sichtbar und gleichzeitig am gefährlichsten.
Verknüpfen Sie dies mit einem automatisierten System zur Ausstellung und Verwaltung von Identitäten. Dies ist der entscheidende Hebel, denn dieses System zahlt sich dreifach aus. Es gewährleistet Zero Trust, hält mit den immer kürzeren Erneuerungsfristen Schritt und ermöglicht den späteren Wechsel zu quantensicheren Algorithmen. Sobald dieses System implementiert ist, wird die Änderung eines Algorithmus zu einer einfachen Konfiguration anstatt eines kompletten Neuaufbaus – genau das ist der Kern der Krypto-Agilität.
Konkrete Daten bilden den Rahmen für all dies. Die 47-Tage-Gültigkeitsgrenze für Zertifikate tritt 2029 in Kraft. Das NIST hat vorgeschlagen, die derzeit anfälligen Algorithmen wie RSA, ECDSA, ECDH, DSA und Diffie-Hellman um das Jahr 2030 schrittweise abzuschaffen und sie ab 2035 vollständig zu verbieten. Dieser Vorschlag befindet sich jedoch noch im Entwurfsstadium. Die CNSA 2.0-Suite der NSA sieht für die nationalen Sicherheitssysteme der Vereinigten Staaten einen Übergang bis 2035 vor (NSM-10). Die Software- und Firmware-Signatur steht dabei im Vordergrund und erfordert Unterstützung bis 2025 sowie die ausschließliche Nutzung ab 2030. Als primäre Signaturalgorithmen kommen LMS und XMSS (SP 800-208) zum Einsatz.
CNSA 2.0 verwendet ML-KEM-1024 für die Schlüsselerzeugung und ML-DSA-87 für allgemeine digitale Signaturen. Für Käufer, die Bundesbehörden oder regulierten Einrichtungen unterliegen, müssen diese Post-Quanten-Algorithmen in einem FIPS 140-3- validierten kryptografischen Modul ausgeführt werden. FIPS 140-2-Zertifikate verlieren im September 2026 ihren Status als historische Zertifikate. Beruhigend ist, dass der Großteil Ihres Vermögens bereits ein geringes Risiko aufweist, wenn Sie die meisten Ihrer Identitäten kurzlebig gestaltet und verwaltet haben. So können Sie Ihre Aufmerksamkeit auf die wenigen Dinge konzentrieren, die besondere Unterstützung erfordern. Dies erfordert Planung und Ruhe – und hier macht die Unterstützung von Experten oft den entscheidenden Unterschied.
Wie Verschlüsselungsberatung helfen kann
Unser CBOM Secure- Tool von Encryption Consulting spielt eine Schlüsselrolle bei der Vorbereitung von Unternehmen. Anstatt mit Tabellenkalkulationen, manuellen OpenSSL-Ausgaben oder verstreuten Konfigurationsdateien zu arbeiten, bietet unser CBOM-Tool einen klaren Überblick über die Kryptonutzung in verschiedenen Umgebungen. Es zeigt, welche Algorithmen verwendet werden, welche Änderungen für Post-Quanten-Sicherheit erforderlich sind und ob Systeme die Sicherheitsziele erfüllen. Für Unternehmen, die sich auf Vorstandssitzungen, Architekturentscheidungen oder Compliance-Planungen vorbereiten, bietet unser Tool Klarheit und Schnelligkeit.
Unser CBOM Secure ist mehr als nur ein Reporting-Tool; es beschleunigt den gesamten Prozess. Es automatisiert Krypto-Inventare, prüft TLS-Konfigurationen, validiert Algorithmen und gleicht Richtlinien ab, sodass Teams ohne Rätselraten von der Analyse zur Umsetzung übergehen können. In zukünftigen Versionen plant Encryption Consulting die Integration automatisierter Korrekturen, Cloud-nativer Lösungen und die Durchsetzung von Richtlinien, um die Einhaltung der Sicherheitsstandards jederzeit zu gewährleisten.
Jetzt ist der ideale Zeitpunkt für den Einstieg: Testen Sie PQC in einer Testumgebung, erfassen Sie Ihre aktuelle Kryptonutzung und beginnen Sie mit der Erstellung interner Richtlinien. Wenn Ihr Unternehmen quantensichere Projekte pilotieren, Feedback geben oder an der Entwicklung neuer Funktionen mitwirken möchte, kontaktieren Sie uns von Encryption Consulting. Je früher die Teams beginnen, desto einfacher gestaltet sich die langfristige Zusammenarbeit.
Benötigt Ihr Unternehmen Unterstützung, strukturierte Analysen oder eine geführte Vorgehensweise? Encryption Consulting steht Ihnen mit Workshops, Beratung und Unterstützung bei der Implementierung unserer CBOM Secure zur Seite. Kontaktieren Sie uns noch heute, um den Übergang souverän zu gestalten, anstatt erst dann handeln zu müssen, wenn Sie dazu gezwungen sind.
Fazit
Maschinenidentitäten haben sich stillschweigend zum am stärksten gefährdeten Aspekt moderner Technologie entwickelt, und der gängige Rat, alle Zertifikate sofort zu ersetzen, verkennt das Risiko. Quantum bedroht die Identität auf zwei Ebenen, und die meisten Maschinenidentitäten sind kurzlebig genug, um sich auf der „langsamen“ Seite dieser Trennlinie zu befinden. Die Gefahr konzentriert sich auf wenige langlebige Ankerpunkte und auf die unkontrollierten Identitäten, die bereits heute Sicherheitslücken verursachen.
Der Weg nach vorn ist recht einfach. Gestalten Sie die meisten Identitäten ephemer und lassen Sie sie automatisch verwalten – was Zero Trust ohnehin schon nahelegt – und konzentrieren Sie sich dann auf die wenigen Identitäten, die wirklich dringend sind. Erstellen Sie zunächst eine Bestandsaufnahme , wo Ihre Identitäten und Ihre Kryptografie tatsächlich gespeichert sind, und lassen Sie sich von dieser Übersicht leiten.
