Zero Trust und NIS2: Null Treffer im BSIG — brauchen Sie wirklich eine neue Zugangsarchitektur?

Suchen Sie den Begriff „Zero Trust“ im BSI-Gesetz, finden Sie ihn nicht. Null Treffer, im gesamten Gesetzestext [3]. In der deutschen Amtsblattfassung der NIS-2-Richtlinie steht er genau einmal – in Erwägungsgrund 89, also in der nicht verbindlichen Begründung [1]. Verbindlich vorgeschrieben ist er an einer einzigen Stelle des gesamten NIS2-Regelwerks – Richtlinie, Durchführungsverordnung und BSIG zusammengenommen: in Nummer 6.2.2 Buchstabe b des Anhangs der Durchführungsverordnung (EU) 2024/2690 [2]. Dort heißt er allerdings nicht „Zero Trust“, sondern Null-Vertrauen-Architekturen – weshalb genau die Verantwortlichen, die im Gesetzestext nach dem Marktbegriff suchen, die einzige bindende Fundstelle systematisch übersehen.

Das ist keine Wortklauberei. Wo eine Anforderung im Regelwerk steht, entscheidet darüber, wer sie erfüllen muss, welche Nachweise die Aufsicht verlangen kann und ob ein siebenstelliges Architekturprojekt eine Pflicht oder eine Entscheidung ist. Dieser Leitfaden ordnet jede Fundstelle ihrem Rechtsstatus zu, zeigt, welche Pflichten aus § 30 BSIG eine Zero-Trust-Architektur tatsächlich bedient – und welche sie nachweislich nicht bedient, weil das BSI selbst darauf hinweist.

Wo „Zero Trust“ im deutschen NIS2-Recht wirklich steht

Im Klartext: Vier Fundstellen, drei davon unverbindlich. Die eine verbindliche gilt nur für elf Kategorien digitaler Diensteanbieter – und sie regelt die Entwicklung von Systemen, nicht den Netzzugang.

Die folgende Tabelle ist das Ergebnis einer Volltextauswertung der amtlichen deutschen Fassungen (Stand 20.09.2026). Jede Zeile lässt sich in wenigen Minuten nachprüfen.

Fundstelle	Wortlaut	Rechtsstatus
NIS-2-Richtlinie (EU) 2022/2555, Erwägungsgrund 89 [1]	„Zero-Trust-Grundsätze“ als Beispiel grundlegender Cyberhygiene; Modalverb „sollten“	Erwägungsgrund – Auslegungshilfe, keine Pflicht
DVO (EU) 2024/2690, Erwägungsgrund 20 [2]	wortgleiche Cyberhygiene-Aufzählung, bezogen auf Art. 21 Abs. 2 Buchst. g	Erwägungsgrund – keine Pflicht
DVO (EU) 2024/2690, Anhang Nr. 6.2.2 Buchst. b [2]	„Null-Vertrauen-Architekturen“ als Beispiel für Grundsätze sicherer Systementwicklung	Verbindlich – aber nur für die in Art. 1 DVO genannten Einrichtungen
ENISA-Leitfaden zur Umsetzung, Fußnote 62 und Leitlinie zu 6.7.2 [6]	„Where appropriate, consider zero-trust network access“	Leitlinie einer EU-Agentur – ausdrücklich keine Verordnungsvorschrift
BSI-Gesetz (BSIG), Fassung vom 02.12.2025 [3]	kein Treffer – weder „Zero Trust“ noch „Null-Vertrauen“	Nicht erwähnt

Der Befund zum BSIG hat eine zweite, praktisch wichtigere Seite: Auch das Wort Segmentierung kommt im BSIG kein einziges Mal vor. Die in deutschen Fachbeiträgen verbreitete Formulierung, § 30 BSIG verlange „ausdrücklich Zugriffskontrolle und Netzwerksegmentierung“, trifft nur zur Hälfte zu. Die Zugriffskontrolle steht dort tatsächlich (Abs. 2 Nr. 9). Die Segmentierung steht dort nicht – sie lässt sich allenfalls aus der allgemeinen Angemessenheitspflicht des Abs. 1 ableiten. Wie weit diese Ableitung trägt, behandelt unser Leitfaden zur NIS2-Netzwerksicherheit und Segmentierung.

