Secure Your Systems: Key Takeaways from the ICS Cybersecurity Conference 2026

The Evolving Threat Landscape for Industrial Control Systems

Industrial Control Systems protecting critical infrastructure now face sophisticated, persistent threats that traditional IT security models cannot adequately address. The ICS Cybersecurity Conference 2025 emphasized that attackers have shifted from opportunistic exploitation to targeted campaigns specifically designed to maximize operational disruption. Unlike information technology networks where data breach impact is primarily financial or reputational, ICS compromises directly endanger physical safety, public health, and national security.

The convergence of IT and OT networks has created attack surfaces that didn’t exist a decade ago. Manufacturing facilities, utility companies, water treatment plants, and transportation systems increasingly connect operational technology to corporate networks for remote monitoring, predictive maintenance, and data analytics. This connectivity delivers efficiency gains but introduces vulnerabilities. A 2024 incident targeting a North American water utility demonstrated how a simple phishing email reaching an IT administrator could eventually cascade into operational technology network access, potentially enabling contamination of water treatment processes.

Device proliferation compounds the challenge. Industrial environments now include Internet of Things (IoT) sensors, wireless access points, programmable logic controllers (PLCs), human-machine interfaces (HMIs), and remote terminal units (RTUs) that were never designed with cybersecurity as a primary requirement. Many devices run firmware from 2010 or earlier, unable to receive security patches, operating without encryption, and offering no authentication mechanisms. The conference highlighted that 67% of organizations surveyed couldn’t provide a complete asset inventory of connected OT devices within their environments.

Supply chain attacks represent another critical vector. Recent incidents showed how vulnerabilities in third-party software used in ICS environments created backdoors bypassing traditional network perimeters. A compromise in software used by a major ICS vendor could potentially affect thousands of facilities simultaneously, as demonstrated when a software update mechanism itself became a distribution channel for malware.

Understanding the SANS 2025 State of ICS/OT Security Report Findings

The SANS Institute published the 2025 State of ICS/OT Security Report, representing survey data from over 1,100 cybersecurity professionals working in operational technology environments. This report provides quantifiable baseline metrics that illuminate both progress and persistent gaps in industrial cybersecurity maturity.

The Detection-to-Recovery Gap: A Critical Strategic Challenge

SANS report data reveals what practitioners call the “two-speed reality.” Organizations have invested substantially in detection technologies including network intrusion detection systems (IDS), behavioral analytics, and security information and event management (SIEM) platforms tailored for OT environments. Mean time to detection (MTTD) has improved to approximately 8-12 hours for most organizations, representing significant progress from 24-48 hour detection windows in 2020.

However, mean time to recovery (MTTR) has actually worsened. Organizations now require 14-21 days median recovery time, up from 10-14 days in previous years. This counterintuitive finding stems from several factors. First, ICS environments cannot simply be taken offline and rebuilt like standard IT systems. Critical infrastructure must maintain continuous operation or face cascading failures affecting downstream systems. Second, ICS recovery requires validation of both system integrity and operational safety before returning to production. A power grid operator cannot simply restart control systems without verifying that generation, transmission, and distribution will remain stable. Water treatment facilities must validate that treatment processes will not introduce contaminants before resuming operation.

This gap creates unacceptable business risk. During the 14-21 day recovery window, operations run in degraded or manual mode, producing significant financial losses and potentially creating safety hazards as operators revert to manual procedures they may not have practiced recently.

Incident Prevalence and Operational Impact Data

The SANS report found that 21% of surveyed organizations experienced a significant security incident in the 12 months prior to the survey. However, incident distribution is heavily skewed toward larger organizations and critical infrastructure operators. Organizations with greater than 500 employees reported incident rates of 34%, while organizations with fewer than 100 employees reported incident rates of 8%. This disparity suggests that smaller organizations either have fewer detection capabilities, experience fewer targeted incidents, or underreport incidents due to lack of incident response infrastructure.

Most critically, 67% of reported incidents caused measurable operational downtime. Of those, 44% resulted in downtime exceeding 8 hours, representing substantial financial impact. An 8-hour outage in a manufacturing facility costs between $100,000 and $5 million depending on industry sector and production volume. For utilities, an 8-hour outage can affect millions of consumers and trigger regulatory investigations.

