Your Second Factor Is Only as Strong as the Door It Guards: Auditing MFA at the VPN Layer

Ask any managing partner what protects client data at their firm and the answer arrives before you finish the question: multi-factor authentication. MFA has become the profession's security talisman — cited on cyber insurance applications, referenced in engagement letters, and checked off during peer reviews. But a credential is only meaningful in the context of the system that validates it, and for remote accounting work, that system is very often the VPN.

What we found when we examined the authentication behavior of leading VPN providers is uncomfortable: the second factor firms believe is protecting them frequently isn't where they think it is, or doesn't exist at all at the layer that matters most.

Two Products, Two Very Different Problems

The first complication is that "VPN" describes two distinct products that accountants tend to conflate.

Consumer and privacy-focused VPNs — the services we review regularly on this site — encrypt traffic between a user and the public internet. Most of them require nothing more than an email and a password to establish an account. Some offer two-factor authentication for the account dashboard; a surprising number don't, or treat it as optional. When your bookkeeper spins up a $3-a-month VPN on a laptop in a coffee shop, the encryption may be excellent. The front door may be a paper lock.

Business VPNs and zero-trust network access (ZTNA) platforms, by contrast, are built around identity. They integrate with identity providers like Okta, Microsoft Entra ID, or Duo, and they can enforce conditional access: device health, geographic checks, and role-based permissions before a tunnel ever opens.

The trap is that firms deploy the first kind while assuming the protections of the second.

Where the Second Factor Actually Lives

To grade this properly, you have to trace the authentication chain end to end. Consider a typical remote CPA session:

1. The user authenticates to the VPN client or application.
2. The VPN establishes an encrypted tunnel.
3. The user authenticates again to the tax software, cloud document management system, or remote desktop gateway.

MFA applied at step three does nothing to protect step one. If an attacker compromises the VPN credential — through phishing, credential stuffing, or a reused password — they may sit inside the tunnel, observing traffic or positioning for lateral movement, long before the firm's carefully configured MFA prompt ever appears.

In our review of provider documentation and configuration defaults, we graded each service on a simple question: can the second factor be enforced at the tunnel itself?

• Enterprise-grade platforms (the tier that includes major ZTNA vendors) generally earn an A. MFA is enforced at connection time, tied to the identity provider, and cannot be bypassed by the end user.
• Business-tier offerings from consumer VPN brands earn a mixed B-to-C. MFA may be available for the admin console but optional — or absent — for client connections.
• Consumer plans largely fail this test. Authentication to the VPN is the account credential, full stop. If that account is protected by MFA at all, it's protecting your billing settings, not your tunnel.

The Settings to Change Before Busy Season

For firm leaders, the practical work is straightforward, and it should be completed before January's volume makes everything harder.

Map your actual tunnel. Document every VPN in use — including the one your outsourced bookkeeper installed on their own. You cannot secure an entry point you haven't inventoried.

Enforce, don't offer, MFA. If your VPN solution supports mandatory two-factor at connection, enable it at the policy level so individual users can't opt out. If it doesn't, the product is wrong for client data, regardless of its encryption marketing.

Tie the VPN to your identity provider. SSO integration does more than reduce password fatigue. It centralizes deprovisioning — the moment a seasonal employee or departed associate should lose access — and gives you one place to review sign-in logs.

Add device trust where available. The strongest configurations verify not just who is connecting but what is connecting. Certificate-based device checks or managed-device requirements close the door on a stolen credential being used from an unmanaged machine.

Test the bypass paths. Some VPN clients retain legacy authentication methods — a fallback protocol, a shared group password, a port that predates the MFA rollout. Attackers look for these. So should you.

The Insurance Angle Is Coming

Cyber insurance underwriters have already begun asking pointed questions about remote access controls, and the interrogation is getting more specific each renewal cycle. "Do you use MFA?" is giving way to "Where is MFA enforced?" A firm that can answer the second question with documentation — screenshots of enforcement policies, identity provider logs, a written remote access standard — will fare materially better than one that can only answer the first.

Multi-factor authentication remains one of the highest-value controls available to a small firm. But it is a control, not a charm. The chain protects client data only where it is actually fastened — and for too many accounting practices, the loosest link is the one nobody thought to inspect: the login to the tunnel itself.