What should teams do when some systems cannot support strong MFA yet?

How to handle systems that cannot yet support strong MFA

When strong MFA is not technically available, the decision should be handled as an exception process, not a quiet exception in practice. The real question is whether the remaining access path is bounded, owned, monitored, and time-limited enough that the weaker control does not become a standing security hole.

That means compensating controls should be tied to a specific system, specific users or service path, and a specific remediation target. The exception should describe what is being accepted, what extra control is reducing the exposure, and what condition will trigger closure or escalation.

For systems where authentication strength cannot be raised immediately, teams should also separate temporary operational necessity from long-term architecture. If the system is critical and the gap will last, the right response is usually to reduce exposure around it rather than treat the missing MFA as acceptable business as usual.

What makes a weak-MFA exception safe enough to approve?

A defensible exception has three properties: explicit risk acceptance, a named owner, and a sunset date. Without all three, the exception becomes ambiguous, ownership drift sets in, and no one is accountable for closing the gap before it hardens into policy by neglect.

The compensating control should match the exposure. If the system handles administrative access, high-value data, or remote entry, the fallback control set should be materially stronger than a routine access exception. In practice, that often means tighter network restriction, stronger session monitoring, narrower user scope, and closer review of every account with access.

Good exception handling also creates auditability. Teams should be able to show why the system could not support stronger MFA, who accepted the residual risk, what was deployed instead, and how the exception will be revalidated before expiry.

How to stop weak authentication from becoming permanent

The main operational failure is not the temporary gap, it is exception drift. Once a workaround is accepted, it can survive product upgrades, ownership changes, and environment changes unless someone is explicitly responsible for rechecking the assumption.

That is why remediation deadlines matter. They force a decision between upgrading the system, replacing it, segmenting access more tightly, or removing the dependency entirely. Systems that cannot support stronger authentication often expose a broader design issue, so the exception should trigger an architecture review, not just a ticket.

Where possible, use the exception period to shrink the blast radius. Limit which roles can reach the system, restrict administrative paths, and increase logging so the weaker factor does not sit alone as the only practical barrier to misuse.

Risk and Threat Considerations

Systems that stay on weaker authentication for too long create an easy target for account takeover, credential stuffing, and phishing success, especially where the compensating controls are informal or inconsistently applied. The larger danger is not just that access is weaker, but that attackers learn which path is least defended and focus on it.

Failure mechanism: A temporary exception becomes a standing access path when ownership is vague, compensating controls are not enforced, or the remediation date is never revisited. That turns the system into a durable weak point that can survive normal control reviews.

Impact: Residual access risk stays elevated until the exception is closed, and the exposed system can become the route an attacker uses to pivot into better protected assets, especially if it has administrative reach, sensitive data, or trusted integrations.

Practitioner Guidance

What to prioritise: Classify every unsupported MFA case as an exception record with an owner, expiry, and a documented compensating-control set. If you cannot name the owner or the expiry, the control is not ready for production reliance.

What to verify: Confirm that the fallback control actually changes the risk, not just the paperwork. The most useful check is whether the exception meaningfully reduces reachability, monitoring gaps, or privilege scope compared with leaving the account untouched.

Common mistake: Treating the exception as “temporary” without forcing a closure path. Temporary exceptions often become inherited exceptions, and inherited exceptions are where assurance degrades fastest.

Practitioner takeaway: Weak MFA is tolerable only when the exception is tightly governed, aggressively time-boxed, and actively driving remediation, because unmanaged exceptions quickly become the programme’s default weak link.

Related resources from NHI Mgmt Group

• How should healthcare security teams reduce identity risk on legacy medical devices that cannot support MFA?
• How should security teams protect Office 365 tenants when some authentication methods do not support MFA?
• What happens when legacy systems cannot support MFA in an identity security programme?
• What should teams do when a critical F5 BIG-IP flaw is reported but some systems cannot be patched right away?