VPN im KMU 2026: Welche Konstellationen erfordern noch klassisches VPN?

Welche regulatorischen Grundlagen sind einschlägig?

Die Anforderungen an die Absicherung von Fernzugängen ergeben sich aus mehreren parallelen Quellen:

• DSGVO Art. 32 verlangt geeignete technisch-organisatorische Maßnahmen, die Absicherung von Fernzugängen ist hierbei regelmäßig ein zentraler Baustein.
• NIS2-Richtlinie (EU) 2022/2555 Art. 21 Abs. 2, in Deutschland umgesetzt in § 30 Abs. 2 BSIG, verlangt zehn Risikomanagement-Maßnahmen. Fernzugriffe nennt die Liste nicht ausdrücklich; einschlägig sind vor allem Zugriffskontrolle (lit. i / Nr. 9) und Multi-Faktor-Authentifizierung (lit. j / Nr. 10).

• BSI IT-Grundschutz Baustein NET.3.3 (VPN) ist die anerkannte Referenz für die Auslegung der VPN-spezifischen Anforderungen im deutschen Raum.
• NIST SP 800-207 (Zero Trust Architecture) beschreibt international die Grundprinzipien einer ressourcen-zentrierten Zugriffsarchitektur als Alternative oder Ergänzung zu netzwerk-zentrierten Konzepten.
• CISA „Guide to Securing Remote Access Software" (06.06.2023) beschreibt den Missbrauch von Fernwartungssoftware durch Angreifer sowie Erkennungs- und Schutzmaßnahmen.
• Sektorspezifische Rahmen (DORA im Finanzsektor, TISAX für Automotive-Zulieferer, branchenspezifische Sicherheitsstandards wie der B3S Krankenhaus, IT-Sicherheitskatalog für Energieversorger) können zusätzliche Vorgaben zu Fernzugriffen enthalten. Die BSI-KritisV selbst regelt nur Anlagenkategorien und Schwellenwerte, keine Fernzugriffs-Maßnahmen.

Welche Schutzbedarfs-Stufe passt typisch zu KMU?

Die Wahl der Fernzugriffs-Architektur richtet sich nach Schutzbedarf, Anwendungsprofil und Sektor:

• Normaler Schutzbedarf (Office-Arbeit mit Cloud-Diensten, Standard-Geschäftsdaten): Ein Identity-zentriertes Zugriffsmodell mit Multi-Faktor-Authentifizierung und Conditional Access kann nach NIST SP 800-207 ein verbreiteter Bezugspunkt sein; ein klassisches VPN ist hier regelmäßig nicht erforderlich, sofern keine On-Premise-Anwendungen mehr genutzt werden.
• Hoher Schutzbedarf (vertrauliche Daten, größere Kundendatenbestände, hybride Anwendungslandschaft): Hier sind Zero-Trust-Network-Access-Konzepte oder restriktiv konfigurierte VPN-Lösungen mit MFA-Erzwingung, Geräte-Compliance-Prüfung und Mikro-Segmentierung in Erwägung zu ziehen.

• Sehr hoher Schutzbedarf (KRITIS, OT/SCADA, regulierte Sektoren): Erweiterte Architekturen mit dedizierten Jump-Hosts, Privileged-Access-Management, Session-Recording, ggf. Hardware-Sicherheits-Modulen und mehrstufigen Genehmigungs-Verfahren kommen hier in Betracht; welche davon nötig sind, ergibt sich aus Schutzbedarfs- und Risikoanalyse.

Welcher Aufbau-Rahmen ist verbreitet?

Die Auswahl zwischen VPN und alternativen Fernzugriffs-Konzepten erfolgt typischerweise entlang des Anwendungsprofils. Die folgende Übersicht ist als Orientierung, nicht als pauschale Empfehlung zu verstehen.

Wann klassisches VPN regelmäßig erforderlich bleibt

• On-Premise-Server mit administrativen oder anwendungsspezifischen Protokollen. RDP- oder SSH-Zugänge auf interne Server sollten nicht direkt ins offene Internet exponiert werden; üblich ist ein VPN-Tunnel oder ein ressourcen-spezifischer ZTNA-Proxy.
• Industrielle Steuerungssysteme (OT, SCADA, SPS-Wartung). Diese Umgebungen sind regelmäßig nicht cloud-native; Fernwartung erfolgt hier typischerweise über abgesicherte Tunnel mit zusätzlichen Schichten wie Jump-Hosts und dedizierten Wartungs-Accounts.
• Sektorspezifische Compliance-Vorgaben. TISAX (Automotive), Pharma- und Verteidigungs-Auflagen sowie der IT-Sicherheitskatalog für Energieversorger können Anforderungen an Fernzugriffe enthalten; ob daraus eine VPN-Architektur folgt, ist am jeweiligen Regelwerk oder Vertrag zu prüfen.
• Drittland-Konstellationen mit besonderen Schutzanforderungen an die Vertraulichkeit der Datenübertragung.
• Eigene Web-Anwendungen ohne ausgereiftes Identity-Federation-Modell, sofern eine Public-Exposition aus Sicherheits- oder Compliance-Gründen unerwünscht ist.

Wann alternative Konzepte (ZTNA) in Erwägung zu ziehen sind

