IT Security vs OT Security: Priorities and Constraints

When IT security practices are applied unchanged to operational technology, the result can be a patch that halts a production line or a scan that crashes a controller, and when OT is left out of the security programme, an IT compromise can still stop physical operations. IT security protects information and the systems that process it; OT security protects the systems that monitor and control physical processes, where the first concern is people, plant and the environment. The two share threats, attackers and much technology, but differ in priorities, change tolerance, asset life and the consequences of failure. This guide compares them side by side, explains which practices transfer and which need adapting, and shows how to run a converged programme. It is for CISOs, OT engineers and security architects working across both estates.

Key takeaways

Short answer: IT security usually puts confidentiality and integrity of data first; OT security puts human safety first, then integrity and availability of the process, with confidentiality usually last, as NIST SP 800-82 Rev. 3 sets out.
Constraints, not goals, drive most differences. Real-time performance, reboots that may not be acceptable, vendor-controlled changes and component lifetimes of 10 to 15 years shape every OT control choice.
Many IT controls transfer, delivered differently. Asset inventory, segmentation, access control, monitoring and backups apply to both; patching, scanning and endpoint agents need OT-specific methods.
The IT and OT boundary is where most risk concentrates. Remote access, shared identities and data flows to enterprise systems connect the two, and an IT incident can force an OT shutdown even when controllers are untouched.
Converge governance, not networks. One risk framework and one incident process, with OT engineering authority over changes in the plant, works better than either team owning everything.

What each discipline protects

IT security protects enterprise information systems: user devices, servers, cloud services, applications and the data they hold. Failures are measured in data exposure, fraud and business downtime.

OT security protects programmable systems that interact with the physical environment. NIST SP 800-82 Rev. 3, the Guide to Operational Technology (OT) Security published in September 2023, scopes OT to include industrial control systems, building automation, transportation systems, physical access control and environmental monitoring. Its executive summary notes that OT logic has a direct effect on the physical world, so failures can harm health and safety, damage the environment and cause financial loss. NIST lists a Rev. 4 initial public draft with comments due by 30 November 2026, so expect updates. The NCSC describes OT priorities as safety, reliability and availability, because malfunction can cause physical danger.

The OT Security Guide covers the OT discipline in depth; this page focuses on the contrast and the joint programme.

Side-by-side comparison

The table follows the categories in NIST SP 800-82 Rev. 3 Table 1, "Summary of typical differences between IT and OT systems", with security implications added.

Category	IT	OT	Security implication
Performance	Not real-time; consistent response and high throughput; some delay and jitter acceptable	Real-time and time-critical; modest throughput acceptable; high delay or jitter not acceptable	Inline inspection, encryption and agents must not add latency to control traffic
Availability	Reboots acceptable; some gaps tolerated	Reboots may not be acceptable; redundancy may be needed; outages planned days or weeks ahead	Containment by "isolate and reboot" may be unsafe; response playbooks differ
Risk priorities	Data confidentiality and integrity first; downtime a business impact	Human safety first, then protection of the process; fault tolerance essential	Risk assessments must include safety and environmental consequence
System operation	Standard operating systems; automated upgrades	Often proprietary or older operating systems; software changes often made by vendors	Security tools and configuration changes need vendor support and testing
Resource constraints	Resources available to add third-party security tools	Devices may lack memory and compute for security functions	Compensating controls at the network level replace host controls
Communications	Standard IT protocols, mostly wired	Many proprietary and standard industrial protocols over wired, radio and satellite media	Monitoring tools must decode industrial protocols; many legacy protocols lack authentication
Change management	Timely, often automated updates	Thorough testing, incremental deployment, outages planned well ahead; unsupported operating systems common	Patch cycles run in months or at turnarounds, with compensating controls in between
Managed support	Diverse support models	Usually a single vendor	Vendor remote access becomes a major attack path
Component lifetime	3 to 5 years	10 to 15 years	Security must be retrofitted to equipment designed before current threats
Component location	Usually local and easy to reach	May be isolated or remote, with significant physical effort to access	Physical security and remote access controls carry more weight

