• Can SDN work in Operational Technology (OT) environments?
• Or is “OT SDN” merely an idea that looks good in whitepapers but collapses under real-world constraints?

The answer, like most things in OT, is nuanced.

Why SDN Is Attractive to OT in the First Place

OT networks have historically been static, flat, and manually managed. That model made sense when uptime and predictability mattered more than flexibility or cyber resilience. But OT environments are changing.

Today’s OT networks face:

• Increased remote access
• More vendors and third parties
• Converged IT/OT architectures
• Regulatory pressure (IEC 62443, NERC CIP, etc.)
• Growing cyber threat exposure

SDN promises:

• Centralized visibility and control
• Micro segmentation without massive VLAN sprawl
• Policy-driven access instead of box-by-box configuration
• Faster response to incidents and changes

From a cybersecurity perspective, SDN sounds almost tailor-made for OT.

So why isn’t everyone already doing it?

The Hard Reality of OT Networking

To determine whether SDN is realistic, you need to understand how OT networks are built and operated.

Determinism Beats Flexibility

OT networks are designed to behave consistently every time. Fixed paths, predictable latency, and known failure modes.

By design, SDN introduces abstraction and centralized decision-making. Even when tightly controlled, this clashes with environments where milliseconds matter and where engineers expect to observe and explain packet behavior.

A discrete manufacturing plant learned this the hard way when it tried to introduce SDN-capable switches into a Level 2 Ethernet/IP control network. The goal was micro-segmentation between machines and centralized policy enforcement. Instead, engineers encountered opaque traffic flows, latency jitter during controller updates, and troubleshooting scenarios where it was unclear whether failures originated in logic, the network, or controller behavior.

The result? The control network was reverted from SDN to static configurations. SDN survived only in the supporting infrastructure.

In OT, predictability often wins over elegance.

Legacy Devices Don’t Speak SDN

At its core, SDN assumes that networked devices can listen to, interpret, and respond to software-driven instructions. Policies are pushed through APIs. Traffic behavior is adjusted dynamically. Network elements are expected to engage in a conversation with a centralized controller.

Most legacy OT devices were never designed to have that conversation.

Traditional industrial systems were built for stability, determinism, and long service life, not for programmability. Many still communicate using:

• Serial protocols (RS-232, RS-485)
• Vendor-specific fieldbus technologies
• Fixed-function Ethernet implementations
• Configuration models intended to be set during commissioning and left untouched

These devices don’t expose APIs. They don’t understand policy abstractions. They don’t negotiate traffic behavior or accept dynamic updates from a controller. In many cases, the “interface” is a physical port, a fixed protocol stack, or a configuration file that changes only during a scheduled outage.

From the device’s perspective, nothing is missing; it is doing exactly what it was designed to do.

Figure 1-SDN vs Legacy OT

The mismatch arises because SDN expects network elements to be software participants, while legacy OT devices behave as deterministic endpoints. Attempting to impose SDN-style control on these systems often requires protocol gateways, overlays, or additional layers of abstraction, each of which introduces complexity, troubleshooting challenges, and new failure modes.

This is why SDN adoption in OT rarely occurs: the technology is not inherently immature. It fails because the underlying devices simply don’t speak the same language.

Most OT environments still rely on:

• Long-lifecycle industrial switches
• Proprietary or timing-sensitive protocols
• Devices that predate APIs, overlays, or controllers

Replacing proven, certified hardware simply to support SDN is rarely defensible.

Electric utilities face this reality every day. In protection and control networks that carry IEC 61850 GOOSE traffic, several utilities have explicitly rejected SDN. Latency guarantees, certification costs, and operational trust outweigh any theoretical benefits of abstraction. In these environments, the most realistic SDN decision is not to deploy it at all.

Change Control Is Slow by Design

In IT, automation is efficiency.
In OT, automation without guardrails is a risk.

Network changes often require management of change reviews, safety validation, downtime planning, and regulatory documentation. The idea of dynamic flow updates, even correct ones, makes many OT teams uncomfortable for good reason.

This resistance isn’t cultural inertia. It’s operational maturity.

Where OT SDN Actually Works in Practice

Despite these constraints, SDN is not a fantasy in OT. It appears in places vendors don’t always highlight.

At the IT/OT Boundary

A regional water utility operating more than 30 remote sites deployed SDN not in the control network, but in the industrial DMZ. The utility struggled with flat architectures, vendor access that never expired, and firewall rules that no one wanted to touch.

By applying SDN-based segmentation at the boundary:

• Vendor access became role-based and time-limited
• Policies aligned to function, not IP address
• Auditability improved without touching PLC traffic

OT engineers accepted the solution because it didn’t interfere with determinism or field operations. SDN worked precisely because it stayed in its lane.

For Secure Remote Access and Cellular OT

Upstream oil and gas operations provide another realistic SDN use case. Remote well pads connected via cellular backhaul often rely on VPN sprawl, shared credentials, and minimal segmentation.

In one deployment, SDN was used at aggregation points to enforce:

• Vendor-specific access zones
• Time-bounded permissions
• Read-only versus control access

Field networks remained static and simple. SDN operated above them, reducing the attack surface without introducing operational risk.

In Virtualized OT Infrastructure

SDN aligns naturally with OT, which already behaves like IT.

Large manufacturers that operate centralized virtual historians and analytics platforms have successfully deployed SDN within virtualized OT data layers. Policy-based segmentation simplified deployments, improved consistency across sites, and accelerated analytics onboarding, all without touching real-time control paths.

Here, SDN acted as a force multiplier rather than a disruption.

The Security Angle: SDN Is an Enabler, not a Savior

SDN does not:

• Fix poor asset inventory
• Replace protocol awareness
• Eliminate zoning and conduits
• Automatically create resilience

What it does do is amplify good architecture.

Used well, SDN:

• Reduces configuration error
• Improves policy consistency
• Speeds containment during incidents
• Makes segmentation manageable at scale

Used poorly, it obscures failure modes and erodes trust.

Figure 2 – Enabler not a Savior

So… Is OT SDN a Pipe Dream?

No, but it’s also not the future many marketing decks promise.

OT SDN today is:

• Incremental
• Hybrid
• Boundary-focused
• Highly constrained

It is not a wholesale replacement for industrial networking, nor is it suited for safety-critical or time-sensitive control paths.

The organizations succeeding with SDN in OT are not chasing trends. They are solving specific problems, keeping physical networks boring, and applying abstraction only where it improves clarity rather than complexity.

The Bottom Line

OT SDN isn’t a pipe dream, but it isn’t inevitable either.

It will continue to appear:

• At IT/OT boundaries
• In virtualized environments
• In secure remote access architectures

The real question isn’t “Can SDN work in OT?” It’s “Where does abstraction improve security and operations without introducing unacceptable risk?”

In OT, realism always wins.

At Enaxy, we help organizations apply SDN in OT environments pragmatically, not ideologically. We work with engineering, operations, and security teams to identify where abstraction adds real value and where traditional industrial networking should remain untouched.

From evaluating SDN use cases at IT/OT boundaries to designing secure hybrid architectures that respect safety and determinism, Enaxy helps ensure SDN is used as a tool, not a liability.

If you’re considering SDN in OT and want a grounded, risk-aware approach, contact Enaxy at [email protected].

Why Do Organizations Conduct OT/ICS Penetration Tests?

Organizations turn to penetration testing for several reasons, but each comes with a critical counterpoint:

1. Identifying Vulnerabilities in Critical Systems

While it’s essential to identify vulnerabilities, most OT organizations are already acutely aware that their environments have security gaps. Conducting penetration tests without first establishing clear goals, remediation pathways, and operational safeguards often results in reports that confirm what’s already known without actually moving the needle on security. Testing for the sake of testing, especially without structured follow-up, can create unnecessary risk without delivering meaningful value.

2. Meeting Regulatory or Compliance Requirements

When penetration testing is driven solely by compliance mandates, it often devolves into a check-the-box exercise, a focus on documentation rather than a catalyst for meaningful change. In OT environments, where safety and uptime are paramount, every test should be justified by its potential to strengthen real-world defenses. Instead of treating testing as a regulatory obligation, organizations should use it as a strategic opportunity to identify critical gaps, validate existing controls, and prioritize remediation efforts that measurably reduce risk.

3. Evaluating Vendor-Supplied Solutions

Understanding third-party risk is essential, but in OT environments, equipment is typically selected for its operational capabilities not its cybersecurity features. Expecting penetration testing to be the primary means of evaluating a vendor’s security posture is unrealistic and often ineffective. Instead, organizations should assess vendor risk early in the procurement lifecycle through security questionnaires, contractual security requirements, and audits. Penetration testing should complement, not replace, robust vendor risk management practices. 

4. Demonstrating Due Diligence to Stakeholders

A test that doesn’t lead to actionable security improvements is just a showpiece. True due diligence requires improving defenses, not just proving weaknesses exist.

5. Testing Incident Response Readiness

One of the most compelling reasons to conduct penetration testing in OT/ICS environments is to test and validate your Incident Response (IR) capabilities. When an organization has a well-defined, thoroughly practiced IR plan, penetration tests can serve as controlled, real-world simulations that highlight how your team detects, communicates, and mitigates threats. This stress-testing of your playbook helps identify blind spots in detection coverage, gaps in response coordination, and areas where documentation or decision-making may falter. In regulated or safety-critical sectors, that kind of validation is essential, not just helpful.

The Readiness Gap: Why Many OT/ICS Penetration Tests Fail

Many penetration tests fail to deliver meaningful results because organizations lack foundational security measures. The key barriers include:

1. Lack of Network Visibility and Asset Inventory

A foundational step in any OT/ICS cybersecurity initiative is establishing clear visibility into the environment. Many organizations lack a comprehensive asset inventory, making it nearly impossible to scope penetration tests appropriately or prioritize the right targets. Without this visibility, testing may miss critical vulnerabilities or worse, disrupt systems unintentionally. To adapt a common cliché: you can’t know if you’re testing the right things if you don’t know what you should be testing. Utilizing network monitoring tools and asset discovery processes can help to establish a baseline inventory.

2. Poorly Defined Objectives

Without clear goals, tests often produce generic findings that don’t address business-critical risks. Testing must align with business priorities, operational safety, and realistic attack scenarios. A vague test leads to vague results.

