SOCI 8B and 8C turn MFA into an isolation requirement

At a glance

What this is: RSA Security’s analysis explains how Australia’s SOCI 8B and 8C amendments turn MFA, least privilege, and access review into resilience requirements for critical infrastructure.

Why it matters: For IAM and NHI teams, the key issue is that authentication and governance controls must keep operating when cloud dependencies are removed, which changes design, testing, and recovery planning.

Context

Australia’s SOCI amendments now tie critical infrastructure identity controls to isolation and recovery conditions, not just steady-state access. The article focuses on Section 8B credential compromise hazards and Section 8C lateral movement hazards, both of which push phishing-resistant authentication and governance deeper into operational resilience.

The problem for practitioners is straightforward: a control that depends on a cloud identity service is fragile if the environment must keep running while disconnected for months. For CI operators, the question is no longer whether MFA exists, but whether authentication, least privilege, and access review still function when the environment is isolated.

That makes this an identity governance issue as much as an authentication issue. The article’s starting point is typical for critical infrastructure, where OT and recovery constraints make cloud-first assumptions harder to defend.

Key questions

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

A: 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.

Q: Why do SOCI 8B and 8C make authentication a resilience issue?

A: Because the rules require critical systems to keep operating while the environment is isolated or being restored. If authentication stops working during that period, identity control becomes a single point of operational failure. For critical infrastructure, identity assurance now has to be available under outage conditions, not only under normal network conditions.

Q: What is the difference between least privilege and access review?

A: Least privilege is the design principle that limits access to what is required, while access review is the governance activity that checks whether current access still matches that principle. You need both. One sets the target state, the other detects entitlement drift and exception creep.

Q: How should critical infrastructure teams test IAM against isolation requirements?

A: They should exercise authentication, privileged access, and review workflows inside the same isolated operating model they expect in production. The test is whether governance still works when cloud dependencies are removed, not whether the controls function in a normal connected environment. If they fail in isolation, they are not meeting the SOCI intent.

Technical breakdown

Why cloud-only phishing-resistant MFA fails in isolation

Phishing-resistant MFA reduces token theft and replay risk, but the control only works if the authentication path remains available. In isolated critical infrastructure, a cloud dependency becomes a single point of failure because the identity provider itself may be unreachable during an outage or recovery event. That shifts the design question from factor strength to deployment resilience. The practical issue is not whether the factor is phishing-resistant, but whether it can authenticate users, operators, and privileged accounts when the network is cut off from the cloud.

Practical implication: Design phishing-resistant MFA so it continues to authenticate in air-gapped or semi-air-gapped operating states.

How 8C turns least privilege into an operational recovery control

Section 8C links lateral movement reduction to the ability to keep systems operational while other assets are being restored. That means least privilege is no longer just a pre-breach access design pattern. It becomes a recovery control because excessive standing access increases the blast radius during rebuild, when teams need constrained but functioning access pathways. Access review also matters more here because operators must know which roles are still valid when parts of the environment are isolated, restored, or temporarily rebuilt.

Practical implication: Map privileged roles and recovery access paths before isolation so rebuild teams can operate without broad emergency access.

Why access review must still work when the environment is disconnected

Access review in this context is not a periodic compliance exercise. It is the mechanism that proves who can reach critical systems while the environment is under restoration and while normal connectivity is absent. If the review workflow depends on cloud services, the control can fail precisely when audit evidence and access assurance are most needed. The governance problem is that many IAM programmes treat review as a SaaS process, while SOCI requires it to remain usable inside the isolated operating model.

Practical implication: Test access review, attestation, and privileged role validation inside the same isolation model as the production environment.

NHI Mgmt Group analysis

Cloud-dependent MFA creates an isolation gap: SOCI 8B does not merely ask whether authentication is phishing-resistant. It exposes the assumption that identity services will always be reachable when operators need them. That assumption fails in isolated critical infrastructure because the control boundary now includes the recovery state, not just the steady-state environment. Practitioners should treat authentication continuity as part of resilience architecture, not a separate IAM concern.

Least privilege becomes a recovery constraint, not just an access policy: Section 8C ties lateral movement prevention to the ability to keep essential services running during restoration. That means broad emergency access is no longer a harmless workaround, because it undermines the very isolation posture the rule is trying to enforce. The right lens is blast radius during recovery, where role design directly affects operational survival.

Access review must survive the same outage conditions as production: If review and attestation live only in the cloud, they stop being governance controls and become unavailable dependencies. SOCI is effectively requiring auditability inside disconnected operating states, which is a stronger test than many IAM programmes currently pass. The implication is that governance workflows must be deployable where the assets actually run.

Isolation-ready identity governance: This article surfaces a specific control pattern that critical infrastructure teams now need to name and test. Identity controls must remain enforceable when connectivity is severed, recovery is in progress, and operational teams are under pressure to restore service. Practitioners should reclassify authentication, privilege, and review as continuity controls with audit consequences.

CI fortification shifts the market question from feature parity to deployment model: The distinction now is not which MFA method a vendor supports, but whether the identity stack can function on-premises, air-gapped, and during failover without breaking governance. That changes procurement criteria for critical infrastructure and makes recovery-capable identity architecture a baseline expectation. Teams should evaluate their own dependency graph before compliance deadlines force the issue.

What this signals

Isolation-ready identity governance: Critical infrastructure programmes should stop treating MFA, privilege, and access review as separate workstreams. SOCI 8B and 8C show that these controls now have to function as a single operating model when the environment is disconnected, restored, and audited at the same time.

The immediate programme signal is to test whether identity workflows depend on the cloud for issuance, attestation, or operator access. If they do, the organisation has a recovery gap, not just a deployment choice, and that gap will surface when the environment is under the most pressure.

For practitioners

• Validate authentication during isolation Test whether phishing-resistant MFA still works when cloud connectivity is removed, including for privileged and unprivileged access paths to critical systems.
• Map recovery access before rebuild starts Document which roles can restore critical systems, which accounts are temporary, and how least privilege is preserved while other computers are in restoration.
• Prove access review inside the isolated model Run attestation and access review workflows in the same on-premises or air-gapped conditions that SOCI 8C expects during continuity operations.
• Separate cloud dependency from identity assurance Identify where your current identity stack depends on SaaS availability and decide which critical access paths need a deployable offline fallback.
• Rehearse restoration with governance controls active Use recovery exercises to confirm that authentication, role checks, and audit evidence still function while systems are being rebuilt after isolation.

Key takeaways

• SOCI 8B and 8C shift MFA from a login control to a resilience control for critical infrastructure.
• Cloud-only identity dependencies are now a governance problem because they can lock operators out during isolation and recovery.
• Practitioners need to prove that authentication, least privilege, and access review still function when critical systems are disconnected.

Key terms

• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Isolation-Ready Identity Governance: An identity governance model designed to keep authentication, privilege control, and access review usable when systems are disconnected from external dependencies. It matters in critical infrastructure because operational continuity and auditability must survive isolation, not pause until restoration finishes.
• Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.