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 verlangt eine breite Palette an Risikomanagement-Maßnahmen, die u. a. die Sicherheit von Fernzugriffen umfasst.

Detail

• 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-Empfehlungen zu Securing Remote Access in Operational Technology geben Hinweise für die OT-spezifische Absicherung.
• Sektorspezifische Anforderungen (BAIT, VAIT, TISAX für Automotive-Zulieferer, B3S Krankenhaus, KRITIS-Verordnung, IT-Sicherheitskatalog für Energieversorger) sehen regelmäßig erweiterte oder explizite Vorgaben zu Fernzugriffs-Verfahren vor.

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.

Detail

• 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 sind regelmäßig erforderlich.

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 nach BSI-Empfehlung nicht direkt ins offene Internet exponiert werden; ein VPN-Tunnel oder ein ressourcen-spezifischer ZTNA-Proxy ist erforderlich.
• Industrielle Steuerungssysteme (OT, SCADA, SPS-Wartung). Diese Umgebungen sind regelmäßig nicht cloud-native; die CISA-Empfehlungen zu Securing Remote Access in Operational Technology referenzieren VPN-basierte Lösungen mit zusätzlichen Sicherheits-Schichten (One-Way-Diode, Jump-Hosts, dedizierte Wartungs-Accounts).
• Sektorspezifische Compliance-Vorgaben. TISAX (Automotive), bestimmte Pharma- und Verteidigungs-Auflagen sowie der IT-Sicherheitskatalog für Energieversorger sehen häufig explizit Fernzugriffs-Konzepte vor, die einer VPN-Architektur entsprechen.
• 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.

Detail

• 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 sind klassisches VPN oder dedizierte Industrial-Remote-Access-Lösungen (Cosy, Secomea, TeamViewer Tensor, Siemens RUGGEDCOM u. a.) regelmäßig die geeignete Architektur. Generische ZTNA-Produkte sind für SPS- und HMI-Protokolle häufig nicht ausgelegt.
• KRITIS-Betreiber nach BSI-KritisV: Sektorspezifische Anforderungen aus dem B3S des jeweiligen Sektors.

Detail

• NIS2-pflichtige wesentliche und wichtige Einrichtungen: Erforderlich ist eine dokumentierte Fernzugriffs-Architektur mit Risikomanagement-Bezug, eine reine technische Umstellung ohne ISMS-Einbettung ist nicht ausreichend.
• Finanzsektor (BAIT, VAIT, KAIT, MaRisk): Detaillierte Vorgaben zu Fernzugriffs-Konzepten, Auslagerungs-Steuerung und Privileged Access.
• Auto-Zulieferer mit TISAX-Anforderungen: Spezifische Vorgaben zur Fernzugriffs-Architektur sind im TISAX-Katalog enthalten.
• 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

Eine erste Strukturierung der NIS2-Pflichtenlage einschließlich Fernzugriffs-Anforderungen lässt sich über den NIS2-Check anlegen. 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 2026-05-16. Sie ersetzt keine Einzelfallprüfung durch eine qualifizierte Beratung.