Gilt die Durchführungsverordnung für Ihr Unternehmen?

Im Klartext: Für die meisten deutschen Unternehmen lautet die Antwort Nein. Dann ist die DVO kein Pflichtenheft, sondern der beste verfügbare Maßstab für die eigene, allgemeiner formulierte Pflicht.

Artikel 1 der DVO zählt ihren Anwendungsbereich abschließend auf: DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste, Anbieter verwalteter Sicherheitsdienste, Anbieter von Online-Marktplätzen, Online-Suchmaschinen, Plattformen für Dienste sozialer Netzwerke und Vertrauensdiensteanbieter [2]. Der deutsche Gesetzgeber hat diesen Vorrang ausdrücklich nachvollzogen: Nach § 30 Abs. 3 BSIG hat der Durchführungsrechtsakt „für die vorgenannten Einrichtungsarten Vorrang“ [3].

Daraus ergeben sich zwei Gruppen mit deutlich unterschiedlicher Beweislast:

Ihre Einrichtung	Was rechtlich gilt	Was das für Zero Trust bedeutet
Eine der elf in Art. 1 DVO genannten Anbieterkategorien	Der DVO-Anhang gilt unmittelbar, Klausel für Klausel – einschließlich Nr. 6.2.2 Buchst. b	Die Entwurfsgrundsätze der Nr. 6.2.2 sind Pflicht. Welche Grundsätze Sie wählen, bleibt Ihre Entscheidung.
Alle übrigen besonders wichtigen und wichtigen Einrichtungen	Nur § 30 BSIG: geeignete, verhältnismäßige und wirksame Maßnahmen, konkretisiert durch die zehn Nummern des Abs. 2	Zero Trust ist nirgends vorgeschrieben. Der DVO-Anhang ist der präziseste verfügbare Maßstab dafür, was „angemessen“ bedeutet.

Ein Fehler, der uns in Erstgesprächen regelmäßig begegnet, ist die Verwechslung dieser beiden Ebenen – und zwar in beide Richtungen: Wer die DVO pauschal auf ein Maschinenbauunternehmen anwendet, finanziert ein Kontrollniveau, das ihn rechtlich nicht bindet. Wer sie ignoriert, weil „das nur für Cloud-Anbieter gilt“, verzichtet auf den einzigen Maßstab, mit dem sich gegenüber der Aufsicht belegen lässt, dass die eigene Auslegung von „angemessen“ nicht willkürlich ist. Details zum Anwendungsbereich klärt unser Beitrag zur NIS2-Durchführungsverordnung.

Die eine verbindliche Stelle – und warum sie nicht dort steht, wo alle suchen

Nummer 6.2.2 Buchstabe b des DVO-Anhangs lautet im amtlichen deutschen Wortlaut: Die betreffenden Einrichtungen müssen „bei allen Tätigkeiten zur Entwicklung von Informationssystemen bestimmte Grundsätze für den Aufbau sicherer Systeme und für ein sicheres Programmieren wie etwa die Förderung von konzeptintegrierter Cybersicherheit und Null-Vertrauen-Architekturen anwenden“ [2].

Drei Details dieser Klausel entscheiden darüber, was sie tatsächlich verlangt.

Erstens: Sie steht im falschen Abschnitt – gemessen daran, wo der Markt sie vermutet. Nummer 6.2 heißt „Sicherer Entwicklungszyklus“ und dient der Umsetzung von Art. 21 Abs. 2 Buchst. e der Richtlinie, deutsch § 30 Abs. 2 Nr. 5 BSIG: Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung [2][3]. Die Zugriffskontrolle regelt dagegen Abschnitt 11 des Anhangs – und dort taucht der Begriff kein einziges Mal auf. Die einzige verbindliche Zero-Trust-Erwähnung im NIS2-Regelwerk ist damit eine Entwurfspflicht, keine Netzwerkbeschaffungspflicht. Praktische Folge in beide Richtungen: Der Kauf einer ZTNA-Plattform erfüllt Nummer 6.2.2 Buchstabe b nicht, weil die Klausel eine Vorgehensweise beim Systementwurf verlangt. Und umgekehrt zwingt die Klausel niemanden, eine ZTNA-Plattform zu kaufen. Wie diese Entwurfspflicht praktisch aussieht, vertieft unser Beitrag zur sicheren Entwicklung nach NIS2.

