OT/IT Cybersecurity: 5 Survival Imperatives for 2026

The convergence of operational technology (OT) and information technology (IT) has created a complex attack surface, making robust and cybersecurity not just an option, but a survival imperative for modern enterprises. We also offer interviews with industry leaders, technology experts, and security practitioners to demystify this critical domain, but how do you actually implement it?

When we talk about securing modern infrastructure, we’re really talking about a blended challenge. Gone are the days when your manufacturing floor or power grid operated in a hermetically sealed bubble, completely disconnected from your corporate email server. Today, everything is interconnected, and that means your vulnerabilities multiply. As a cybersecurity consultant specializing in industrial control systems (ICS) for the past decade, I’ve seen firsthand how a seemingly innocuous phishing email on an IT network can lead to a complete shutdown of a production line, costing millions per hour. This isn’t theoretical; it’s the daily reality for many organizations.

1. Segment Your Networks Like Your Business Depends On It (Because It Does)

The absolute first step—and frankly, the most overlooked by many organizations—is network segmentation. This isn’t just about throwing up a firewall; it’s about creating logical and physical barriers between your IT (Information Technology) and OT (Operational Technology) environments. Think of your OT network as the crown jewels: the systems that control your physical processes, often with legacy equipment that can’t handle modern security agents. Your IT network is more like the administrative offices—still important, but a different risk profile.

I always recommend a “DMZ” (Demilitarized Zone) architecture between IT and OT. This acts as a buffer. All communication between the two environments must pass through this DMZ, where it can be inspected and filtered. For instance, imagine a manufacturing plant in Gainesville, Georgia. Their corporate HR system (IT) might need to pull production data from the SCADA system (OT) to calculate bonuses. Instead of a direct connection, the data flows from OT to a historian server in the DMZ, and then the IT system queries the historian. This breaks the direct attack path.

To implement this, you’ll typically use enterprise-grade firewalls like those from Palo Alto Networks or Fortinet.

Configuration Steps for Palo Alto Networks Firewall:

1. Identify Network Zones: Define your IT, OT, and DMZ subnets. For example, IT could be 192.168.1.0/24, OT 10.0.0.0/24, and DMZ 172.16.0.0/24.
2. Configure Interfaces: Assign physical or virtual interfaces on your firewall to each zone. For instance, `ethernet1/1` for IT, `ethernet1/2` for OT, and `ethernet1/3` for DMZ.
3. Create Security Zones: In the Palo Alto Networks web interface, navigate to `Network > Zones` and create three zones: `IT_Zone`, `OT_Zone`, and `DMZ_Zone`. Assign the respective interfaces to these zones.
4. Define Security Policies: This is where the magic happens. Go to `Policies > Security`.
   • Rule 1 (OT to DMZ): Allow only necessary outbound communication from OT to DMZ. For example, `Source Zone: OT_Zone`, `Destination Zone: DMZ_Zone`, `Application: Modbus/TCP` (if applicable), `Service: tcp/502`, `Action: Allow`. This might be for a data historian.
   • Rule 2 (DMZ to IT): Allow specific data pulls from DMZ to IT. `Source Zone: DMZ_Zone`, `Destination Zone: IT_Zone`, `Application: SQL-Browser` (if using SQL database in DMZ), `Service: tcp/1433`, `Action: Allow`.
   • Rule 3 (IT to DMZ – Limited): Strictly limit IT access to DMZ. Perhaps only for patching DMZ servers. `Source Zone: IT_Zone`, `Destination Zone: DMZ_Zone`, `Application: ssh, rdp`, `Service: any`, `Action: Allow` (but only from specific IT admin IPs).
   • Default Deny: Ensure a `Source Zone: Any`, `Destination Zone: Any`, `Application: Any`, `Service: Any`, `Action: Deny` rule is at the bottom of your policy list. This is non-negotiable.

(Screenshot description: A screenshot of a Palo Alto Networks firewall security policy rule list, showing rules for IT_Zone, OT_Zone, and DMZ_Zone communication, with specific applications and services allowed, and a final “deny all” rule at the bottom.)