• Reine SaaS- und Cloud-Suite-Nutzung (Microsoft 365, Google Workspace, weitere SaaS-Anwendungen ohne On-Premise-Komponenten): Identity-zentrierter Zugriff mit MFA und Conditional Access ist hier nach NIST SP 800-207 ein verbreiteter Bezugspunkt. Ein zusätzlicher VPN-Tunnel erzeugt regelmäßig Komplexität ohne wesentlichen Sicherheits-Mehrwert.
• Veröffentlichung interner Web-Anwendungen über einen ressourcen-spezifischen Reverse-Proxy mit Identity-Validierung (verschiedene ZTNA-Anbieter wie Cloudflare Access, Microsoft Entra Private Access, Zscaler Private Access, Tailscale, Twingate u. a.) als Alternative zur Netzwerk-Einbindung der Endgeräte.
• Federated Access auf SaaS-Anwendungen über einen zentralen Identity Provider mit Single Sign-On und MFA-Erzwingung.

Welche Konstellation für ein konkretes Unternehmen tragfähig ist, ergibt sich aus einer Bestandsaufnahme der tatsächlich genutzten Anwendungen und Datenflüsse.

Welche Anforderungen an Migrations-Vorhaben sind verbreitet?

Eine Migration von klassischem VPN zu ressourcen-zentrierten Zugriffs-Konzepten erfolgt typischerweise in mehreren Phasen:

• Bestandsaufnahme. Welche Anwendungen werden tatsächlich über den VPN-Tunnel genutzt, und sind diese cloud-fähig oder verbleiben sie auf einer On-Premise-Architektur.
• Architektur-Bewertung. Welche Anwendungen lassen sich auf SaaS-Dienste oder Reverse-Proxy-Modelle migrieren, welche erfordern weiterhin einen Netzwerk-Tunnel.

• Pilotbetrieb. Eine Pilot-Gruppe mit einem ausgewählten ZTNA-Anbieter zur Validierung von Funktionalität, Performance und Mitarbeitenden-Akzeptanz.
• Rollout. Schrittweise Migration unter Beibehaltung des Parallelbetriebs, bis alle Anwendungen über die neue Architektur erreichbar sind.
• Stilllegung. Geordnete Außerbetriebnahme der VPN-Komponenten mit Dokumentation für das Asset-Inventar, relevant für NIS2- und ISMS-Audits.

Der Zeitrahmen hängt von der Anzahl und Komplexität der Anwendungen ab und ist im Einzelfall zu schätzen.

Welche Konstellationen erfordern abweichendes Vorgehen?

Eine pauschale Ablösung klassischer VPN-Lösungen ist nicht für alle Unternehmensprofile geeignet. In den folgenden Konstellationen ist regelmäßig ein abweichendes Vorgehen erforderlich:

• OT-/SCADA-zentrierte Betriebe (Maschinenbau, Energieversorgung, Wasserwirtschaft, Logistik mit Anlagensteuerung): Hier kommen klassisches VPN oder dedizierte Industrial-Remote-Access-Lösungen häufig zum Einsatz. Ob ein ZTNA-Produkt die eingesetzten SPS- und HMI-Protokolle unterstützt, ist vor einer Umstellung zu prüfen.
• Betreiber kritischer Anlagen: Zusätzlich zu § 30 BSIG gelten die besonderen Anforderungen nach § 31 BSIG, u. a. der Einsatz von Systemen zur Angriffserkennung. Branchenspezifische Sicherheitsstandards (B3S) können sie nach § 30 Abs. 9 BSIG vorschlagen; sie sind ein Weg zur Umsetzung, keine eigenständige Pflicht.

• Besonders wichtige und wichtige Einrichtungen nach BSIG: Die Fernzugriffs-Architektur ist Teil der Risikomanagement-Maßnahmen nach § 30 BSIG (insbesondere Zugriffskontrolle und Multi-Faktor-Authentifizierung) und sollte entsprechend dokumentiert in das ISMS eingebettet werden.
• Finanzsektor (DORA, VO (EU) 2022/2554, anwendbar seit 17.01.2025): Vorgaben zum IKT-Risikomanagement einschließlich Zugriffssteuerung und zum IKT-Drittparteienrisiko. VAIT und KAIT sind aufgehoben, die BAIT entfallen mit Ablauf des 31.12.2026.
• Auto-Zulieferer mit TISAX-Anforderungen: Maßgeblich sind der VDA-ISA-Katalog, auf dem TISAX-Assessments beruhen, und die Vorgaben der Kunden.
• Verteidigungs- und Pharma-Zulieferer: Sektorspezifische Vorgaben aus Kunden-Verträgen oder regulatorischen Rahmen (z. B. GxP).
• Mehrstandort- und internationale Konstellationen mit datenschutzrechtlichen Drittland-Bezügen: Erweiterte Anforderungen aus DSGVO, Schrems-II-Rechtsprechung und ggf. Branchen-Auflagen.

Bei Unsicherheit über die einschlägige Architektur-Wahl ist eine fachliche Beratung der intuitiven Übernahme von Marktnarrativen vorzuziehen.

Nächster Schritt

Ob NIS2, DORA oder KRITIS-Pflichten überhaupt in Betracht kommen, lässt sich mit dem NIS2-Check vorläufig einordnen; Fernzugriffs-Anforderungen prüft der Check nicht einzeln. Welche Architektur für das eigene Anwendungs- und Schutzbedarfsprofil tragfähig ist, ist im Anschluss durch eine Bestandsaufnahme und Schutzbedarfsanalyse zu bestimmen.

Eine Einordnung in das Asset-Management findet sich in NIS2 Asset Management: Was erwartet das BSI?.

Diese Einordnung beruht auf den oben genannten Quellen mit Stand: 18.09.2026. Sie ersetzt keine Einzelfallprüfung durch eine qualifizierte Beratung.