Zweitens: „wie etwa“ ist eine Beispielsaufzählung, keine Auswahl aus einer Liste. Verbindlich ist, dass überhaupt anerkannte Grundsätze sicherer Systementwicklung angewandt werden. Null-Vertrauen-Architekturen und Security by Design sind die beiden Beispiele, die der Verordnungsgeber nennt. Eine Einrichtung, die stattdessen nachweisbar nach einem anderen anerkannten Grundsatzkatalog entwickelt, verstößt nicht gegen den Buchstaben der Klausel – sie trägt aber die Begründungslast dafür, dass ihr Katalog gleichwertig ist.

Drittens: Die Klausel trägt keinen Angemessenheitsvorbehalt. Artikel 2 Abs. 2 Unterabsatz 2 der DVO erlaubt betroffenen Einrichtungen, eine Anforderung nicht anzuwenden und ihre Begründung stattdessen „in verständlicher Weise“ zu dokumentieren – aber ausdrücklich nur dort, wo der Anhang selbst „soweit angemessen, anwendbar oder durchführbar“ sagt [2]. Nummer 6.2.2 Buchstabe b sagt das nicht; sie sagt schlicht „müssen … anwenden“. Dieser Ausweg steht für sie also nicht offen. Die Flexibilität liegt hier allein im Wort „wie etwa“. Zum Vergleich: Die Multi-Faktor-Authentifizierung in Nummer 11.7.1 ist doppelt relativiert – „soweit angemessen, im Einklang mit der Klassifizierung der Anlage“ – und erreichbar über genau diesen Dokumentationsweg.

Was das BSI über Zero Trust sagt – und warum das mit § 30 Abs. 1 BSIG kollidiert

Im Klartext: Die deutsche Fachbehörde schreibt, dass Zero Trust zwei der drei Schutzziele stärkt und das dritte bewusst opfert. Genau dieses dritte nennt § 30 Abs. 1 BSIG an erster Stelle.

Das BSI hat 2023 ein eigenes Positionspapier zu Zero Trust veröffentlicht [4]. Die zentrale Passage der Definition lautet wörtlich: „Durch diese Designprinzipien und mit Hilfe von kontinuierlicher Vertrauensbetrachtung wird das Sicherheitsrisiko für Vertraulichkeit und Integrität minimiert. Einschränkungen bei der Verfügbarkeit werden dabei in Kauf genommen.“ Und unter den Kernbotschaften: „Die Schutzwirkung bezieht sich vorrangig auf die Schutzziele Integrität und Vertraulichkeit und nicht Verfügbarkeit.“

§ 30 Abs. 1 Satz 1 BSIG verpflichtet Einrichtungen dagegen zu Maßnahmen, „um Störungen der Verfügbarkeit, Integrität und Vertraulichkeit der informationstechnischen Systeme, Komponenten und Prozesse … zu vermeiden“ [3]. Die Verfügbarkeit steht dort nicht als Nebenbedingung, sondern als erstes der drei Schutzziele.

Der Mechanismus dahinter ist kein theoretisches Risiko, sondern eine direkte Folge der Architektur. In einer Zero-Trust-Architektur wird jede Verbindung einzeln autorisiert, bevor sie zustande kommt. Die Komponente, die diese Entscheidung trifft, liegt damit im Pfad praktisch jedes Zugriffs. NIST beschreibt die Konsequenz in SP 800-207, Abschnitt 5.2, unmissverständlich: „An operational error could prevent an entire enterprise from functioning if the policy engine or policy administrator component becomes inaccessible from the network“ [5]. Ein fehlerhaft ausgerollter Richtliniensatz wirkt dann nicht auf ein System, sondern auf alle gleichzeitig – und der Weg zur Korrektur führt durch dieselbe Komponente, die gerade blockiert.

