OT vs IT Security Differences

Applying IT security practices directly to OT often does more harm than good. The two domains optimize for different goals, run different technology, and fail in different ways. A practitioner crossing into OT must unlearn several reflexes.

This lesson contrasts the priorities, constraints, and threats that make OT security its own discipline.

IT prioritizes the CIA triad as Confidentiality, Integrity, Availability. OT effectively inverts it.

• Availability first — the process must keep running; downtime can be dangerous or hugely costly
• Integrity second — readings and commands must be trustworthy
• Confidentiality last — sensor values are rarely secret

Above all sits a concern IT does not share: safety. Protecting human life and the environment outranks everything.

In OT, a security control that could cause a process to behave unexpectedly may be worse than the threat. An automated action that trips a turbine or closes a valve at the wrong moment can injure people.

• Security changes must never compromise the safety function
• Engineers, not just security staff, must sign off on changes
• The SIS must remain independent and trustworthy

This is why aggressive IT tactics like auto-isolation need careful adaptation in OT.

In IT, patching promptly is gospel. In OT it is constrained.

• Patching may require a plant shutdown, scheduled months apart
• Vendor certification may forbid unapproved patches
• A bad patch can halt production or break a safety case

Because patching is slow, OT leans harder on compensating controls: segmentation, monitoring, and access control to protect systems that cannot be quickly updated.

OT equipment runs for decades. It is common to find controllers and operating systems long past vendor support still in production because replacing them means rebuilding the physical line.

• Unsupported OS versions with no patches available
• Hardware that cannot run modern security agents
• Protocols designed in an era that assumed an isolated network

You must secure what exists, not what you wish existed.

Many industrial protocols were created for trusted, physically isolated networks and therefore have no authentication or encryption by default. On such a network, any device that can reach a controller can command it.

• Commands are accepted without proving the sender's identity
• Traffic is often plaintext and easily spoofed
• This is a design assumption, not a fixable bug, in legacy versions

Protection comes from controlling who can reach the network, covered later.

In IT, vulnerability scanning is routine. In OT, aggressive scanning can crash fragile devices. Some PLCs fault or stop when they receive unexpected traffic, which on a live process can be dangerous.

• Prefer passive network monitoring over active scanning
• Test any active tool in a lab or maintenance window first
• Coordinate with operations before touching production networks

The mantra: in OT, the assessment must not become the incident.

Control loops run on strict timing. Adding latency or jitter can destabilize a process.

• Inline security devices must not introduce harmful delay
• Heavy agents may starve real-time tasks of CPU
• Network changes can break tightly timed communications

Security must fit within the determinism the process requires, which often rules out solutions that are trivial in IT.

The defining difference: OT incidents have physical, real-world effects. A compromised IT server leaks data; a compromised OT system can overflow a tank, damage a turbine, contaminate water, or endanger workers.

This raises the stakes and changes risk assessment. The worst-case outcome is not financial or reputational alone; it can be loss of life. Threat modeling in OT must consider physical and safety impact, not just data.

OT attracts a distinct threat profile.

• Nation-states seeking strategic disruption of critical infrastructure
• Attackers whose goal is physical disruption, not data theft
• Even untargeted IT ransomware can spill into OT and halt operations

Because consequences are severe and attackers may be well-resourced, OT defense emphasizes resilience and detection alongside prevention.

The goal is not to abandon IT security but to adapt it.

• Favor passive monitoring and segmentation over intrusive scanning and rapid patching
• Put safety and availability ahead of confidentiality
• Involve process engineers in every security decision
• Use compensating controls for systems that cannot be patched

These principles drive the protocol and architecture lessons that follow.

Apply the inverted priorities to a real decision.

You learned why OT security is a distinct discipline.

• Priorities invert: safety and availability first, confidentiality last
• Patching is constrained; rely on compensating controls
• Legacy gear and insecure-by-design protocols are facts of life
• Active scanning and intrusive agents can harm fragile, real-time devices
• Incidents have physical consequences; involve process engineers in every decision

Next: the specific protocols and their weaknesses.