Resource Allocation and Capability Gaps

SANS data highlights that cybersecurity investment in OT environments remains lower than IT investment. Organizations reported median cybersecurity budgets representing 3.2% of operational technology budgets, compared to 6.8% for information technology budgets. This investment gap directly correlates with capability maturity. Organizations with OT security budgets exceeding 5% of operational budgets reported:

• Detection capabilities covering 78% of network assets versus 34% for under-budget organizations
• Formal incident response procedures documented and tested quarterly versus annual or untested procedures
• Dedicated OT security staff versus shared IT/OT roles without specialized training
• Network segmentation architecture protecting critical assets versus flat network topologies
• Vulnerability management programs with quarterly assessments versus ad-hoc patching

CISA’s Secure by Demand Framework: 12 Critical Security Elements

The Cybersecurity and Infrastructure Security Agency (CISA) introduced the “Secure by Demand” initiative, fundamentally shifting accountability for ICS security from end-user organizations to equipment manufacturers and software developers. This represents significant policy change, acknowledging that downstream organizations cannot adequately compensate for insecure design through operational controls alone.

Secure by Demand establishes 12 mandatory security elements that must be embedded in ICS product design, architecture, and software development lifecycle:

Security Element	Implementation Requirement	Example Controls
Authentication and Authorization	All user and administrative access must require strong authentication; role-based access control (RBAC) enforced	Multi-factor authentication (MFA), principle of least privilege, session timeout enforcement
Secure by Default Configuration	Products ship with security features enabled; insecure protocols disabled; ports closed unless explicitly required	Telnet disabled, SSH required; HTTP Basic Auth disabled; firewall rules restrictive; default credentials changed
Secure Communication	All data in transit encrypted using strong protocols; integrity protection for commands and data	TLS 1.2 minimum for remote access; encrypted SCADA protocols; signed firmware updates; digitally signed configurations
Secure Architecture	Products designed to operate securely in segmented networks; support for network access controls and demilitarized zones (DMZ)	Support for firewall rules; proxy compatibility; ability to operate with network monitoring
Vulnerability Management	Secure development practices; regular security assessments; disclosure mechanism for reported vulnerabilities	Third-party penetration testing; responsible vulnerability disclosure program; prioritized patch releases
Logging and Monitoring	Comprehensive logging of security-relevant events; log integrity protection; no covert operation capability	Authentication attempts logged; configuration changes auditable; logs forwarded to central SIEM; tamper-evident logging
Software Supply Chain Security	Third-party components verified; dependencies tracked; integrity of build and distribution assured	Software Bill of Materials (SBOM) provided; third-party vulnerability scanning; signed releases; build provenance tracking
System Resilience	Systems designed to withstand attack attempts and continue operation; recovery procedures documented	Graceful degradation under attack; backup and restore capabilities; redundancy in critical components
Update Management	Secure, reliable mechanisms for patch delivery; capability to update without operational disruption where possible	Staged rollout of patches; signed updates; rollback capability; non-disruptive updates for monitoring components
Physical Security	Hardware components protected against tampering; ports that enable unauthorized access disabled or protected	Sealed enclosures; protected debug ports; TPM (Trusted Platform Module) for integrity verification
Data Protection	Sensitive data encrypted at rest; secure key management; purging of sensitive data when no longer needed	Encrypted credential storage; secure key derivation; secure deletion of sensitive data; encrypted backup media
Documentation and Guidance	Clear security documentation; deployment guides reflecting secure practices; known limitations transparently disclosed	Security reference architectures; hardening guides; risk assessment documentation; known issues published

Organizations now face accountability pressure to demand Secure by Demand compliance from equipment vendors. The conference highlighted that major utilities and manufacturers are including Secure by Demand requirements in vendor contracts, providing financial incentive for compliance. However, implementation challenges remain, particularly for legacy device manufacturers lacking modern development infrastructure or security expertise.

Left of Boom: Proactive Security Posture and Prevention-First Strategy

The “Left of Boom” concept inverts traditional security thinking. Rather than focusing on incident response after compromise, Left of Boom prioritizes prevention and vulnerability elimination before attackers can exploit them. In military terminology, “Left of Boom” refers to actions taken before an explosion occurs; in cybersecurity, it means action before successful compromise.

