Zero Trust ist nicht mehr optional: Bundesauftragnehmer stehen vor einer Frist im Jahr 2026

Zero Trust wird zur Realität im Bundesauftragswesen

Zero Trust ist seit Jahren Teil der Diskussion über Cybersicherheit im öffentlichen Sektor. Was sich jetzt ändert, sind der Grad an praktischen Details, die Prüfung und die Dringlichkeit bei der Umsetzung. Für Bundesauftragnehmer, Organisationen der Verteidigungsindustrie und Teams, die sensible Regierungssysteme unterstützen, ist Zero Trust keine abstrakte Sicherheitsphilosophie mehr. Es wird zu einem Bestandteil der Art und Weise, wie Behörden Bereitschaft, Widerstandsfähigkeit und Risiko bewerten.

Im Januar 2026 veröffentlichte die National Security Agency neue Materialien zu Zero-Trust-Implementierungsleitlinien, darunter einen Einführungstext und Leitlinien für die Erkundungsphase, gefolgt von zusätzlichen Leitlinien zur Umsetzung der Phasen eins und zwei. Die Dokumente bauen auf früheren Vorgaben des Bundes von NIST, CISA, OMB und Rahmenwerken für die Cybersicherheit im Verteidigungsbereich auf. Ihr Zweck besteht nicht darin, ein Tool zu verkaufen oder ein eng gefasstes technisches Muster zu fördern. Sie bieten Systemverantwortlichen, Cybersicherheitsteams und Stakeholdern einen konkreteren Weg, um von der Zero-Trust-Theorie zur operativen Umsetzung zu gelangen.

Das ist wichtig, weil viele Organisationen die Lücke zwischen der Aussage, Zero Trust zu unterstützen, und dem praktischen Nachweis dafür noch immer unterschätzen. Ein moderner Identitätsanbieter, Multi-Faktor-Authentifizierung, Endpoint Detection oder ein neues Monitoring-Tool können Teil der Lösung sein. Nichts davon macht eine Organisation allein zu einem Zero-Trust-fähigen Unternehmen.

Was die Leitlinien des Bundes wirklich signalisieren

Die US-Bundesregierung bewegt sich mindestens seit Executive Order 14028 und dem OMB Memorandum M-22-09 in diese Richtung. Diese Vorgaben drängten zivile Behörden dazu, bis zum Ende des Haushaltsjahres 2024 konkrete Zero-Trust-Cybersicherheitsziele zu erreichen. Das Zero Trust Maturity Model der CISA, das erstmals 2021 zur öffentlichen Stellungnahme veröffentlicht und später aktualisiert wurde, bot Behörden eine Möglichkeit, Fortschritte in Kernbereichen wie Identität, Geräten, Netzwerken, Anwendungen, Workloads und Daten zu bewerten.

Die Zero-Trust-Implementierungsleitlinien der NSA aus dem Jahr 2026 fügen eine weitere Ebene hinzu: Sie helfen Organisationen, die tatsächliche Arbeit zu durchdenken, die für die Umsetzung der einzelnen Implementierungsphasen erforderlich ist. Dazu gehören Erkundungsarbeiten, grundlegende Aktivitäten und konkretere Implementierungsaufgaben in den Bereichen Identität, Geräte, Anwendungen, Daten, Netzwerke, Automatisierung und Transparenz.

Für Auftragnehmer ist die praktische Botschaft eindeutig. Behörden und Kunden aus dem Verteidigungsbereich erwarten zunehmend, dass Partner die Zero-Trust-Prinzipien verstehen, Zero-Trust-konforme Umgebungen unterstützen und so arbeiten, dass die Sicherheitslage der Regierung nicht geschwächt wird. Das bedeutet nicht, dass jeder Auftragnehmer mit exakt derselben Frist oder technischen Checkliste konfrontiert ist. Es bedeutet jedoch, dass die Richtung eindeutig ist.

Zero Trust ist keine Produktkategorie

Einer der einfachsten Fehler besteht darin, Zero Trust als etwas zu betrachten, das eine Organisation kaufen kann. Der Markt ist voll von Produkten, die Zero-Trust-Begriffe verwenden, und viele dieser Tools können nützlich sein. Zero Trust selbst ist jedoch eine Architektur und ein Betriebsmodell. Es verändert, wie Systeme Benutzern, Geräten, Diensten, Daten und Netzwerkverkehr vertrauen.

Traditionelle Sicherheitsmodelle stützten sich oft zu stark auf die Vorstellung eines vertrauenswürdigen internen Netzwerks. Sobald sich ein Benutzer oder System „innerhalb“ befand, war der Zugriff häufig umfassender als nötig. Zero Trust geht von einer anderen Annahme aus: Kein Benutzer, kein Gerät, kein Workload und keine Verbindung sollte automatisch als vertrauenswürdig gelten. Der Zugriff sollte explizit, begrenzt, kontinuierlich bewertet und an Richtlinien gebunden sein.

