Wer einen Überblick zur NIS-2-Betroffenheit, den zehn Anforderungen aus Artikel 21, dem Bußgeldrahmen und der Geschäftsführerhaftung sucht, findet das in unserem Beitrag NIS-2 Compliance: Pflichten für den Mittelstand 2026. Dieser Artikel ist die technische Vertiefung: Welche konkreten Tools, Architekturen und Konfigurationen taugen 2026 für eine NIS-2-konforme IT-Umgebung im Mittelstand, und welche Designentscheidungen sparen später Audit-Stress.
Wir konzentrieren uns auf die fünf technischen Bausteine, die in jeder NIS-2-Umsetzung wiederkehren: Multi-Faktor-Authentifizierung, Netzwerksegmentierung, zentrales Logging, ein passendes SIEM und automatisiertes Patch-Management. Die Auswahl ist deliberately pragmatisch. Wer einen reifen Stack will, baut hier auf, ohne in Tool-Sprawl zu verfallen.
MFA-Architektur: Hardware-Token plus IDP
MFA ist die wirksamste Einzelmaßnahme gegen Phishing- und Credential-Stuffing-Angriffe. Wer 2026 noch SMS-OTP einsetzt, sollte diese Architektur priorisiert ablösen, da SIM-Swap-Angriffe und SS7-Schwachstellen die Methode entwerten.
Der pragmatische Ziel-Stack im Mittelstand besteht aus drei Schichten. Erstens: ein zentraler Identity Provider, der OIDC und SAML 2.0 spricht. Keycloak (Open Source) und Microsoft Entra ID (früher Azure AD) sind die häufigsten Wahlen. Wer aus DSGVO- und Sovereignty-Gründen einen europäischen Anbieter sucht, findet in Authentik eine moderne Open-Source-Alternative mit aktiver Community und kommerziellem Support über die Firma authentik Security. Zweitens: FIDO2-Hardware-Token (YubiKey, Token2, Nitrokey) für privilegierte Accounts und alle Mitarbeitenden mit Zugriff auf produktive Systeme. Drittens: TOTP-Apps (Microsoft Authenticator, Aegis, FreeOTP) als Fallback für Standard-User.
Der Roll-out folgt einer klaren Priorisierung. Administrative Accounts und Service-Accounts mit Zugriff auf Domain-Controller, Kubernetes-Cluster, Cloud-Konsolen, Backup-Systeme und CI/CD-Pipelines werden zuerst mit FIDO2 hart abgesichert. Standardarbeitsplätze folgen in der zweiten Welle. Externe Dienstleister werden über zeitlich begrenzte Just-in-Time-Accounts gehandhabt, am pragmatischsten via PIM in Entra oder einer Open-Source-Lösung wie Teleport.
Was wir in Projekten regelmäßig sehen: MFA wird zwar ausgerollt, aber Bypass-Pfade bleiben offen. Legacy-Protokolle wie IMAP, SMTP-AUTH oder POP3 müssen für alle Accounts deaktiviert werden. Conditional Access in Entra ID oder Policy Rules in Keycloak schließen diese Lücken, sofern sie konsequent gepflegt werden.
Netzwerksegmentierung: VLANs, Mikrosegmentierung, Zero Trust
Netzwerksegmentierung ist die zweite Verteidigungslinie, falls MFA umgangen wird. Sie reduziert lateral Movement und ist in NIS-2 Art. 21 implizit über die Anforderungen an Zugriffskontrolle und Schadensbegrenzung adressiert.
Im klassischen Office-Setup setzen wir auf VLAN-basierte Trennung mit MikroTik, Ubiquiti oder Fortinet-Hardware. Das Grundmuster: Management-VLAN für Switches und Router, Server-VLAN für interne Dienste, Client-VLAN für Mitarbeiter-Endgeräte, Guest-VLAN für Besucher und Drucker-VLAN für die Peripherie. Inter-VLAN-Routing nur über explizit definierte Firewall-Regeln, niemals über Default-Allow.
Für Cloud- und Container-Umgebungen reicht VLAN-Trennung nicht mehr. Hier kommen Mikrosegmentierung und Identity-aware Networking ins Spiel. In Kubernetes-Clustern setzen wir Cilium oder Calico mit Default-Deny-Network-Policies pro Namespace ein. Für hybride Setups mit Remote-Mitarbeitern ist Tailscale mit ACLs eine pragmatische Zero-Trust-Brücke, die ohne komplexe SD-WAN-Investition auskommt.
Die NIS-2-relevante Pointe: Segmentierung muss dokumentiert und nachweisbar sein. Ein Netzwerkdiagramm im Confluence-Wiki, ein aktueller Asset-Bestand und Firewall-Konfigurationen unter Versionskontrolle sind Audit-Material. Wer Infrastructure as Code lebt, hat hier strukturell einen Vorsprung. Mehr Details dazu in Infrastructure as Code mit Terraform und Pulumi.
Logging-Stack: was, wo und wie lange
Zentrales Logging ist die operative Grundlage für die 24-Stunden-Meldepflicht. Ohne korrelierbare Logs ist die Ursachenanalyse nach einem Vorfall ein Stochern im Nebel.
Der Mindest-Logset für NIS-2 umfasst sechs Quellen. Authentifizierungs-Events (Logins, Failed Logins, MFA-Bypässe, Privilegienänderungen). System-Audit-Logs auf Servern und Endpoints (auditd unter Linux, Windows Security Eventlog). Netzwerk-Flows (NetFlow, Suricata-Alerts, Firewall-Logs). Anwendungs-Logs der business-kritischen Systeme. Cloud-Audit-Logs (CloudTrail, Azure Activity Log, Google Cloud Audit Logs). Container- und Kubernetes-Audit-Logs.
Der Open-Source-Stack der Wahl 2026 ist Grafana Loki für die Aggregation, Promtail oder Vector als Shipper und Grafana für die Visualisierung. Wer Elastic-Erfahrung mitbringt, fährt mit OpenSearch und Filebeat ebenfalls solide. Für Endpoint- und Server-Monitoring ist Wazuh attraktiv, weil es Logging, File Integrity Monitoring und Endpoint Detection in einem Stack bündelt.
Aufbewahrungsdauern leiten sich aus regulatorischen Anforderungen ab. Für NIS-2 sind sechs Monate als Untergrenze realistisch, zwölf Monate sind Best Practice. Sicherheitsrelevante Authentifizierungs- und Audit-Logs sollten 24 Monate vorgehalten werden, weil viele Vorfälle erst Monate später entdeckt werden. Cold-Storage in S3-Glacier oder einem deutschen Object-Storage-Anbieter wie IONOS oder Hetzner Object Storage hält die Kosten im Rahmen.
Eine häufige Falle: zu viel Logging. Wer alle Debug-Logs sammelt, produziert ein Volumen, das weder bezahlbar noch durchsuchbar ist. Eine Log-Reduction-Schicht (Cribl Stream oder Vector mit Filter-Transforms) am Ingest-Punkt halbiert in unseren Projekten typischerweise die Datenmenge ohne forensischen Verlust.
SIEM-Auswahl im Mittelstand
Ein SIEM korreliert die zentral aggregierten Logs zu Alerts und gibt der Incident-Response-Pipeline Struktur. Die NIS-2-Anforderung nach Erkennung und Behandlung von Sicherheitsvorfällen ist ohne SIEM schwer nachweisbar.
Die Auswahl im Mittelstand bewegt sich praktisch zwischen vier Kategorien. Erstens: Open-Source-SIEMs wie Wazuh oder das selbst betriebene Elastic-Stack-Setup mit OpenSearch Security. Niedrige Lizenzkosten, hoher Betriebsaufwand, gute Souveränität. Zweitens: Cloud-native SIEMs der Hyperscaler, also Microsoft Sentinel und Google Chronicle. Schneller Start, gute Integration ins jeweilige Ökosystem, aber Vendor-Lock-in und Datenabfluss in den Hyperscaler. Drittens: dedizierte SIEM-Vendoren wie CrowdStrike Falcon LogScale, Elastic Security oder Splunk. Hochwertige Detection-Content-Libraries, hohe Lizenzkosten. Viertens: Managed-Detection-and-Response-Services (MDR) deutscher Anbieter wie G Data Advanced Analytics oder Cognosec. Die Auslagerung des 24/7-Betriebs kompensiert fehlendes internes Personal.
Für einen NIS-2-betroffenen Mittelständler mit 200 bis 500 Mitarbeitenden und ohne dediziertes SOC-Team empfehlen wir in den meisten Fällen Wazuh als Plattform-Basis plus einen MDR-Partner für Off-hours-Coverage. Die Kombination liegt typischerweise bei 30.000 bis 70.000 Euro pro Jahr und kompensiert die fehlende 24/7-Bereitschaft. Wer ein eigenes Security-Team aufbaut, fährt mit CrowdStrike oder Microsoft Sentinel schneller, zahlt aber mehr.
Wichtig in der Bewertung: ein SIEM ohne gepflegte Detection-Rules ist ein teurer Log-Aggregator. MITRE ATT&CK-Coverage, regelmäßige Sigma-Rule-Updates und ein dokumentierter Tuning-Prozess sind die echten Qualitätskriterien. Wir haben das Thema kontinuierliche Sicherheits-Telemetrie auch in DevSecOps vs. DevOps angerissen.
Patch-Management automatisieren
NIS-2 verlangt nachweisbares Schwachstellen-Management. In der Praxis scheitert das selten am Wollen, sondern an der Ausführung. Ein automatisierter Patch-Prozess löst das.
Für Linux-Server ist Ansible mit dem unattended-upgrades-Modul plus ein wöchentlicher Reboot-Slot der Standard. Kritische CVEs werden über ein zusätzliches CVE-Polling-Skript identifiziert und außer der Reihe gepatcht. Auf Windows-Seite läuft Microsoft Intune oder ein klassisches WSUS-Setup mit Microsoft Update for Business. Für die Server-Tier empfehlen wir Microsoft Defender Vulnerability Management oder eine Open-Source-Lösung wie OpenVAS.
Container-Images werden über zwei Mechanismen aktuell gehalten. Renovate oder Dependabot updaten Base-Image-Tags und Application-Dependencies in Pull Requests. Trivy oder Grype scannen vor dem Push und blockieren bei kritischen Findings. Wir haben das Setup im Detail in Trivy und der npm Supply-Chain-Angriff durchexerziert.
Für die NIS-2-Nachweisführung lohnt sich ein zentrales Dashboard, das Patchstand pro System, offene CVEs und letzten Scan-Zeitpunkt zeigt. Grafana auf Loki oder Wazuh-Dashboards reichen dafür aus, ein Enterprise-Tool ist meist überdimensioniert.
Fazit
NIS-2-konforme Technik im Mittelstand ist 2026 keine Frage exotischer Werkzeuge, sondern konsequenter Architektur. Ein Stack aus zentralem IDP plus FIDO2, segmentiertem Netzwerk, Loki- oder Wazuh-basiertem Logging, Wazuh als SIEM-Basis und automatisiertem Patch-Management deckt die operativen Pflichten aus Artikel 21 mit überschaubarem Budget. Wer parallel die Mittelstands-Roadmap aus unserem NIS-2-Übersichtsartikel abarbeitet, hat die organisatorische und technische Seite synchron im Griff.
EverBright IT begleitet Mittelständler beim Aufbau und Hardening dieses Stacks, von der Tool-Auswahl über die Roll-out-Planung bis zum Tuning der SIEM-Detection-Rules. Mehr zu unserer Cloud- und Security-Beratung oder direkt Kontakt aufnehmen.
Häufige Fragen
Welches SIEM ist 2026 für den Mittelstand am wirtschaftlichsten?
Für einen NIS-2-betroffenen Mittelständler mit 200 bis 500 Mitarbeitenden ohne eigenes SOC empfehlen wir Wazuh als Plattform plus einen MDR-Partner für 24/7-Coverage. Microsoft Sentinel ist die Alternative für M365-zentrische Umgebungen, kostet aber mehr und bindet ans Microsoft-Ökosystem.
Reicht TOTP-MFA für NIS-2 oder braucht es FIDO2?
TOTP reicht für Standard-User. Für administrative Accounts, Domain-Controller-Zugriffe, Cloud-Konsolen und Backup-Systeme verlangen aktuelle BSI-Empfehlungen und der Stand der Technik FIDO2-Hardware-Token. SMS-OTP gilt seit Jahren als unzureichend und sollte aktiv abgeschafft werden, da SIM-Swap- und SS7-Angriffe die Methode kompromittieren.
Wie lange müssen Logs für NIS-2 aufbewahrt werden?
NIS-2 selbst nennt keine harte Frist. In der Praxis sind sechs Monate Mindestaufbewahrung, zwölf Monate Best Practice und 24 Monate für sicherheitsrelevante Auth- und Audit-Logs sinnvoll. Hintergrund: Viele Vorfälle werden erst nach Monaten entdeckt. Cold-Storage in einem deutschen Object-Store hält die Kosten dabei im Rahmen.
Was kostet ein NIS-2-konformer Security-Stack im Mittelstand?
Für ein Unternehmen mit 200 bis 500 Mitarbeitenden setzen sich die Betriebskosten aus mehreren Komponenten zusammen: SIEM und MDR, Endpoint-Schutz und Patch-Management, Logging-Infrastruktur und FIDO2-Hardware. Die genauen Kosten hängen stark vom gewählten Stack, bestehenden Verträgen und dem Reifegrad der IT-Security ab. Eine individuelle Kalkulation nach der Gap-Analyse gibt verlässliche Zahlen.