Vulnerability Assessment and Elimination Programs

Left of Boom security begins with systematic vulnerability identification and elimination. This differs fundamentally from traditional vulnerability management focused on patch application. Organizations must conduct ongoing assessments across multiple vulnerability vectors:

External Penetration Testing: Simulated attacks from external perspective, testing perimeter defenses, public-facing systems, and supply chain entry points. Frequency should increase to quarterly for critical infrastructure, with specific focus on social engineering and phishing campaigns that could provide initial access.

Internal Penetration Testing: Post-compromise scenario testing, assuming attackers have already obtained network access through phishing, supply chain compromise, or insider threat. Internal testing focuses on lateral movement, privilege escalation, and critical asset compromise. This reveals how far an attacker could progress with legitimate domain credentials.

Architecture Reviews: Assessment of network topology, segmentation design, and data flow between IT and OT systems. Architecture reviews should specifically evaluate single points of failure, inadequate segmentation, and overly-permissive firewall rules that could enable lateral movement.

Secure Code Review: For custom applications and scripts used in ICS environments, security-focused code review identifies hardcoded credentials, insecure cryptographic practices, command injection vulnerabilities, and unsafe API usage before deployment.

Configuration Analysis: Automated scanning of system configurations against hardening baselines. Tools like Nessus, Qualys, or Tenable can provide configuration-specific vulnerability identification when properly tuned for ICS environments (standard IT scanning tools often generate false positives or create operational disruption in OT networks).

Threat Intelligence Operationalization

Organizations collect threat intelligence from multiple sources including government agencies (CISA alerts), commercial threat feeds, industry information sharing organizations, and internal network telemetry. However, intelligence only provides value when operationalized through specific actions:

Detection Rule Development: Threat intelligence should directly inform detection rule creation for SIEM systems and network monitoring tools. When intelligence indicates an attacker is exploiting CVE-2024-xxxx, detection rules must be created before exploitation occurs in your environment. This requires security operations teams to review threat reports and create matching detection signatures within days, not weeks.

Defensive Prioritization: Threat intelligence should drive which vulnerabilities get patched first, which assets require additional monitoring, and which risks justify architectural changes. If threat intelligence indicates that attackers are actively exploiting a specific vulnerability affecting your asset types, that vulnerability should receive immediate prioritization for patching despite operational constraints.

Alerting Tuning: Threat intelligence should directly inform SIEM and intrusion detection system (IDS) alert tuning to focus detection on attacker behavior patterns, command sequences, and network signatures actually used by threat actors. Organizations should subscribe to CISA AIS (Automated Indicator Sharing) feeds to receive real-time indicators of compromise (IOCs) from actual incidents affecting similar organizations.

Incident Response Preparedness and Tabletop Exercises

Prevention efforts fail when attackers eventually achieve compromise. Effective incident response planning, before incidents occur, directly determines recovery speed. The conference emphasized that organizations conducting quarterly incident response exercises see MTTR improvements of 30-50% when actual incidents occur.

Incident response planning for ICS environments must address operational realities absent from typical IT incident response plans:

Safety Considerations: ICS incidents cannot always be handled through immediate isolation and containment. Shutting down a water treatment facility control system to contain a compromise endangers public health if untreated water enters the distribution system. Response plans must identify which systems can be immediately isolated and which require continued operation during incident response.

Field Technician Involvement: Many ICS incidents require on-site technician involvement to verify physical system state, perform manual operations, or collect forensic evidence from equipment lacking network-accessible logging. Response plans must identify which incidents require field presence and how to coordinate remote security teams with field technicians in real-time.

Regulatory Notification Requirements: Critical infrastructure operators face specific regulatory notification timelines. NERC CIP requires utilities to report cybersecurity incidents within one hour to reliability coordinators. Response plans must account for these obligations and ensure evidence preservation for regulatory review.

Communication Procedures: Tabletop exercises should simulate communication protocols during incidents when normal communication systems may be compromised. These exercises should identify communication chains of command, external agency notification requirements (CISA, FBI, sector-specific ISACs), and customer notification obligations.

Network Segmentation Architecture for Critical Asset Protection

