SOCI 8B and 8C: Security After the Internet Cable Is Unplugged

The internet uplink is disconnected. The server lights are still green. Then an operator tries to sign in and discovers that the authentication service is on the other side of the connection. The equipment has power, but the team has lost a dependable way to operate it.

This fictional scenario captures the question behind RSA's discussion of SOCI 8B and 8C: can critical infrastructure preserve strong identity controls while continuing essential services during isolation and recovery? RSA emphasizes authentication continuity. For operators, that is an architectural requirement to investigate, not simply a product feature to purchase.

The practical answer is to design isolation and access together. Decide what must remain available, which dependencies can be removed, who may still act, and how those decisions will be enforced and recorded when normal infrastructure is unavailable.

First, understand the Australian scope and deadlines

SOCI refers to Australia's Security of Critical Infrastructure Act. The 8B and 8C provisions discussed here are in the Critical Infrastructure Risk Management Program Rules, or CIRMP Rules. They should not be confused with identically numbered provisions in the Act itself. This article is an educational engineering overview, not legal advice or a compliance determination for your organisation.

The enhanced regime covers specified broadcasting, DNS, electricity, energy-market, freight, gas, liquid-fuel, and water assets. Owning a server rack alone does not establish applicability. Confirm your asset classification and applicable obligations with your regulatory and legal advisers.

The Department of Home Affairs' June 25, 2026 town hall explains that the enhanced rules commenced on June 10, 2026. For existing in-scope assets, the substantive measures have a June 10, 2028 compliance date, while specified material-risk measures have an earlier June 10, 2027 date. Later-designated assets have asset-relative grace periods under the rules. Do not treat June 2028 as permission to postpone every obligation.

Section 8B: protect credentials without creating a lockout

Under the registered amendment, 8B applies when the chosen framework does not require phishing-resistant MFA. Its controls address identified internet-connected, critical-component, and remote access, including privileged and unprivileged users. They specify phishing-resistant MFA and centrally logged, monitored, routinely reviewed authentication successes and failures.

Framework requirements differ. An Essential Eight maturity label does not apply indiscriminately to ISO 27001 or NIST CSF. Reasonably-practicable risk-management duties remain where specified measures cannot be implemented: this is not a blanket exemption.

ASD's MFA guidance distinguishes stronger public-key-based methods from weaker approaches such as SMS. It also emphasizes hardening and restricting access to the authentication service. A security key is only part of the system: the verifier, endpoint, recovery path, and policies still matter.

For an isolation design, ask a separate availability question: can a properly authorized operator complete a fresh login when external identity services are unavailable? An existing session continuing to work does not answer that question. Test fresh authentication, expired sessions, and loss of the normal administration path independently.

Section 8C: contain movement and preserve operations

Section 8C addresses critical-system inventories, connections, recovery, and continued availability. Specified measures include segregation, operational independence, least privilege, controlled and monitored connections, and at least three months of operation during other computers' restoration or recovery. Consult the official rules for the exact conditions, not a universal 90-day shutdown rule.

Three months is not always 90 days. More importantly, operational independence is not the same as keeping a powered-on rack in a disconnected room. You need a service that authorized staff can operate, monitor, and recover throughout the required period.

ASD's CI Fortify guidance recommends the capability to isolate vital OT and enabling systems for three months while maintaining critical services, alongside the ability to rebuild those systems. It calls for graduated planning and warns that isolation can break business processes. The goal is continuity under controlled conditions, not disconnection for its own sake.

Find the dependencies hidden behind the cable

ASD's July 2026 isolation guidance identifies dependencies including identity, DNS, address assignment, certificates, time services, shared virtualisation, storage, and backups. It also distinguishes physical separation from the ability to disconnect and keep operating. Distributed and internet-facing services may need different approaches where complete physical isolation is not operationally feasible.

For your own service, turn that into a dependency worksheet. For each dependency, record its owner, what fails when it is lost, the approved isolated-mode arrangement, how long that arrangement remains valid, and the evidence required before reconnection. Include vendor and peer-service connections, not just the most obvious internet uplink.

