This article is for executives, operations leaders and technology teams at Australian critical infrastructure operators, and at the suppliers and service providers those operators depend on. It summarises what CI Fortify asks for, then looks at the part we think gets least attention: the integrations, automations and reports that sit between OT and the rest of the business. Facts were checked against ASD's publication and PDF on 2 November 2026.
What is CI Fortify?
CI Fortify is high-level cyber security guidance from ASD, published on 13 October 2025, for operators of Australian critical infrastructure (CI). Its purpose is continuity: making sure critical services keep running during a crisis, a conflict or a serious cyber incident.
The case ASD makes is blunt. State-sponsored actors routinely target Australian CI networks, "possibly to conduct espionage or to pre-position" for disruptive or destructive effects. The guidance names Volt Typhoon, Salt Typhoon, APT29, APT40 and the Lazarus Group, and cites ASIO's Annual Threat Assessment 2025, which found espionage and foreign interference already at extreme levels and a growing willingness among authoritarian regimes to disrupt or destroy critical infrastructure.
ASD also traces 15 years of attacks on OT, from Stuxnet in 2010 to Industroyer 2 in 2022. The example most worth remembering is Colonial Pipeline in 2021: an IT breach led the operator to shut down its OT proactively, closing an 8,850 km fuel pipeline and causing a week of shortages on the US east coast. The attack never had to reach the pipeline controls. The dependency between IT and OT did the damage.
Two definitions frame everything that follows:
- Critical services: services required to sustain the survival of Australians, or that support national security and economic stability.
- Vital OT and enabling systems: systems essential to the continuity of a critical service.
Note the words "enabling systems". CI Fortify isn't only about PLCs and control networks. Anything a critical service can't run without is in scope.
What does ASD ask operators to do?
Three preparatory steps, then two planned actions.
| Step | What ASD asks for | What it really requires |
|---|---|---|
| Prepare 1 | An up-to-date inventory of OT assets and enabling systems: types, roles, locations and dependencies, classified by function and criticality | A register that stays current through the asset lifecycle, not a one-off spreadsheet |
| Prepare 2 | Define the organisation's critical services, then the vital OT and enabling systems each one needs | A business decision about what must keep running and what can stop |
| Prepare 3 | Identify the isolation points | Knowing exactly where each connection would be cut |
| Action 1 | Isolate vital OT and enabling systems from the internet, other networks and third-party systems for 3 months while maintaining critical services, under a graduated plan with thresholds | Manual or offline versions of every process that crosses the boundary, staffed for 3 months |
| Action 2 | Rapidly rebuild vital OT and enabling systems completely, from offline, known-good, tested backups of firmware, configuration and processes | A rebuild you have rehearsed, with spares pre-positioned |
ASD's own closing advice sets the priority: keep critical services running, "even if this affects the delivery of non-critical services in the short term".
Why is three months the number that matters?
Because three months turns a security question into an operating model question.
A one-day isolation is an incident: people stay late, a supervisor phones the numbers through, and the backlog is cleared next week. Three months is a full quarter. It covers at least one month-end and a quarter-end, a payroll cycle or six, regulatory reporting deadlines, planned maintenance, staff leave and the fatigue of doing by hand what a system used to do overnight. Any workaround that only works because someone heroic is doing it won't last 90 days.
ASD is candid that most operators won't get there immediately. It says operators "may initially struggle to achieve complete isolation", depending on how their networks are architected, their business processes and their staffing levels. We read that as the real brief: find out which of those three is the constraint before an adversary does.
Where will isolation actually break?
At the seams. ASD's guidance puts it plainly: "Any automated processes that cross from the isolated network to adjacent networks will most likely need to be completed manually during the period of isolation."
In most organisations, nobody owns the full list of those processes. The OT team knows the network paths. The ERP team knows which jobs import operational data. Finance knows which reports feed the board pack. The integration layer in between (scheduled jobs, middleware, scripts, file drops, and increasingly automation tools and AI agents) is often documented only in the heads of the people who built it.
These are the kinds of cross-boundary flows to look for:
| Flow | What stops when the link is cut | What a 3-month fallback needs |
|---|---|---|
| Operational readings to billing, settlement or inventory in the ERP | Invoices, settlements and stock levels drift from reality | A manual capture method, a reconciliation process, and an ERP that can close the month on estimates |
| Equipment alarms and condition data to maintenance work orders | Work orders aren't raised automatically; spare parts aren't reserved | A paper or offline work-order process and a local parts list |
| OT incidents and changes logged in the IT service desk | No ticket trail; change approvals stall | An offline change log and a way to load it back into the service desk afterwards |
| Shared identity: directory, single sign-on and cloud MFA | Engineers can't sign in to the systems they still need | Local accounts and break-glass credentials, held and audited offline |
| Vendor remote support, licence activation and cloud-connected devices | Vendors can't log in; some software stops when its licence can't check in | Contracts and configurations that allow offline operation, and support on site |
| Cloud dashboards, analytics and regulatory or market reporting | Leaders and regulators lose visibility | Reports produced inside the isolated zone and moved out on a controlled, one-way path |
| Automations and AI agents with access to operational data | Silent failures, or retries that hammer a closed connection | A register entry for every one, with an owner and a switch-off step |
The last row deserves attention. Low-code automation and AI assistants connected through the Model Context Protocol (MCP) make it easy to add a new connection to operational data in an afternoon. Each one is a new path across the boundary that the isolation plan needs to know about. Our MCP integration guide covers how to keep those connections governed.
Is your integration list part of your asset inventory?
It should be. ASD asks for an inventory that records dependencies, and the asset inventory guidance it points to sets out how. A device list is the usual starting point. A list of interfaces is the part that tends to be missing, because integrations fall between teams.
A useful integration register has one row per flow, with:
- source and target systems, and the direction of data
- the method (API, file transfer, database link, message queue, vendor cloud) and the isolation point that would cut it
- frequency and volume
- the business process and critical service it supports
- the owner on each side
- what happens downstream if it stops, and how long the business can tolerate that
- the manual fallback, who performs it, and how the data is reconciled afterwards
If a critical service can't run without a flow, that flow, and the middleware that runs it, is an enabling system under ASD's definition. It belongs in the same register as the PLCs.
How do you design integrations that can be cut cleanly?
CI Fortify doesn't prescribe integration patterns, so what follows is our view of what makes the isolation and rebuild actions achievable. It sits alongside ASD's secure connectivity principles for OT and principles of OT cyber security, which cover the network side.
- Every flow goes through a known crossing point. If data leaves the OT environment through ten undocumented routes, you have ten isolation points to find under pressure. Fewer, deliberate crossings make the plan executable.
- Prefer one-way, outbound flows. A flow that only pushes data out of OT can be cut without breaking anything inside it. A flow that reaches in to read or write is harder to isolate and easier to abuse.
- Store, then forward. Queue data at the boundary so that when the link is restored, readings and work orders captured during isolation can be replayed and reconciled rather than re-keyed.
- Make the IT side tolerant of silence. An ERP month-end that blocks because one import is missing turns an OT isolation into a finance outage. Design for estimates, flags and later true-ups.
- Give each flow a switch and a runbook. Isolation should be a planned, graduated set of steps, as ASD describes, not a person pulling cables. Each step should say what to switch off, who confirms it, and which manual process starts.
- Keep configuration in version control. Mappings, schedules, endpoints and certificates are what you will need to rebuild. If they only exist in a running system, a compromised system is your only copy.
What does "rebuild completely" mean for the systems around OT?
ASD asks for offline, known-good and tested backups of "firmware, configuration and processes" for every vital OT and enabling system. It singles out the cases that matter most: malicious actions that happened before isolation or trigger after it, isolation that wasn't fully effective, low confidence that attackers have been evicted, and business-as-usual backups that can no longer be trusted.
For the integration layer, that means three things:
- Rebuild from source, not from snapshots. A snapshot of a compromised middleware server restores the compromise. Integration definitions held in version control, with offline copies, can be redeployed onto clean infrastructure.
- Treat runbooks as backups. "Processes" is in ASD's list for a reason. The manual procedures for a three-month isolation are part of what has to survive, offline and tested.
- Rehearse. A rebuild nobody has practised is a plan, not a capability. ASD's word is "prove".
Is CI Fortify only relevant to critical infrastructure operators?
No, for two reasons.
First, supply chains. ASD says supply chain dependencies "should be considered" when applying the guidance, and notes that the attack surface includes "those within the supply chain". If you maintain equipment, run software or provide managed services for a CI operator, expect questions about how your connections behave when they cut you off, and whether your remote access can be switched off cleanly.
Second, the benefits apply to any business that depends on a few systems working together. ASD lists them as parallel benefits: proactive resilience, stability through weather and safety events, and much lower recovery time and cost. A mid-sized manufacturer facing ransomware needs the same things: a list of what talks to what, a decision about what must keep running, and a rebuild it has practised.
Where to start
Most operators can make real progress in a quarter without buying anything:
- Name the critical services and get the executive team to agree, in writing, which non-critical services can stop during isolation.
- Build the integration register for those services alongside the OT asset inventory, starting with flows that cross into OT or out of it.
- Walk through one month of isolation on paper with operations, finance, maintenance and IT in the room. Every "we'd just..." answer is a missing runbook.
- Write and test the fallback for the three flows with the biggest downstream impact.
- Prove one rebuild of one enabling system from offline copies, and time it.
Governance matters as much as engineering: boards should see who owns each crossing point and how isolation is approved. Our AI agent governance framework for ANZ boards applies the same thinking to automated access.
Frequently asked questions
Is CI Fortify mandatory?
It is guidance. ASD describes the two planned actions as capabilities operators "are encouraged to achieve". It doesn't replace any legal obligations an operator already has, but it does show where ASD believes the bar should sit.
Does isolation mean switching everything off?
No. The aim is to keep critical services running inside the isolated zone, with links to the internet, the corporate network and third parties cut. ASD expects a graduated plan with thresholds, so isolation can be applied in stages as the threat level rises.
Who should own the integration register?
One named person, with input from OT, IT, the business application owners and finance. Integrations fall between teams by nature; a register owned by everyone is current for no one.
How Great Minds can help
We are not an OT security specialist, and CI Fortify's network design work belongs with people who are. Our work is on the other side of the boundary: the ERP, CRM and service management platforms that OT data feeds, and the integrations between them.
We help organisations map the flows between their systems, design integrations that can be cut and replayed, run continuity runbooks and offline change logs in Jira Service Management, and make ERP platforms tolerant of missing data. Our cyber security review for an Australian asset manager found insufficient network segmentation and an incomplete incident response plan, two of the gaps CI Fortify is designed to close. For the wider picture of how connected systems should fit together, see our guide to the connected enterprise.
Talk to us about mapping the integrations around your OT, and we'll help you find the flows your isolation plan will break before you have to cut them.
