Critical infrastructure cybersecurity: the gap between compliance and what attackers see
Julian ThorneApril 29, 2026
Key takeaways
In Vulnox assessments of critical infrastructure environments, 28% of OT assets were directly internet-exposed despite network diagrams showing them as isolated behind segmentation controls. The diagram is not the control.
Default credentials on HMIs and engineering workstations are the most consistently found critical finding across OT assessments — present in environments that have passed compliance audits, deferred because credential rotation on OT devices requires operational coordination that never gets scheduled.
IT vulnerability scanners cannot safely run against OT assets. Active scanning crashes PLCs and RTUs that cannot handle unexpected traffic. This means standard vulnerability programs produce incomplete inventories for exactly the assets attackers prioritize.
The IT-OT convergence attack path is consistently underestimated: lateral movement from a compromised IT endpoint to SCADA systems is possible in the majority of critical infrastructure environments that document segmentation as a control but have not tested whether it is enforced.
CISA cybersecurity directives require evidence of operational implementation, not policy documentation. Network segmentation plans, access control measures with default credential removal, and continuous monitoring for OT environments are required outcomes, not framework alignment checkboxes.
Vendor remote access paths are the least-monitored entry points in critical infrastructure environments. Credentials not rotated in years, access scopes broader than the vendor's maintenance requirements, and accounts that survive contract termination are consistent findings across assessments.
TL;DR
Critical infrastructure cybersecurity fails in the space between what compliance audits check and what attackers can reach. Auditors verify that controls are documented. Attackers verify that controls are enforced. The distance between those two checks is where internet-exposed HMIs, default OT credentials, and unvalidated IT-OT segmentation boundaries live. This article covers what assessments of critical infrastructure environments actually find, where standard security programs cannot see, and what the gap between IT and OT security looks like from the network.
Compliant firewall. Tap mode. Blocking nothing.
A client in the energy sector had spent six figures on their Palo Alto perimeter firewall. The compliance audit reviewed the management interface, confirmed the device was licensed and operational, checked the policy documentation, and marked the control as satisfied. The firewall was deployed in tap mode. It was logging traffic and generating alerts. It was not blocking a single packet. The configuration decision had been made during a maintenance window to avoid disrupting operations, was documented as temporary, and had never been revisited. The compliance audit did not test whether the firewall blocked traffic. It tested whether the firewall existed.
This is not an isolated finding. In critical infrastructure environments, the operational risk of disrupting production systems during security control validation creates a systematic pattern: controls are deployed, verified as present, and never tested under realistic conditions. The compliance program verifies presence. The attack surface is determined by function. Those are different questions, and in critical infrastructure, the gap between them has real physical consequences.
Why standard security programs cannot see most of the OT attack surface
Critical infrastructure environments run two fundamentally different technology stacks under the same compliance framework. The IT network runs standard enterprise infrastructure: Windows servers, Linux hosts, network equipment with known vulnerability surfaces and asset lifecycles measured in three-to-five years. Standard security tools — vulnerability scanners, EDR platforms, SIEM systems — were designed for this environment. They work correctly here.
The OT network runs industrial control systems: PLCs, RTUs, HMIs, historians, engineering workstations. These systems run proprietary operating systems, industrial protocols (Modbus, DNP3, IEC 61850, PROFINET), and hardware with operational lifespans of 15 to 25 years. They were designed for availability and deterministic operation, not for security patching or unexpected network traffic. Active vulnerability scanning sends traffic patterns these devices were never designed to handle. The result is either device crashes or undefined behavior that can affect physical processes.
The practical consequence is that security teams face a choice: run standard scanning against OT assets and risk crashing production systems, or exclude OT assets from scanning and have an incomplete vulnerability inventory for the most operationally critical and physically consequential systems in the environment. Most organizations choose exclusion. Attackers do not face the same constraint.
Example
In 2021, a water treatment plant in Oldsmar, Florida had an attacker gain remote access to the SCADA system and increase sodium hydroxide levels to 111 times the normal concentration. An operator caught the change manually. The access path was remote desktop software that had been installed for legitimate maintenance and was never removed. Standard vulnerability scanning would not have identified this as a critical finding because the remote desktop tool was not a known CVE. A network exposure assessment that mapped what was reachable from the internet would have found it immediately.
Passive monitoring is the correct technical approach for OT asset discovery and vulnerability assessment. Passive network traffic analysis captures device communications, identifies protocols, infers device types and firmware versions, and detects anomalous traffic without sending a single packet to OT devices. Tools purpose-built for industrial environments — Claroty, Dragos, Nozomi Networks — use this approach. The gap in most compliance programs is that passive monitoring infrastructure requires deployment inside the OT network, which requires coordination with operations and OT vendors that IT security teams cannot accomplish unilaterally.
What critical infrastructure assessments find
Assessment base: Vulnox assessment data, 2024-2025, across critical infrastructure assessments in energy, water, and transportation verticals.
Internet-exposed OT assets in environments with documented segmentation controls
In Vulnox assessments of critical infrastructure environments, 28% of OT assets that were documented as segmented from internet exposure were directly reachable from external networks. The consistent cause is asset inventory incompleteness: segmentation controls were implemented for the assets that were in the inventory at the time of implementation. Assets added later, assets migrated to new network segments, and assets with dual network interfaces (common on engineering workstations that bridge IT and OT networks) were not covered by the same controls. The segmentation documentation was accurate for the assets it was designed to cover. It did not cover all assets.
External attack surface assessment of critical infrastructure environments consistently reveals OT exposure that the internal team does not know exists. The client's belief going in is that the network diagram accurately represents the exposure. The network diagram represents the intended architecture. The actual exposure is determined by what is reachable, not what was designed.
Default credentials on HMIs and OT devices in operational environments
Default credentials on OT devices are the single most consistent critical finding across critical infrastructure assessments. The pattern is identical across every engagement where we find it: credentials were noted as a finding in a previous assessment, the remediation was deferred because credential rotation requires a maintenance window and vendor coordination, the deferral was documented as an accepted risk, and the credentials are still present two years later. The accepted risk documentation satisfies the compliance requirement to acknowledge the finding. It does not change the exposure.
Default credentials on internet-exposed OT devices are not a sophisticated finding. They require no exploitation technique. Any threat actor with Shodan access and a list of default credential pairs can attempt authentication. The finding survives because the remediation friction in OT environments is genuinely high. That friction is the gap that compliance programs document and attackers exploit.
Lateral movement paths from IT to OT networks that tested segmentation does not block
In environments with documented IT-OT network segmentation, we test specific traffic paths to determine whether the segmentation is enforced as documented. The most common finding: traffic from IT network workstations can reach OT historian servers and engineering workstations through paths that the firewall rules do not explicitly deny. The paths exist because historians need to share data with IT business intelligence systems, and the firewall rules that permit this traffic are broader than required — permitting access to more OT destinations than the historian integration requires. The rule was written for operational convenience. The lateral movement path follows the same rule.
The Colonial Pipeline attack moved from an IT network compromise to OT systems through exactly this pattern: legitimate connectivity required for business operations, implemented with broader access than the specific use case required, never reviewed after initial deployment. Testing segmentation means sending traffic from an IT network host to OT destinations and confirming it is blocked. Documentation review does not confirm this.
Where critical infrastructure security programs cannot see
Vendor remote access paths established before current security policies
Critical infrastructure organizations maintain remote access paths for OT vendors to perform maintenance, diagnostics, and software updates on industrial equipment. These paths were provisioned when the vendor relationship started, sometimes years or decades ago, under security policies that predate current standards. In assessments, we consistently find: vendor VPN credentials that have not been rotated since provisioning, access paths that permit broader network access than the vendor's specific maintenance scope requires, vendor accounts that remain active after contract termination, and no logging or monitoring of vendor session activity that would detect misuse. The SolarWinds compromise and the subsequent Oldsmar water treatment attack both moved through trusted third-party access paths. The access was legitimate. The use was not.
Engineering workstations that bridge IT and OT networks
Engineering workstations are a consistent segmentation bypass in critical infrastructure environments. They are used by engineers who need access to both IT resources (email, documentation, vendor portals) and OT systems (PLCs, HMIs, historian servers). The operational requirement creates a device that is logically on both networks. If the workstation's IT-facing interface is compromised — through phishing, credential theft, or a vulnerable remote access tool — the attacker has a pivot point into the OT environment that the segmentation boundary does not block, because the workstation is a permitted crossing point. Most threat models for critical infrastructure treat the IT-OT boundary as a perimeter. The engineering workstation is a gate in that perimeter that is always open.
Firmware versions and patch status on OT devices with long operational lifespans
OT devices operate for 15 to 25 years. A PLC installed in 2010 is running firmware from 2010 or from the most recent patch the vendor released before support ended. Vendor support lifecycles for OT firmware are shorter than device operational lifespans by design — vendors want customers to buy new hardware. The result is that operational OT environments routinely run firmware versions with known CVEs for which no patch exists or for which applying the patch requires taking the device offline for extended maintenance windows that operations cannot accommodate. Standard vulnerability management approaches — identify, patch, verify — do not map to this reality. The exposure is permanent and the remediation is architectural replacement, not patching.
What compliance verification versus exposure validation actually checks
Compliance-based audit
Reviews documentation, policy existence, and control implementation records. Verifies that required controls are present and documented. Does not test whether controls function under operational conditions. Does not scan OT assets for fear of operational disruption. Does not test lateral movement paths. Produces a compliance status that reflects documentation quality.
A passing compliance audit in a critical infrastructure environment tells you that your documentation is complete and your controls exist. It does not tell you what an attacker who scans your external attack surface can reach, whether your IT-OT segmentation blocks lateral movement, or whether your OT devices are running default credentials. These are the findings that determine breach likelihood.
External attack surface assessment
Maps what is reachable from outside the network perimeter without prior knowledge of the internal architecture. Identifies internet-exposed OT assets, open management interfaces, and remote access services that are visible to attackers. Does not require internal access and does not rely on documentation. Produces findings based on what the network actually presents, not what it is documented to present.
The most consistent finding in critical infrastructure external assessments is that the external exposure does not match the internal documentation. Assets that are documented as not internet-facing are reachable. Services that are documented as requiring authentication present unauthenticated interfaces. The assessment finds what attackers find, which is different from what auditors find.
Passive OT network monitoring
Captures OT device communications, identifies protocols and device types, detects anomalous traffic, and builds an asset inventory from observed network behavior rather than documentation. Does not send traffic to OT devices. Requires deployment inside the OT network. Produces an accurate asset inventory and behavioral baseline that compliance documentation cannot replicate.
The only approach that provides accurate asset inventory and anomaly detection for OT environments without operational risk. Requires operational coordination and vendor involvement that makes it harder to deploy than IT-focused tools. The deployment barrier is why most critical infrastructure organizations do not have it, which is why most critical infrastructure vulnerability programs have systematic blind spots in their OT coverage.
Where critical infrastructure threats are heading
By 2027, at least one significant critical infrastructure incident in a NATO member state will be traced to a compromised vendor remote access path that had not been reviewed or rotated since initial provisioning, affecting a sector where that vendor maintains access to multiple operator environments simultaneously.
The concentration of OT vendor relationships — a small number of vendors maintaining remote access to large numbers of critical infrastructure operators — creates a high-value supply chain target that mirrors the SolarWinds pattern in industrial context. Vendor remote access paths in OT environments have weaker credential hygiene and less monitoring than IT vendor access, the access permissions are broader relative to actual maintenance requirements, and the impact of a single compromised vendor credential spans multiple operators. The structural conditions for this incident are present now. The only question is timing.
Confidence: highIncident disclosure data from critical infrastructure operators in 2026-2027 showing initial access vector as vendor remote access credential compromise affecting multiple operators through a shared vendor relationship.AI-assisted process anomaly detection will be deployed in critical infrastructure OT environments faster than the training data quality required to make it reliable, producing a wave of false negative security events by 2027 where AI-detected 'normal' behavior includes attacker activity that falls within the variance of operational baselines.
OT behavioral baselines are narrow by design — industrial processes are supposed to be deterministic. AI anomaly detection trained on historical OT data will classify attacker behavior that resembles low-variance operational patterns as normal. The Oldsmar attack involved changes to chemical feed rates that, at the speed they were introduced, would have fallen within normal operational variance if the operator had not been watching the screen in real time. AI systems trained to detect anomalies will be tuned to reduce false positives on legitimate operational variation, which will systematically increase false negatives on attacker activity that mimics that variation.
Confidence: mediumSecurity research or incident disclosures demonstrating successful attacker activity in AI-monitored OT environments where the monitoring system classified the activity as within normal operational parameters, published before end of 2027.
The compliance framework for critical infrastructure was written for IT environments
NIST 800-82 and most critical infrastructure security frameworks address OT environments by adding OT-specific appendices to IT security frameworks. The core structure — asset inventory, vulnerability management, access control, incident response — was designed for environments where assets are patchable, scanning is safe, and the primary consequence of a security failure is data loss. Critical infrastructure OT environments have none of those properties. Assets are not patchable on compliance timelines. Scanning is operationally risky. The primary consequence of security failure is physical process disruption, equipment damage, or public safety impact. Applying a framework designed for data confidentiality to systems where the risk is sodium hydroxide in the water supply is a category error. The frameworks are useful as baselines. They are not sufficient as the primary security posture for environments where the failure consequences are physical.
Counterargument
The counterargument is that imperfect frameworks applied consistently are better than no framework, and that sector-specific frameworks for every OT environment type would fragment the compliance landscape to the point where cross-sector coordination and government oversight become impossible. That is a fair operational argument. The problem is that organizations treat framework compliance as a security outcome rather than a baseline. 'We passed NIST 800-82' is treated as equivalent to 'we are secure.' It is not. The framework describes controls that are necessary but not sufficient for the threat environment critical infrastructure actually operates in.
One thing to do this week
Run a passive external scan of your organization's internet-facing infrastructure — specifically looking for any OT protocols (Modbus, DNP3, BACnet, IEC 60870) reachable from outside your network perimeter. Shodan indexes this data and your attackers are already querying it. If you find any results, you have internet-exposed OT assets that your documentation says should not exist. That finding takes precedence over everything else in your security program until it is resolved. If you find nothing, you have confirmed one of the highest-impact exposures in critical infrastructure environments is not present in your case. Either outcome is worth knowing before an attacker finds it first.
Further Reading
Gap Analysis
framework gap analysisVulnerability Assessment
vulnerability assessment servicesCISA Known Exploited Vulnerabilities
CISA known exploited vulnerabilities catalogNIST SP 800-30 Risk Assessment Guide
NIST risk assessment guideOWASP Penetration Testing Guide
OWASP penetration testing guide
Frequently Asked Questions
What do attackers target first in critical infrastructure environments that compliance audits miss?
Internet-exposed OT assets that documentation says are segmented from IT networks. In Vulnox assessments, 28% of critical infrastructure OT assets were directly reachable from the internet despite network diagrams showing them as isolated. The segmentation existed as a policy and a firewall rule. It did not exist as an enforced boundary for every asset. Attackers do not read your network diagram. They scan for exposed HMIs, engineering workstations, and historian servers — and they find them in environments that have passed compliance audits.
How does IT and OT network convergence create security gaps that standard assessments miss?
IT security tools — vulnerability scanners, EDR platforms, SIEM systems — are designed for Windows and Linux environments with known asset lifecycles. OT environments run protocols like Modbus, DNP3, and IEC 61850 on hardware with 15-to-25 year operational lifespans. Active vulnerability scanning can crash PLCs and RTUs that cannot handle unexpected traffic. This means standard IT scanning is either not run against OT assets (leaving them invisible to your security program) or run in a configuration that produces unreliable results. Either way, your vulnerability inventory is incomplete for the assets attackers most want to reach.
What is the most common critical infrastructure security failure Vulnox finds in assessments?
Default credentials on HMIs and engineering workstations that have been in production for years. The credentials were set at deployment, were never changed, are documented as a known issue in previous assessments, and are still present at the time of our engagement. The consistent explanation is that changing credentials on OT devices requires a maintenance window, coordination with operations, and sometimes a vendor, and that combination of friction means it keeps being deferred. Default credentials on internet-exposed OT devices are not a sophisticated attack surface. They are an open door.
How should network segmentation between IT and OT environments actually be validated?
Documentation review is not validation. Validation requires testing specific traffic paths: can a workstation in the IT network reach the OT historian? Can a compromised IT endpoint send commands to a PLC? Can lateral movement from a phishing compromise in the corporate network reach the SCADA environment? These tests require coordination with operations to avoid triggering safety systems, but they are the only way to confirm that the segmentation in your architecture diagram matches the enforcement reality of your firewall rules and network ACLs. The Colonial Pipeline attack moved from an IT network to OT systems that were documented as segmented.
What do CISA cybersecurity directives actually require for critical infrastructure operators that standard compliance frameworks do not?
CISA's Cross-Sector Cybersecurity Performance Goals and sector-specific directives (particularly TSA directives for pipeline and aviation) require specific operational measures that go beyond NIST framework alignment: network segmentation plans with implementation timelines and validation evidence, access control measures specifically for OT systems including removal of default credentials, continuous monitoring capabilities for both IT and OT environments, and incident reporting within specific timeframes. The key difference from standard frameworks is that CISA directives specify required outcomes and require evidence of operational implementation, not just policy documentation. Compliance requires demonstrating that the controls function under operational conditions.
What does a realistic incident response exercise look like for critical infrastructure and why do tabletop exercises fail?
Tabletop exercises fail because they are run in conference rooms against scenarios that participants know in advance, with all the right people available and no actual system constraints. Real incidents happen during shift changes, on weekends, with the primary incident responder unavailable, against systems whose documentation is outdated, and with pressure from operations leadership to restore service before containment is complete. A useful exercise runs against a realistic scenario without advance notice, involves the people who are actually on shift, requires participants to work with the actual documentation that exists rather than ideal documentation, and tests the restoration process against real backup and recovery timelines. The test of an IR plan is whether it works when the people who wrote it are not in the room.
How do third-party vendor access paths create critical infrastructure attack surface that organizations cannot see?
Vendor remote access paths are consistently the least-monitored entry points in critical infrastructure environments. Vendors need access for maintenance, diagnostics, and software updates on OT systems. That access is typically provided through a VPN or jump host that was provisioned when the vendor relationship started and is rarely reviewed thereafter. In assessments, we find vendor access credentials that have not been rotated in three years, access paths that permit broader network access than the vendor's specific maintenance scope requires, and vendor accounts that remain active for vendors whose contracts ended. The SolarWinds compromise moved through exactly these trusted vendor access paths.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.