A useful design question is: what stops working tomorrow even though it works today? A certificate can approach expiry, a log store can fill, a new shift may need access, or a necessary recovery package may exist only outside the boundary. These are proposed failure cases to investigate, not claims about a particular operator's installation.

Build an authentication capability that can stand alone

Begin with one critical service and its approved operator roles. Define which identities and policy information the isolated environment needs, who maintains them, and how authority changes during the incident. A local identity component needs its own protection and recovery plan; moving software on premises does not automatically make it trustworthy.

Plan both access and denial. Can the next authorized shift sign in? Can the local team disable a lost authenticator or a departed user's access without reaching a cloud console? What happens when the disconnected copy of a policy becomes stale? Assign owners to these decisions before a crisis forces an improvised answer.

Keep a controlled emergency-access process for situations where normal authentication cannot be restored promptly. Avoid an undocumented shared password or a permanent hidden backdoor. Define authorization, custody, use records, post-use review, and how normal controls are restored. Our break-glass recovery article explores that distinction. Any fallback needs an explicit risk assessment; convenience does not establish regulatory compliance.

RSA describes its sovereign deployment and hybrid failover capabilities as ways to support phishing-resistant authentication in disconnected environments. That is a vendor-described approach, not an independent HackWednesday product test. Ask RSA or any shortlisted supplier to demonstrate your required login, revocation, logging, recovery, and reconnection scenarios in the exact proposed architecture.

Exercise isolation safely, not dramatically

Do not test this by unexpectedly pulling a cable in production. NIST SP 800-82 Rev. 3 treats OT security alongside performance, reliability, and safety requirements. Start with a tabletop and a representative test environment. Any live exercise needs the operator's approved change process, safety assessment, rollback plan, and responsible decision-makers.

The following is a proposed exercise sequence, not a SOCI certification checklist or evidence of a test HackWednesday has run.

Before the exercise

Choose a measurable service outcome, such as an agreed minimum operating capability, rather than simply checking that servers respond. Name the incident lead, operations lead, identity owner, and person authorized to stop the exercise. Document the planned boundary, allowed communications, expected failure cases, and abort conditions.

During the exercise

Remove the agreed external dependencies in the test environment. Require a fresh operator login and verify that an unauthorized account is denied. Perform an approved representative task, check audit evidence, and exercise the documented recovery path. Introduce controlled scenarios for authenticator loss, session expiry, and an unavailable administrator.

A short drill does not prove three months of endurance. Support longer-period planning with a dependency schedule covering certificate and credential validity, policy changes, storage growth, spares, and staffing. Verify assumptions through appropriate staged tests. Do not change production clocks to simulate future expiry.

Before reconnection

Require an explicit decision about what is safe to reconnect. Reconcile identity changes and locally collected logs, investigate unexpected access, and validate restored configurations. Record which checks passed, which remain uncertain, and who accepts any remaining operational risk. Reconnection is another security transition, not the automatic end of the incident.

Give leadership evidence, not a compliance slogan

A useful review pack contains the scoped service and legal-obligation mapping, a dependency map, approved isolated-mode access rules, exercise results, unresolved gaps, and an accountable owner for each next action. State clearly whether a result came from a tabletop, test environment, or approved operational exercise. Those are different levels of evidence.

If AI agents help collect evidence or prepare recovery changes, keep their permissions narrower than the incident lead's authority. An assistant should not reconnect networks, expand access, or clear a safety condition merely because a task appears blocked. Use the same independently enforced boundaries discussed in our Zero Trust AI agent guide.

The strongest question for this Wednesday is simple: if the external connection disappears, can the right people still operate the service while the wrong people remain locked out? A credible answer names the dependencies, the decision-makers, and the tests that support it.

Follow the Wednesday Brief for practical security analysis. Download the unplugged-rack artwork.

Sources checked September 6, 2026. This is an AI-assisted educational article awaiting human editorial review, not legal advice, a compliance attestation, or an independently tested vendor recommendation. Confirm current requirements and asset-specific applicability with your advisers and the relevant authorities.