Which IT practices transfer, and how

Practice	IT approach	OT adaptation
Asset inventory	Agent and active discovery, CMDB	Passive network discovery plus engineering records; the NCSC recommends a definitive record of OT architecture. See the OT Asset Visibility Guide.
Vulnerability scanning	Scheduled authenticated active scans	Passive identification and vendor advisories; active scans only in tested, approved windows
Patching	Monthly or faster, automated	Risk-based: vendor-qualified patches applied in planned outages, with segmentation and monitoring as compensating controls. See the OT Patch Management Guide.
Endpoint protection	EDR on every endpoint	Vendor-approved anti-malware or application allowlisting on Windows hosts such as HMIs and engineering workstations; none on controllers. See the OT Endpoint Protection Guide.
Segmentation	Zero trust and micro-segmentation	Zones and conduits from IEC 62443 and an IT/OT demilitarised zone, often drawn on the Purdue reference model. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
Monitoring	SIEM and EDR telemetry	Passive OT network monitoring that understands industrial protocols, feeding a shared SOC. See the OT Network Security Monitoring Guide.
Incident response	Isolate, reimage, restore	Engineering-led decisions; safe states; manual operation; containment that keeps the process safe. See the OT Incident Response Guide.
Backup and recovery	Frequent automated backups	Golden images, controller logic and configuration backups, tested restores on spare hardware
Penetration testing	Production testing common	Test environments, digital twins or offline equipment; production testing only with engineering approval

Where identity fits

Identity is the strongest link between the two estates and a common route across them. OT environments rely on shared engineering accounts, vendor support logins, service accounts for historians and data diodes, and machine credentials embedded in controllers and integration software. Many cannot use enterprise single sign-on or MFA directly. A separate OT Active Directory with no trust back to IT, privileged access workstations for engineering tasks (an approach in NCSC OT guidance), brokered and recorded vendor access, and an inventory of OT non-human identities reduce the chance that one stolen IT credential reaches the plant. See the OT and ICS Identity and Access Guide and the OT Active Directory Design Guide.

The Colonial Pipeline Ransomware Attack 2021 began with a legacy VPN account that had no MFA and had never been disabled. The pipeline was shut down as a containment measure, with no report of attackers manipulating pipeline controls: an IT identity failure that still stopped physical operations.

When to apply which approach

The question is rarely "IT security or OT security": industrial organisations need both. The decision is which rules govern a given asset or boundary.

Apply IT security practice as-is: enterprise systems in corporate zones, including ERP, email, office devices and cloud services, even when they consume plant data.
Apply OT security practice: anything that can directly affect a physical process or safety system, including controllers, safety instrumented systems, HMIs, engineering workstations and field networks.
Apply a hybrid: the IT/OT DMZ, historians, remote access gateways and OT servers running standard Windows. These can usually take IT tooling such as EDR and authenticated scanning, but changes go through OT change control.
Small sites: a single operator with a handful of PLCs may not justify a dedicated OT team; priorities are removing internet exposure, controlling remote access, segmenting from the office network and keeping offline backups of logic.
Large or regulated operators: critical infrastructure under rules such as the NIS2 Directive typically needs an OT security function, an OT-aware SOC and a programme aligned to the IEC 62443 series.

Running a converged programme

