Cisco AnyConnect MFA Options Compared: RADIUS, SAML, and Native Duo

Cisco AnyConnect is one of the most widely deployed VPN clients in enterprise environments — which makes it one of the most actively targeted.

Rapid7 and Cisco PSIRT tracked brute-force campaigns by ransomware groups Akira and LockBit specifically targeting Cisco ASA VPN authentication in 2025, and reported zero confirmed cases where a correctly configured MFA deployment was bypassed.

GreyNoise observed over 25,000 unique IP addresses scanning Cisco ASA login portals in a single spike in August 2025.

The question most administrators face isn’t whether to add MFA — it’s which approach fits their infrastructure. There are three meaningfully different paths.

Three Ways to Add MFA to Cisco AnyConnect

Cisco AnyConnect authenticates through the ASA or FTD appliance, which supports several authentication backends. The three practical options for adding a second factor are:

1. RADIUS-based MFA — a RADIUS proxy handles primary authentication against AD/LDAP and enforces a second factor via Access-Challenge before returning an Accept to the ASA
2. SAML/SSO-based MFA — the ASA delegates authentication to a cloud identity provider (Entra ID, Okta) that handles both the primary credential and the second factor
3. Native Duo integration — Cisco’s own MFA product integrates directly with ASA/FTD, with push notifications delivered via Duo’s cloud service

Each approach has a legitimate use case. The right choice depends on your infrastructure, compliance requirements, and operational constraints.

RADIUS-Based MFA

RADIUS has been the standard authentication protocol for network devices since RFC 2865, and ASA/FTD support it natively.

A RADIUS proxy sits between the ASA and your directory: the ASA sends an Access-Request with the user’s credentials, the proxy validates the password against AD or LDAP, and if successful, issues an Access-Challenge — prompting the user for their OTP. Only after both factors are validated does the proxy return an Access-Accept to the ASA.

From the ASA’s perspective, nothing changes. It’s talking RADIUS exactly as before, just to a different server IP.

What RADIUS-based MFA covers well:

On-premises and air-gapped environments. The entire authentication flow — password validation against AD, OTP enforcement, Access-Accept — happens inside your network. No authentication traffic leaves the perimeter. This matters for organizations in regulated industries with outbound traffic restrictions, for networks with physical isolation requirements, and for any environment where cloud dependencies in the authentication chain are unacceptable.

Hardware token support. RADIUS-based MFA with full OATH TOTP/HOTP support covers physical token devices without cloud dependencies or additional licensing tiers. This matters for users who can’t use smartphones — manufacturing floors, secure facilities, executives who prefer physical tokens for privileged access — and for organizations that require hardware tokens for compliance reasons.

Direct AD/LDAP integration. The proxy authenticates directly against on-premises Active Directory or LDAP without requiring a sync layer to a cloud directory. Multi-domain environments, OpenLDAP directories, and custom LDAP implementations are all supported without additional infrastructure.

The practical AnyConnect-specific consideration: AnyConnect’s challenge/response support means the Access-Challenge flow works cleanly — users see a secondary OTP prompt in the AnyConnect client after their password is accepted. For legacy configurations where challenge/response creates issues, Inline Mode (password + OTP in a single field with a configured separator) provides a fallback that works with any RADIUS client.

For organizations specifically running Cisco ASA or FTD, the RADIUS MFA for Cisco AnyConnect integration covers the full configuration path including AAA server group setup, tunnel group assignment, and timeout configuration (the default 5-second RADIUS timeout needs to be extended to at least 60 seconds for MFA — users need time to retrieve their OTP).

SAML/SSO-Based MFA

SAML-based authentication delegates the entire login flow to a cloud identity provider. When a user connects via AnyConnect, the ASA redirects the authentication request to the IdP — Entra ID (Azure AD), Okta, or another SAML 2.0-compliant provider.

The IdP handles primary authentication and MFA, then sends a signed SAML assertion back to the ASA authorizing the session.

Where SAML makes sense:

Organizations already heavily invested in Entra ID or Okta get significant operational leverage from SAML integration. If users are already enrolled in Microsoft Authenticator or Okta Verify for other services, AnyConnect MFA uses the same enrollment — no additional token management, no separate helpdesk workflow for VPN-specific MFA issues.

SAML also handles SSO across multiple applications. A user who authenticated to the IdP this session can connect to AnyConnect without re-entering credentials, depending on session policy.

Where SAML creates problems:

Every AnyConnect authentication event requires a round-trip to the cloud IdP. Internet outage, IdP availability issues, or degraded connectivity blocks VPN access. For remote workers connecting over unreliable links, this creates a failure mode where the VPN itself — the tool they’re using to reach corporate resources — fails because the authentication service is unreachable.

