OT isolation crisis: will encrypted connections keep working?

In an OT isolation crisis, critical infrastructure operators cut vital operational technology off from the internet, cloud services and third-party networks, then keep essential services running from inside that boundary. For encrypted connections, this raises a practical question: will the links between your own substations, plants and control centres keep working when every outside dependency is gone?

This article explains what the joint CI Fortify guidance expects, which parts of a quantum-safe encryption setup keep working in island mode, which parts tend to fail without warning, and how to show it works before a real crisis.

What does the CI Fortify guidance require when critical infrastructure isolates vital OT systems?

CI Fortify asks operators to plan for disconnecting vital OT from all other networks and to keep it running in that state for a long time. Encryption design has to fit inside that plan.

The joint publication, CISA CI Fortify - Advice for Isolating Vital Systems, was published by the Cybersecurity and Infrastructure Security Agency, Australian Signals Directorate (ASD), United Kingdom’s National Cyber Security Centre (NCSC-UK), and Canadian Centre for Cyber Security (CCCS). The work was led by ASD, through the Australian Cyber Security Centre (ASD’s ACSC), and released on 28 July 2026. It contains practical steps for critical infrastructure (CI) organizations to isolate vital operational technology and enabling systems from all other networks in the event of disruption or crisis and operate in isolation for an extended period.

According to CISA’s release, the main themes are identifying and mapping vital systems and connections, building effective separation points, graduated isolation planning and regular testing. The planning assumption behind the guidance is strict. Operators should assume that in a conflict scenario third-party connections, such as telecommunications, internet, vendors, service providers, and upstream dependencies, will be unreliable and that threat actors will have some access to the OT network.

Isolation duration (CISA, 2026): operators are asked to update business continuity plans and engineering processes to allow for safe operations for weeks to months while isolated.

CISA Acting Director Nick Andersen has described the goal this way: operators must be able to isolate vital systems from harm, continue operating in that isolated state. Chris Butera, CISA’s Acting Executive Assistant Director for Cybersecurity, said that CISA urges OT owners and operators to maintain robust isolation and recovery plans so that essential services can continue under degraded conditions.

For encrypted connections, the “weeks to months” figure matters most. Many encryption deployments are designed around the assumption that a certificate authority, a time server, a licence server or a management console can always be reached. CI Fortify removes that assumption.

Can quantum-safe tunnels between substations or plants keep running when internet and cloud connectivity is cut?

Yes, but only if the physical path between the sites stays inside the isolated zone and the gateways need nothing outside it to set up and renew sessions. Encryption cannot keep a link alive when the bearer underneath it has been disconnected.

The bearer question comes first

Many organisations miss this point. CISA tells operators to practise isolating from third-party networks, such as those belonging to managed service providers, integrators, and telecommunications providers, including cellular modems to remote sites. A tunnel between two substations that runs over a carrier’s internet service or a cellular modem is, by definition, on the wrong side of the separation point. In a full isolation it goes down, however strong the cryptography is.

So the first design decision is about network topology, not cryptography. Sort every inter-site link into one of three groups: links on operator-owned infrastructure (private fibre, utility radio, owned microwave), links on third-party services that are planned to be cut, and links on third-party services that you hope to keep. The third group is a planning gap. Graduated isolation can help here: you might cut cloud and vendor access first while keeping a carrier link up, but your plan should not depend on that link staying up.

What happens to cloud and remote-user connections

Edge-to-cloud links and secure remote access are normally the first things an isolation plan cuts on purpose. The design goal is that no vital OT function depends on them. Historians, analytics or engineering tools in a cloud environment should fail without disrupting the OT, and remote engineers should have an on-site fallback. Encrypting these paths well protects them while they are up. It does not make them part of the island.

Why quantum safety still matters in island mode

Isolation is a short-term measure, but the data crossing inter-site links can stay sensitive for years. The post-quantum algorithm most gateways now use is ML-KEM. At present, ML-KEM is believed to be secure, even against adversaries who possess a quantum computer.

Sources: FIPS 203, Date Published: August 13, 2024; in order of increasing security strength and decreasing performance, these are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. NIST IR 8547 lists RSA at 112 bits of security strength as deprecated after 2030 and disallowed after 2035. NIST says it will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier. On timing, many anticipate they could become feasible within 15 to 20 years.

