MFA für VPN nachrüsten: die drei Wege im Vergleich

MFA für den Fernzugriff sauber umsetzen lassen? WZ-IT plant und betreibt Fernzugriff mit Identität und Mehrfaktorauthentifizierung - vom IdP bis zum Netzwerk, DSGVO-konform aus einer Hand. Managed Secure Access ansehen

Seit dem NIS2-Umsetzungsgesetz ist Multi-Faktor-Authentifizierung für viele Unternehmen keine Empfehlung mehr. Die praktische Frage lautet dann: Wie bekommt man einen zweiten Faktor an ein VPN, das ihn nicht vorgesehen hat? Es gibt drei Wege - unterschiedlich schnell, unterschiedlich gründlich. Dieser Artikel ordnet sie ein. Stand Juli 2026.

Inhaltsverzeichnis

• Was die Pflicht konkret sagt
• Was als zweiter Faktor zählt
• Weg 1: RADIUS mit OTP davor
• Weg 2: MFA auf der Appliance
• Weg 3: Identitätsbasiertes Overlay
• Die drei Wege im Vergleich
• Was vorher aufgeräumt werden muss

Was die Pflicht konkret sagt

Das NIS2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft. Es verpflichtet wichtige und besonders wichtige Einrichtungen zu Risikomanagementmaßnahmen, und das BSI führt darunter ausdrücklich „Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung" (BSI-Infopaket).

Zwei Punkte werden dabei oft falsch wiedergegeben:

• Die Anforderung ist nicht auf Fernzugriff oder privilegierte Konten beschränkt. Sie gilt breit und risikobasiert - der Fernzugriff ist nur der Ort, an dem sie am dringlichsten wird.
• Kontinuierliche Authentifizierung ist kein gleichwertiger Ersatz. Das BSI merkt selbst an, dass sie reaktiv ist und eine Kompromittierung nicht verhindert, sondern nur den Schaden begrenzt.

Wie NIS2 den Fernzugriff insgesamt betrifft, steht in NIS2-konformer Fernzugriff.

Was als zweiter Faktor zählt

Ein verbreiteter Irrtum, der ganze Konzepte kippen lässt: Ein Client-Zertifikat ist kein zweiter Faktor. Es liegt auf dem Gerät und ist damit ein Besitzfaktor - dieselbe Kategorie wie das Gerät selbst. Wer das Notebook übernimmt, hat Zertifikat und Zugang in einem.

Ein echter zweiter Faktor kommt aus einer anderen Kategorie: Wissen (PIN, Passwort) oder ein davon getrennter Besitz (Hardware-Token, Authenticator-App auf einem anderen Gerät, Passkey). Für WireGuard gilt dasselbe: Das Schlüsselpaar ist die Identität und der Besitz zugleich - MFA muss von einer Ebene darüber kommen.

Weg 1: RADIUS mit OTP davor

Der klassische Nachrüstweg: Ein RADIUS-Server mit Einmalpasswörtern wird dem bestehenden VPN vorgeschaltet. OpenVPN und die meisten Appliances sprechen RADIUS; die Anmeldung verlangt dann zusätzlich zum Passwort ein OTP.

Stärken: schnell umsetzbar, meist ohne Eingriff in Netzdesign und Clients, erfüllt die MFA-Anforderung.

Grenzen: Es bleibt bei einem nachgerüsteten Baustein. Zentrale Gruppen- und Rechteverwaltung entsteht dadurch nicht, und nach erfolgreicher Anmeldung steht weiterhin der gewohnte, oft flache Netzzugriff offen. Zusätzlich wird der RADIUS selbst zu einer Komponente, die verfügbar sein und gepflegt werden muss.

Passt, wenn: wenige Zugänge, homogene Nutzergruppe, kurzfristiger Handlungsdruck.

Weg 2: MFA auf der Appliance

Firewalls bringen für ihre VPN-Funktion meist eigene MFA mit, teils mit eigenem Token-System. Das ist bequem, weil alles an einer Stelle liegt.

Die Einschränkung ist strukturell: Die Prüfung findet auf dem internet-exponierten Gerät statt. Damit hängt die Wirksamkeit der MFA an der Unversehrtheit genau der Komponente, die von außen erreichbar ist. In der Praxis gab es Schwachstellen in VPN-Appliances, mit denen sich die Authentifizierung einschließlich MFA vollständig umgehen ließ - der zweite Faktor half dann nicht, weil er gar nicht erst abgefragt wurde.

Passt, wenn: die Appliance ohnehin bleibt, gepatcht wird und der Zugriff dahinter zusätzlich segmentiert ist.

Weg 3: Identitätsbasiertes Overlay

Der dritte Weg dreht die Reihenfolge um: Nicht der Netzzugang wird abgesichert, sondern die Identität wird zur Voraussetzung für Konnektivität. Ein Identity Provider - etwa das selbst hostbare Authentik oder Keycloak - prüft Nutzer samt MFA, bevor eine Verbindung entsteht. Anschließend entscheiden Zugriffsrichtlinien, welche Systeme überhaupt erreichbar sind.

Stärken: MFA, zentrale Nutzerverwaltung und Segmentierung entstehen in einem Zug. Der internet-exponierte Listener entfällt, und Protokollierung wird pro Identität und Ziel möglich - was für Nachweise deutlich mehr wert ist als ein Verbindungsprotokoll.

Aufwand: höher als Weg 1, weil Identitäten, Gruppen und Richtlinien einmal sauber modelliert werden müssen. Dafür entfällt späteres Nachrüsten.

Passt, wenn: mehrere Nutzergruppen unterschiedliche Ziele brauchen, Dienstleister- und Maschinenzugänge dazukommen oder ohnehin eine Ablösung ansteht. Die konkreten Abläufe stehen in OpenVPN zu NetBird migrieren und FortiGate-SSL-VPN zu NetBird migrieren.

Die drei Wege im Vergleich

Alle drei erfüllen die Pflicht. Sie unterscheiden sich darin, wie viel vom eigentlichen Problem sie mitlösen.

Was vorher aufgeräumt werden muss

Unabhängig vom Weg gibt es zwei Voraussetzungen, an denen Projekte sonst scheitern:

Sammelkonten auflösen. Ein geteiltes Konto lässt sich nicht sinnvoll mit einem zweiten Faktor versehen - und selbst wenn, wäre die Protokollierung wertlos, weil sich kein Zugriff einer Person zuordnen lässt. Das betrifft vor allem Wartungs- und Dienstleisterzugänge. Sie brauchen personengebundene Konten, idealerweise befristet.

Identitäten konsolidieren. Solange Nutzer in der Appliance, im Verzeichnisdienst und in einzelnen Anwendungen getrennt gepflegt werden, ist jede MFA-Einführung ein Flickwerk. Ein IdP als führende Quelle zahlt sich unabhängig vom gewählten Weg aus - Details in SSO & MFA für das Fernzugriffs-Portal.