Retrofitting MFA for VPN: the three paths compared

Want MFA for remote access done properly? WZ-IT plans and operates remote access based on identity and multi-factor authentication - from the IdP to the network, GDPR-compliant from one team. See managed secure access

Since the German NIS2 implementation act, multi-factor authentication is no longer a recommendation for many companies. The practical question then becomes: how do you get a second factor onto a VPN that was never designed for one? There are three paths - differing in speed and in thoroughness. This article places them. As of July 2026.

Table of contents

• What the obligation actually says
• What counts as a second factor
• Path 1: RADIUS with OTP in front
• Path 2: MFA on the appliance
• Path 3: Identity-based overlay
• The three paths compared
• What has to be cleaned up first

What the obligation actually says

The German NIS2 implementation act has been in force since 6 December 2025. It obliges important and particularly important entities to take risk management measures, and the BSI explicitly lists "solutions for multi-factor authentication or continuous authentication" among them (BSI information package).

Two points are frequently misreported:

• The requirement is not limited to remote access or privileged accounts. It applies broadly and risk-based - remote access is simply where it becomes most urgent.
• Continuous authentication is not an equivalent substitute. The BSI itself notes that it is reactive and does not prevent a compromise but only limits the damage.

How NIS2 affects remote access overall is covered in NIS2-compliant remote access.

What counts as a second factor

A widespread misconception that topples entire concepts: a client certificate is not a second factor. It sits on the device and is therefore a possession factor - the same category as the device itself. Whoever takes over the laptop has certificate and access in one.

A genuine second factor comes from a different category: knowledge (PIN, password) or possession separate from the device (hardware token, authenticator app on another device, passkey). The same applies to WireGuard: the key pair is identity and possession at once - MFA has to come from a layer above.

Path 1: RADIUS with OTP in front

The classic retrofit: a RADIUS server with one-time passwords is placed in front of the existing VPN. OpenVPN and most appliances speak RADIUS; login then requires an OTP in addition to the password.

Strengths: quick to implement, usually without touching network design or clients, meets the MFA requirement.

Limits: it remains a retrofitted component. It does not create central group and permission management, and after a successful login the familiar, often flat network access is still open. On top of that the RADIUS itself becomes a component that has to stay available and maintained.

Fits when: few access paths, a homogeneous user group, short-term pressure to act.

Path 2: MFA on the appliance

Firewalls usually bring their own MFA for their VPN function, sometimes with a proprietary token system. That is convenient because everything sits in one place.

The limitation is structural: verification happens on the internet-exposed device. The effectiveness of MFA therefore depends on the integrity of exactly the component reachable from outside. In practice there have been vulnerabilities in VPN appliances that allowed authentication including MFA to be bypassed entirely - the second factor did not help, because it was never requested.

Fits when: the appliance stays anyway, is kept patched, and access behind it is additionally segmented.

Path 3: Identity-based overlay

The third path reverses the order: instead of securing network access, identity becomes the precondition for connectivity. An identity provider - such as the self-hostable Authentik or Keycloak - verifies users including MFA before a connection exists. Access policies then decide which systems are reachable at all.

Strengths: MFA, central user management and segmentation arrive in one go. The internet-exposed listener disappears, and logging becomes possible per identity and target - considerably more valuable for evidence than a connection log.

Effort: higher than path 1, because identities, groups and policies have to be modelled cleanly once. In exchange, later retrofitting is unnecessary.

Fits when: several user groups need different targets, contractor and machine access are involved, or a replacement is due anyway. The concrete procedures are in Migrate OpenVPN to NetBird and Migrate FortiGate SSL-VPN to NetBird.

The three paths compared

All three meet the obligation. They differ in how much of the underlying problem they solve along the way.

What has to be cleaned up first

Regardless of the path, two prerequisites decide whether projects succeed:

Dissolve shared accounts. A shared account cannot sensibly be given a second factor - and even if it could, logging would be worthless because no access can be attributed to a person. This mainly affects maintenance and contractor access. They need personal accounts, ideally time-limited.

Consolidate identities. As long as users are maintained separately in the appliance, the directory service and individual applications, every MFA rollout is patchwork. An IdP as the leading source pays off regardless of the chosen path - details in SSO & MFA for the remote access portal.