Das BSI benennt einen zweiten, weniger offensichtlichen Pfad zum selben Ergebnis: „Ist die Bestandsaufnahme der eigenen, bestehenden IT-Infrastruktur unvollständig, führt diese unvollständige Sichtbarkeit mit hoher Wahrscheinlichkeit mindestens zu Verfügbarkeitsproblemen“ [4]. Jede Kommunikationsbeziehung, die im Inventar fehlt, ist in einer Default-Deny-Architektur eine Beziehung, die nach dem Rollout nicht mehr funktioniert.

Daraus folgt keine Warnung vor Zero Trust, sondern eine konkrete Planungsauflage: Jeder Durchsetzungsschritt gehört mit der Pflicht aus § 30 Abs. 2 Nr. 3 BSIG – Aufrechterhaltung des Betriebs – zusammen geplant. Praktisch heißt das: ein dokumentierter Notfallzugang, der unabhängig von der Richtlinienkomponente funktioniert; ein Rollback-Pfad für jede Richtlinienänderung; und eine Beobachtungsphase im Protokollier-, nicht im Blockiermodus, bevor eine Regel scharf geschaltet wird. Wer diese drei Punkte dokumentiert, hat gegenüber der Aufsicht zugleich belegt, dass der Zielkonflikt zwischen den Schutzzielen bewusst behandelt und nicht übersehen wurde.

Welche §-30-Pflichten Zero Trust tatsächlich bedient

Zero Trust ist kein Maßnahmenpaket, das sich gegen § 30 Abs. 2 BSIG abhaken ließe. Es deckt einzelne Nummern weitgehend ab, andere teilweise, die meisten gar nicht. Die folgende Zuordnung ist eine eigene Auswertung entlang der zehn Nummern des Absatzes und der zugehörigen Anhangsabschnitte der DVO [2][3].

§ 30 Abs. 2 BSIG	DVO-Anhang	Beitrag einer Zero-Trust-Architektur
Nr. 9 – Konzepte für Personalsicherheit, Zugriffskontrolle, IKT-Verwaltung	Abschnitte 10 bis 12, v. a. Nr. 11.1 bis 11.5	Hoch. Need-to-know und Aufgabentrennung (11.2.2 Buchst. a), dedizierte Administrationskonten (11.3.2), eindeutige Identitäten (11.5.2) sind Zero-Trust-Kernprinzipien. Das Konzept selbst ersetzt die Technik jedoch nicht.
Nr. 10 – MFA oder kontinuierliche Authentifizierung	Nr. 11.6, 11.7	Hoch. Kontinuierliche Authentifizierung ist die Zero-Trust-Auslegung dieser Pflicht. Achtung: 11.6.2 Buchst. a und 11.7.2 knüpfen die Authentifizierungsstärke an die Klassifizierung der Anlage – und genau dieses Klassifizierungsschema verlangt Abschnitt 12.1. Ohne es ist eine MFA-Richtlinie nicht begründbar.
Nr. 5 – Erwerb, Entwicklung und Wartung	Abschnitt 6, v. a. Nr. 6.1 und 6.2	Teilweise, und dies ist der einzige verbindliche Ankerpunkt (6.2.2 Buchst. b). Er betrifft die Entwurfs- und Beschaffungsphase, nicht den Betrieb.
Nr. 3 – Aufrechterhaltung des Betriebs	Abschnitt 4	Keiner – tendenziell gegenläufig. Siehe den vorigen Abschnitt.
Nr. 1, 2, 4, 6, 7, 8	Abschnitte 1 und 2, 3, 5, 7, 8, 9	Keiner. Risikoanalyse, Vorfallbehandlung, Lieferkette, Wirksamkeitsbewertung, Schulung und Kryptokonzepte bleiben eigenständige Pflichten [3].

Ein Zero-Trust-Programm bedient damit im besten Fall zwei bis drei der zehn Maßnahmenbereiche. Es als „NIS2-Umsetzung“ zu verkaufen oder einzukaufen, lässt sieben Bereiche offen – beginnend mit der Risikoanalyse, die nach § 30 Abs. 2 Nr. 1 BSIG [3] ohnehin logisch am Anfang steht, weil alle übrigen Maßnahmen ihre Angemessenheit aus ihr ableiten.