How do encryption gateways handle certificate revocation checks and key renewal during long periods of isolation?

Session key renewal is negotiated between the two gateways and needs no outside service. Revocation checking and long-term credential validity are where isolated links usually fail, because they often depend on infrastructure outside the island.

Session rekeying: usually local

An ephemeral key exchange, whether classical, post-quantum or hybrid, happens directly between the two gateways. As long as both gateways can reach each other, have working randomness and trust each other’s identity, rekeying continues without the internet. For example, Quantum Network’s QPN gateway combines a classical and an ML-KEM key exchange into one session key and renews both handshakes every two minutes, so a long isolation includes thousands of rekey events. Each one is a chance to find a hidden dependency during testing rather than during a crisis.

Revocation: decide hard-fail or soft-fail in advance

When gateways authenticate with X.509 certificates, each handshake may trigger a revocation check against an OCSP responder or a CRL distribution point. If those are hosted outside the island, isolation causes one of two outcomes. With hard-fail, the gateway rejects its peer and the link drops. With soft-fail, the check is skipped silently and a revoked credential could be accepted. Neither should be found out for the first time during a crisis.

Practical options include:

• Running an issuing CA and revocation service on infrastructure inside the isolated zone, with its own backup and recovery procedure.
• Publishing CRLs with a nextUpdate window that covers your planned isolation duration, and knowing exactly when cached CRLs expire.
• Using an authentication model for gateway pairs that needs no online checks, and having a documented manual procedure for removing a compromised peer.

Time is a crypto dependency

Certificate validity, CRL freshness and many replay protections depend on accurate clocks. If gateways sync to public NTP servers, isolation lets their clocks drift. Over weeks, that drift can push a gateway outside a validity window. Provide a time source inside the island, such as a local reference clock, and monitor clock offset as part of the link’s health.

Which management, licensing or update dependencies can break encrypted links in island mode?

Any function that has to reach a vendor or cloud service before a gateway will start, authenticate or forward traffic is a single point of failure in island mode. Licence check-ins, cloud-hosted management and fail-closed update logic are the usual causes.

Read your vendor documentation with these questions in mind, and ask for the answers in writing. As one example of a design that avoids these dependencies, QPN sends no telemetry, has no cloud dependency and keeps working in its current state if its subscription lapses. It then stops receiving support and security updates. That trade-off is better than a link going down, but it means a long isolation also needs a plan for bringing updates in afterwards through a controlled transfer.

Also check what happens on a line failure. A gateway that recovers automatically after an outage reduces the manual work needed during a crisis. The connection must also never fall back to sending traffic unencrypted when the encrypted path is unhealthy.

How do you test that site-to-site encryption keeps working during a planned isolation exercise?

Combine a live cutover with a cold restart and a lab test with the clock moved forward. Many dependencies only appear when a device boots or when cached credentials expire.

CI Fortify puts regular testing at the centre of graduated isolation. CISA also tells operators to practise recovering their systems in that isolated state, without phone or internet connection. CISA has published a Tabletop Exercise Package Isolation & Recovery that can frame the discussion before a technical test.

A test sequence that finds real problems

1. Baseline. Record current tunnel state, rekey counters, clock offsets and certificate and CRL expiry dates at every site in scope.
2. Cut external paths. Disconnect internet, cloud, vendor and cellular paths at the planned separation points. Confirm with packet capture that no gateway is still trying to reach outside services.
3. Observe rekeying. Let the links run through many rekey cycles. Confirm that sessions renew and OT traffic continues without errors.
4. Cold restart. Power-cycle at least one gateway at each end while still isolated. Boot is when licence checks, controller registration and time sync usually run.
5. Line failure. Interrupt the inter-site bearer and restore it. Confirm automatic recovery, and use captures to confirm no unencrypted traffic was sent during the outage.
6. Clock moved forward (lab). On a test pair, move the clocks past your planned isolation length to find where certificates, CRLs or licence grace periods would run out.
7. Reconnect. Restore external connectivity in stages and check that updates, management sync and revocation data come back without disrupting active tunnels.

Record the results against each link’s role in your service delivery target. If a link only works in isolation when nothing restarts, write that down as a risk rather than a pass.