Pro Tip: Don’t just block; use Application-ID and User-ID features on modern firewalls. This allows you to block based on the actual application (e.g., Siemens TIA Portal) rather than just port numbers, and even based on the user accessing it. This provides much finer control and reduces your attack surface dramatically.

Common Mistake: Organizations often create “any-any” rules for convenience during setup and then forget to tighten them. This completely defeats the purpose of segmentation. I once worked with a client in Marietta who had a “temporary” any-any rule between their IT and OT networks that had been active for six months!

2. Implement Centralized Logging and Monitoring with a SIEM

Once you’ve segmented, you need to know what’s happening in both environments. This is where a Security Information and Event Management (SIEM) system becomes indispensable. A SIEM aggregates logs from every device—firewalls, servers, workstations, industrial controllers, HMI (Human Machine Interface) systems—and correlates them to detect anomalies and potential threats. Without a SIEM, you’re looking for a needle in a haystack; with one, you’re using a powerful magnet.

My go-to solution for this is Splunk Enterprise Security (ES). Its ability to ingest diverse data types, including proprietary OT protocols like Modbus or OPC UA, is a huge advantage.

Configuration Steps for Splunk Enterprise Security:

1. Deploy Splunk Universal Forwarders: Install Splunk Universal Forwarders on key IT servers, workstations, and any Windows-based HMIs or engineering workstations in the OT network. Configure them to send security event logs (Windows Event Logs, Sysmon), application logs, and firewall logs to your Splunk indexers.
2. Integrate OT Data Sources: For specialized OT devices that don’t support standard logging, you’ll need specific connectors or data diodes. For example, for Modbus/TCP traffic, you might use a CyberX (now Microsoft Defender for IoT) sensor deployed in the OT network. This sensor passively monitors network traffic, extracts asset information and communication patterns, and then forwards this enriched data to Splunk via syslog or API.
3. Configure Data Inputs in Splunk: On your Splunk deployment, navigate to `Settings > Data Inputs`.
   • For Universal Forwarders: Configure `Files & Directories` or `Local Event Log Collection` as needed.
   • For Syslog: Set up a UDP or TCP input for devices sending syslog.
   • For CyberX/Defender for IoT: Configure an appropriate data input (e.g., HTTP Event Collector or specific API integration) to receive its alerts and asset inventory.
4. Create Correlation Rules: This is where you define what constitutes a “threat.” In Splunk ES, go to `Configure > Content > Correlation Searches`.
   • Example 1: Multiple Failed Logins from OT to IT: Create a rule that triggers an alert if a source IP from the OT network attempts more than 5 failed logins to an IT domain controller within 5 minutes.
   • Example 2: Unexpected PLC Program Change: If your CyberX sensor detects an unauthorized program download to a PLC, correlate this with any related network activity and alert.
5. Build Dashboards and Reports: Develop dashboards that provide a real-time overview of IT and OT security posture. Include metrics like top talkers in OT, critical alerts over time, and asset inventory.

(Screenshot description: A screenshot of a Splunk Enterprise Security dashboard showing a security posture overview, including graphs for notable events, asset vulnerabilities, and top detected threats across both IT and OT assets.)

Pro Tip: Don’t try to log everything. Focus on critical events that indicate security issues: authentication failures, configuration changes, network connection attempts to unusual ports, and alarms from OT devices. Over-logging can lead to alert fatigue and make it harder to find real threats.

Common Mistake: Deploying a SIEM without a clear plan for what to monitor and how to respond to alerts. A SIEM is only as good as the threat intelligence and response procedures built around it. I’ve seen expensive SIEM deployments turn into “alert dumps” because no one had the time or expertise to tune them.

3. Implement Strong Access Control and Multi-Factor Authentication (MFA)

Access control is foundational. If an attacker can simply log in, all your firewalls and SIEMs become less effective. This applies equally to IT and OT environments. For IT, it’s standard practice, but for OT, it’s often an afterthought. Many legacy OT systems still rely on shared passwords or no passwords at all. This is a ticking time bomb.

