The SRA Triad: Safety, Reliability, Availability — and Why OT Still Needs CIA
- CIA, ICS cyber security, ics security assurance, process safety, risk assessment
OT Cybersecurity Fundamentals — Estimated reading time: 12–14 minutes
Introduction
One of the most repeated statements in OT cybersecurity is:
“IT uses CIA, while OT uses SRA”
It is memorable. It is also too simplistic.
Confidentiality, Integrity, and Availability remain important in OT.
At the same time, industrial systems have additional engineering requirements that traditional information-security discussions may not adequately capture.
NIST SP 800-82 Rev. 3 explicitly describes OT security in the context of its unique performance, reliability, and safety requirements.
In this article, we will therefore use:
Safety — Reliability — Availability
as an OT engineering lens.
Not as a formal replacement for CIA.
Start with CIA
The familiar information-security triad is:
Confidentiality -Prevent unauthorized disclosure
Integrity -Prevent unauthorized or improper modification
Availability – Ensure systems and information are accessible when required
All three matter in OT, but their consequences may look different.
Confidentiality in OT
Confidentiality may protect:
- Network diagrams
- Engineering files
- PLC logic
- Process recipes
- Credentials
- Vulnerability information
- Safety documentation
- Proprietary production information
Loss of confidentiality may also help an attacker understand the system well enough to plan more targeted actions.
So, confidentiality does matter.
Integrity in OT
Integrity can be extremely important because industrial systems make decisions based on data and configuration.
Examples include:
- Sensor values
- Setpoints
- PLC logic
- Protection settings
- Valve commands
- Alarm thresholds
A system that is available but producing false information may be more dangerous than a system that is obviously offline.
Availability in OT
Availability matters because operations may depend continuously on:
- Control
- Visibility
- Communication
- Protection
- Engineering access
Loss of availability may lead to:
- Production loss
- Equipment trip
- Loss of control
- Loss of visibility
- Manual operation
- Emergency shutdown
In some environments, it may contribute to unsafe conditions.
Availability is therefore not just a business metric, but it can become an operational requirement.
Then Add the Engineering Lens
Cybersecurity decisions must also preserve three properties that industrial engineers care deeply about:
Safety
Reliability
Availability
For convenience, we will refer to this as SRA.
Again, SRA here is a practical teaching model.
It should not be interpreted as an official replacement for the CIA triad.
Safety
Safety means preventing unacceptable harm to:
- People
- Environment
- Equipment
- Surrounding communities
For OT cybersecurity, the important question becomes:
Could the security decision create or increase a hazardous process condition?
Suppose an incident responder sees malicious activity and disconnects an HMI.
That might stop part of the attack.
But if the HMI provides the operator’s only practical visibility of a critical process, the action may create another problem.
OT incident response therefore requires process context.
Reliability
Reliability asks:
Will the system perform its required function correctly and consistently when needed?
A production system that crashes twice per day is not acceptable merely because it has excellent encryption.
Industrial equipment may be expected to operate:
- Continuously
- Predictably
- For long time (many years, even decades)
- Under strict timing requirements
- With limited maintenance windows
A cybersecurity measure that significantly destabilizes the control system may reduce cyber exposure while increasing operational risk.
That trade-off must be understood.
Availability
Availability asks:
Is the required capability accessible when the process needs it?
Availability does not always mean:
“Never shut anything down.”
Planned maintenance is compatible with good availability.
What matters is understanding which functions must remain available, under which operating conditions, and how quickly they must be restored.
This may involve:
- Redundancy
- Failover
- Spare equipment
- Offline backups
- Tested restoration
- Alternate communication
- Manual operation
- Emergency procedures
CIA and SRA Are Not Competitors
A more accurate picture is:
| Security / Engineering Concern | Example OT Question |
| Confidentiality | Can unauthorized parties obtain engineering information or credentials? |
| Integrity | Can process data, logic, commands, or configuration be altered? |
| Availability | Can required systems and functions be used when needed? |
| Safety | Could failure or compromise cause unacceptable physical harm? |
| Reliability | Will the system perform its intended function consistently? |
Notice that availability appears in both cybersecurity and engineering discussions.
It is not a different definition.
The difference is often the consequence attached to losing it.
An unavailable business application may delay work.
An unavailable control function may shut down production.
An unavailable protective or visibility function may have safety implications.
Context determines importance.
Why OT Priorities Cannot Be Reduced to an Acronym
It is sometimes said:
IT: C > I > A
and:
OT: A > I > C
That may be a useful introductory illustration.
But it should not become a design rule.
Consider an SIS.
Would availability always matter more than integrity?
Not necessarily.
“A safety controller that is continuously available but executes maliciously modified logic may be worse than one that fails safely.”
Consider product formulation.
Integrity of recipe data may be critical.
Consider nuclear, defense, pharmaceutical, or proprietary industrial environments.
Confidentiality can also be highly significant.
The correct priority depends on:
Process + Function + Consequence + Operating Mode + Risk
It is not a universal ranking.
How SRA Changes Cybersecurity Design
Safety, reliability, and availability influence many familiar cybersecurity decisions.
Network Segmentation
Security perspective: Reduce unnecessary attack paths
Operational perspective: Preserve required communication
The objective therefore becomes:
“Allow necessary communication through controlled conduits while eliminating unnecessary communication”
Not:
Block everything because segmentation is good
Patching
Security perspective: Remove known vulnerabilities
Reliability perspective: Do not destabilize critical equipment
Availability perspective: Respect production and maintenance windows
Safety perspective: Assess whether the change affects protective functions
The result may involve:
- Vendor qualification
- Testing
- Staged deployment
- Compensating controls
- Rollback procedures
- Deferred remediation with documented risk
That is risk-based patch management.
Authentication
Security perspective: Prevent unauthorized access
Availability perspective: Ensure authorized engineers can still access critical systems when required
Reliability perspective: Avoid unnecessary dependencies on infrastructure that may not be continuously available
The answer is not:
No MFA because this is OT
Nor is it:
MFA everywhere regardless of process consequence
The correct implementation must fit the environment.
Redundancy and Failover
Industrial systems often use redundancy to maintain function when a component fails.
Examples include:
- Redundant controllers
- Dual network paths
- Redundant servers
- Backup power
- Redundant sensors
But cybersecurity introduces another question:
Does redundancy really create independence?
Two redundant servers:
- In the same domain
- Using the same credentials
- Running identical vulnerable software
- Managed from the same compromised workstation
may both fail under one cyber event.
Redundancy helps reliability only when common-cause vulnerabilities are understood.
Fail-Safe vs Fail-Secure
This distinction illustrates the difference between safety and cybersecurity priorities particularly well.
A fail-safe design moves toward a state intended to reduce physical hazard when something fails.
A fail-secure design preserves security or access restrictions when something fails.
Sometimes these goals align. Sometimes they conflict.
For example, an access-control mechanism might fail locked for security reasons.
But in an emergency, people may need to exit.
In industrial control, a valve’s desired failure position depends on the process.
There is no universal answer such as:
“Loss of communication should always close the valve.”
For one process that may reduce risk.
For another it could create dangerous pressure.
Security behavior must therefore respect the engineering definition of the safe state.
Deterministic and Time-Sensitive Communication
Some OT functions depend on predictable timing.
Adding:
- Inspection
- Encryption
- Authentication
- Network devices
- Monitoring
may affect:
- Latency
- Jitter
- Communication timing
- Device resources
Modern technology increasingly supports strong security without unacceptable performance impact.
But engineering validation is still necessary.
Security cannot assume that control-system timing is irrelevant.
Backups Are an Availability Control Only If Recovery Works
A backup file has little operational value if:
- It is corrupted
- It contains compromised logic
- Nobody knows how to restore it
- Required software is unavailable
- Replacement hardware cannot use it
- Restoration takes longer than the process can tolerate
Availability therefore includes recoverability.
A good OT recovery strategy should be able to answer the following questions:
- What must be restored first?
- What is the trusted configuration?
- How do we verify integrity?
- What dependencies are required?
- Has restoration actually been tested?
Safety Can Override Availability
Industrial culture often emphasizes uptime. But uptime is not the ultimate objective.
If continued operation creates unacceptable physical risk, the correct action may be to shut down.
That is why:
“Availability should support safe operation—not compete with it”
A system that remains online while its integrity or protection functions are uncertain may not represent successful cybersecurity or successful operations.
Reliability Is Not the Same as Availability
The two terms are often confused.
A system may be highly available because redundancy keeps it online.
But if it produces incorrect results frequently, it is not reliable.
Likewise, a system may be highly reliable when operating but unavailable during extended maintenance.
Both properties need to be understood.
OT Cybersecurity Is a Multi-Objective Engineering Problem
The mature question is not:
How do we maximize cybersecurity?
It is:
How do we reduce cyber risk while preserving the required safety, integrity, reliability, availability, and operational performance of the process?
Sometimes these objectives reinforce each other.
Sometimes they create trade-offs.
Those trade-offs require:
- Engineering
- Operations
- Cybersecurity
- Process safety
- Management
to make risk decisions together.
From SRA to Asset Criticality
Now we can see why two technically similar devices may have very different cybersecurity priorities.
Consider two PLCs.
PLC A controls a noncritical utility function.
PLC B controls equipment whose loss could shut down the plant.
The devices may have:
- Similar hardware
- Similar vulnerabilities
- Similar operating systems
- Similar network exposure
Yet their consequences are different.
Therefore:
“Vulnerability severity alone does not determine OT risk”
We also need to understand:
- Process function
- Safety consequence
- Production consequence
- Environmental consequence
- Dependencies
- Recovery requirements
- Existing safeguards
That leads directly to the next discussion: Criticality and Risk Assessment.
Key Takeaway
OT does not abandon the CIA triad.
It adds engineering reality.
Confidentiality protects sensitive information and system knowledge.
Integrity protects trustworthy data, logic, configuration, and commands.
Availability ensures required capabilities are accessible.
And OT engineering also demands:
Safety — the system must not create unacceptable physical harm.
Reliability — the system must perform correctly and consistently.
Availability — the required function must be available when the process needs it.
Cybersecurity therefore succeeds only when security controls support the industrial mission rather than unintentionally undermine it.
The question is not:
“Is this asset vulnerable?”
The more important question is:
“What happens to the process if this asset is compromised, fails, or becomes unavailable?”
That is the beginning of consequence-based criticality and OT cyber risk assessment.