Das klingt einfach, bis es auf die reale Infrastruktur trifft. Altsysteme unterstützen möglicherweise keine modernen Identitätsmuster. Interne Anwendungen können auf Annahmen aufbauen, die inzwischen nicht mehr gelten. Daten können ohne klare Klassifizierung zwischen Tools verschoben werden. Netzwerksegmente spiegeln möglicherweise alte Hosting-Entscheidungen statt des tatsächlichen Geschäftsrisikos wider. Protokolle können vorhanden sein, aber nicht in einer Form, die sinnvolle Überwachung oder Reaktion ermöglicht.

Deshalb wird Zero-Trust-Arbeit sehr schnell zu Infrastrukturarbeit.

Die Perspektive der Auftragnehmer

Für Bundesauftragnehmer gehen die Auswirkungen über die interne Sicherheitshygiene hinaus. Die Zero-Trust-Bereitschaft beeinflusst zunehmend, wie glaubwürdig eine Organisation als Partner der Regierung wirkt. Behörden wünschen sich Anbieter und Implementierungspartner, die Identität, Zugriffskontrolle, Segmentierung, Überwachung, sicheren Umgang mit Daten und operative Widerstandsfähigkeit verstehen. Ein Auftragnehmer, der seinen Ansatz in diesen Bereichen nicht erklären kann, könnte größere Schwierigkeiten haben, Aufträge für sensible Systeme oder regulierte Umgebungen zu gewinnen.

Aktuelle Branchenanalysen, darunter ein von Cabrillo Club beschriebenes anonymisiertes 26-wöchiges Rollout eines Auftragnehmers, unterstreichen einen wichtigen Punkt: Selbst eine anfängliche Zero-Trust-Implementierung kann Monate dauern, wenn die Organisation bereits teilweise vorbereitet ist. Die Arbeit umfasst häufig Erkundung, Richtlinienentscheidungen, Änderungen an der Identität, Verbesserungen an Endgeräten, Netzwerksegmentierung, Überwachung, Governance sowie die Kommunikation zwischen technischen und geschäftlichen Teams.

Dieser Zeitrahmen sollte Organisationen nicht vom Beginn abhalten. Er sollte das Gegenteil bewirken. Wenn die Arbeit Monate dauert, ist es keine gute Strategie, auf eine Vertragsanforderung, einen Prüfungsbefund oder eine dringende Anfrage einer Behörde zu warten.

Die betrieblichen Auswirkungen

Ein ernsthaftes Zero-Trust-Vorhaben berührt normalerweise mehrere Teile der Technologieumgebung:

• Identitäts- und Zugriffsmanagement, einschließlich stärkerer Authentifizierung, Rollendesign, bedingtem Zugriff und Berechtigungen nach dem Prinzip der geringsten Privilegien
• Geräte- und Endpoint-Sicherheitsstatus, einschließlich Transparenz darüber, was eine Verbindung herstellt, ob es verwaltet wird und ob es die Sicherheitsanforderungen erfüllt
• Netzwerksegmentierung, einschließlich Möglichkeiten, den Schadensradius einer Kompromittierung zu begrenzen
• Zugriff auf Anwendungen und Workloads, einschließlich der Kommunikation zwischen Diensten und richtliniengesteuerter Autorisierung
• Datenklassifizierung und -schutz, einschließlich Kontrollen, die sensiblen Daten folgen, statt sich nur darauf zu verlassen, wo die Daten gespeichert sind
• Überwachung und Analytik, einschließlich Transparenz über Zugriffsmuster, Anomalien und verdächtiges Verhalten
• Automatisierung und Reaktion, einschließlich Workflows, die Teams dabei unterstützen, schnell zu handeln, wenn sich das Risiko verändert

Die konkrete Umsetzung wird je nach Organisation unterschiedlich ausfallen. Ein kleiner Bundesauftragnehmer mit einer cloudlastigen Umgebung wird nicht denselben Weg einschlagen wie ein großer Verteidigungszulieferer mit Altsystemen, mehreren Netzwerken und komplexen Verpflichtungen zur gemeinsamen Datennutzung. Die Planungsdisziplin ist jedoch ähnlich: den aktuellen Zustand verstehen, die größten Risikolücken erfassen, die Arbeit priorisieren und nicht so tun, als würden einige voneinander unabhängige Tool-Käufe eine Architektur ergeben.

Wo Implementierungen scheitern

Zero-Trust-Projekte geraten meist aus vorhersehbaren Gründen ins Stocken. Manchmal beginnt die Organisation mit Produkten, bevor sie die Architektur verstanden hat. Manchmal definieren Sicherheitsteams Kontrollen, ohne genügend Rückmeldungen von den Personen einzuholen, die die Systeme täglich betreiben. Manchmal wird das Vorhaben zu einer Compliance-Übung, bei der es darum geht, Nachweise zu erstellen, statt reale Risiken zu reduzieren.

Das häufigste Scheitermuster ist Fragmentierung. Ein Team fügt einen neuen Identitätsanbieter hinzu. Ein anderes Team ergänzt Endpoint-Tools. Ein weiteres Team verbessert die Protokollierung. Noch ein anderes Team beginnt ein Segmentierungsprojekt. Jede Maßnahme kann für sich sinnvoll sein, doch ohne ein kohärentes Design endet die Organisation mit Kontrollen, die schwer zu betreiben, schwer zu auditieren und schwer zu erklären sind.