Network segmentation represents the single most effective control for limiting blast radius when compromise occurs. Rather than attempting to prevent all breaches, segmentation ensures that compromise of one network zone cannot spread to critical assets. The conference highlighted that organizations with comprehensive segmentation reduce mean time to recovery by up to 60% because compromise can be isolated to non-critical systems while critical operations continue on isolated network segments.

Segmentation Architecture Models

Air-Gapped Critical Zones: Most critical assets should operate on physically isolated networks with no network connectivity to less-trusted segments. Examples include control systems for power generation, water treatment chemical dosing, and grid protection systems. These systems should operate on dedicated networks, with information flowing in only one direction through carefully controlled mechanisms like unidirectional data diodes. While air-gapping eliminates network-based attacks, it requires careful management of software updates and configuration changes since traditional network update mechanisms are unavailable.

DMZ-Style Intermediate Zones: Systems requiring bidirectional communication with IT or external networks should operate in demilitarized zones (DMZs) with restricted communication rules. Example: a SCADA historian system collecting data from operational networks but also providing reporting to corporate IT systems. The historian should operate in a restricted zone with specific rules allowing communication only to known source systems, not to broader IT networks or the internet.

Managed Micro-Segmentation: Where complete network isolation is operationally infeasible, micro-segmentation enforces granular network policies. A manufacturing facility might require communication between plant floor equipment and engineering workstations, but this communication should be restricted to specific protocols, specific source and destination IPs, and specific ports. Tools like zero-trust network access platforms (example: Zscaler) or software-defined perimeter (SDP) solutions can enforce these granular policies without requiring major network redesign.

OT-Aware Firewall Policies: Traditional IT firewalls focused on TCP/IP layer filtering are insufficient for OT networks using specialized protocols like Modbus, DNP3, and Profibus. OT-aware firewalls understand these protocols and can enforce application-layer policies. Example: a firewall rule might allow “read coil” operations but deny “write coil” operations on Modbus devices, preventing attackers from altering device behavior even if they achieve network access.

Practical Segmentation Implementation Challenges

Effective segmentation faces technical and organizational obstacles. The conference revealed that organizations average 18-24 months to implement comprehensive segmentation, not because the technology is complex but because operational continuity requirements force staged implementation.

Latency Impact: Segmentation architecture adding firewall inspection and routing hops can increase latency. In some OT environments, latency exceeding 100 milliseconds causes operational problems. Operators reporting to the conference described control systems becoming unstable when network latency increased from 5ms to 25ms due to added firewall hops, requiring rollback of segmentation until firewall rules could be optimized.

Legacy Device Compatibility: Some legacy OT devices cannot be updated with modern security capabilities, cannot authenticate through modern identity systems, and cannot support encrypted communication. Segmentation architecture must accommodate these devices either by maintaining separate, isolated network segments or by deploying authentication proxies that translate between legacy device protocols and modern security controls.

Troubleshooting Complexity: Segmented networks make troubleshooting more difficult. Engineers accustomed to wide-open network access suddenly find that standard diagnostic tools (ping, traceroute) fail due to firewall rules, requiring security team involvement to troubleshoot operational issues. Organizations must invest in training and documentation to help operators and engineers understand how to work within segmented network architecture.

Cyber Safety: Integrating Security, Safety, and Compliance

Industrial Control Systems differ fundamentally from IT systems because they control physical processes directly affecting public safety. A security control that causes unexpected system behavior could create immediate physical safety hazards. The conference introduced “cyber safety” as the integration of cybersecurity controls, functional safety design, and regulatory compliance requirements.

Safety-Security Alignment Challenges

Cybersecurity and functional safety were historically separate disciplines. Safety engineers designed systems to tolerate component failures through redundancy, error checking, and safe-state mechanisms. Security engineers designed systems to prevent and detect attacks. These disciplines can conflict:

Conflict Example – Security Updates: A security update patches a critical vulnerability in control system software. The update requires 15 seconds of system downtime. Safety design assumes continuous operation, with redundant systems providing fault tolerance only if the primary system fails. During the 15-second update window, if a fault occurs, the safety system may not respond appropriately because it cannot switch to redundancy for non-critical reasons. Organizations must design update procedures that maintain safety properties during brief outages through careful coordination of redundant system updates.