Eine weitere Einschränkung betrifft den Umfang dessen, was marktgängige Zero-Trust-Produkte belegen. Die ENISA beschreibt in ihrem Umsetzungsleitfaden – in Fußnote 62, also in ihrer eigenen Leitlinie und nicht im Verordnungstext – die Kernkomponenten von Zero Trust: Identitäts- und Zugangsmanagement mit MFA, Gerätesicherheit mit EDR, Mikrosegmentierung, ZTNA als VPN-Ersatz, CASB und DLP sowie fortlaufende Überwachung per SIEM [6]. Jede dieser Komponenten betrifft einen Menschen oder ein Endgerät, das auf ein Unternehmensnetz zugreift. Die Kommunikation zwischen Diensten im Rechenzentrum – der Ost-West-Verkehr, den Nummer 6.7.2 Buchstabe i der DVO mit „vertrauenswürdigen Kanälen“ und „sicherer Identifizierung ihrer Endpunkte“ adressiert – kommt in dieser Aufzählung nicht vor. Eine ZTNA-Plattform belegt also den Zugriff von Beschäftigten und Dienstleistern. Über die interne Dienst-zu-Dienst-Kommunikation belegt sie nichts.

Entscheidungshilfe: Wann sich eine neue Zugangsarchitektur rechnet

§ 30 Abs. 1 Satz 2 BSIG nennt die Prüfkriterien für Verhältnismäßigkeit ausdrücklich: Risikoexposition, Größe der Einrichtung, Umsetzungskosten sowie Eintrittswahrscheinlichkeit und Schwere von Sicherheitsvorfällen [3]. Die Kosten sind also kein Gegenargument gegen die Pflicht, sondern ein gesetzlich vorgesehener Teil der Abwägung – wenn die Abwägung dokumentiert wird.

Das BSI ist bei der Aufwandsfrage ungewöhnlich deutlich. Kernbotschaft: „Eine ganzheitliche, wirksame Umsetzung von Zero Trust-Prinzipien ist ein langfristiges Vorhaben und erfordert ebenso hohen wie dauerhaften finanziellen sowie personellen Ressourcenaufwand.“ Zur Produktfrage: Das Paradigma sei „kein definierter Standard, der sich mit Hilfe von einzelnen Produkten vollumfänglich realisieren ließe“; die unter dem Label beworbenen Produkte stellten „lediglich einen Teil der Funktionalität“ bereit, und eine ganzheitliche Umsetzung in allen Bereichen der IT-Infrastruktur sei „derzeit noch unrealistisch“ [4]. Vor der Budgetfreigabe ist die entscheidende Frage deshalb nicht, welches Produkt, sondern ob die Voraussetzungen erfüllt sind: Das BSI nennt in Kapitel 7.1 vier Schritte, die der Technikauswahl vorausgehen müssen – zentrale Geschäftsprozesse identifizieren und priorisieren, beteiligte Organisationseinheiten bestimmen, rechtliche Vorgaben erheben und die beteiligten Ressourcen ableiten. Fehlen diese, ist die Wahrscheinlichkeit hoch, dass „Integrationsansätze scheitern bzw. die IT-Sicherheit ggf. sogar nachteilig“ beeinflusst wird [4].

Daraus ergibt sich eine belastbare Entscheidungslogik:

Ausgangslage	Empfohlener Weg	Aufwand
Kein vollständiges Asset-Inventar, keine Anlagenklassifizierung nach Nr. 12.1	Kein Zero-Trust-Projekt. Erst Inventar und Klassifizierung – sie sind ohnehin Voraussetzung für die MFA-Begründung nach Nr. 11.7	Mittel
Inventar vorhanden, klassische Perimeterarchitektur, geringe Cloud- und Fernzugriffsanteile	Gezielte Einzelmaßnahmen statt Architekturwechsel: MFA nach Klassifizierung, dedizierte Administrationskonten (Nr. 11.3.2), Fernzugriffskontrollen (Nr. 6.7.2 Buchst. d)	Niedrig bis mittel
Hoher Anteil Cloud, Fernzugriff und Dienstleisterzugriff; Perimeter faktisch aufgelöst	Schrittweise Zero-Trust-Einführung, beginnend beim kritischsten Geschäftsprozess, jeweils erst im Protokollier-, dann im Blockiermodus	Hoch
Einrichtung fällt unter Art. 1 DVO	Nr. 6.2.2 Buchst. b ist Pflicht – aber als dokumentierter Entwurfsgrundsatz im Entwicklungs- und Beschaffungsprozess, nicht als Produktkauf	Mittel