For your IT environment, Microsoft Entra ID (formerly Azure Active Directory) with Conditional Access policies is my recommendation. For OT, it’s more challenging, but not impossible.

Configuration Steps for Microsoft Entra ID with Conditional Access:

1. Enable MFA for All Users: Navigate to the Microsoft Entra admin center (entra.microsoft.com). Go to `Protection > Identity Protection > MFA Registration Policy` and enforce MFA registration for all users.
2. Create Conditional Access Policies: Go to `Protection > Conditional Access > Policies`.
   • Policy 1 (Require MFA for Admins):
     • `Users:` Select `All users` and `Exclude` your emergency access accounts.
     • `Cloud apps or actions:` `All cloud apps`.
     • `Conditions:` (Optional, but recommended) `Device platforms: Any device`, `Locations: Any location` (or trusted locations only).
     • `Grant:` `Require multi-factor authentication`.
     • `Enable policy:` `On`.
   • Policy 2 (Block Legacy Authentication): Legacy protocols (like POP3, IMAP4) can bypass MFA.
     • `Users:` `All users`.
     • `Cloud apps or actions:` `All cloud apps`.
     • `Conditions:` `Client apps: Exchange ActiveSync clients, Other clients`.
     • `Grant:` `Block access`.
     • `Enable policy:` `On`.

(Screenshot description: A screenshot of the Microsoft Entra ID Conditional Access policy configuration page, showing a policy named “Require MFA for Admins” with its conditions and grant controls enabled.)

For OT systems, especially those that can’t integrate with modern identity providers, you need a different approach. This often involves jump servers or secure remote access solutions like BastionZero or CyberArk Privileged Access Manager. These solutions act as a gatekeeper, requiring MFA to access the jump server, and then logging all activity on the OT systems.

Pro Tip: Implement Privileged Access Management (PAM) for both IT and OT administrative accounts. Tools like CyberArk or Delinea (formerly Thycotic) securely store credentials, rotate them automatically, and require approval for access, providing an audit trail for every privileged action.

Common Mistake: Believing that “air-gapped” means “secure from all threats.” While physical separation is good, human error and supply chain attacks can still bridge the gap. I’ve seen USB drives carry malware from an IT network directly into an “air-gapped” OT system at a data center near Northside Hospital in Atlanta.

4. Conduct Regular Vulnerability Assessments and Penetration Testing

You can build the most secure fortress, but if you don’t test its walls, you’ll never know its weaknesses. Regular vulnerability assessments (VA) and penetration testing (PT) are non-negotiable for both IT and OT environments. A VA identifies known weaknesses; a PT actively attempts to exploit them to demonstrate real-world risk.

For IT, standard tools like Nessus Professional or Qualys Vulnerability Management are excellent. For OT, you need specialized tools and expertise that understand industrial protocols and the delicate nature of live production systems.

Steps for a Combined IT/OT Vulnerability Assessment and Penetration Test:

1. Scope Definition: Clearly define the scope. This should include all IT assets (servers, workstations, network devices) and all OT assets (PLCs, RTUs, HMIs, SCADA servers). For OT, specify if the test will be passive (network monitoring only) or active (port scanning, limited exploitation attempts). Active testing on live OT systems requires extreme caution and usually occurs during scheduled downtime.
2. Tool Selection:
   • IT VA: Use Nessus Professional for credentialed scans of Windows and Linux servers. Configure it to scan your IT subnets.
   • OT VA (Passive): Deploy Claroty Continuous Threat Detection or Nozomi Networks Vantage sensors in your OT network. These passively monitor traffic, identify assets, vulnerabilities, and communication patterns without impacting operations.
   • IT PT: Use tools like Metasploit Framework or commercial offerings like Core Impact to attempt exploitation of identified vulnerabilities.
   • OT PT (Active – Extreme Caution): If approved and during a maintenance window, specialized tools like Industrial Exploitation Framework (ISF) or custom scripts can be used. This is often done by highly specialized firms like Dragos or Mandiant.