3. Legacy Systems with Undocumented Configurations

Legacy OT systems often lack modern security controls and documentation, making them particularly fragile in the face of penetration testing. Unknown or undocumented vulnerabilities such as outdated software configurations or brittle authentication systems can cause disruptions during testing. For example, something as basic as testing password strength could inadvertently trigger account lockouts, especially if the organization’s actual lockout policy differs from what the testers were told. That’s why it’s critical to carefully scope penetration tests, asking questions like, “What’s your account lockout threshold?” to avoid unintended outages and ensure the test does not interfere with operations. In OT, even minor disruptions can escalate into safety or reliability issues, so due diligence in test planning is non-negotiable.

4. Lack of Established Testing Policies and Safety Measures

Penetration testing in OT/ICS environments carries significantly higher stakes than in traditional IT networks. Without clearly defined safety protocols, even minor missteps like locking out a user account can cascade into operational failures. In IT, this might frustrate a single employee. In OT, it could mean operators lose visibility or control over critical systems, leading to safety hazards, environmental damage, or production downtime. To mitigate these risks, all testing tools and procedures should be vetted in a lab setting that accurately reflects the production environment. Strict change control processes, real-time communication between testers and operations staff, and predefined rollback procedures are essential to ensure that testing improves resilience without compromising operations.

The bottom line is, conducting penetration tests without proper readiness introduces operational hazards such as system instability, inaccurate findings, and unintentional downtime.

Bridging the Gap: Practical Steps to Improve OT/ICS Readiness

So, what should you do before you perform a penetration test on an OT/ICS environment? Before diving into testing, it’s essential to lay the groundwork to ensure safety, relevance, and effectiveness. The following preparatory actions are critical to making sure your organization is not only ready for penetration testing but positioned to gain real value from it:

1. Build a Phased Roadmap

Use the penetration test as part of your defined cybersecurity roadmap.

Step 1: Achieve full visibility into assets and network activity.
Step 2: Define the scope and objectives of testing efforts.
Step 3: Align stakeholders, ensure engineering and security teams are on board.
Step 4: Execute the test in a controlled, safe manner.
Step 5: Leverage the test to drive security improvements.

2. Gather Stakeholder Engagement and Buy-in

Engage operations, engineering, and cybersecurity teams from the outset to ensure penetration testing is grounded in operational reality. Their insights help define test boundaries, assess potential risks, and coordinate responses if disruptions occur. This collaboration not only improves test effectiveness but also strengthens organizational readiness and resilience during and after testing.

3. Leverage Third-Party Expertise While Prioritizing Safety

Bringing in third-party specialists can provide fresh perspectives and uncover blind spots. However, in OT/ICS environments, it’s essential that their testing methods are specifically tailored to industrial systems. Testing techniques that may be safe in IT networks could introduce unacceptable risk in OT environments. Always ensure that any external testing is coordinated closely with operations teams, and that it includes safety reviews and contingency planning to prevent disruptions. 

4. Focus on Continuous Improvement

A single penetration test is not a standalone fix. Effective OT/ICS security requires an ongoing cycle of testing, remediation, and validation. Each round of testing should drive actionable improvements, with lessons learned feeding into future assessments. This iterative approach builds maturity over time and ensures security posture keeps pace with evolving threats and changes in the operational environment.

Conclusion

Penetration testing in OT/ICS environments can deliver tremendous value, but only when it’s done at the right time and under the right conditions. Without adequate preparation, testing can lead to operational disruptions, produce misleading results, or simply find already-known problems without providing a clear path forward.

Before you proceed, ensure you’ve laid the groundwork:

• Establish a complete and accurate asset inventory
• Define meaningful, risk-aligned testing objectives
• Involve stakeholders across operations, engineering, and security
• Put safeguards in place to protect system availability and safety

At Enaxy, we help organizations assess their readiness, scope, and execute meaningful tests, then turn results into action. Whether you’re building your first OT security program or looking to enhance your testing strategy, our experts are here to guide you safely and effectively.Contact us at [email protected] to discuss how to prepare your organization for a successful and impactful OT/ICS penetration test.

What is API 1164

API 1164 provides best practices for identifying and managing cybersecurity risks associated with pipeline operations. Its objective is to establish a systematic approach that helps organizations protect their critical infrastructure from cyber threats. By adopting these guidelines, companies can enhance their security posture and foster resilience in their operations.

Implementing API 1164

API 1164 outlines best practices for risk management, access control, incident response, and resilience strategies specific to the midstream sector, helping pipeline operators safeguard their networks against cyberattacks. However, implementing these guidelines effectively requires a structured approach that aligns security measures with operational needs.

This blog will examine API 1164’s core components, explore practical implementation steps, and discuss how organizations can enhance their cybersecurity posture while ensuring compliance. Whether you’re a cybersecurity professional, IT leader, or pipeline operator, this guide will provide actionable insights to help you fortify your pipeline infrastructure against cyber threats. Let’s dive in! 

Step 1: Asses Current Cybersecurity Posture

The first step in implementing API 1164 is to assess your cybersecurity posture by conducting a thorough risk assessment. This process involves:

• Identifying Assets: Inventory all hardware, software, and data systems.
• Evaluating Vulnerabilities: Assess each asset for potential vulnerabilities and weaknesses. This is more broad than just listing specific vulnerabilities based on the hardware and software. It includes holistically examining the environment and how systems interact to identify ways a system could be misused.
• Understanding Threats: Identify potential cyber threats specific to pipeline operations (e.g., malware, insider threats).
• Impact Analysis: Evaluate the potential impact of different threats on operations, safety, and compliance.

It is critical to engage key stakeholders from various departments (IT, operations, compliance, management), as they must be involved to ensure a comprehensive understanding of cybersecurity risks.

Step 2: Create a Cybersecurity Policy

Based on the risk assessment, develop a cybersecurity policy by:

• Defining the objective and what you aim to achieve regarding cybersecurity.
• Clearly outlining who is responsible for various aspects of cybersecurity.
• Including relevant regulatory and industry standards.

Step 3: Establish Security Controls

Implement a defense-in-depth approach to cybersecurity by incorporating both technical and operational controls:

Technical Controls:

• Firewalls and intrusion detection systems are foundational systems that should be implemented to provide the ability to control and monitor traffic in and out of the OT/ICS networks. 
• Regular software updates and patch management help address vulnerabilities within the OT/ICS systems and mitigate the risk of exploits. 
• Strong access controls and authentication measures prevent unauthorized access to systems that can read and write data to devices that control the process. 

Operational Controls:

• Employee training programs should raise cybersecurity awareness among system maintainers and those responsible for Operations.
• Incident response plans detailing steps required in a cyber incident, from identification to eradication. 
• Regular audits are conducted to assess compliance with established policies and ensure that security controls are being maintained. 

Step 4: Continuous Monitoring and Improvement

Implement Monitoring Solutions

Set up continuous monitoring systems to detect and respond to cybersecurity threats in real time. This can include:

• Network monitoring tools that track unusual activities.
• Centralized log management systems to analyze access and activity logs.

Step 5: Improvement 

Review and Update Regularly

Cybersecurity is not a one-time effort.

• Review and update your policies, procedures, and security measures regularly to adapt to evolving threats. 
• Schedule annual reviews of your cybersecurity framework and conduct periodic assessments based on changing technology and threat landscapes.

Step 6: Train and Engage Employees

Foster a Cybersecurity Culture

Employees play a crucial role in your cybersecurity strategy. Implement regular training sessions to educate staff on the following:

• Recognizing realistic attack vectors and tactics.
• Best practices for data protection and secure handling of information.
• The importance of reporting suspicious activities.

Create a Reporting Mechanism

Encourage employees to report potential security incidents or vulnerabilities. Anonymous reporting tools or dedicated hotlines can facilitate this.

Step 6: Collaborate with Industry Peers

Share Information and Best Practices

Collaboration is vital in combating cybersecurity threats. Engage with industry peers, participate in information-sharing forums, and stay updated on the latest cybersecurity trends and incidents within the pipeline sector.

Leverage External Expertise

Consider partnering with cybersecurity firms or consultants who specialize in pipeline security. Their expertise can provide valuable insights and help implement advanced security measures. 

Conclusion

Implementing the API 1164 cybersecurity guidelines involves more than mere compliance; it emphasizes protecting your organization and ensuring the integrity of your operations. By following these steps, you can significantly improve your cybersecurity and operational resilience: assess your current posture, create a strong framework, establish security controls, continuously monitor your systems, train your employees, and collaborate with peers.

As cyber threats become more sophisticated, our defenses must evolve in tandem. By embracing this challenge and proactively embedding cybersecurity into every layer of the operation, the pipeline industry can ensure safer, more reliable performance.

At Enaxy, we support energy and infrastructure operators in translating API 1164 into actionable strategies, helping them safeguard what matters most.

Looking to operationalize API 1164 effectively? Let’s talk, reach out to [email protected].

Resources

