Warum Team-Passwortmanagement die ultimative Lösung für KMU ist
Das Problem entsteht nicht durch Nachlässigkeit. Es entsteht durch das Fehlen eines besseren Systems.
Warum der Browser nicht ausreicht
Browser-Passwortmanager funktionieren gut für eine einzelne Person. Sobald jemand Zugriff teilen, ein Projekt übergeben oder das Unternehmen verlassen muss, bricht das Modell zusammen. Im Browser gespeicherte Passwörter sind an das Konto und Gerät einer einzelnen Person gebunden — kein Prüfpfad, keine Möglichkeit, Zugriff gezielt zu widerrufen.
Der Browser ist ein persönliches Werkzeug, das für den Teameinsatz zweckentfremdet wurde. Er wurde nie dafür gebaut.
Der blinde Fleck beim Offboarding
Die meisten Unternehmen deaktivieren beim Offboarding die E-Mail, sammeln den Laptop ein — und übersehen dabei alles andere. Lieferantenportale, Social-Media-Zugänge, Helpdesk-Tools, das Büro-WLAN: diese Passwörter landen fast nie auf der Checkliste. IBMs Cost of a Data Breach Report 2025 ergab, dass credential-basierte Datenpannen im Durchschnitt 246 Tage benötigen, um identifiziert und eingedämmt zu werden.
„Die meisten KMU merken erst dann, dass sie ein Passwortproblem haben, wenn es zu spät ist. Ein gemeinsamer, verschlüsselter Tresor mit rollenbasiertem Zugriff ist keine Frage der Größe — es ist eine Frage der Kontrolle."
— Alex Muntyan, CEO, Passwork
Mehr erfahren
Warum NIST SP 800-63B obligatorische 90-Tage-Passwort-Resets heute ausdrücklich ablehnt, wie ein 3-Fragen-Offboarding-Audit in 15 Minuten alle kritischen Zugangsdaten identifiziert und eine Schritt-für-Schritt-Anleitung zur Einführung eines Team-Passwortmanagers — das alles finden Sie im vollständigen Artikel im Passwork Blog.
Passwork ist ein unabhängiges europäisches Cybersicherheitsunternehmen, das selbst gehostete und cloudbasierte Passwortmanagement-Lösungen für Unternehmen und öffentliche Einrichtungen entwickelt. Das Unternehmen operiert nach EU-Recht und ist vollständig NIS2-, ENS- und DSGVO-konform. Passwork legt den Schwerpunkt auf nachhaltigen Mehrwert, hält ISO-27001-zertifizierte Entwicklungsstandards ein und gewährleistet absoluten Datenschutz für seine Kunden.
Passwork Europe SL.
Carrer d’Arago, 208, 2-5
E08011 Barcelona
Telefon: +34613704284
https://passwork.pro/de/
CEO
Telefon: +34673328602
So setzen Sie NIS2-Zugangskontrollen für die Lieferkettensicherheit um
Die vollständige Version des Originalartikels finden Sie in unserem Blog.
Warum die Sicherheit der Lieferkette kritisch geworden ist
Laut dem Verizon Data Breach Investigations Report 2026 sind Dritte an 48 % aller bestätigten Datenpannen beteiligt — ein Anstieg von 60 % gegenüber dem Vorjahr, als dieser Anteil noch bei 30 % lag. Bei dieser Entwicklung ist das Management von Lieferantenzugriffen kein aufschiebbares Risiko mehr.
Die finanziellen Folgen sind erheblich. Laut IBM Cost of a Data Breach Report 2025 belaufen sich die durchschnittlichen Kosten einer Kompromittierung der Lieferkette auf 4,91 Mio. US-Dollar; die Erkennung solcher Vorfälle dauert im Schnitt 267 Tage. Art. 21 der NIS-2-Richtlinie sowie die Durchführungsverordnung (EU) 2024/2690 — im deutschen Recht umgesetzt durch § 30 BSIG (NIS2UmsuCG) — machen das Management von Lieferantenzugriffen zur Pflichtanforderung im IAM. Ihre Organisation trägt die regulatorische Verantwortung für jeden Zugangspfad, den Sie einem externen Dritten gewähren — ob VPN, API, administrative SaaS-Konsolen, CI/CD-Pipelines oder Fernwartungswerkzeuge.
Fünf wesentliche Zugriffskontrollen
Sobald ein Lieferant über Fernzugriff oder privilegierten Zugang verfügt, wird NIS-2-Konformität zu einer Frage der Identitätskontrolle. § 30 Abs. 2 BSIG nennt zehn Mindestmaßnahmen — fünf davon betreffen den Lieferantenzugriff unmittelbar: rollenbasierte Zugriffskontrolle, Mehrfaktorauthentifizierung, Privileged Access Management, Audit-Protokollierung und automatischer Zugriffsentzug.
1. Rollenbasierte Zugriffskontrolle (RBAC)
Gemeinsam genutzte Lieferantenkonten sind abzuschaffen. Jeder Mitarbeiter eines Lieferanten erhält ein namentliches, personenbezogenes Konto, das an seinen konkreten Auftrag gebunden ist. Gemeinsam genutzte Konten vom Typ „vendor" machen eine Zurechenbarkeit im Falle eines Vorfalls unmöglich — diese ist jedoch für die Einhaltung der 24-Stunden-Frühwarnpflicht nach Art. 23 NIS-2-Richtlinie (§ 32 BSIG) zwingend erforderlich.
2. MFA der Stufe 1 für privilegierten Zugriff
Die ENISA-Leitlinien 2025 klassifizieren die Mehrfaktorauthentifizierung in drei Stufen. Für jeden Lieferanten mit administrativem Zugriff ist ausschließlich Stufe 1 (FIDO2, WebAuthn, Hardware-Sicherheitsschlüssel) akzeptabel. SMS-OTP ist für die schrittweise Abschaffung vorgesehen und erfüllt die Mindestanforderungen nicht.
3. Privileged Access Management (PAM)
Der Just-in-time-Zugang (JIT) ist das richtige Modell für externe Support-Teams. Erhöhte Berechtigungen werden für eine definierte Sitzung gewährt, protokolliert und nach deren Abschluss automatisch entzogen. Für gemeinsam genutzte Zugangsdaten ist ein Tresor mit rollenbasierten Berechtigungen einzusetzen.
4. Unveränderliche Audit-Protokolle
32 BSIG (Art. 23 NIS-2-Richtlinie) legt strenge Meldefristen fest: 24-Stunden-Frühwarnung, 72-Stunden-Meldung und Abschlussbericht innerhalb eines Monats. Diese Fristen ohne manipulationssichere Audit-Protokolle einzuhalten ist nicht realistisch. Die Protokolle müssen vor unbefugtem Zugriff und Veränderung geschützt sein.
5. Automatischer Entzug von Zugangsdaten
Der Lieferantenzugriff muss direkt mit den Ereignissen im Vertragslebenszyklus verknüpft sein. Bei Vertragsablauf muss der Zugriffsentzug unverzüglich und automatisiert erfolgen.
Lieferanten-Zugriffskontrolldatensatz (Supplier Access Control Record)
Dies ist ein operativer Datensatz, der die Lieferantenbeziehung mit konkreten Zugriffsrechten und dem Nachweis ihrer Kontrolle verknüpft. Ein Datensatz pro Lieferant bildet die Einheit der Rechenschaftspflicht. Der Datensatz muss folgende Fragen beantworten: Wer hat Zugriff, worauf, über welchen Zugangspfad, mit welcher Authentifizierungsmethode und wer hat dies genehmigt?
7-Punkte-Checkliste: Bestandsaufnahme des Lieferantenzugriffs
Beginnen Sie mit einer vollständigen Bestandsaufnahme aller Lieferanten. Erfassen Sie alle externen Verbindungen (VPN, API, SaaS usw.) und identifizieren Sie die jeweilige Authentifizierungsmethode sowie die Berechtigungsstufe. Verwenden Sie dabei folgende Prüfliste:
- Jedes Lieferantenkonto ist namentlich und personenbezogen.
- Die MFA-Stufe entspricht der Sensitivität des Zugriffs.
- Alle Konten werden mit automatischem Entzug bereitgestellt.
- Verträge enthalten Anforderungen an namentliche Konten, MFA, 24-Stunden-Vorfallmeldung und Prüfrechte.
- PAM deckt alle privilegierten Lieferantensitzungen ab.
- API-Token unterliegen definierten Rotationsplänen.
- Die Häufigkeit von Zugriffsüberprüfungen ist dokumentiert.
Die Kosten der Nichteinhaltung: Bußgelder und Haftung
Besonders wichtige Einrichtungen (§ 28 Abs. 1 BSIG) riskieren Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes. Für wichtige Einrichtungen (§ 28 Abs. 2 BSIG) beträgt der Rahmen bis zu 7 Millionen Euro oder 1,4 % des Umsatzes.
Darüber hinaus begründet § 38 BSIG (Art. 20 NIS-2-Richtlinie) die persönliche Haftung von Leitungsorganen. Führungskräfte können mit einem vorübergehenden Verbot der Ausübung von Leitungsaufgaben belegt werden, wenn ihrer Organisation grobe Fahrlässigkeit nachgewiesen wird. Die Pflicht, Risikomanagementmaßnahmen zu genehmigen und deren Umsetzung zu überwachen, liegt bei der Geschäftsleitung.
Die Umsetzung der NIS-2-Zugriffskontrollen für die Sicherheit der Lieferkette erfordert einen systematischen Ansatz: von der Erfassung jedes Lieferanten bis hin zur Automatisierung der Zugriffsentzugsprozesse. Unternehmen müssen proaktiv handeln, um ihre Assets zu schützen und schwerwiegende regulatorische Sanktionen nach NIS2UmsuCG zu vermeiden.
Ausführliche Informationen und eine detaillierte Beschreibung jedes Umsetzungsschritts finden Sie in der vollständigen Version des Artikels in unserem Blog.
Passwork ist ein unabhängiges europäisches Cybersicherheitsunternehmen, das selbst gehostete und cloudbasierte Passwortmanagement-Lösungen für Unternehmen und öffentliche Einrichtungen entwickelt. Das Unternehmen operiert nach EU-Recht und ist vollständig NIS2-, ENS- und DSGVO-konform. Passwork legt den Schwerpunkt auf nachhaltigen Mehrwert, hält ISO-27001-zertifizierte Entwicklungsstandards ein und gewährleistet absoluten Datenschutz für seine Kunden.
Passwork Europe SL.
Carrer d’Arago, 208, 2-5
E08011 Barcelona
Telefon: +34613704284
https://passwork.pro/de/
CEO
Telefon: +34673328602
Secrets Sprawl 2026: Wie KI-gestützte Entwicklung einen Rekordanstieg bei der Offenlegung von Unternehmens-Zugangsdaten befeuert
Der Anstieg spiegelt keine individuellen Fehler wider, sondern einen grundlegenden Wandel hin zu schnelleren, KI-gestützten Entwicklungs-Workflows.
Das Ausmaß des Problems: 28 Millionen Secrets und mehr
Seit 2021 sind geleakte Secrets auf öffentlichem GitHub um 152 % gewachsen, während die Entwicklerpopulation um 98 % zunahm. Die Lücke weitet sich aus. Im Jahr 2025 stieg die Anzahl der Repositories, die mindestens ein hardcodiertes Secret enthalten, um fast 40 % gegenüber dem Vorjahr — auf über 4 Millionen öffentliche Repositories.
Eine Kennzahl blieb stabil: Secrets pro Repository. GitHubs Push Protection scheint die Leak-Dichte zu reduzieren, kann aber das Volumenwachstum nicht ausgleichen. Da die Commits um 42 % gegenüber dem Vorjahr gestiegen sind, führte selbst eine gleichbleibende Leak-Rate zu einer Rekordzahl an exponierten Zugangsdaten.
„Das 34-prozentige Wachstum bei geleakten Secrets ist eine Geschichte über strukturellen Wandel. KI-Tools haben es schneller gemacht, Projekte aufzusetzen, Dienste zu verbinden und Code zu generieren. Sie haben es auch schneller gemacht, unsichere Muster in großem Maßstab zu reproduzieren. Die Branche muss Credential-Management als Lifecycle-Disziplin behandeln, nicht als Bereinigungsaufgabe."
— Alex Muntyan, CEO von Passwork
KI-Infrastruktur: der dominierende Treiber der Credential-Exposition
Acht der zehn am schnellsten wachsenden geleakten Secret-Typen im Jahr 2025 sind mit KI-Diensten verknüpft. GitGuardian entdeckte 1.275.105 Secrets, die zu KI-Diensten gehören — ein Anstieg von 81 % gegenüber 2024.
Der bedeutendere Trend sind nicht die Modellanbieter selbst. LLM-Infrastruktur — die Orchestrierungs- und Speicherschicht rund um die Kernmodelle — leckt 5× schneller als die Modellanbieter. Supabase allein rangiert nun in den Top 20 der am häufigsten geleakten Secrets insgesamt, mit über 248.600 Vorkommen.
Das Muster ist konsistent: Entwickler, die KI-gestützte Anwendungen bauen, verbinden ein Modell mit einer Retrieval-Schicht, einem Orchestrierungstool, einer Vektordatenbank und einem Monitoring-Dienst. Jede Integration fügt ein neues Credential hinzu. Jedes Credential ist ein potenzieller Leak.
MCP-Konfigurationsdateien sind eine neue Leak-Angriffsfläche. Im Jahr 2025 fand GitGuardian 24.008 einzigartige Secrets in öffentlichen GitHub-MCP-Configs, von denen 8,8 % zum Zeitpunkt der Entdeckung noch gültig waren. Das Problem wird durch offizielle Setup-Anleitungen verstärkt, die oft dazu ermutigen, Zugangsdaten direkt in Konfigurationsdateien zu speichern.
Im April 2026 fand CloudSEK 32 aktive Google-API-Schlüssel in 22 Android-Apps — mit zusammen über 500 Millionen Installationen. Ein Entwickler verlor innerhalb von Stunden 15.400 USD durch unbefugte Abbuchungen; ein anderer verlor 128.000 USD, obwohl Sicherheitskontrollen vorhanden waren (Infosecurity Magazine, April 2026).
Der blinde Fleck: Interne Systeme sind 6× gefährlicher
Der folgenreichste Befund des 2026er Berichts: Interne Repositories enthalten mit 6× höherer Wahrscheinlichkeit ein hardcodiertes Secret als öffentliche — 32,2 % gegenüber 5,6 %.
Der Grund ist das Antipattern „Security through Obscurity". Teams behandeln private Repositories oft als geringeres Risiko und lassen hardcodierte Zugangsdaten mit der Absicht ansammeln, sie später zu entfernen — was selten geschieht.
Interne Repositories enthalten auch die wertvollsten Zugangsdaten: CI/CD-Tokens, Cloud-Access-Keys, Datenbank-Credentials und interne Tooling-Tokens. Das sind genau die Assets, die ein Angreifer benötigt, sobald er Fuß gefasst hat.
Kollaborationstools wie Slack, Jira und Confluence machen 28 % der internen Vorfälle aus und haben eine um 13 Prozentpunkte höhere Rate kritischer Schweregrade als codebasierte Leaks. Da Zugangsdaten dort häufig während der Incident-Response geteilt werden, entgeht dem reinen Repository-Scanning etwa ein Viertel der gesamten Exposition einer Organisation.
Drittanbieter-Auftragnehmer multiplizieren das Risiko. GitGuardian fand 1.834 kritische Vorfälle bei 13 Beratungsunternehmen, die potenziell 1.203 Kundenorganisationen betrafen. Der Red-Hat-Breach vom Oktober 2025, bei dem die Gruppe „Crimson Collective" 570 GB Daten aus 28.000 Repositories stahl, betraf rund 800 Organisationen weltweit — darunter Bank of America, IBM, Cisco, die U.S. Navy und die NSA.
„Wir sehen konsequent, dass Organisationen stark in Perimeter-Sicherheit investieren, während sie interne Repositories und Kollaborationstools als vertrauenswürdige Zonen behandeln. Die Daten von 2026 machen es deutlich: ‚Privat‘ ist keine Sicherheitskontrolle. Die wertvollsten Zugangsdaten befinden sich innen — und genau dort suchen Angreifer, sobald sie eingedrungen sind."
— Alex Muntyan, CEO von Passwork
Warum alte Methoden versagen: 64 % der 2022 geleakten Secrets sind heute noch gültig
Erkennung ohne Remediation ist keine Sicherheit — es ist Dokumentation.
GitGuardian testete Secrets erneut, die ursprünglich 2022 als gültig bestätigt wurden. Stand Januar 2026 waren 64 % noch ausnutzbar — vier Jahre nach dem ersten Leak. Die Gültigkeitsrate lag bei etwa 70 %, als derselbe Datensatz im Januar 2025 erneut getestet wurde — ein nur gradueller Rückgang trotz jahrelanger Exposition.
Rotation findet selten statt, weil Zugangsdaten tief in Repositories, CI-Pipelines, Container-Images und Integrationen eingebettet sind. Angesichts dieser Komplexität wählen Teams oft die Option, die am wenigsten wahrscheinlich etwas kaputt macht.
Ein paralleles Problem: 46 % der kritischen Secrets sind für validierungsbasierte Tools unsichtbar. Private Keys, benutzerdefinierte API-Tokens und Passwörter können nicht automatisch gegen eine Provider-API validiert werden — treiben aber 35 % der kritischen Vorfälle und 51 % der hoch-oder-kritischen Vorfälle an. Teams, die nicht validierbare Secrets nachrangig behandeln, sind systematisch genau den Bedrohungen ausgesetzt, die am meisten zählen.
Der Weg nach vorne: Von reaktiver Erkennung zu NHI-Governance
Der Wandel, den die Daten von 2026 fordern, ist kein neues Tool — es ist ein Positionswechsel: vom Verfolgen von Leaks hin zur Verwaltung von Non-Human Identities (NHI) als Lifecycle-Disziplin.
In der Praxis bedeutet das:
– Secrets in Vault-Plattformen zentralisieren. Wenn Teams Zugangsdaten von einem einzigen, zugangskontrollierten Ort abrufen können, hören sie auf, fragmentierte Speicherstrategien zu erfinden — einer der primären Treiber von Secrets Sprawl. Passworks Vault-Struktur bietet organisierte, verschlüsselte, zugangskontrollierte Speicherung für API-Schlüssel, Datenbank-Passwörter, Zertifikate, SSH-Keys und Service-Account-Credentials — deploybar innerhalb der eigenen Infrastruktur der Organisation.
– Rotation automatisieren. Wenn ein Secret existieren muss, sollte es nicht ewig bestehen. Regelmäßiger Credential-Austausch verkürzt das Zeitfenster, in dem ein Angreifer ein geleaktes Secret ausnutzen kann, und zwingt Teams dazu, Zugangsdaten als Objekte mit einem Lifecycle zu behandeln.
– Erkennung über Code hinaus ausweiten. Slack, Jira und Confluence scannen. Wer nur Repositories scannt, verpasst ein Viertel der gesamten Exposition.
– Scanning früher verlagern. Pre-Commit-Scanning und Erkennung auf Workstation-Ebene stoppen Vorfälle, bevor sie irgendwo dauerhaft landen.
– Zu identitätsbasierter Authentifizierung wechseln. Der langfristige Ausweg aus langlebigen statischen Secrets ist kurzlebiger, identitätsgesteuerter Zugriff — Frameworks wie SPIFFE/SPIRE ersetzen Shared-String-Authentifizierung durch stark attestierte Workload-Identität.
Drei Governance-Fragen, die jede Organisation mit Sicherheit beantworten können muss:
Welche Non-Human Identities existieren in unserer Umgebung?
Wer ist für sie verantwortlich?
Worauf können sie zugreifen?
Wenn auch nur eine dieser Fragen nicht beantwortet werden kann, überholt die KI-Adoption die Sicherheitslage.
Passwork ist ein unabhängiges europäisches Cybersicherheitsunternehmen, das selbst gehostete und cloudbasierte Passwortmanagement-Lösungen für Unternehmen und öffentliche Einrichtungen entwickelt. Das Unternehmen operiert nach EU-Recht und ist vollständig NIS2-, ENS- und DSGVO-konform. Passwork legt den Schwerpunkt auf nachhaltigen Mehrwert, hält ISO-27001-zertifizierte Entwicklungsstandards ein und gewährleistet absoluten Datenschutz für seine Kunden.
Passwork Europe SL.
Carrer d’Arago, 208, 2-5
E08011 Barcelona
Telefon: +34613704284
https://passwork.pro/de/
CEO
Telefon: +34 (6733) 28602
NIS2 geht von der Umsetzung zur Durchsetzung über: Was sich im Mai 2026 geändert hat
Obwohl NIS2 einen gemeinsamen Rahmen vorgibt, verläuft die nationale Umsetzung in den Mitgliedstaaten uneinheitlich. Die Anforderungen auf nationaler Ebene unterscheiden sich nach wie vor, weshalb Entwicklungen in einzelnen Ländern ein nützlicher Indikator dafür sind, wohin die behördliche Aufmerksamkeit tendiert.
Der Mai 2026 hat diesen Wandel deutlich gemacht: Bulgarien hat sein Sanktionsregime aktiviert, Luxemburg hat eine Pflichtregistrierung eingeführt, die NIS-Kooperationsgruppe hat gemeinsame Meldevorlagen für Sicherheitsvorfälle verabschiedet, ENISA hat seine sektorale Reifegradbewertung aktualisiert, und die Niederlande sowie Irland haben ihre lange verzögerte Umsetzung vorangetrieben.
Bulgarien: Vollständige Durchsetzung hat begonnen
Ab dem 1. Juni 2026 setzt Bulgarien sein NIS2-konformes Cybersicherheitsgesetz vollständig durch. Die bisherige 50-prozentige Bußgeldreduzierung entfällt.
Das Gesetz erfasst Einrichtungen der Anhang-I- und -II-Sektoren ab mittlerer Unternehmensgröße sowie bestimmte kritische Anbieter unabhängig von ihrer Größe. Auch Kommunen fallen als wesentliche Einrichtungen in den Anwendungsbereich.
Eine Lücke bleibt: Die Mindestsicherheitsmaßnahmen sind noch nicht per Verordnung definiert. Dennoch gelten alle Pflichten bereits, Sanktionen werden verhängt.
Von Organisationen wird erwartet, dass sie eine Lückenanalyse durchführen und sich an Rahmenwerken wie ISO 27001 und ISO 22301 ausrichten.
Leitungsorgane haften persönlich: Einzelne Mitglieder können mit 500 bis 5.000 Euro belegt werden, Unternehmen mit bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes. In schwerwiegenden Fällen ist ein gerichtliches Verbot von Leitungsfunktionen möglich.
Aufsichtsbehörden prüfen konkrete Nachweise: Beschlüsse des Leitungsorgans, Richtlinien, Audits und dokumentierte Schulungen.
Quelle: Bulgarisches Staatsblatt, 2026; Capital.bg, 2026
Ein einheitliches Meldeformat für die gesamte EU
Am 26. Mai 2026 hat die NIS-Kooperationsgruppe gemeinsame Vorlagen für die NIS2-Vorfallsmeldung vereinbart. Sie ersetzen die fragmentierten nationalen Formulare und sollen per Durchführungsrechtsakt verbindlich werden.
Die Meldefristen nach Artikel 23 bleiben unverändert: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht nach einem Monat. Nur das Einreichungsformat ändert sich. Wer Incident-Response-Prozesse auf nationalen Formularen aufgebaut hat, sollte die Aktualisierung jetzt einplanen.
Quelle: Europäische Kommission, 2026
ENISA identifiziert Hochrisikosektoren
Am 28. Mai 2026 hat ENISA seinen dritten NIS360-Bericht veröffentlicht, der den Cybersicherheitsreifegrad in den kritischen Sektoren gemäß Anhang I der NIS2-Richtlinie bewertet.
Der Bericht bewertet gesamte Sektorökosysteme, nicht einzelne Organisationen, und hebt Lücken zwischen der Kritikalität und der tatsächlichen Sicherheitsbereitschaft hervor.
Acht Sektoren werden als Hochrisikobereiche eingestuft: Gesundheitswesen, Schienenverkehr, Seeverkehr, IKT-Dienstleistungsmanagement, Raumfahrt, öffentliche Verwaltung, Trinkwasserversorgung und Abwasserentsorgung.
Für IT- und Sicherheitsverantwortliche in diesen Sektoren ist die NIS360-Bewertung ein nützlicher Referenzpunkt. Wer in der Risikoliste erscheint, sollte mit erhöhter Aufsichtsaufmerksamkeit rechnen: Behörden nutzen sektorale Reifegradsdaten, um ihre Prüfpläne zu priorisieren.
Quelle: ENISA, 2026
Luxemburg: Registrierung ist nun Pflicht
Das luxemburgische NIS2-Gesetz wurde am 6. Mai 2026 veröffentlicht und trat am 10. Mai in Kraft, womit es den NIS1-Rahmen ablöst.
Es gilt für Organisationen mit 50+ Beschäftigten oder 10 Mio. Euro Jahresumsatz in 18 kritischen Sektoren. Wesentliche Einrichtungen unterliegen proaktiver Aufsicht und Bußgeldern bis zu 10 Mio. Euro oder 2 % des Umsatzes, wichtige Einrichtungen reaktiver Aufsicht mit Obergrenzen bis zu 7 Mio. Euro oder 1,4 %.
Alle Einrichtungen müssen dieselben grundlegenden Sicherheitsmaßnahmen umsetzen (Risikomanagement, Incident Response, Geschäftskontinuität, Lieferkettensicherheit, Zugangssteuerung, MFA usw.) und die NIS2-Meldefristen einhalten (24 Stunden, 72 Stunden, 1 Monat).
Eine wichtige Frist ist der 10. Juli 2026 für die obligatorische Selbstregistrierung bei der zuständigen Behörde (ILR oder CSSF, je nach Sektor). Das Versäumnis der Registrierung ist selbst sanktionierbar.
Quelle: Journal officiel du Grand-Duché de Luxembourg, 2026
Niederlande: Cyberbeveiligingswet erreicht Plenarphase im Senat
Das niederländische Repräsentantenhaus hat das Cyberbeveiligingswet (NIS2-Umsetzungsgesetz) am 15. April 2026 mit breiter Mehrheit von 140 zu 10 Stimmen verabschiedet. Der Gesetzentwurf befindet sich nach der Ausschussberatung im Mai 2026 nun in der Plenarphase des Senats.
Das Gesetz, das im Juni 2025 nach Versäumnis der EU-Frist eingebracht wurde, wird parallel zur Umsetzung der CER-Richtlinie bearbeitet. Die Durchsetzung wird von bestehenden Sektoraufsichtsbehörden und nicht von einer einzigen zentralen Behörde übernommen.
Die Zustimmung des Senats ist der letzte Schritt. Danach legt die Regierung das Inkrafttreten fest, und die Pflichten (Risikomanagement, Meldung von Sicherheitsvorfällen, Verantwortlichkeit des Leitungsorgans) gelten unmittelbar für betroffene Organisationen.
Quellen: Eerste Kamer, Gesetzentwurf 36764; Tweede Kamer, Gesetzentwurf 36764
Irland: National Cyber Security Bill als NIS2-Umsetzungsinstrument bestätigt
Irland hat im Mai 2026 bestätigt, dass der National Cyber Security Bill das NIS2-Umsetzungsgesetz wird und im Sommer 2026 veröffentlicht werden soll. Das NCSC wird darin als zuständige Behörde und CSIRT benannt.
Trotz verpasster EU-Frist sind Sektoraufsichtsbehörden bereits aktiv und bereiten sich auf ihre Durchsetzungsrollen vor. Für Organisationen mit Aktivitäten in Irland gilt: Das Fehlen eines in Kraft getretenen Gesetzes entbindet nicht von der Vorbereitungspflicht.
Quelle: Oireachtas, schriftliche Anfrage, Mai 2026; NCSC Irland, Juni 2025
DigitalEurope: NIS2 erfordert weitergehende Harmonisierung
Am 13. Mai 2026 hat DigitalEurope ein Positionspapier veröffentlicht, in dem argumentiert wird, dass das EU-Cybersicherheitspaket die zentralen Herausforderungen bei der NIS2-Umsetzung noch unzureichend adressiert.
Die Organisation hat fünf Bereiche hervorgehoben, die einer stärkeren Harmonisierung bedürfen:
Anwendungsbereich — Begrenzung der NIS2-Pflichten auf Kerngeschäftsaktivitäten
Größenschwellenwerte — Reduzierung nationaler Unterschiede bei der Einstufung von Einrichtungen
Meldung von Sicherheitsvorfällen — Vereinheitlichung von Meldefeldern, Fristen und Einreichungsprozessen
Hauptniederlassungsregeln — Klärung, welche Behörde die primäre Zuständigkeit für grenzüberschreitend tätige Organisationen hat
Konformitätsbewertungen — Angleichung der Compliance-Anforderungen in den Mitgliedstaaten
Zudem wurde eine stärkere koordinierende Rolle für ENISA gefordert. Während die neuen gemeinsamen Meldevorlagen für Sicherheitsvorfälle eines dieser Probleme angehen, bleiben die meisten Harmonisierungslücken ungelöst.
Quelle: DigitalEurope, Mai 2026
Was diese Entwicklungen im Vorfeld von NIS2-Prüfungen bedeuten
Erstens: Governance-Dokumentation. Zugewiesene Verantwortlichkeiten, dokumentierte Entscheidungen und abgeschlossene Schulungen — die persönliche Haftung gilt nun in Bulgarien und Luxemburg, wenn diese Nachweise fehlen.
Zweitens: Incident Response. Aktualisieren Sie Ihre Prozesse für die bevorstehenden EU-weiten Meldevorlagen. Das Format wird sich nach Verabschiedung des Durchführungsrechtsakts ändern — es ist daher einfacher, die Aktualisierung jetzt in bestehende Pläne zu integrieren.
Drittens: Sektorale Risikoexposition. Prüfen Sie, ob Sie oder wichtige Kunden unter einen der acht in ENISA NIS360 2026 als Hochrisiko eingestuften Sektoren fallen. Diese Sektoren werden im zweiten Halbjahr 2026 voraussichtlich verstärkte Aufsicht erfahren.
Der Rahmen ist weitgehend festgelegt. Der Fokus liegt nun darauf, ob Schutzmaßnahmen vorhanden, operativ und nachweisbar sind.
Passwork ist ein europäisches Unternehmen, das selbst gehostete und cloudbasierte Passwortmanagement-Lösungen für Unternehmen und Behörden entwickelt. Das Unternehmen operiert nach EU-Recht, ist ISO-27001-zertifiziert und vollständig NIS2-, ENS- und DSGVO-konform.
Erfahren Sie, wie Passwork die NIS2-Prüfungsvorbereitung unterstützt: passwork.pro/nis2
Passwork ist ein unabhängiges europäisches Cybersicherheitsunternehmen, das selbst gehostete und cloudbasierte Passwortmanagement-Lösungen für Unternehmen und öffentliche Einrichtungen entwickelt. Das Unternehmen operiert nach EU-Recht und ist vollständig NIS2-, ENS- und DSGVO-konform. Passwork legt den Schwerpunkt auf nachhaltigen Mehrwert, hält ISO-27001-zertifizierte Entwicklungsstandards ein und gewährleistet absoluten Datenschutz für seine Kunden.
Passwork Europe SL.
Carrer d’Arago, 208, 2-5
E08011 Barcelona
Telefon: +34613704284
https://passwork.pro/de/
CEO
Telefon: +34 (673) 328602