3. Execution:
   • VA: Run Nessus scans weekly or monthly. Ensure Claroty/Nozomi sensors are continuously monitoring.
   • PT: Conduct full penetration tests annually, with targeted tests on critical systems twice a year.
4. Reporting and Remediation: Generate detailed reports outlining identified vulnerabilities, their severity, and recommended remediation steps. Prioritize fixes based on risk to business operations. For OT, remediation often involves vendor patches, firmware upgrades, or compensating controls (e.g., stricter firewall rules).

(Screenshot description: A screenshot from a Claroty Continuous Threat Detection dashboard showing a real-time inventory of OT assets, identified vulnerabilities, and network communication flows within an industrial control system environment.)

Pro Tip: When testing OT, always engage the operational teams early. They understand the systems’ sensitivities and can advise on safe testing windows. Never, ever, scan a live PLC without explicit, documented approval and a clear rollback plan. I once had a client who tried a “quick scan” of a legacy PLC and brought down their entire packaging line for half a day. Not a fun conversation.

Common Mistake: Treating OT security as an afterthought or applying IT security tools directly to OT systems. This can destabilize critical operations and is a recipe for disaster. OT systems often require different patching cycles, protocols, and security considerations.

5. Develop and Test a Comprehensive Incident Response Plan

Even with the best defenses, a breach is always a possibility. Your ability to detect, contain, eradicate, and recover from an incident quickly determines the true impact. An incident response (IR) plan is your playbook for when things go wrong. It must cover both IT and OT, recognizing their unique characteristics.

Key Components of an Integrated IT/OT Incident Response Plan:

1. Preparation:
   • Incident Response Team: Define roles and responsibilities for IT security, OT engineering, legal, communications, and executive leadership. Include contact information for key personnel.
   • Tools: Ensure you have forensic tools, secure communication channels, and offline backups readily available.
   • Playbooks: Develop specific playbooks for common scenarios (e.g., ransomware attack on IT, unauthorized access to PLC, denial-of-service on HMI).
2. Detection & Analysis:
   • Monitoring: Rely on your SIEM (Splunk ES) and OT specific monitoring (Claroty/Nozomi) for early detection.
   • Triage: Establish clear criteria for classifying incidents and escalating them.
3. Containment:
   • IT: Isolate compromised systems, block malicious IPs at the firewall, disable affected user accounts.
   • OT: This is critical. Containment might involve isolating an entire production line, putting a PLC into program mode, or even physically disconnecting a network segment. The goal is to prevent further damage to physical processes while maintaining safety.
4. Eradication & Recovery:
   • IT: Clean infected systems, patch vulnerabilities, restore from clean backups.
   • OT: This is often more complex. Recovery might involve restoring PLC programs from trusted backups, re-imaging HMI workstations, and verifying system integrity with operational staff. Always verify system functionality thoroughly before bringing production back online.
5. Post-Incident Activity:
   • Lessons Learned: Conduct a thorough post-mortem analysis. What went wrong? What could be improved?
   • Reporting: Document the incident, its impact, and the steps taken.

(Screenshot description: A flowchart illustrating an integrated IT/OT incident response process, showing parallel tracks for IT and OT containment, eradication, and recovery, with decision points for escalation and communication.)

Pro Tip: Conduct tabletop exercises at least annually. Gather your IT, OT, and leadership teams and walk through a simulated incident. This identifies gaps in your plan, clarifies roles, and builds muscle memory. It’s far better to discover these issues in a conference room than during a real attack.

Common Mistake: Having an IR plan that exists only on paper. A plan is useless if it’s not tested, updated, and understood by everyone involved. I’ve seen organizations with beautifully written plans that crumbled under the pressure of a real incident because no one had ever practiced their role.

The integration of IT and OT security is no longer optional; it is a fundamental pillar of operational resilience. By systematically segmenting networks, centralizing monitoring, strengthening access controls, rigorously testing defenses, and preparing for incidents, organizations can build a robust defense that protects both their data and their physical operations. Additionally, understanding the broader tech’s 2026 shift towards practical advice and robust security solutions is crucial for sustained success.