Je nach Rolle führt dieselbe Ausgangslage zu unterschiedlichen nächsten Schritten:

Rolle	Nächster Schritt
Geschäftsleitung	Keine Budgetfreigabe ohne Antwort auf zwei Fragen: Fallen wir unter Art. 1 DVO? Und liegen die vier BSI-Voraussetzungen vor? § 38 Abs. 1 BSIG adressiert die Umsetzung und deren Überwachung ausdrücklich an die Geschäftsleitung; Abs. 2 knüpft daran die Haftung für schuldhaft verursachte Schäden [3] – siehe Managementhaftung nach NIS2.
CISO / IT-Leitung	Anlagenklassifizierung nach Nr. 12.1 vor jeder MFA- oder Richtlinienentscheidung. Danach Zuordnung der geplanten Maßnahmen zu den Nummern 11.1 bis 11.7 – nicht zu Produktkategorien.
Compliance / ISB	Die Begründung dokumentieren, nicht nur die Maßnahme: welches Schutzziel jede Maßnahme adressiert, und wie der Verfügbarkeitskonflikt aus § 30 Abs. 1 behandelt wurde.

Was Prüfer tatsächlich sehen wollen

§ 30 Abs. 1 Satz 3 BSIG verlangt, die Einhaltung der Pflicht zu dokumentieren [3]. Da das Gesetz keine Technologie vorschreibt, entscheidet im Zweifel die Dokumentation darüber, ob eine Architekturentscheidung als angemessen gilt – eine Zero-Trust-Plattform im Einsatz ist für sich genommen kein Nachweis.

Für den Bereich Zugriffskontrolle sind das die Belege, die sich aus dem Anhang unmittelbar ableiten lassen:

• das dokumentierte Konzept für die logische und physische Zugriffskontrolle (Nr. 11.1.1), das ausdrücklich auch den Zugang von Systemen erfasst und nicht nur von Personen (Nr. 11.1.2 Buchst. b)
• das Register der gewährten Zugangs- und Zugriffsrechte (Nr. 11.2.2 Buchst. e)
• die Ergebnisse der Rechteüberprüfung einschließlich der vorgenommenen Änderungen – Nr. 11.2.3 und Nr. 11.3.3 verlangen ausdrücklich die Dokumentation der Ergebnisse, nicht nur die Durchführung
• die Anlagenklassifizierung (Nr. 12.1), auf die sich die gewählte Authentifizierungsstärke stützt
• bei jeder Klausel mit dem Vorbehalt „soweit angemessen“, die Sie nicht umsetzen: die dokumentierte Begründung nach Art. 2 Abs. 2 Unterabs. 2 DVO – für nicht relativierte Klauseln wie Nr. 6.2.2 Buchst. b existiert dieser Weg nicht

Wann diese Unterlagen abgefragt werden können, unterscheidet sich je nach Einrichtungsart deutlich. Nach § 61 Abs. 1 BSIG kann das BSI gegenüber einzelnen besonders wichtigen Einrichtungen Audits, Prüfungen oder Zertifizierungen anordnen – die Norm nennt dafür keinen Anlass als Voraussetzung; nach Abs. 3 kann es gegenüber weiteren besonders wichtigen Einrichtungen Nachweise verlangen, allerdings erst „frühestens drei Jahre nach Inkrafttreten dieses Gesetzes“, also ab Dezember 2028. Für wichtige Einrichtungen setzt § 62 BSIG dagegen voraus, dass „Tatsachen die Annahme rechtfertigen“, eine Verpflichtung werde nicht oder nicht richtig umgesetzt [3]. Die Unterlagen erst bei einer Anfrage zusammenzustellen, ist deshalb vor allem für besonders wichtige Einrichtungen riskant. Welche Bußgeldrahmen im Verstoßfall gelten, behandelt unsere Übersicht zur NIS2-Bußgeldstaffel.