Hardware token support through SAML/SSO is limited to what the IdP supports. Entra ID’s hardware OATH TOTP token support requires P1/P2 licensing and involves a CSV import process for each token. HOTP tokens and third-party OATH devices outside the IdP’s approved list are difficult to accommodate. Note that SAML also requires AnyConnect 4.6 or later — environments with legacy appliances or mixed client versions may not support it across the board.

Native Duo Integration

Cisco acquired Duo Security in 2018, and Duo’s integration with ASA/FTD is tighter than any third-party option — it uses a dedicated proxy component and supports Duo-specific features like device health checks and trusted endpoint policies.

Where Duo works well:

For organizations already using Duo across their application portfolio, adding AnyConnect MFA through Duo keeps everything in one management console, one enrollment flow, and one audit log. The Duo push notification experience is well-polished, and Duo’s documentation for ASA/FTD integration is detailed and maintained.

Where Duo creates constraints:

Duo is cloud-dependent. The authentication proxy must reach Duo’s cloud service for every MFA verification. Air-gapped environments are not supported. Organizations with strict data residency requirements or outbound traffic restrictions face the same cloud-dependency problem as SAML.

Hardware token support is limited — primarily Duo D100 or basic TOTP tokens via the admin panel. Full OATH HOTP support and flexible third-party token accommodation are not a strength of the platform.

Vendor lock-in is also a real consideration: Duo’s per-user pricing has increased since the Cisco acquisition, and consolidating on Duo ties your authentication infrastructure to Cisco/Duo licensing decisions going forward.

Comparison Table and Which to Choose

Choose RADIUS-based MFA if: you need on-premises deployment, hardware token support beyond basic TOTP, air-gapped segments, direct AD/LDAP integration without a cloud sync layer, or if you want your authentication infrastructure to remain independent of any cloud vendor’s pricing and availability.

Choose SAML/SSO if: your organization is deeply invested in Entra ID or Okta, users are already enrolled in the IdP’s MFA, and you want unified SSO across VPN and cloud applications. Cloud dependency is acceptable and hardware token requirements are minimal.

Choose native Duo if: you’re already running Duo across your application portfolio, want device health checks and trusted endpoint enforcement, and are comfortable with Cisco/Duo licensing long-term.

Coalition’s 2025 Cyber Claims Report found that VPN compromise was the initial access vector in 73% of intrusions with an established entry point.

Microsoft’s data shows MFA blocks more than 99.2% of automated credential attacks. All three approaches close the password-only gap — the choice is about which constraints you can live with and which you can’t.

For environments evaluating OATH hardware tokens as part of the MFA rollout — whether for privileged users, air-gapped segments, or compliance requirements — full TOTP and HOTP support is a differentiating factor between the three approaches.

For a broader look at RADIUS MFA across VPN, Wi-Fi 802.1X, and NPS in a single deployment, the RADIUS MFA proxy page covers the architecture in detail.

FAQs

How do I add MFA to Cisco AnyConnect?

Three approaches: RADIUS-based MFA (a proxy between the ASA and your directory), SAML/SSO (Entra ID or Okta handles both credential and second factor), and native Duo integration. RADIUS is the most flexible for on-premises environments; SAML integrates best with existing cloud identity platforms; Duo suits organizations already on the Cisco/Duo stack.

RADIUS vs SAML for AnyConnect MFA — what’s the practical difference?

RADIUS validates credentials against AD/LDAP locally with no cloud dependency. SAML delegates authentication to a cloud IdP — every VPN login requires a round-trip to Azure or Okta. RADIUS supports hardware tokens and air-gapped environments; SAML provides unified SSO across cloud applications.

Does AnyConnect MFA work on-prem without any cloud dependency?

Yes, with RADIUS-based MFA. A RADIUS proxy deployed inside your network handles password validation against on-premises AD and OTP enforcement locally. No authentication traffic leaves the perimeter. SAML-based and Duo-based approaches both require cloud connectivity.

Can I use hardware tokens with Cisco AnyConnect?

Yes, with RADIUS-based MFA that supports full OATH TOTP/HOTP. SAML-based approaches depend on what the IdP supports — Entra ID requires P1/P2 licensing for hardware OATH tokens and has a cumbersome import process. Duo’s hardware token support is limited primarily to Duo D100 and basic TOTP devices.

Does MFA actually stop the VPN brute-force attacks targeting Cisco ASA?

Yes — consistently. Rapid7 and Cisco PSIRT documented that ransomware groups Akira and LockBit ran sustained brute-force campaigns against Cisco ASA VPN endpoints in 2025 and found no confirmed cases where correctly configured MFA was bypassed. The attacks succeed only against password-only configurations.