Agree governance and authority. One cyber risk owner across IT and OT, with OT engineering retaining authority over changes that affect process safety. Record the split in a RACI (CSF 2.0 GV.RR-02).
Build the inventory and architecture record. Combine passive discovery with engineering drawings to create a definitive view of OT assets, connections and third parties (ID.AM-01).
Secure the boundary first. Remove direct internet exposure, route all IT to OT traffic through a DMZ, and centralise and record remote access, in line with the NCSC secure connectivity principles. See the OT Remote Access Guide.
Assess risk with consequence. Use IEC 62443-3-2 zone-based risk assessment and include safety and environmental consequence alongside cyber likelihood. See the IEC 62443-3-2 OT Risk Assessment Guide.
Extend monitoring into a shared SOC. Deploy passive OT monitoring, forward to the enterprise SOC, and write OT-specific playbooks with engineering escalation.
Adapt hygiene controls. Patch, harden and allowlist by asset class using the transfer table above, testing every change on representative equipment before deployment.
Exercise jointly. Run tabletop exercises that start in IT and spread to OT, including the decision to shut down or run manually.
Review annually. Track maturity with the OT Security Maturity Model and update as NIST SP 800-82 and IEC 62443 parts are revised.

Detection and measurement

The OT threat model in ATT&CK for ICS highlights entry through External Remote Services (T0822), Internet Accessible Device (T0883) and Remote Services (T0886), and impact techniques such as Device Restart/Shutdown (T0816). Monitor remote access sessions, new connections across the IT/OT boundary, controller mode changes and logic downloads, and engineering workstation activity outside planned work.

Boundary coverage: percentage of IT/OT connections that pass through the DMZ and are logged.
Asset visibility: percentage of OT assets in the inventory with owner, firmware version and zone.
Remote access control: percentage of vendor sessions brokered, MFA-protected and recorded.
Vulnerability exposure: high-severity OT vulnerabilities without a patch or documented compensating control.
Recovery readiness: percentage of critical controllers with a tested, current logic backup.
Exercise frequency: joint IT and OT incident exercises completed per year.

Framework mapping

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISA/IEC 62443
Roles and authority across IT and OT	GV.RR-02	CP-2 (contingency roles)	62443-2-1 asset owner programme
Asset inventory	ID.AM-01	CM-8	62443-2-1
Segmentation and boundary	PR.IR-01	SC-7	62443-3-2, 62443-3-3
Remote and privileged access	PR.AA-05	AC-17	62443-3-3, 62443-2-4 service providers
Patching and change	PR.PS-02	SI-2, CM-3	62443-2-3 patch management
Monitoring and containment	DE.CM-01, RS.MI-01	SC-7	62443-3-3

The IEC 62443 Guide explains the series and its roles: asset owners, product suppliers, integrators and service providers.

Common mistakes

Running IT vulnerability scans on OT networks. Active scans can disrupt fragile devices; use passive discovery and approved windows.
Applying IT patch deadlines to controllers. Unachievable service levels lead either to unsafe patching or to ignored policy; set risk-based OT timelines with compensating controls.
Shared domain trust between IT and OT. One compromised IT administrator account then reaches HMIs and engineering workstations.
Unmanaged vendor remote access. Always-on vendor VPNs and remote desktop tools bypass the DMZ and its logging.
Treating OT as air-gapped. Historians, remote support, cloud analytics and removable media mean most "isolated" networks are connected.
Leaving engineering out of incident response. Security teams that isolate or reboot OT systems without engineering input can create the safety incident they aimed to prevent.

Practitioner checklist

Document who owns cyber risk across IT and OT and who has authority over plant changes.
Maintain a definitive OT asset and connectivity record, including third-party connections.
Remove direct internet exposure of OT devices and route IT to OT traffic through a DMZ.
Separate OT identity from IT identity, and broker, MFA-protect and record vendor access.
Replace active scanning with passive discovery in control networks.
Set OT-specific, risk-based patch timelines with documented compensating controls.
Feed OT monitoring into the SOC with engineering escalation paths in every OT playbook.
Keep tested offline backups of controller logic, configurations and golden images.
Run at least one joint IT and OT incident exercise each year.

Standards and references

Related NHI Mgmt Group resources: OT Security Guide · OT and Critical Infrastructure Executive Briefing · OT Security Operations Centre Guide · Industrial Protocol Security Guide · OT Security Checklist

IT Security vs OT Security: Priorities, Constraints and Converged Programmes