What breaks when cloud-only MFA is used for isolated critical infrastructure?

Cloud-only MFA breaks the continuity of identity assurance when the environment is disconnected. Operators can be locked out of critical systems exactly when they need to restore service, which turns authentication into a recovery dependency instead of a control. In regulated critical infrastructure, that failure undermines both compliance and operational resilience.

Why Cloud-Only MFA Stops Working in Isolated Operations

Cloud-only MFA assumes the authenticator, policy service, and enrolment path remain reachable when access is needed. In isolated critical infrastructure, that assumption fails the moment the network is segmented, degraded, or deliberately disconnected. The result is not just inconvenience. It creates a single point of failure for recovery access, can strand operators outside control systems, and forces teams to choose between outage recovery and identity enforcement.

Critical infrastructure teams often discover this failure mode during incident response or maintenance windows, when the environment is already under stress and the authentication dependency is least forgiving. In practice, many organisations treat MFA as a security add-on until the first disconnected recovery event turns it into an availability issue.

How It Works in Practice

Cloud-only MFA usually depends on an external identity provider to issue, validate, or refresh a second factor. That works in connected environments because the authentication workflow can reach the policy engine, time source, device registry, or push service. In isolated environments, each of those dependencies becomes fragile. If the control plane cannot be reached, users may be unable to complete login even when they hold valid credentials and are physically present at the site.

The operational problem is not that MFA is inherently wrong. It is that the trust path is longer than the environment can safely tolerate. For critical infrastructure, the design question is whether the site can still authenticate approved operators during a network outage, a vendor outage, or an emergency segmentation event. If the answer is no, identity becomes coupled to external uptime rather than local recovery capability.

Offline access paths must be planned before an outage, not improvised during one.
Recovery accounts need tightly governed fallback handling because they become high-value targets.
Local authentication services may reduce dependency on cloud reachability, but they also shift responsibility for hardening, monitoring, and revocation.

Current guidance for isolated environments increasingly favours authentication designs that preserve local continuity while still enforcing strong assurance, rather than assuming constant reachability. NIST’s Zero Trust model is useful here because it emphasises continuous verification and explicit trust decisions, while critical infrastructure guidance from CISA highlights the operational need to maintain secure access during degraded conditions. For broader governance of network-dependent resilience, the EU NIS2 Directive reinforces that security controls must support operational continuity, not just policy intent.

The point is not to abandon MFA, but to avoid making a remote service the only path to operator legitimacy. NHIMG’s research on non-human identity management shows that organisations already struggle with consistent access across hybrid and multi-cloud environments, and that difficulty becomes more severe when access must function without dependable connectivity. These controls tend to break down when the environment is air-gapped, intermittently connected, or protected by strict segmentation because the identity workflow silently inherits the weakest external dependency.

Common Variations and Edge Cases

Tighter authentication usually improves assurance, but in isolated operations it also increases the chance that security controls interfere with restoration. The trade-off is especially sharp where operators need emergency access during a safety event, because the most restrictive login path may be the one least available under fault conditions.

Not every disconnected environment needs the same answer. A lightly segmented plant network, a truly air-gapped system, and a remote site with intermittent backhaul each impose different assumptions about local identity services, backup factors, and break-glass procedures. Best practice is evolving, but there is no universal standard that says every MFA flow must be cloud-hosted.

What matters most is whether the fallback path is itself governed. A locally trusted offline factor can preserve continuity, but only if it is inventoried, rotated, monitored, and disabled cleanly after use. A poorly managed emergency path can become a more durable exposure than the cloud dependency it replaced.

In practice, security teams need to distinguish between authentication failures that are acceptable in office IT and authentication failures that would halt a control room, lock out a restoration console, or delay a safety-relevant change. The same MFA design can be strong in one environment and operationally unsafe in another.

Risk and Threat Considerations

The material risk is loss of recoverable access at the exact moment an isolated environment needs local control. In critical infrastructure, that can turn an identity service into a single point of operational failure and create pressure to bypass controls informally.

Failure mechanism: Cloud-only MFA depends on external reachability for enrolment, validation, or factor approval. When connectivity is absent or degraded, legitimate operators cannot complete authentication, so teams either delay restoration or fall back to weaker manual workarounds and shared access paths.

Impact: The consequence is lockout of authorised personnel, slower incident recovery, and increased likelihood of uncontrolled exception handling. In regulated environments, that also weakens auditability and can undermine resilience obligations.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the technical controls, and NIS2 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	Cloud-only MFA breaks identity assurance and access continuity in isolated operations.
Recommendation — Design authentication paths that still work during isolation and outage conditions.
NIST Zero Trust (SP 800-207)	3.0 — Zero Trust Principles	The question concerns trust decisions that must remain explicit and resilient when connectivity is lost.
Recommendation — Preserve explicit trust decisions without depending on a remote control plane.
CIS Controls v8	6.3 — Access Control Management	Isolated critical infrastructure needs governed fallback access and tightly controlled recovery paths.
Recommendation — Inventory and govern emergency access so outage recovery does not rely on ad hoc exceptions.
NIS2	Art. 21 — Cybersecurity risk-management measures	Critical infrastructure identity controls must support resilience and operational continuity under disruption.
Recommendation — Align authentication design with continuity and resilience obligations for essential services.
OWASP Non-Human Identity Top 10	NHI-06 — Secrets and Credential Lifecycle	Cloud-only MFA often introduces dependent credentials and fallback paths that need lifecycle control.
Recommendation — Rotate and govern any offline fallback credentials and keep their blast radius minimal.

Practitioner Guidance

What to prioritise: Treat operator continuity as the primary requirement, not cloud preference. If the site must be recoverable without external connectivity, the authentication design must support that condition explicitly.

Decision rule: If a control room, engineering workstation, or safety-relevant admin path must function during isolation, do not rely on a cloud-only second factor as the sole gate to access.

What to verify: Verify that the offline or local fallback is tested under real outage conditions, not only in planned maintenance, and that break-glass access is limited, time-bound, and attributable.

Common mistake: Teams often assume the cloud MFA provider is a security control boundary, when in this setting it is actually a dependency boundary. That assumption fails when the network path disappears.

Practitioner takeaway: The right design is the one that preserves strong identity assurance without making external availability a prerequisite for restoring the facility.