Walk into most introductory OT security talks and you will hear the same piece of advice. Forget CIA, think AIC: Availability first, Integrity second, Confidentiality last. It has become one of those things repeated so often nobody questions it anymore.
The problem is that a shorthand for adjusting how people think about OT has gradually been treated as a security architecture principle, and those are two very different things.
Key Takeaways
- AIC was never designed to be a security architecture principle, it was a corrective for IT practitioners entering OT environments.
- The Stuxnet, Triton/TRISIS, and Industroyer attacks all targeted integrity, not availability. Integrity failures persist undetected where availability failures trigger immediate response.
- Triton/TRISIS targeted the Safety Instrumented System rather than the process itself. Keeping the plant running was the mechanism of harm.
- OT confidentiality matters not for regulatory reasons but as reconnaissance. Network diagrams, setpoints, and credentials are what targeted attacks are built from.
- Safety and availability are not interchangeable. Taking a system offline to contain a safety risk is the correct response to a compromise.
Neither IEC 62443 nor NIST SP 800-82 endorses a priority ordering of CIA. Both derive control requirements from threat modelling and zone classification.
The CIA Triad, Briefly
The CIA triad is a foundational security model with three parts:
- Confidentiality means only authorised people can access information.
- Integrity means data is accurate and untampered.
- Availability means systems are there when you need them.
Where AIC Comes From (And Why It Stuck)
The reordering reflects something genuinely true about OT environments: plants do not tolerate downtime the way office networks do. An unexpected outage does not mean someone cannot access their email, it means a blast furnace cannot be shut down safely, or a production run is wasted mid-process, or a water treatment facility loses pressure at the wrong moment. Operators in these environments make availability-first decisions every day, and most of them understand the operational fragility in their systems far better than any incoming security team does.
As the progressive IT/OT convergence brought IT security thinking into industrial environments, the mismatch between those instincts and operational reality became a practical problem. For people arriving with IT instincts, AIC was a reasonable enough flag that those instincts needed adjusting.
Where it went wrong is that it kept getting repeated long after it had served that purpose. What was a shorthand for adjusting instincts is not a framework for building controls.
A Coverage Model, Not a Hierarchy
The CIA triad was never a ranked list. It asks whether you have addressed all three properties of a secure system. The order the letters appear in does not carry argumentative weight any more than the order of items on a nutrition label tells you which nutrient the food is optimised for.
Reordering it to AIC imposes a hierarchy the original model never had. Once that becomes the working assumption, it influences which controls get funded, which risks get accepted, and which conversations get closed down with “we prioritise availability.”
The Integrity Problem
Stuxnet is cited a lot, possibly too much, but it remains the clearest illustration of why the integrity argument matters more than the availability argument in OT, so it is worth being precise about what it actually did.
The malware did not shut down centrifuges at Natanz. Shutting them down would have triggered alarms and ended the attack’s usefulness almost immediately. Instead, it manipulated them, driving them outside safe operating parameters while feeding false readings back to the control room. Operators watched dashboards showing normal operation for months while the equipment was being destroyed. The attack worked precisely because it preserved the appearance of availability.
Triton/TRISIS, discovered in 2017 at a petrochemical facility, took that logic further. It targeted Safety Instrumented Systems, the independent layer designed to shut a process down safely before it becomes catastrophic. The attackers were not trying to cause an outage. They were trying to remove the safeguard that would have prevented a process failure from becoming a physical disaster.[1]
Industroyer, deployed against Ukraine’s power grid in 2016, issued commands directly to substation equipment using native industrial protocols rather than simply cutting power.[2]
All three targeted integrity. Sophisticated actors structure attacks this way because availability failures generate alerts and incident responses. An integrity failure that looks like normal operation can persist far longer, and by the time it is identified the window for intervention has often closed. If your security model places integrity below availability, you are deprioritising the failure mode that the most capable threat actors have consistently chosen.
On Confidentiality
The standard dismissal goes like this: “OT data is not sensitive in the way personal data or financial records are; there’s no GDPR exposure in a PLC ladder diagram.” That argument confuses data sensitivity with operational value to an attacker.
Stuxnet required detailed knowledge of Siemens S7-315 configurations, specific rotational tolerances, and the operational parameters of the enrichment process before a line of code was written. Network topology, engineering diagrams, process setpoints, HMI software versions, vendor access credentials. None of this is sensitive in a regulatory sense, but it is the reconnaissance material from which a targeted, high-consequence attack is built. The Government Accountability Office (GAO) has noted that attacks on OT increasingly originate in IT systems and migrate laterally across boundaries that exist more reliably in architecture diagrams than in actual network configurations.[3]
Those paths are considerably easier to navigate when the attacker already knows what’s on the other side.
The Property That Is Not in the Triad
Safety.
In environments where process failures can cause physical harm, the operational hierarchy does not start with availability. When a system is compromised in a way that creates a safety risk, the correct response is to shut it down and accept the availability loss. Operators in nuclear, chemical, and oil-and-gas environments do this routinely. AIC collapses safety into availability by treating them as the same concern ranked at the top of the hierarchy. Triton was designed precisely to exploit that conflation. Neutralise the safety layer first, and the availability of the process becomes the mechanism of harm.
As a small aside, it’s worth noting that German has only one word for both concepts: “sicherheit,” which covers safety and security without distinction. Whether that reflects a more integrated way of thinking about the two or is simply a linguistic coincidence, it’s a neat arrangement, and one the English-speaking security world could learn from.
What the Actual Frameworks Say
IEC 62443 does not organise security requirements around CIA or AIC. It uses security levels assigned to zones and conduits, derived from an assessment of breach consequences and the capabilities of realistic threat actors for that environment.[4] Confidentiality, integrity, and availability are all addressed. The zone model determines which controls are proportionate, not a mnemonic ordering.
NIST SP 800-82 Rev 3, updated in 2023, works similarly.[5] It was written specifically to account for the operational constraints that make OT different from enterprise IT, including the availability concerns the AIC framing was originally meant to highlight. It does not endorse deprioritising the other two properties as a result.
A More Useful Frame
The narrower point is that AIC was a useful corrective that has been promoted into something it was never designed to be. The evidence from actual attacks does not support the hierarchy it implies. Integrity and confidentiality are not lower-priority concerns to be addressed after availability has been secured. They are where the most consequential attacks have been constructed. IEC 62443 offers a more structurally sound basis for these decisions, treating asset criticality, zone classification, and threat modelling as the inputs. NIST SP 800-82 provides the operational context for applying it within real industrial constraints. Neither is a quick read, which is partly why the shorthand persists
About IOActive
IOActive is a global cybersecurity services firm specialising in critical infrastructure security, OT/ICS assessments, adversary simulation, supply chain integrity, and preparedness testing. To speak with our specialists, visit ioactive.com.
References
[1] Federal Bureau of Investigation. TRITON Malware Remains Threat to Global Critical Infrastructure Industrial Control Systems, Private Industry Notification 20220324-001. FBI/IC3, 24 March 2022. https://www.ic3.gov/CSA/2022/220325.pdf
[2] Cybersecurity and Infrastructure Security Agency. CrashOverride Malware (CISA Alert TA17-163A, updated July 2021). https://www.cisa.gov/news-events/alerts/2017/06/12/crashoverride-malware
[3] US Government Accountability Office. Critical Infrastructure Protection: Actions Needed to Better Ensure an Effective Cybersecurity Approach, GAO-24-106576. Washington DC: GAO, 2024. https://www.gao.gov/assets/d24106576.pdf
[4] ISA/IEC 62443-3-3, System Security Requirements and Security Levels. Research Triangle Park: ISA. https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
[5] National Institute of Standards and Technology. Guide to Operational Technology (OT) Security, NIST SP 800-82 Rev 3. Gaithersburg: NIST, September 2023. https://doi.org/10.6028/NIST.SP.800-82r3