Conflict Example – Encryption: Encrypting communication between control devices prevents attackers from modifying commands in-flight. However, encryption adds processing overhead and latency. A system designed to operate with maximum latency of 50ms might exceed this threshold if encryption adds 20ms of latency. Organizations must select encryption approaches minimizing latency (example: TLS with modern cipher suites more efficient than older approaches) or redesign systems to tolerate increased latency.

Cyber Safety Framework Implementation

Risk Assessment Integration: Safety risk assessments must incorporate cybersecurity attack vectors alongside environmental hazards and component failures. Example: a water treatment facility safety analysis must assess risks from: (1) pump failure causing inadequate flow, (2) chemical sensor failure causing overdosing, and (3) attacker compromising chemical sensor causing overdosing. Mitigation strategies must address all three risk sources.

Functional Safety Standard Alignment: IEC 61508 and sector-specific standards (IEC 61513 for nuclear, IEC 62280 for railway) define safety integrity levels (SIL) and design requirements. Security controls must not degrade the safety integrity level. For example, adding security monitoring that generates false alarms could cause operators to ignore legitimate safety alerts, degrading SIL. Security controls must be designed to avoid this risk.

Fail-Safe Mechanisms: When security controls fail or malfunction, systems must transition to safe states. Example: if an intrusion detection system malfunctions and blocks legitimate control traffic, the control system must detect this communication loss and transition to safe operation (example: shutdown, reduced-power mode) rather than attempting continued operation with lost communications.

Cross-Functional Team Integration: Breaking IT-OT Silos

Separate IT and OT organizations developed historically because the systems were genuinely separate. Corporate IT managed office networks and servers while operations teams managed production equipment. Network connectivity was minimal. This separation is no longer feasible. The conference presented data showing that organizations with integrated IT-OT security teams achieved substantially better outcomes:

Metric	Integrated Teams	Separate Teams
Mean Time to Detect (MTTD)	6.2 hours median	14.8 hours median
Mean Time to Recover (MTTR)	12 days median	19 days median
Detection Coverage (Assets Monitored)	74% of assets	38% of assets
Quarterly Incident Response Drills	91% conduct quarterly	34% conduct quarterly
Documented Segmentation Architecture	88% have formal architecture	23% have formal architecture

Organizational Structural Options

Integrated Security Operations Center (SOC): Some large organizations are establishing integrated SOCs where IT security analysts and OT security specialists work in the same facility, with shared alert dashboards, shared incident response processes, and regular cross-training. IT analysts learn to understand OT risks and operational constraints; OT specialists learn IT detection technologies. This approach works well for large organizations with sufficient scale to hire specialized OT security talent.

Embedded OT Security Specialists: Smaller organizations embed OT security specialists within operations teams, maintaining organizational separation but ensuring close working relationships. These specialists report directly to operations leadership but coordinate with IT security on policy and architecture decisions. This approach is common in utilities and manufacturing facilities with 500+ employees.

Shared CISO with Separate Teams: Organizations maintain separate IT and OT security teams but place them under a single Chief Information Security Officer (CISO) responsible for unified security strategy. The CISO ensures alignment and prevents conflicting policies. This works well for organizations with mature security practices but significant OT distinctiveness (example: utilities with complex operational requirements).

Communication and Collaboration Structures

Incident Response Planning: Joint IT-OT incident response planning ensures that IT and OT teams understand each other’s capabilities and constraints. IT teams learn that OT incidents may require on-site technician presence and cannot always proceed with immediate system shutdown. OT teams learn that rapid forensic evidence collection requires IT forensics expertise and specialized tools.

Change Advisory Boards: Changes to either IT or OT systems should be reviewed through joint change advisory boards (CABs) ensuring that IT changes don’t introduce OT risks (example: network change affecting latency-sensitive control traffic) and OT changes don’t introduce IT risks (example: new wireless devices creating unauthorized network access points).

Quarterly Architecture Reviews: Organizations should conduct quarterly joint reviews of network architecture, segmentation design, and security controls, with IT and OT stakeholders examining how IT and OT networks interact and whether segmentation remains effective. These reviews identify new connectivity that violates segmentation policies and reveal controls that have drifted from design intent.

Practical Implementation Strategies for ICS Security Programs

Tier 1 (Critical Assets): Systems whose compromise directly creates safety