2FA for VPNs: OpenVPN, Cisco AnyConnect, and FortiClient (2026)

A VPN login is the only credential most companies hand out that grants a network instead of an account. Get past it and you are a laptop on the office LAN: file shares, printers, intranet sites, admin panels, the flat network where everything still trusts everything. One phished password to a SaaS tool leaks one tenant; one phished password to the VPN is a seat inside the perimeter. VPN credentials get stuffed, phished, and resold constantly, for exactly that reason.

The second factor guarding them is nearly always a TOTP code or something shaped like one — a push, a passcode, an identity-provider login with its own MFA attached. How those codes work is covered in what TOTP is; this post is about where the factor actually lives in each VPN stack, which is almost never where people go looking for it.

Where the second factor actually lives

Not in the client. AnyConnect, FortiClient, OpenVPN Connect, OpenConnect — these apps are relays. The authentication happens at the VPN server, or at an identity provider standing behind it, over one of three worn channels: LDAP against Active Directory, the classic; RADIUS, which usually fronts an MFA provider; or SAML to an identity provider such as Okta or Entra ID, which brings its own MFA and access policies along. The client's job is to carry prompts back and forth and get out of the way.

This one fact answers half the questions in any VPN forum thread. "Does OpenConnect support 2FA?" is the wrong question — the client supports whatever the server enforces, because the client is not the one deciding. If you want a different second factor, you change the server's configuration or the identity provider behind it. Client choice changes look and feel, not authentication.

OpenVPN: two products, two answers

Access Server, the commercial build, has TOTP built in. An administrator turns MFA on globally, per group, or per user in the admin web UI, and each user enrolls a secret by scanning a QR code at the client web UI on next sign-in; the AS documentation covers the toggles. One honest limit: built-in TOTP does not combine with SAML authentication — when you federate to an identity provider, that provider is expected to carry the MFA. The homelab-side walkthrough of all this lives in self-hosted 2FA.

The community edition — the open-source server most people actually run — ships with no built-in user management beyond certificates and whatever backend you wire it to. The server hands username and password checks to PAM, or to LDAP and RADIUS through its plugin interfaces, and the classic pattern for over a decade has been PAM plus the google-authenticator module: every user gets a TOTP secret, and the code rides along with the password or arrives as a second prompt, depending on how you wire it. Half the tutorials on the internet are variations on this recipe. If you are building the verification side yourself rather than installing it, implementing TOTP covers the server math.

And the distinction that trips people up: certificates and MFA are different axes. A client certificate says which device is allowed to connect; a TOTP code says which human is asking. Neither answers the other's question, and serious setups use both.

Cisco AnyConnect

AnyConnect is the client for remote-access VPNs terminated on Cisco ASA and FTD firewalls, and it has since been folded into Cisco Secure Client. It does no authentication of its own. MFA arrives on the firewall side over RADIUS or SAML: point it at Duo — which Cisco owns, so the pairing is everywhere — or Okta, or Entra ID, and the login gains a second act. The classic flow is password in the client first, then the secondary prompt: a push lands on your phone, or a second field wants a passcode.

The push variant carries the usual caveat — approval prompts can be fatigue-bombed, which is why number matching exists. How 2FA gets bypassed ranks where push sits among the attacks that actually work, and the Duo guide covers the hardening from the user's side. The short version: "approve" is a factor only as long as the human pressing it is paying attention.

FortiClient and FortiGate

Fortinet's stack splits the same way: the FortiGate firewall terminates the VPN — SSL-VPN or IPsec — and FortiClient is the endpoint app. The native second factor is FortiToken: an app that puts rolling one-time codes on your phone, plus hardware tokens, enforced per user or per group on the firewall. RADIUS and SAML are on the menu too, so everything said about identity providers above applies here. Fortinet's documentation portal carries the configuration guides.

The uncomfortable note, kept short: Fortinet's SSL-VPN has spent recent years as one of the most-attacked VPN gateways on the internet, with a run of seriously exploitable vulnerabilities — several of them pre-authentication and actively exploited in the wild. MFA raises the cost of a stolen password and does nothing about a hole in the gateway itself. Patching is the companion control, not an alternative; the two cover different failure modes, and skipping either one leaves the other exposed.