Das ist keine Zero-Trust-Strategie. Es ist eine Sammlung von Sicherheitsverbesserungen mit einem Zero-Trust-Label obendrauf.

Wie Ridiculous Engineering die Zero-Trust-Bereitschaft betrachtet

Bei Ridiculous Engineering betrachten wir Zero Trust als Architektur- und Implementierungsproblem, nicht als Checklistenübung. Das Ziel besteht nicht darin, ein Diagramm modern aussehen zu lassen oder ein weiteres Produkt in eine bereits komplizierte Umgebung einzubauen. Ziel ist es, Organisationen dabei zu unterstützen, praktische Entscheidungen über Identität, Zugriff, Datenbewegungen, Infrastrukturgrenzen, Überwachung und operative Workflows zu treffen.

Diese Arbeit beginnt mit einer ehrlichen Bewertung des aktuellen Zustands. Welche Systeme sind am wichtigsten? Wo befinden sich sensible Daten? Wie authentifizieren sich Benutzer und Dienste? Welche Anwendungen sind noch von implizitem Vertrauen abhängig? Welche Protokolle sind nützlich, und welche existieren nur, weil ein Tool sie erzeugt? Wo würde sich ein kompromittiertes System zu leicht ausbreiten? Welche Kontrollen würden bei schlechter Umsetzung zu unzumutbaren Reibungsverlusten führen?

Darauf aufbauend können Organisationen eine priorisierte Roadmap erstellen. Nicht alles muss gleichzeitig geschehen. Tatsächlich führt der Versuch, alles auf einmal zu erledigen, oft dazu, dass solche Vorhaben an Schwung verlieren. Der bessere Ansatz besteht darin, die risikoreichsten Lücken zu ermitteln, die Arbeit zu staffeln und Verbesserungen zu entwickeln, die die Umgebung zugleich sicherer und besser betreibbar machen.

Für viele Auftragnehmer kann das bedeuten, zunächst Identität und Zugriff zu verschärfen, die Transparenz über Endgeräte zu verbessern und anschließend Segmentierung, Datenkontrollen und Monitoring-Verbesserungen anzugehen. Für andere kann der richtige erste Schritt in der Modernisierung von Anwendungen, der Bereinigung der Cloud-Architektur, dem Richtliniendesign oder der besseren Beweissammlung für Audits und Kundenprüfungen liegen.

Der richtige Zeitpunkt für den Start ist, bevor es dringend wird

Zero Trust ist keine neue Idee, doch die Erwartungen an ihre Umsetzung werden konkreter. Bundesbehörden stehen unter Druck, ihre eigene Sicherheitslage zu verbessern, und dieser Druck überträgt sich ganz natürlich auf das Auftragnehmer-Ökosystem. Auftragnehmer, die staatliche Systeme unterstützen, sensible Daten verarbeiten oder in Bundesumgebungen integrieren, sollten mit mehr Fragen dazu rechnen, wie ihre Systeme Daten authentifizieren, autorisieren, überwachen, segmentieren und schützen.

Die Kosten einer Verzögerung beschränken sich nicht auf Compliance-Risiken. Sie umfassen auch die betriebliche Belastung, die entsteht, wenn Sicherheit unter Zeitdruck nachgerüstet werden muss. Wenn Zero-Trust-Arbeit überstürzt erfolgt, kaufen Organisationen häufig zuerst Werkzeuge, bevor sie das Problem verstehen, erstellen Richtlinien, die Benutzer frustrieren, und entwickeln Kontrollen, die schwer zu warten sind. Wird die Arbeit geplant, kann sie die Sicherheit verbessern und zugleich Teile der Umgebung vereinfachen.

Wenn Ihre Organisation verstehen muss, wo sie steht, sich auf Cybersicherheitsanforderungen des Bundes vorbereiten oder Zero-Trust-Leitlinien in eine praktische Umsetzungs-Roadmap übertragen möchte, kann Ridiculous Engineering helfen. Wir unterstützen Kunden dabei, den aktuellen Stand zu bewerten, realistische Prioritäten zu ermitteln, die Architektur zu entwerfen und von Richtlinientexten zu Systemen überzugehen, die tatsächlich betrieben werden können.

Zero Trust bedeutet nicht, einem Schlagwort hinterherzulaufen. Es geht darum, Annahmen an den Stellen zu reduzieren, an denen sie Risiken verursachen. Für Auftragnehmer des Bundes wird dies zunehmend zu einem Bestandteil davon, ein glaubwürdiger und zuverlässiger Technologiepartner zu sein.

Quellen und weiterführende Literatur: NSA: Erste einer Reihe von Leitlinien zur Zero-Trust-Implementierung, NSA: Leitlinien zur Zero-Trust-Implementierung, Phase eins und Phase zwei, CISA: Reifegradmodell für Zero Trust, OMB-Memorandum M-22-09, Cabrillo Club: Zero-Trust-Roadmap für Auftragnehmer des Bundes