• API 1164 Official Guidelines (https://www.api.org/)
• NIST Cybersecurity Framework (https://www.nist.gov/cyberframework)
• Cybersecurity & Infrastructure Security Agency (CISA) (https://www.cisa.gov/)

This blog will dispel the myth through technical analysis, case studies, and an overview of modern attack techniques. Methods such as automated, opportunistic, and occasionally indiscriminate attacks often affect even the smallest OT environments. We’ll also explore how small OT networks are compromised and provide practical steps to mitigate these risks.

The Modern Threat Landscape

Opportunistic Attacks Are Now the Norm

Modern attackers, both criminal and nation-state, rarely conduct manual reconnaissance for every target. Instead, they deploy automated tools and mass vulnerability scanners that probe the Internet for exploitable systems. Once a target is found, even if small or obscure, it’s either:

• Compromised immediately through automated exploits.
• Logged for later human exploitation.
• Sold on underground markets to third-party threat actors for further reconnaissance and exploitation.

The 2021 Colonial Pipeline ransomware attack started with a single compromised VPN account, not an extensive, targeted campaign. If big organizations can be breached through a small entry point, the same applies to small networks: they can be hacked using automation, no matter their size.

The Rise of OT Malware

Tools like Industroyer2, TRITON, and Incontroller show increasing sophistication and modular design, allowing attackers to create OT-focused payloads that are more flexible. Some recent malware variants include built-in modules for Modbus, OPC, DNP3, and other common OT protocols, so attackers no longer need custom reconnaissance to target operational systems.

Attackers don’t need to know who you are, just that you run a vulnerable HMI or RTU.

Why Small OT Networks Are Attractive

Lack of Security Hygiene

Organizations operating smaller OT networks frequently lack:

• Dedicated cybersecurity staff
• Regular cadence for applying patches and updates
• Network segmentation
• Continuous monitoring or logging

This makes them low-hanging fruit. Attackers routinely compromise small OT networks because the probability of success is higher, and the risk of detection is lower.

Supply Chain and Pivot Points

Attackers often exploit smaller networks not for direct value, but as steppingstones to larger environments. For instance:

• A small OEM facility may interface with a global manufacturing partner.
• A small SCADA vendor might have VPN access to multiple utility clients.
• A third-party contractor may manage remote substations across various jurisdictions.

In a hyperconnected OT ecosystem, the size of your network is irrelevant if it provides a pathway to a larger prize.

Real-World Incidents Involving Small OT Environments

• Rural Hospitals (2020–2022): Several ransomware groups targeted healthcare providers like Ridgeview Medical Center and Memorial Health System, which had limited IT and OT resources. Disruptions affected medical gas systems, HVAC, and other OT assets.
• Agricultural Cooperatives (2021): Multiple co-ops in the U.S. were hit with ransomware, causing downtime during critical harvesting seasons. Small OT networks controlling grain elevators or processing lines were affected.

Technical Pathways to Compromise

Remote Access Weaknesses

Small OT networks frequently rely on:

• Exposed RDP, VNC, or TeamViewer interfaces.
• Static credentials or default passwords.
• VPN appliances with outdated firmware.

In recent years, Shodan and Censys have revealed thousands of exposed industrial control interfaces, many without proper authentication or TLS. Below is an example of Shodan displaying hosts that are exposed. 

Mitigation:

• Use MFA and robust authentication for all remote access.
• Log and monitor remote sessions.
• Disable unused remote tools, especially after hours.

Flat Network Architecture

Without VLANs or network segmentation, once an attacker breaches the IT-OT boundary (or even just an engineering workstation), they often have unrestricted access to:

• PLCs
• HMIs
• SCADA servers
• Historian databases

In some cases, attackers can issue destructive commands directly, such as by issuing Modbus/TCP or DNP3 commands with no authentication required.

Mitigation:

• Implement network segmentation (e.g., Purdue Model tiers).
• Restrict communication to authorized hosts only.
• Use firewalls that understand OT protocols.

Legacy and Unsupported Assets

Many small networks still run:

• Windows XP or 7-based HMIs.
• Unpatched Linux systems.
• Embedded systems with hardcoded credentials.

Vulnerabilities like EternalBlue, BlueKeep, or Shellshock remain viable in these environments. Even known CVEs from 10+ years ago still plague small networks.

Mitigation:

• Apply virtual patching via firewalls or intrusion prevention systems.
• Isolate legacy systems.
• Use host-based protections where patching is impossible.

Attacker Motivations in Small OT Networks

While large industrial enterprises often dominate cybersecurity headlines, smaller OT networks are far from immune. In fact, their limited resources, outdated infrastructure, and lack of mature defenses can make them even more appealing targets. Understanding the motivations behind these attacks is critical to building adequate defenses.

The most visible driver is financial extortion, where ransomware operators and Ransomware-as-a-Service (RaaS) affiliates exploit the urgency of time-sensitive OT processes to force quick payouts.

Beyond profit, some actors are motivated by ideological or hacktivist goals, using small but symbolic OT environments to draw attention to their causes. These attacks may be relatively low-cost to launch, yet they can create disproportionate visibility and disruption.

Finally, small OT networks can also serve as quiet entry points for espionage and surveillance operations. By compromising less-defended suppliers, contractors, or utilities, advanced actors can establish persistence, gather intelligence, and eventually pivot into larger and more strategic targets.

Financial Extortion

Ransomware-as-a-Service (RaaS) actors increasingly target small OT sites because:

1. Smaller Facilities Are Easier, High-ROI Targets

• Rural hospitals and smaller healthcare providers are especially attractive targets because attackers need less technical skill and expect quicker payouts. Analysts describe these as “an easier payday” for ransomware actors, even when the demanded amounts aren’t necessarily large, because the return on investment remains high.
• Many of these facilities operate on tight budgets and often can’t absorb prolonged downtime or afford robust cybersecurity infrastructure.

2. Lack of Adequate Backups Makes Quick Payment More Likely

• A large-scale study found that ransomware attacks on U.S. healthcare organizations caused on average 17 days of downtime, costing roughly $1.9 million per organization per day. The total downtime costs across all incidents from 2018 to 2024 reached around $21.9 billion.
• This enormous financial burden incentivizes small OT operators to pay quickly if backups are insufficient or non-existent.

3. OT Environments Are Especially Time-Sensitive

• In several cases, rural hospitals struck by ransomware had to operate under severe constraints. For example, when Sky Lakes Medical Center (a small 90-bed rural hospital in Oregon) refused to pay, it experienced a 28-day network outage. It had to repair or replace 2,500 computers, severely disrupting operations.

4. OT Systems, Like Water Treatment and SCADA, Are Often Vulnerable

• Critical infrastructure, such as water and wastewater treatment facilities, have been repeatedly targeted. A joint advisory issued by U.S. agencies (FBI, NSA, CISA, EPA) detailed multiple ransomware incidents in 2021 against facilities in Nevada, Maine, and California, where SCADA systems and backup systems were impacted.
• These small OT sites are often configured with remote access tools for maintenance, but lack proper segmentation or firewalls, making them low-hanging fruit for attackers.

Ideological and Hacktivist Goals

Hacktivist groups might target small, symbolic OT infrastructure to make an impact. The Iranian attack on the Bowman Avenue Dam, a small flood-control dam in New York, is a good example. The attackers probably thought they were targeting something larger because the dam shared a name with the Arthur Bowman Dam in Oregon, a (much) larger facility. The cost for the attackers is low, while the visibility can be worldwide.

Espionage and Surveillance

Small OT networks in defense subcontractors or utilities may be targeted to:

• Establish persistent access.
• Map supply chains.
• Pivot to larger networks.

These efforts often go undetected for years due to the lack of centralized logging or monitoring.

Defending the Small OT Network

If small OT networks are attractive targets, they must also become resilient defenders. The challenge, however, is that most of these environments operate with tight budgets, small teams, and limited time for cybersecurity. Despite these constraints, practical and achievable steps can significantly reduce risks.

Threat Modeling for Small Environments

The first step is threat modeling, which small operators often overlook. Even a simple approach, identifying assets, potential attackers, and possible vulnerabilities, can guide more informed investment and defense decisions. Tools like MITRE ATT&CK for ICS and the CISA “Cybersecurity Performance Goals (CPGs)” make this process more accessible than ever. 

A common mistake is assuming only large enterprises need formal threat models. However, even a lightweight threat model can help small OT operators understand:

• What they have (asset inventory).
• Who might want to attack them?
• What could go wrong?
• Where to place defenses.

Tools like MITRE ATT&CK for ICS and the CISA CPGs provide actionable starting points.

Cost-Effective Security Measures

Once risks are understood, the next priority is implementing cost-effective security measures. Small networks may not afford enterprise-grade security stacks, but simple tools can provide strong protection and provide a good ROI without exceeding budgets. 

Some examples of good cost-effective measures are:

• Read-only network taps plus basic logging.
• Allowlisting software on HMIs and workstations.
• USB lockdown tools to prevent portable media infection.
• Offline backups which are stored physically disconnected from the network.
• Managed detection and response (MDR) services tailored for OT to provide expertise small organizations may lack.

Workforce and Culture

Finally, technology alone isn’t enough; workforce and culture are crucial. In many small OT environments, a few engineers juggle multiple responsibilities, leaving little room for cybersecurity. Cybersecurity often takes a back seat. Embedding basic cyber hygiene training, maintaining simple incident response plans, and regularly reviewing vendor access can shift the culture toward security without overwhelming already stretched teams.

Shifting the culture toward addressing cybersecurity challenges without overwhelming already stretched teams begins with:

• Cyber hygiene training for plant personnel.
• Basic incident response playbooks, even if it’s a one-pager.
• Vendor and contractor access audits to limit exposure.

Size Doesn’t Equal Safety

The belief that “a small OT network won’t be targeted” is not only outdated, but also actively harmful. Today’s threat actors do not discriminate based on size. They exploit exposed services, obsolete systems, and weak defenses. And too often, they succeed.

Operational Technology, regardless of scope or budget, underpins physical processes that can impact safety, the environment, and critical services. That makes OT networks all high-value targets from a cybersecurity standpoint.

Your network isn’t too small to matter and it’s too important to ignore.

At Enaxy, we help organizations of every size strengthen their OT defenses. From assessing vulnerabilities and hardening small-scale networks to building scalable security programs, our experts ensure that even the leanest OT environments are resilient against modern cyber threats.

Don’t wait until your network is targeted, connect with us at [email protected] to secure your OT systems today.

This article will explore why cybersecurity is essential for maritime operations, explain BIMCO’s guidance, and present practical strategies with actionable steps for integrating these recommendations effectively.  

Why Does Cybersecurity Matter in Maritime?  

Maritime vessels rely on various interconnected digital systems, including GPS navigation, communication networks, and operational technology (OT) systems for propulsion, cargo handling, and more. While these systems improve efficiency, they expose the industry to cyber risks.  

Critical cyber threats include:  

• Operational disruptions: Cyberattacks can paralyze essential systems, halting a vessel mid-journey.  
• Data breaches: Sensitive information, such as cargo manifests and crew details, can be stolen or manipulated.  
• Financial losses: Ransomware, downtime, and recovery efforts can incur significant costs.  
• Safety hazards: Compromised systems can endanger crew, passengers, and the environment.  

As cyber incidents in the maritime sector become more frequent and sophisticated, robust cybersecurity is no longer optional, it’s essential for operational integrity and safety.

Understanding BIMCO’s Cybersecurity Guidance  

BIMCO has long recognized the importance of cybersecurity in maritime operations. Its flagship publication, “The Guidelines on Cyber Security Onboard Ships,” has been a cornerstone for building resilient defenses against cyber threats since 2016, with four more revisions as of November 2024. 

Here’s a breakdown of the critical components:  

1. Risk Management  

• Regular cyber risk assessments to identify and address vulnerabilities.  Alignment with the IMO’s resolution MSC.428(98) required cybersecurity to be integrated into the ISM Code by 2021.  

2. Defensive Measures:

• BIMCO regulations emphasize securing IT (Information Technology) and OT networks.
• Recommendations include segmenting networks, promptly updating software, and enforcing strong password policies.  

3. Crew Awareness and Training:

• Human error is a significant contributor to cybersecurity breaches. BIMCO’s guidelines stress educating crew members to recognize phishing emails, protect devices, and follow security protocols.

4. Incident Response Planning:  

• Effective cybersecurity isn’t just about prevention but also response. BIMCO advises creating robust incident response plans to quickly detect, contain, and recover from cyber incidents.  

5. Supply Chain Collaboration:  

• Cybersecurity is only as strong as its weakest link. BIMCO highlights the need to ensure suppliers and partners follow cybersecurity best practices to prevent vulnerabilities from spreading through interconnected systems.  

How to Implement BIMCO’s Cybersecurity Guidance  

Applying BIMCO’s recommendations requires a strategic and systematic approach:  

• Policy Integration: Incorporate cybersecurity into existing safety and operational management systems to ensure alignment with the ISM Code.
• Technology Investment: To secure systems use tools like firewalls, intrusion detection systems, and regular software updates.
• Continuous Monitoring: Regularly evaluate and update your cybersecurity measures to stay ahead of emerging threats.  
• Crew Training: Make cybersecurity awareness a cornerstone of your training programs, emphasizing real-world scenarios such as phishing and ransomware attacks.
• Stakeholder Engagement: Foster collaboration across the supply chain to ensure everyone is responsible for maintaining robust cybersecurity standards.

Why BIMCO’s Cybersecurity Guidance Matters  

BIMCO’s guidance is more than a set of rules, it’s a roadmap for navigating the digital challenges of the maritime industry. By following these guidelines, stakeholders can:  

• Enhance resilience against cyber threats.  
• Safeguard the integrity of maritime operations.  
• Protect the safety of crew, passengers, and cargo.  
• Build trust with customers and partners through robust cybersecurity practices.  

A Safer, More Secure Digital Horizon  

Cybersecurity must remain a top priority as the maritime industry continues its digital transformation. BIMCO’s guidance provides the tools and strategies to protect vessels, ports, and global supply chains from evolving cyber risks.  

The call to action is clear: whether you’re a shipowner, operator, or crew member, adopting BIMCO’s cybersecurity practices is essential for a safer and more secure maritime future.

At Enaxy, we partner with maritime organizations to turn cybersecurity principles into operational practice, helping safeguard maritime infrastructure at scale.

Need support implementing BIMCO-aligned cybersecurity in your operations? Reach out to [email protected] and let’s chart a safer course forward.

In May 2021, the Colonial Pipeline ransomware attack sent shockwaves around the world. A criminal group exploited weak VPN credentials to penetrate the company’s IT systems, forcing Colonial to shut down 5,500 miles of pipeline. The resulting disruption caused fuel shortages, panic buying, and cascading economic effects along the East Coast of the United States.

For many, this incident highlighted a truth that cybersecurity experts had long warned about: critical transportation infrastructure is a prime target for cyber adversaries.

In response, the Transportation Security Administration (TSA), responsible for securing U.S. transportation systems, moved quickly. While most people think of TSA as focused on physical security in aviation and passenger travel, transporting Oil & Gas in pipelines is also regulated by TSA. After the Colonial Pipeline incident, the agency pivoted to cyber regulation. It issued a series of Security Directives designed to strengthen defenses across the transportation sector, starting with pipelines and expanding to rail and aviation.

These directives are not optional; they carry the force of regulation. Their goal is to create a baseline cybersecurity standard across an industry that historically relied on voluntary guidelines and sector-specific best practices.

This blog takes a deep dive into the TSA Security Directive:

• Its origins and scope.
• The key requirements operators must meet.
• The cyber risks it addresses.
• Practical challenges and opportunities for industry.
• Why compliance is just the beginning.

Origins and Scope of the TSA Security Directive

The TSA’s cybersecurity directives were created because the existing system was seen as inadequate. Before the Colonial Pipeline incident, much of the critical infrastructure depended on voluntary adoption of cybersecurity frameworks, such as the NIST Cybersecurity Framework (CSF) or ISA/IEC 62443. Adoption varied widely, and many pipeline, rail network, and airport operators were behind in cybersecurity maturity.

Pipeline Security Directive (2021)

The initial directive focused on pipeline operators, requiring:

• 24-hour reporting of cybersecurity incidents to the Cybersecurity and Infrastructure Security Agency (CISA).
• A designated Cybersecurity Coordinator is available 24/7.
• Conducting vulnerability assessments and remediating gaps.
• Implementing specific mitigation measures to protect against ransomware and remote access attacks.

Expansion to Rail and Aviation

By 2022, directives had expanded to include surface transportation (freight and passenger rail, aviation, and mass transit), recognizing its importance to national security and commerce. These directives are aligned in spirit but tailored to the unique systems and risks of each industry.

The scope is clear: TSA directives apply to owners and operators of essential transportation infrastructure deemed critical to the nation’s security and economy.

Key Requirements of the TSA Security Directive

The TSA directives aim to establish minimum expectations across the industry. While exact requirements differ slightly across pipeline, rail, and aviation, the core principles are consistent.

1. Cybersecurity Incident Reporting

Operators must report specific cybersecurity incidents to CISA within 24 hours of detection.

• Why it matters: Rapid reporting allows federal agencies to help contain threats, identify patterns across sectors, and provide defensive guidance to other operators.
• Cyber risk addressed: Delayed detection or reporting enables adversaries to move laterally across networks, allowing them to cause more damage before defenders can respond.

Case Example: In the Colonial Pipeline incident, the lack of real-time reporting left government agencies scrambling to gather information. The directive ensures future incidents are visible at the national level.

2. Cybersecurity Coordinator

Operators must designate a Cybersecurity Coordinator who is available 24/7 as the primary point of contact with TSA and CISA.

• Why it matters: Establishes a clear line of communication between federal agencies and operators during crises.
• Cyber risk addressed: Miscommunication and delays during an attack can result in the loss of precious recovery time.

This requirement professionalizes response coordination across an industry where cybersecurity expertise varies widely.

3. Vulnerability Assessments and Gap Analysis

Operators must regularly assess their current cybersecurity posture, identify vulnerabilities, and document remediation plans.

• Why it matters: Identifies weaknesses before adversaries exploit them.
• Cyber risk addressed: Unpatched systems, weak authentication, flat networks, and misconfigurations that create attack vectors.

Practical Tip: Many operators leverage the NIST CSF or ISA/IEC 62443 frameworks to structure these assessments, thereby aligning TSA mandates with industry best practices.

4. Implementation of Cybersecurity Measures

Operators must adopt layered defenses, a principle known as defense-in-depth. TSA directives emphasize:

• Network segmentation between IT and OT.
• Access control (multi-factor authentication, least privilege).
• Regular patching for critical systems.
• Continuous monitoring of networks and logging of suspicious activity.
• Backup and recovery procedures for critical systems.
• Cyber risk addressed: Ransomware, unauthorized remote access, insider misuse, and persistence by nation-state actors.

Challenge: Many OT systems were never designed for patching or segmentation, requiring creative compensating controls.

5. Cybersecurity Contingency and Recovery Plan

Operators must document and maintain a contingency and recovery plan to ensure resilience.

• Why it matters: Transportation disruptions have real-world consequences, including fuel shortages, supply chain delays, and flight cancellations.
• Cyber risk addressed: Prolonged downtime after ransomware, destructive malware, or IT/OT convergence incidents.

Case Example: In 2023, a ransomware attack on the Port of Nagoya in Japan halted operations for days, delaying thousands of shipments. A well-tested contingency plan could minimize such downtime.

6. Regular Testing and Training

Operators must conduct exercises to validate plans and train staff to recognize and respond to cyber threats.

• Why it matters: Technology alone cannot prevent incidents; people and processes are equally important.
• Cyber risk addressed: Human error, lack of awareness, or poor execution of incident response procedures.

Note: Many organizations now conduct tabletop exercises simulating ransomware attacks that involve both technical and executive stakeholders; however, they often lack a focus on OT disruptions.

Cyber Risks: The TSA Directive Aims to Address

The directive directly responds to incidents that have impacted the transportation sector.

1. Ransomware

Ransomware is arguably the most visible threat to transportation Operators. Adversaries exploit weak credentials or unpatched systems, encrypt data, and demand payment. Beyond data, ransomware can force operators to shut down physical processes, as seen in the Colonial Pipeline incident.

2. Supply Chain Compromise

Attackers increasingly target third-party vendors, contractors, and service providers. TSA’s vulnerability assessment and reporting requirements encourage operators to scrutinize their supply chain and detect unusual activity early.

Example: The SolarWinds compromise demonstrated how adversaries can infiltrate thousands of organizations through trusted software updates.

3. Insider Threats

Transportation systems rely on thousands of employees and contractors with varying levels of access. Insider misuse, whether malicious or accidental, remains a serious risk. Access controls and continuous monitoring aim to mitigate this.

4. Nation-State Adversaries

Critical transportation systems are attractive targets for state-sponsored cyber campaigns, particularly in times of geopolitical tension. By raising the cybersecurity baseline across operators, TSA reduces systemic risk.

5. Operational Technology (OT) Vulnerabilities

Rail signaling systems, pipeline SCADA networks, and aviation ground systems often operate on legacy OT equipment that was never designed for cybersecurity. Segmentation, monitoring, and contingency planning address the reality that OT is increasingly connected to IT.

Implementation Challenges for Industry

While the TSA directives raise the bar, operators face significant challenges in implementation:

1. Legacy Infrastructure: Many OT devices cannot easily be patched or segmented without disrupting operations.
2. Resource Constraints: Smaller Operators often lack dedicated cybersecurity staff, making 24/7 coordination and continuous monitoring challenging.
3. Vendor Dependency: Operators often rely on third-party vendors for system maintenance, which creates additional risk.
4. Compliance vs. Security: Meeting the letter of the directive doesn’t always equal true resilience.

Beyond Compliance: Building True Resilience

Compliance with TSA directives is necessary but not sufficient. Operators should treat the directives as a baseline, then build a more mature cybersecurity program:

• Establish a Company Culture: Clearly communicate company policies and procedures, and effectively address cybersecurity risks.  
• Integrate with Industry Frameworks: Utilize ISA/IEC 62443 and NIST CSF to develop long-term security strategies.
• Invest in Monitoring and Detection: Leverage threat-hunting, intrusion detection, and managed OT security services.
• Adopt Zero Trust Principles: Move beyond perimeter defenses toward continuous authentication and least-privilege access.
• Prioritize Workforce Training: A well-trained workforce is the first line of defense.
• Plan for the Worst: Assume compromise will happen, focus on limiting blast radius and recovering quickly.

Conclusion: TSA Directives as a Turning Point

The TSA Security Directives mark a turning point in U.S. critical infrastructure protection. By mandating incident reporting, vulnerability assessments, layered defenses, and recovery planning, the directives directly address the most pressing cyber risks to transportation systems.

For operators, these mandates are both a compliance requirement and an opportunity for growth. Implemented thoughtfully, they can enhance resilience, reduce downtime, and strengthen public trust in essential services.

The Colonial Pipeline attack was a wake-up call. TSA’s directives are part of the response. But in the long run, security will depend on Operators moving beyond compliance to embrace a culture of continuous improvement, workforce readiness, and resilience in the face of evolving threats.

Transportation systems are the lifelines of modern society. Securing them is not just a regulatory requirement; it is a national imperative.

At Enaxy, we help transportation and critical infrastructure operators turn compliance into capability. Our team assists with TSA Directive implementation, risk assessments, and the development of tailored cybersecurity programs that strengthen resilience and operational continuity.Need help operationalizing TSA cybersecurity directives or building a stronger defense strategy? Contact us at [email protected] to get started.

Introduction and Background

At Enaxy, we recently wrapped up a blog series exploring how organizations can choose the right cybersecurity standard to build or enhance their OT/ICS security programs. That series focused on broadly applicable frameworks such as NIST CSF, ISA/IEC 62443, NIST SP 800-82, and the CIS Controls comparing their strengths, limitations, and strategic fit across different industrial sectors.

But what about standards designed for specific industries?

To put it plainly: Why might an organization choose to implement the ISA/IEC 62443 standards instead of the NIST Cybersecurity Framework? Or why lean on the SP 800-82 control catalog rather than the CIS Critical Security Controls when defining technical safeguards? These are questions of alignment, choosing what fits best for your environment, resources, and risk landscape.

Some standards, however, aren’t optional. They’re mandated.

One of the most prominent examples is the North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) Standards, which apply specifically to entities operating in the Bulk Electric System (BES). Overseen by the Federal Energy Regulatory Commission (FERC), the NERC CIP standards were first introduced in 2008 and have evolved significantly through ongoing revisions and working groups.Compliance with CIP is not just best practice, it’s a legal requirement.

Failure to comply can result in significant regulatory penalties, making it essential for covered entities to understand the scope, structure, and enforcement of these standards.¹

Who Must Comply with NERC CIP Regulations?

NERC CIP regulations apply to a specific subset of organizations operating within the North American Bulk Electric System (BES). Entities typically required to comply with NERC CIP standards include:

• Electric Generation Owners and Operators
• Electric Transmission Owners and Operators
• Balancing Authorities –  Entities responsible for maintaining the supply-demand balance within a given area
• Reliability Coordinators – The highest level of authority for ensuring BES reliability in a defined region 
• Interchange Authority – Entities coordinating energy transfers between Balancing Authorities 

However, NERC CIP applicability is not universal across all electric utilities. Instead, it depends on several operational and infrastructure-related factors, such as:

• The voltage level of the transmission lines owned or operated
• The total generating capacity of the facilities
• The potential impact of the entity’s assets on the overall reliability of the Bulk Electric System

Some smaller utilities or those not directly connected to the bulk power system may be exempt from NERC CIP requirements. But just because you are a small utility doesn’t mean you are not required to comply with the NERC CIP requirements. For example, a dam which is necessary for re-energizing the BES in a blackstart scenario (i.e. the entire grid in a region/area is down) would generally be subject to the CIP requirements even if its total generating capacity was minimal.

Understanding whether your organization falls under NERC CIP jurisdiction is a crucial first step in ensuring compliance and contributing to the overall security of the North American power grid. If you have questions about whether your organization must comply with the NERC CIP standards then the first step would be to check with any internal compliance department your organization may have, and if it is still not clear then to reach out to the NERC Regional Entity, the organizations responsible for auditing NERC standards compliance, which has responsibility for your region of the country.

Overview of NERC CIP Impact Rating Levels

NERC CIP standards recognize that not all assets within the BES have the same level of criticality or potential impact on overall grid reliability. To address this, the standards implement a tiered approach based on the potential impact of cyber systems on the reliable operation of the Bulk Electric System. These tiers are known as Impact Rating Levels, and they determine the specific security requirements that apply to each asset. The three Impact Rating Levels are referred to as High, Medium, or Low Impact.

• High Impact Systems: Control Centers used by Reliability Coordinators or used by Transmission or Generation Operators and Balancing Authorities which meet specific size/criticality criteria.
• Medium Impact Systems: BES Cyber Assets which meet specific criteria related to their size or criticality. For example, Transmission Facilities which are operated at 500 kV or higher would meet the Medium Impact criteria.
• Low Impact Systems: All other BES Cyber Systems that do not meet the criteria for High or Medium Impact. While these systems are considered to have a lower potential impact on grid reliability, they are still subject to certain baseline security requirements.

The Impact Rating Level of a system determines the specific set of security controls that must be implemented. Generally, the requirements become more stringent as the impact level increases. For example:

• High and Medium Impact systems require more comprehensive access control measures, including multi-factor authentication for remote access.
• High and Medium Impact systems have more stringent requirements for security event monitoring and incident response planning.
• Physical security requirements are more detailed and extensive for High and Medium Impact systems.

It’s important to note that a single organization may have systems at multiple impact levels. For instance, a large utility might have High Impact Control Centers, Medium Impact generation facilities, and Low Impact Transmission substations. Each of these would be subject to different sets of requirements under the NERC CIP standards.

Understanding these Impact Rating Levels is crucial for organizations to properly categorize their systems and implement the appropriate security controls. In the following sections, we’ll delve deeper into the specific requirements for Low Impact systems and Medium/High Impact systems.

Overview of NERC CIP Low Impact Requirements

While Low Impact BES Cyber Systems are subject to less stringent requirements compared to their Medium and High Impact counterparts, they are by no means insignificant. They still play a crucial role in maintaining the overall security of the Bulk Electric System. The requirements for Low Impact systems focus on establishing foundational cybersecurity practices and plans. Let’s examine the key areas of NERC CIP requirements for Low Impact systems:²

1. Cyber Security Awareness

Organizations must implement a cybersecurity awareness program that reinforces sound security practices. This typically involves regular training or communications, usually at least once a year,³ to ensure that personnel are aware of cyber security risks and their role in protecting BES Cyber Systems.

2. Physical Security Controls

Entities are required to implement measures to restrict physical access to Low Impact BES Cyber Systems. This can include, but is not limited to:

• Locked doors
• Security guards 
• Access control systems (e.g., badges, card readers, or biometric systems)

The intent is to prevent unauthorized physical access that could compromise the security or reliability of these systems. For Low Impact assets, NERC CIP provides flexibility in how these controls are implemented. Entities have significant discretion to tailor their physical security measures based on the facility’s risk profile, layout, and operational needs so long as the controls are effective and enforceable.

3. Electronic Access Controls

Organizations must implement electronic access controls to protect Low Impact BES Cyber Systems. This involves identifying all remote electronic access connections from external (e.g. outside the Facility) to BES Cyber Systems and implementing access control measures to permit only necessary inbound and outbound electronic access. There are two carveouts for this requirement, though, where it only applies if the communications are using a routable protocol and if they are “not used for time-sensitive protection or control functions between intelligent electronic devices.”

4. Cyber Security Incident Response

Entities must have a Cyber Security Incident Response (IR) plan that includes processes for identification, classification, and response to Cyber Security Incidents related to Low Impact BES Cyber Systems. Entities must also test their IR plans (or actually use them in a Reportable Cyber Security Incident) at least every 36 calendar months.

5. Transient Cyber Asset and Removable Media Management

Organizations must implement plans to mitigate the risks associated with:

• Transient Cyber Assets (TCA) – such as laptops, tablets, or diagnostic tools used temporarily for maintenance or troubleshooting
• Removable Media – such as USB drives, external hard drives, or SD cards

These plans must apply not only to internal assets but also to those brought in by third parties, such as contractors and vendors. The objective is to prevent these portable devices from introducing malware or unauthorized access into Low Impact BES Cyber Systems, maintaining system integrity and reliability. 

6. Declaring and Responding to CIP Exceptional Circumstances

The NERC CIP standards recognize that certain emergency situations may require flexibility in how requirements are applied. These situations are known as CIP Exceptional Circumstances. During such events, entities are not held to standard compliance expectations for certain requirements, such as those related to Transient Cyber Assets (TCA) and Removable Media.
For example, if emergency responders such as firefighters need immediate access to a facility to prevent injury or loss of life, the organization would not be considered non-compliant simply because those responders were not escorted, did not log their visit, or bypassed other standard physical security protocols.
This provision ensures that safety and emergency response are prioritized, while still aligning with the intent of the CIP standards. However, entities should document the exceptional circumstance and take appropriate actions after the fact, such as reviewing access logs or conducting post-event assessments, to ensure security integrity is maintained.

7. (BONUS!!) Vendor Electronic Remote Access Security Controls

Going into effect on April 1, 2026, CIP-003-9 adds requirements to mitigate risks involved with vendor remote access and have methods to determine where that remote access exists, ways to disable vendor remote access, and methods to detect malicious communications which may exist within vendor electronic remote access. 

While the NERC CIP requirements for Low Impact systems are less prescriptive than those for Medium and High Impact assets, they establish a foundational level of cybersecurity designed to address common threats. Organizations should treat these requirements not as the finish line, but as a baseline framework, a starting point for building a more comprehensive security posture. Entities are encouraged to evaluate their own risk environment and implement additional controls as needed to safeguard critical infrastructure effectively.

Overview of NERC CIP Medium/High Impact Requirements

Medium and High Impact BES Cyber Systems (BCS) are subject to significantly more robust and detailed security requirements due to the critical role they play in maintaining the reliability of the BES. Although there are nuanced differences between Medium and High Impact requirements, many of the standards and control families are shared between the two. These requirements are typically organized thematically across the NERC CIP standards. For example, CIP-005 focuses on electronic security perimeters, while CIP-007 addresses system security management. Here’s an overview of the key NERC CIP requirements for Medium and High Impact systems:

1. CIP-003: Security Management Controls

This standard outlines the foundational policies and procedures needed to govern a compliant cybersecurity program.

2. CIP-004: Personnel and Training

This standard focuses on ensuring that personnel who access BES Cyber Assets (BCAs) or BES Cyber System Information (BCSI) are properly vetted and trained. It includes requirements related to security awareness programs, cyber security training programs, and personnel risk assessment programs (e.g. background checks). These requirements generally include both initial requirements, such as the need to perform a personnel risk assessment prior to granting electronic access to BCA, as well as ongoing reviews, such as the need to verify at least once every 15 months that people with access to BCSI still need the provisioned access.

3. CIP-005: Electronic Security Perimeters

This standard is focused on securing the electronic boundaries around BCS. It requires organizations to identify a controlled Electronic Security Perimeter (ESP) and implement measures to control and monitor all electronic access points. CIP-005 also includes requirements related to remote access management, such as that it must be encrypted and require multi-factor authentication, and to be configured in a way to not allow direct access from an external source directly to the BCS. This standard ensures that only authorized communications can traverse into or out of sensitive OT environments and that these communications are secure and auditable.

4. CIP-006: Physical Security of BES Cyber Systems

CIP-006 establishes requirements for protecting BES Cyber Systems from physical threats by enforcing layered, risk-based physical security controls. Entities must develop and maintain a physical security plan tailored to the impact rating of each BCS. For Medium Impact BCS with External Routable Connectivity, these must utilize “at least one physical access control” before entering Physical Security Perimeters, while for High Impact BCS it requires “two or more different physical access controls.” Entities also must diligently monitor for unauthorized physical access. CIP-006 also includes requirements around logging visitor access and testing of Physical Access Control Systems.

5. CIP-007: Systems Security Management

CIP-007 includes technical, operational, and procedural requirements to manage system security. Requirements in this standard relate to the following areas:

1. Ports and services management
2. Security patch management
3. Malicious code prevention
4. Security event monitoring
5. System access control

6. CIP-008: Incident Reporting and Response Planning

CIP-008 outlines the requirements for developing, maintaining, and executing a Cyber Security Incident Response (IR) plan for BES Cyber Systems. This standard ensures that organizations can effectively detect, respond to, and recover from cyber incidents. There are also requirements around testing the IR plans at least once every 15 calendar months and to update IR plans to incorporate any lessons learned from either tests or actual Incidents. CIP-008 also includes notification requirements. Entities must notify both the E-ISAC and the United States National Cybersecurity and Communications Integration Center within one hour of confirming that a Reportable cyber Incident has occurred. 

7. CIP-009: Recovery Plans for BES Cyber Systems

CIP-009 focuses on ensuring that organizations are prepared to restore critical cyber assets after a disruption. Organizations must develop recovery plans that address the restoration of BCS following a cyber incident or failure. Recovery plans must be tested periodically to ensure effectiveness. Lessons learned from tests or actual recovery efforts must be incorporated into updated plans. Entities must also implement and maintain backup systems and documented restore procedures. These backups must be protected to ensure availability and integrity during emergencies.  

8. CIP-010: Configuration Change Management and Vulnerability Assessments

This standard contains requirements around establishing baseline configurations of systems and detecting changes to the baseline configuration. It also covers vulnerability assessments. High Impact BCS must have an active vulnerability assessment every 36 calendar months (using a testbed rather than a live system is acceptable, if not preferred), while both High and Medium Impact BCS require a “paper or active vulnerability assessment” be performed at least once very 15 calendar months. 

9. CIP-011: Information Protection

CIP-011 focuses on the protection and proper handling of BES Cyber System Information (BCSI)—sensitive data that, if compromised, could negatively impact the reliability of the BES. It requires entities to identify and classify information which is BCSI. BCSI must be secured against unauthorized access, disclosure, or misuse. This applies during storage, use, and transmission. Entities also must implement procedures for the secure disposal of BCSI. For example, simply throwing hard drives with sensitive data into a dumpster is not acceptable, data must be securely deleted, and physical media must be destroyed according to industry best practices.

10. CIP-012: Communications between Control Centers

CIP-012 is designed to safeguard the confidentiality and integrity of Real-time Assessment and monitoring data as it is transmitted between Control Centers. It is written as an objective-based requirement, where the goal of the security of communications is given, but entities have freedom to determine how they meet that objective.

11. CIP-013: Supply Chain Risk Management

CIP-013 focuses on reducing cybersecurity risks associated with third-party vendors and suppliers who provide products or services that impact the security of BES Cyber Systems. Entities must develop, document, and implement a supply chain cyber security risk management plan that addresses procurement of BES Cyber Systems and services. This plan must include vendor notification of incidents, coordinating responses with vendors, disclosure of known vulnerabilities, and verifying software and patches provided by the vendor. It also must include a plan to coordinate controls for vendor-initiated remote access and for the vendor to notify the entity when remote or onsite access is no longer needed. While entities have flexibility in how they meet these requirements, they must be able to demonstrate the existence and effectiveness of their risk management processes during audits.

12. CIP-014: Physical Security

CIP-014 stands out among the NERC CIP standards due to its narrow and highly targeted scope. Unlike other standards that apply broadly across cyber systems, CIP-014 is specifically focused on the physical security of the most critical Transmission Facilities. It requires a physical risk assessment to be performed for the Facility, evaluated by an unaffiliated third-party with expertise in physical security protections, and then the plan must be implemented and regularly reviewed and updated. CIP-014 is designed to protect the BES from physical attacks that could cause widespread outages or compromise grid stability. Given the high-impact nature of these facilities, this standard ensures that physical risks are addressed with the same rigor as cyber threats.

13. (Another Bonus!!) CIP-015: Internal Network Security Monitoring

CIP-015 has been written and approved by FERC, and will go into effect in 2028. It is focused on detecting anomalous or unauthorized network traffic in order to improve response and recovery from an attack. Organizations will need to determine how they will get data (e.g. configuring traffic monitoring feeds) and then how they will use the data to identify anomalous activity on the network. If FERC approves the Implementation Plan as written, then the requirements will go into effect for High Impact Control Centers and for Medium Impact Control Centers with External Routable Connectivity 36 months after that approval. For other Medium BES with ERC (e.g. not Medium Control Centers) then there will be an additional 24 months to comply with the requirements.

These requirements form a comprehensive security framework for Medium and High Impact BES Cyber Systems, encompassing both technical controls and essential organizational practices. They address not just systems and technology but also the governance, documentation, testing, and personnel readiness required to maintain a resilient cybersecurity program.

While many requirements overlap between Medium and High Impact systems, High Impact environments demand greater rigor including more frequent assessments, stricter access controls, and deeper validation of security mechanisms.

Achieving and sustaining compliance with NERC CIP standards requires a substantial commitment of resources, continuous monitoring, and expert insight. From building robust technical defenses to maintaining extensive documentation and training programs, organizations must remain agile and audit-ready.

More Questions?

Navigating the complex landscape of NERC CIP compliance can be challenging, but it’s crucial for maintaining the security and reliability of our power grid. Whether your organization manages Low, Medium, or High Impact BES Cyber Systems, implementing and maintaining compliance with NERC CIP standards requires ongoing effort, expertise, and resources. Enaxy can provide invaluable support in several ways:

1. Compliance Assessment: Evaluate your current cybersecurity posture against NERC CIP requirements and identify any gaps.
2. Strategy Development: Create a tailored roadmap for achieving and maintaining NERC CIP compliance.
3. Implementation Support: Assist in implementing necessary technical controls, policies, and procedures.
4. Training and Awareness: Develop and deliver customized training programs to ensure your staff understands their roles in maintaining compliance.
5. Audit Preparation: Help you prepare for NERC CIP audits, including documentation review and mock audits.
6. Ongoing Support: Provide continuous monitoring and support to help you stay compliant as regulations evolve and your systems change.

Cybersecurity is about more than just compliance, it’s a responsibility. By taking proactive measures to protect your BES Cyber Systems, you’re not only securing your organization you’re helping to safeguard the reliability of the power grid millions rely on every day.

Let’s build a more resilient future together.

Reach out to [email protected] to take the first step toward strong, sustainable NERC CIP compliance.

Your organization and the energy sector as a whole will be stronger because of it.

¹ Some definitions and concepts, especially in the background sections, are simplified for the purposes of this blog. The NERC CIP standards have an official glossary, and LiveWire’s NERCipedia is also a good resource for specific definitions of the various terms used throughout the standards.

² The Low Impact requirements are found in NERC CIP-003-8. The general areas are identified in Requirement 1.2, while more detailed descriptions of what the various areas require are in Attachment 1 of the same document.

³ This is an example where the CIP standard itself says “at least once every 15 calendar months,” but in implementing the requirement most organizations will treat the activity as an annual requirement, where the extra three months allows the organization to be compliant even if a long weekend (for example) makes the activity actually be completed in 12 months and 2 days after the previous occasion.

In industrial and critical infrastructure circles, few security concepts have been as misunderstood and misapplied as the idea of the “air gap.” For decades, operational technology (OT) networks were assumed to be physically isolated from any external connection, whether corporate IT, the public internet, or other external sources. This thinking went: if nothing connects, nothing can attack.

This mindset used to make sense. Power grids, water treatment plants, manufacturing lines, and oil refineries often operated on separate systems. Any interaction between OT and IT was manual, intentional, and infrequent. If you needed to reprogram a PLC, you’d walk into the plant, connect a cable, and enter the commands yourself.

But fast-forward to today, and that picture is nearly unrecognizable. The demands of modern business, along with advances in connectivity and automation, have diminished the air gap. Corporate and OT networks are merging, remote access is widespread, and many industrial devices now feature built-in network connectivity.

The myth persists that OT is still “air-gapped,” but the truth is that it is much more connected and, therefore, more vulnerable. Believing otherwise leads to dangerous complacency, underfunded security controls, and unprepared incident response.

Where the Air-Gap Assumption Came From

To understand why this myth refuses to die, we must revisit how OT networks were initially designed.

1. Proprietary Systems and Protocols

Historically, OT environments depended on specialized, vendor-specific systems. PLCs, RTUs, and DCS controllers communicated via proprietary protocols like Modbus, Profibus, or DNP3. These were not designed with security in mind, nor were they built to connect to external networks.

2. Physical Separation

Plant floor systems operated on their networks, often using serial connections, isolated hubs, or private fiber. Any data sharing with the outside world involved manual processes, floppy disks, later CDs or USB drives, and often strict change control.

3. Availability Over Security

The priorities of OT have always been the “CIA triad” flipped on its head:

• Availability- Keep systems running 24/7
• Integrity- Ensure processes are consistent and reliable
• Confidentiality- Important, but rarely the top priority

Because these networks were initially physically isolated, the lack of built-in cybersecurity wasn’t seen as a major problem.

Reality: The Gap Has Closed

The “gap” was never absolute. Even in the 1990s, engineers occasionally carried data between networks on removable media. But in the last 20 years, business and technical drivers have steadily connected OT to IT, and by extension, to the internet.

1. OT Convergence

Modern industrial operations depend on real-time data for efficiency, compliance, and profitability. That means OT systems need to share information with corporate business systems:

• Enterprise Resource Planning (ERP) systems use production data to manage supply chains.
• Manufacturing Execution Systems (MES) require continuous updates from plant-floor sensors and control systems.
• Data historians collect long-term process data for quality control, analytics, and reporting.
• Centralized monitoring allows the corporate HQ to oversee multiple facilities.

The result: a path, sometimes direct, sometimes through multiple network hops, between OT and IT.

2. Remote Access for Vendors and Maintenance

Downtime in OT environments can cost millions per hour. To minimize disruption, many organizations allow remote troubleshooting by:

• Original equipment manufacturers (OEMs)
• Systems integrators
• Specialized engineering contractors

This is often done over:

• VPNs
• Remote desktop protocols
• Vendor-hosted portals
• “Temporary” cellular or broadband modems connected directly to OT assets

In many cases, “temporary” remote access becomes permanent for convenience, and with it, a permanent vulnerability.

3. Industrial Smart Devices

Modern sensors, drives, and controllers increasingly ship with Ethernet, Wi-Fi, or even Bluetooth capabilities, and sometimes even embedded SIM cards. Many of these devices “phone home” to vendor cloud services for:

• Predictive maintenance alerts
• Firmware updates
• Performance analytics

While convenient, these features often bypass traditional OT network controls.

4. Shadow OT

It is not uncommon to find that network connections are not officially sanctioned. Engineers under pressure to deliver results may add:

• Unmanaged switches or hubs used to extend networks for new devices.
• Consumer-grade routers for temporary connectivity to an endpoint.
• USB storage devices used to transfer data for upgrades or other purposes. 
• Engineering laptops that connect to both IT and OT networks, or even worse, are a personal computer that has little to no security controls enforced.

Each shortcut increases exposure.

Why This Myth is Dangerous

Believing the air-gap myth leads to three critical mistakes:

1. Complacency – If you assume OT is unreachable, you don’t monitor it, segment it, or patch it.
2. Underfunding – Security budgets focus on IT because OT is “safe.”
3. Unpreparedness – Security teams don’t include OT in incident response, leaving engineers to improvise under pressure.

In short, if you think the bridge doesn’t exist, you won’t defend it, but attackers will find it.

Real-World Examples of the Airgap Failing

Stuxnet (2010)

Perhaps the most famous example, Stuxnet, was designed to target Siemens PLCs controlling uranium centrifuges in Iran. Even though the network was not connected to the internet, the worm spread via infected USB drives brought in by unsuspecting staff. It manipulated physical processes while hiding its changes from operators.

TRITON / TRISIS (2017)

A sophisticated malware framework targeted safety instrumented systems (SIS) in a petrochemical facility. The attacker entered through the corporate network, moved laterally into the OT environment, and attempted to reprogram the SIS controllers. In this case, they entered fail-safe mode, which prevented the attackers from gaining full control but also caused an unplanned plant shutdown.

Colonial Pipeline (2021)

While the ransomware attack targeted corporate IT systems, the pipeline operator shut down OT operations pre-emptively due to the interconnected nature of their networks. The incident caused fuel shortages and widespread disruption.

Oldsmar Water Treatment Plant (2021)

An attacker used a remote desktop connection exposed to the internet to try to raise sodium hydroxide levels in drinking water. Quick action by an operator prevented harm, but the intrusion was entirely digital.

These incidents prove that OT threats can originate from both direct connections and indirect pathways through IT or physical media.

Engineering and Security Practices to Address the Risk

The solution isn’t to try to rebuild the “perfect” air gap. It is no longer realistic or practical in modern operations. Instead, organizations need layered, realistic defenses that assume connectivity exists.

1. Network Architecture

Adopt a layered security approach. The following example is the Purdue Enterprise Reference Architecture, identifying the devices that are within each level:

• Level 0–1 – Field devices, PLCs, sensors
• Level 2 – Local HMIs, control servers
• Level 3 – Site operations network (manufacturing execution, historians)
• Level 3.5 – Industrial DMZ (buffer zone between OT and IT)
• Level 4–5 – Corporate IT, ERP, cloud services

Key steps:

• Use firewalls to strictly control traffic between zones.
• Implement data diodes for one-way data flow where possible.
• Ensure that any cross-network communication is authenticated, encrypted, and logged.

2. Secure Remote Access

• Require multi-factor authentication (MFA) for all remote sessions.
• Use jump servers in the DMZ rather than direct connections into OT.
• Make vendor access time-bound, and credentials expire after the work is done.
• Log and review all remote activity.

3. Monitoring and Detection

• Deploy OT-aware intrusion detection systems (IDS) that can interpret ICS protocols.
• Passively monitor network traffic for anomalies.
• Integrate OT telemetry into the Security Information and Event Management (SIEM) used for IT.

4. Patch and Asset Management

• Maintain a complete asset inventory, including hardware, firmware, software, and network topology.
• Classify assets by criticality to prioritize patching.
• Schedule vendor-approved patch windows to minimize disruption.
• Track and manage end-of-life systems that can’t be patched, applying compensating controls.

5. Cross-Team Collaboration

• Break down the silos between IT security teams and OT engineering teams.
• Conduct joint risk assessments that consider both business and operational impacts.
• Run tabletop exercises that simulate OT-specific incidents, such as process manipulation or safety system shutdown.

An OT Security Checklist for the Post-Air-Gap World

1. Inventory everything – You can’t protect what you don’t know exists.
2. Segment your network – Create choke points for monitoring and control.
3. Secure remote access – Limit, monitor, and authenticate.
4. Monitor continuously – Look for both IT-style threats and OT-specific anomalies.
5. Patch intelligently – Plan and test updates; apply vendor guidance.
6. Train all staff – Engineers, operators, and IT staff all have a role in security.
7. Plan for incident response – Include OT in your playbooks and drills.

Key Takeaway

The air gap, as it once existed, is gone for most industrial environments. Connectivity, whether intentional or accidental, means OT systems face many of the same cyber threats as IT. But OT attacks can cause far more than data loss: safety incidents, environmental damage, and prolonged outages are all on the table.

By accepting that OT is interconnected, organizations can concentrate on developing realistic, layered defenses that safeguard both business operations and physical processes. The myth of the perfect air gap is outdated; the future of OT security focuses on resilience in a connected world.

At Enaxy, we help organizations adapt to this new reality by designing layered OT security architectures, deploying monitoring solutions, and building incident response plans that protect both digital assets and physical operations. Our expertise ensures your defenses evolve alongside the threat landscape.

Ready to strengthen your OT security posture for a connected world? Contact us at [email protected] to get started.

In the digital era, cybersecurity has become a boardroom conversation, especially in sectors that rely heavily on Operational Technology (OT). From energy and utilities to manufacturing, pharmaceuticals, and transportation, OT environments underpin some of the most critical infrastructure in our modern world. Despite this, cybersecurity practices in OT often lag behind, hamstrung by outdated assumptions and persistent myths that can expose entire organizations to significant risk.

To combat this, we’re launching a new blog series titled “Myths of OT Cybersecurity”. We will unravel one common myth in each installment, an assumption that might have once held a kernel of truth but now serves as a dangerous blind spot. These blogs are not just for cybersecurity professionals, but for plant managers, operations leaders, IT staff, and executive decision-makers who all have a stake in protecting the digital and physical assets of their organization.

Why OT Cybersecurity Deserves a Myth-Busting Series

For decades, the world of OT operated in a bubble, largely untouched by the rapid evolution of digital threats that plagued traditional IT networks. Control systems, PLCs, SCADA environments, and industrial sensors were designed for availability and longevity, not for the complex threat landscapes of today.

But times have changed.

The convergence of IT and OT has introduced a host of new vulnerabilities. Remote access capabilities, cloud integrations, and the Industrial Internet of Things (IIoT) have created a sprawling attack surface. Yet, the cultural and operational gap between IT and OT has allowed misconceptions to persist. These myths lead to underfunded security programs, poorly scoped risk assessments, and an over-reliance on legacy controls.

The goal of this series is to challenge those myths head-on. By dissecting one common misconception at a time, we aim to educate, spark discussion, and ultimately help build a more secure and resilient OT landscape.

Examples of the Myths We’ll Cover

To give you a preview, here are just a few of the myths we’ll be tackling in upcoming posts:

• “Our OT network is isolated, so we’re safe.”
  Once a foundational security assumption, “air-gapping” is increasingly rare in practice. We’ll explore how network interconnectivity, vendor access, and wireless integrations have eroded this sense of safety.
• “We have an OT firewall, so we’re protected.”
  Firewalls are just one layer of a defense-in-depth strategy. We’ll discuss how relying on perimeter defenses alone is insufficient against sophisticated threats that exploit insider access and misconfigurations.
• “Cybersecurity is IT’s job, not OT’s.”
  This mindset contributes to organizational silos that weaken response strategies. We’ll unpack the importance of cross-functional collaboration and shared responsibility.
• “Our systems are proprietary, so they can’t be hacked.”
  Security through obscurity is no substitute for robust controls. Attackers are increasingly reverse-engineering industrial systems and exploiting zero-days in niche environments.
• “We’ve never had an incident, so our security must be working.”
  Absence of evidence is not evidence of absence. We’ll dive into how undetected intrusions, poor visibility, and lack of monitoring can create a false sense of security.
• “Patching OT systems is too risky and not worth it.”
  While availability is paramount, we’ll explore strategies for safe patching, compensating controls, and how unpatched systems can be exploited.
• “Compliance equals security.”
  Meeting regulatory requirements is just the beginning. We’ll differentiate between checkbox compliance and true risk-based security.

Each post will break down the myth, explore why it exists, share real-world consequences of believing it, and provide practical steps to shift the mindset and improve defenses.

Who Should Read This Series?

This series is designed for a broad audience across the OT and cybersecurity ecosystem:

• Industrial Control System (ICS) Engineers who want to better understand cybersecurity threats without diving into IT jargon.
• CISOs and Security Architects seeking better alignment between IT and OT programs.
• Plant Managers and Operations Directors who hold responsibility for uptime but are increasingly being asked about cyber risk.
• Executives and Board Members who are beginning to grasp the financial and reputational implications of a cyber-physical incident.
• IT Professionals who are expanding their responsibilities into OT environments.

Whether you’re hands-on in the field or guiding strategy in the boardroom, these blogs will offer actionable insights tailored to your vantage point.

Why Myths Persist in OT Security

It’s worth reflecting on why these myths are so persistent. In many cases, they come from:

• Legacy Thinking: OT systems are often decades old, and the original design assumptions no longer hold in a connected world.
• Fear of Disruption: Security upgrades and monitoring tools are often viewed as potential threats to uptime.
• Organizational Silos: With IT and OT teams traditionally working separately, miscommunication is rampant.
• Vendor Narratives: Some vendors still perpetuate myths to avoid scrutiny of their insecure-by-design products.
• Lack of Visibility: Many OT environments simply don’t have the logging and monitoring capabilities to understand their risk posture.

Understanding these root causes is the first step in breaking down resistance and fostering a culture of cybersecurity maturity.

What Makes This Series Different?

There is no shortage of content on OT cybersecurity today, but much of it falls into two extremes: overly technical whitepapers or high-level overviews lacking practical depth. This series aims to strike a balance.

Here’s what you can expect from each installment:

• Straight Talk: No FUD (fear, uncertainty, doubt). We aim for clarity, not scare tactics.
• Real-World Stories: Where possible, we’ll share anonymized examples of security incidents or close calls that highlight the myth in action.
• Practical Takeaways: Each post will close with specific actions or questions you can use to assess and improve your environment.
• Visual Aids: Diagrams, checklists, and simple models will help break down complex concepts.

Join the Conversation

Cybersecurity isn’t just a technical issue; it’s a human one. Breaking down OT cybersecurity myths isn’t just about technology, it’s about shifting mindsets, building trust, and driving culture change across departments.

We invite you to follow this series, challenge your own assumptions, and share your insights. If you want us to explore a myth, drop us a message at [email protected]. Let’s make this a dialogue, not a monologue.

Subscribe, bookmark, or follow and make “Myths of OT Cybersecurity” part of your monthly routine.

Because the most dangerous myth of all is thinking it can’t happen to you.

Stay safe, stay skeptical.

Compliance Isn’t Security

One of the early missteps in the IT cybersecurity space was an excessive focus on compliance rather than actual risk reduction. Too often, organizations pursued “checkbox security”, meeting the minimum requirements of a standard without truly addressing the underlying risks. This approach can lead to wasted time and money, as teams prioritize the quickest or cheapest route to compliance, even when those actions do little to improve the organization’s security posture.

A classic example (while not directly from cybersecurity) comes from the utility sector. Some utilities are required to trim trees a certain distance from power lines. On paper, this mitigates storm damage. But when trees are allowed to grow around the lines, the spirit of the requirement is missed. Technically compliant? Maybe. Effective? Not at all.

Another key issue with compliance-focused cybersecurity programs is the near impossible task of crafting perfect regulations, ones that strike just the right balance between protecting critical assets and addressing evolving threats, all while ensuring efficient use of resources. The lack of a “perfect” regulatory framework can lead to gaps where organizations meet the letter of the law without meaningfully reducing risk. 

A clear example comes from the IT world and the PCI DSS standards, developed to protect credit card information. Although well-intentioned, these standards unintentionally incentivized organizations to engineer systems to be “out of scope.” As a result, potentially vulnerable systems were excluded from security protections not because they posed no risk, but because they were no longer covered by regulatory requirements.

This same pattern has been echoed in the OT space through NERC CIP standards, which aim to secure the Bulk Electric System (BES). Some organizations have tried to downplay the criticality of their systems to avoid regulatory scrutiny. In a 2024 report, the Federal Energy Regulatory Commission (FERC) found that some entities were classifying multiple systems within a single facility as separate “Control Centers” to reduce each one’s individual risk profile under the standards, essentially gaming the system to avoid stricter obligations.

This leads to a constant cycle of rule revisions and debates over applicability. While the goal is to close loopholes, this ongoing tug-of-war drains time and energy from where it’s needed most: actually reducing cybersecurity risk. Ultimately, when compliance becomes the destination rather than a stepping stone, organizations risk losing sight of their broader responsibility, to secure critical infrastructure in a meaningful and sustainable way.

The Pitfall of Perimeter-Only Thinking 

Another misstep in the evolution of IT cybersecurity was the overreliance on perimeter defense. Firewalls, once heralded as the ultimate safeguard, became the centerpiece of many security programs. This perimeter-focused approach left end users vulnerable once those outer defenses were breached, with few (if any) controls in place to mitigate damage from within.

As organizations layered on more technology, new problems emerged. Alert fatigue, driven by the sheer volume of irrelevant or false-positive notifications, diluted response effectiveness. This in turn gave rise to the adoption of Security Information and Event Management (SIEM) tools to manage the noise. Yet even SIEMs require thoughtful configuration, tuning, and human expertise to deliver real value.

The reality is that no single tool whether it’s firewalls, antivirus software, Intrusion Detection/Prevention Systems (IDS/IPS), or even the more modern Extended Detection and Response (XDR) solutions can guarantee protection against cybersecurity threats. Every tool has limitations, and even the most advanced can be rendered ineffective if relied upon in isolation.

Ultimately, the failure isn’t in using these technologies it’s in treating them as silver bullets instead of components in a layered, risk-based security strategy.

The Danger of the Cybersecurity Silo and the “Culture of No”

A third common misstep in IT cybersecurity has been the tendency for security teams to operate in isolation disconnected from the broader business they are meant to support. This siloed approach often gives rise to what’s known as a “Culture of No,” where cybersecurity teams are seen primarily as gatekeepers, focused on denying requests and blocking initiatives rather than enabling secure innovation.

In practice, this disconnect creates friction. Employees, frustrated by rigid restrictions, find their own workarounds which introduces unmanaged, unapproved solutions that introduce even greater risk. This phenomenon, known as Shadow IT, became especially visible in the widespread use of personal tools like Dropbox or Google Drive when corporate systems failed to meet users’ evolving needs for remote access and collaboration. Rather than empowering the business, this posture undermines trust and security alike. Effective cybersecurity requires active collaboration, empathy, and an understanding that security should be a business enabler, not a business obstacle.

Collaborating for Security: Aligning OT/ICS Cybersecurity with Operational Priorities 

To advance cybersecurity in the industrial space, the OT/ICS security community must move beyond mandates and embrace collaboration. Cybersecurity cannot succeed in isolation particularly in critical infrastructure sectors where uptime, safety, and reliability are non-negotiable. When security professionals approach operations teams with prescriptive demands (especially without first establishing mutual trust) resistance is almost guaranteed. This adversarial dynamic not only erodes cooperation but ultimately undermines the organization’s ability to reduce risk.

Instead, OT/ICS cybersecurity leaders should begin by listening. Engage with operations teams to understand their pain points, workflows, and constraints. When cybersecurity solutions are aligned with operational needs, they become enablers, not obstacles. For example, maintaining an accurate asset inventory is a challenge shared by both cybersecurity and operations. Leveraging network visibility tools that can automate asset discovery helps both teams, reducing manual effort while enhancing cyber hygiene.

This kind of win-win collaboration requires more than just technology. It demands a shared vision. A successful OT/ICS cybersecurity program depends on fostering cross-functional partnerships between cybersecurity, compliance, and operations built on respect, transparency, and common goals. These relationships enable the development of programs that are not only technically sound but also operationally feasible.

Cybersecurity professionals in industrial settings must refocus their priorities: from enforcing controls to reducing real-world risks, from checking boxes to enabling resilient operations. This mindset shift will pave the way for both short-term wins and long-term program maturity.

How Enaxy Can Help

At Enaxy, we specialize in bridging the gap between cybersecurity and operations. Our team works directly with industrial organizations to build tailored OT/ICS cybersecurity programs that align with operational realities not against them. Whether it’s deploying asset discovery tools, designing risk-informed segmentation strategies, or guiding teams through NERC CIP, ISA 62443, or NIST frameworks, we meet you where you are.

We’ve helped energy, manufacturing, and infrastructure clients across North America strengthen their security posture without sacrificing uptime or straining operational teams.

Let’s turn cybersecurity into a strategic asset. Contact us at [email protected] to start a conversation. We’re ready to help you build a safer, more resilient industrial future.