OpenConnect

OpenConnect is the open-source client that speaks the AnyConnect protocol — and GlobalProtect, among others — for Linux laptops and anyone who would rather not run a vendor installer; its site lists the protocols it supports. The authentication story is inherited wholesale: whatever the server enforces, the client relays. The Duo push, the TOTP prompt, the SAML web login — it all arrives through the same flow, because the server is speaking protocol, not checking logos. Endpoint-compliance scans aside, the MFA flow is the MFA flow, and choosing a different client does not change which factors your users can present.

WireGuard: no usernames, nothing to type

WireGuard made a different design decision: there are no users, only keys. Each peer is a Curve25519 public key, the handshake authenticates both ends cryptographically, and the protocol contains no password prompt anywhere. That removes an entire attack class — there is nothing to phish, nothing to stuff — and it removes the MFA attachment point with it. The tunnel cannot ask "which human," because the question does not exist in the protocol.

So the factor arrives as an overlay: a portal that issues peer configurations only after authentication, or an identity-aware mesh that signs users in through your identity provider and manages keys underneath. For a small team, protecting the portal and treating key issuance as the controlled act is the honest pattern. A company that needs per-connection proof of personhood is shopping for a different product.

The zero-trust drift

The reason VPN MFA so often feels bolted on is that network-level access is an old model being asked to do identity work. Zero-trust network access inverts it: instead of one tunnel to the flat network, each application gets its own tunnel, opened per request, after the user authenticates to an identity provider — with MFA and policy baked into every decision. The VPN is not dying; site-to-site links, full-tunnel road warriors, and regulated networks keep it employed. But for remote access to internal apps, the direction of travel is per-app access with identity at the center, and MFA comes along by construction.

The pattern under all of them

Whichever stack you operate, the division of labor is the same: certificates say which device, TOTP or SAML says which human. Enforce the second factor at the server or the identity provider, never at the client. Test the admin lockout path before you need it, because a VPN administrator locked out at 2 a.m. is its own incident. And patch the gateway — MFA is not a patch.

And while the VPN gets modern authentication, the rest of your logins still run on TOTP: the registrar, the hosting panel, the SaaS tools that administer all of this. The vault on this site stores those secrets zero-knowledge — create a free account and entries are encrypted in your browser before upload, so the server holds ciphertext only, and codes still generate fully offline in the installed app.

Frequently asked questions

Does OpenVPN support two-factor authentication?

It depends which OpenVPN. Access Server has per-user TOTP built in, enforced from the admin web UI, with each user enrolling a secret at next sign-in. The open-source community edition has no built-in user authentication beyond certificates and your choice of backend: wire it to PAM or RADIUS and add TOTP there — most classically with the google-authenticator PAM module — or front the whole thing with an MFA provider.

How do I enable MFA on Cisco AnyConnect?

Not in the client — on the ASA or FTD firewall that terminates the VPN. Configure RADIUS or SAML authentication and point it at your MFA provider: Duo, Okta, Entra ID, and so on. The user experience is a password in the client first, then the second act — a push approval or a passcode prompt — relayed through the same connection. The client app itself needs no configuration for any of it.

What is FortiToken?

Fortinet's own second factor. FortiToken Mobile is a phone app that generates rolling one-time codes, and there are hardware token form factors as well, enforced per user or per group on the FortiGate. The firewall also speaks RADIUS and SAML, so FortiToken is the native path rather than the only one. Whether tokens are included with your hardware or licensed separately depends on the bundle, so check your entitlements before budgeting.

Can WireGuard use 2FA?

Not natively, and by design rather than omission: the protocol authenticates peers by public key and has no username or password anywhere to challenge. Adding a second factor means putting it in front of the tunnel — an SSO portal that issues peer configurations after authentication, or an identity-aware overlay that manages keys underneath. There is nothing in the handshake to type, which is both the appeal and the limit.

Do client certificates replace MFA on a VPN?

No — they answer a different question. A certificate proves which device connected; a TOTP code or an identity-provider login proves which human asked. A certificate file copied off a compromised laptop authenticates whoever holds it, so device trust and user trust fail independently. The strong pattern is both: certificates to pin the device, TOTP or SAML for the person.