Die Personal- und Berechtigungsseite dieser Nachweise – Joiner-Mover-Leaver-Prozesse, rollenbasierte Rechtevergabe und die Pflichten aus DVO-Abschnitt 10 – behandelt unser Leitfaden zur NIS2-Zugangssteuerung und Personalsicherheit. Wie die kryptografische Absicherung der Kanäle einzuordnen ist, die Nummer 11.4.2 Buchstabe c und Nummer 6.7.2 Buchstabe i verlangen, klärt der Beitrag zur Verschlüsselung nach Art. 21 Abs. 2 Buchst. h. Die konkreten Anforderungen an Faktoren und Ausnahmen finden Sie unter MFA-Anforderungen nach NIS2.

Häufig gestellte Fragen

Ist Zero Trust nach NIS2 Pflicht?
Nein, mit einer eng begrenzten Ausnahme. Im BSIG kommt der Begriff nicht vor; in der Richtlinie nur in Erwägungsgrund 89 und damit unverbindlich. Verbindlich ist allein Nummer 6.2.2 Buchstabe b des DVO-Anhangs – und nur für die in Art. 1 DVO aufgezählten Anbieterkategorien, dort als Grundsatz der Systementwicklung [1][2][3].

Warum finde ich „Zero Trust“ nicht im deutschen Verordnungstext?
Weil die amtliche deutsche Fassung an der verbindlichen Stelle „Null-Vertrauen-Architekturen“ schreibt. Der Marktbegriff erscheint auf Deutsch nur in den Erwägungsgründen. Wer den Volltext nach „Zero Trust“ durchsucht, findet deshalb ausgerechnet die bindende Klausel nicht [2].

Erfüllt der Kauf einer ZTNA-Plattform § 30 Abs. 2 Nr. 9 und Nr. 10 BSIG?
Nicht allein. Nr. 9 verlangt ein Konzept, Nr. 10 eine an der Anlagenklassifizierung ausgerichtete Authentifizierung. Ein Produkt kann beides unterstützen, ersetzt aber weder das dokumentierte Konzept noch die Klassifizierung, aus der sich die Authentifizierungsstärke begründet [2][3].

Schadet Zero Trust der Verfügbarkeit?
Das BSI formuliert es als bewusste Abwägung: Die Schutzwirkung beziehe sich vorrangig auf Integrität und Vertraulichkeit, Einschränkungen bei der Verfügbarkeit würden „in Kauf genommen“ [4]. Da § 30 Abs. 1 BSIG die Verfügbarkeit ausdrücklich nennt, gehört dieser Zielkonflikt behandelt und dokumentiert – nicht vermieden.

Wir sind ein mittelständischer Zulieferer. Womit fangen wir an?
Mit dem Asset-Inventar und der Anlagenklassifizierung. Beide sind Voraussetzung für jede begründbare MFA- und Zugriffsentscheidung und zugleich der erste der vier vom BSI genannten Vorbereitungsschritte. Ob Sie danach eine Zero-Trust-Architektur brauchen, lässt sich erst auf dieser Grundlage beantworten [4].

Dieser Artikel bietet ausschließlich allgemeine Informationen und stellt keine Rechts- oder Regulierungsberatung dar. Die Anforderungen können je nach Rechtsraum und Unternehmensart variieren. Wenden Sie sich für eine auf Ihre Situation zugeschnittene Beratung an eine qualifizierte Rechts- oder Compliance-Fachkraft.

Quellen

• [1] Richtlinie (EU) 2022/2555 (NIS-2-Richtlinie), amtliche deutsche Fassung – EUR-Lex
• [2] Durchführungsverordnung (EU) 2024/2690, amtliche deutsche Fassung – EUR-Lex
• [3] § 30 BSIG – Risikomanagementmaßnahmen (Fassung vom 02.12.2025)
• [4] BSI, Positionspapier Zero Trust 2023 (Version 1.12)
• [5] NIST Special Publication 800-207, Zero Trust Architecture (August 2020)
• [6] ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, Version 1.0 (Juni 2025)