Should organisations prioritise MFA or firmware patching first for exposed VPNs?

Why the first move depends on whether the VPN is already exposed

For an internet-facing VPN, the first decision is whether the device itself is still a live exploitation path. If a known vulnerability is present, firmware patching or an effective mitigation is the containment step because MFA does not close the hole. If the main issue is stolen credentials, MFA becomes the fastest way to reduce the value of those credentials while you work the patch and monitor for abuse.

That is why the sequence matters: exposure reduction first, then authentication hardening, then monitoring. A vulnerable edge appliance can be reached before any login challenge is triggered, so the control that removes remote exploitability has priority over the control that only protects the sign-in flow.

When organisations frame the question as “MFA or patching?”, they often miss that they are protecting against two different failure modes. One is exploit of the device or service itself, the other is abuse of valid access. The right answer depends on which failure mode is active, but in a real incident both usually need treatment.

How MFA and patching complement each other on remote access

MFA is strongest when the attacker’s path depends on a password or other reusable credential. It sharply reduces the value of credential theft, password reuse, and basic phishing. For that reason, it should be enforced at every exposed entry point, especially remote access portals that terminate trust before a user reaches internal systems.

Patching is strongest when the VPN appliance, concentrator, or edge gateway has a reachable flaw that can be exploited without valid user interaction. In that case, adding MFA does not remove the attacker’s ability to hit the vulnerable service. The appliance may still be used for code execution, session theft, or authentication bypass depending on the flaw, which is why vulnerability remediation comes first when exposure exists.

A practical way to think about it is this: MFA narrows who can get in, but patching determines whether the front door itself can be broken. Both matter, but they defend different layers of the same access path.

What good sequencing looks like for exposed VPNs

The most useful order is to identify whether the appliance is actively exposed and vulnerable, then remove that exposure, then raise the authentication bar, then verify that logging and alerting can detect both login abuse and appliance compromise. That sequence is consistent with how remote-access incidents unfold in practice, where an edge device can be the initial foothold and stolen credentials can be the expansion mechanism.

Remote Access Identity Guide is the right starting point when you are deciding how VPN, MFA, ZTNA, and dormant access accounts fit together. It helps teams treat remote access as a control surface, not a single product choice.

MFA Guide is the practical reference when the question is how to reduce the value of stolen credentials, choose stronger factors, and avoid weaker deployment patterns that attackers can bypass.

CitrixBleed exploitation 2023 shows why patching and mitigation can outrank MFA when the appliance itself is the problem, because session token theft and similar flaws can bypass normal sign-in protections.

Risk and Threat Considerations

Exposed VPNs are high-value targets because they sit at the boundary between the internet and trusted internal resources. If the device is vulnerable, attackers can use the flaw to reach the appliance directly, bypassing the normal authentication decision entirely. If valid credentials are stolen, attackers can log in through a legitimate channel and blend into ordinary remote access activity.

Failure mechanism: A vulnerable edge device preserves the exploit path even when MFA is enabled, while stolen credentials preserve the login path even when the password alone is no longer sufficient. In both cases, attackers are exploiting trust placed in the remote access layer.

Impact: The result can be initial access, session theft, lateral movement, or wider environment compromise, with the blast radius determined by how much trust the VPN endpoint confers once access is established.

Practitioner Guidance

What to prioritise: If the VPN or gateway is internet-facing and a known flaw exists, patch or mitigate first, because that is the step that removes the reachable attack path. Then enforce MFA everywhere the device still accepts interactive sign-in, including admin and backup access paths.

What to verify: Confirm that the patch or mitigation actually covers the exposed instance, that the authentication policy is enforced on all entry points, and that logging captures both failed and successful sign-ins, unusual source IPs, and post-authentication activity.

Common mistake: Treating MFA as a substitute for patching. MFA reduces credential abuse, but it does not protect a device that can be exploited before authentication or hijacked after session establishment.

Practitioner takeaway: Patch what is exposed, then harden who can log in. The right security sequence is to remove the exploitable entry path first, because a stronger login control cannot compensate for a vulnerable edge device.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• How do organisations reduce the dwell time of exposed credentials at scale?
• Should organisations prioritise MFA or compromised-credential screening first?
• Should organisations prioritise patching or retiring outdated applications first?