The most important question in OT security is what a compromised device can reach—and what it can change once it gets there.
In “Only 13% of OT Network Segments Are Fully Isolated: Analysis,” Eduard Kovacs reports on Forescout research showing how often operational, medical, enterprise and connected devices occupy the same network segments. The finding deserves attention because shared infrastructure can create routes from a relatively ordinary compromise to a high-consequence physical process.
The original Forescout Vedere Labs research, published September 22, provides the underlying figures. A day earlier, NIST released the initial public draft of SP 800-82 Revision 4. Read together, they point toward a practical agenda: establish actual reachability, protect management functions, verify the identities and content allowed through, and test how the system behaves when protection fails. [1] [2] [3]
Study scope: Forescout Vedere Labs, September 22, 2026. These are observed environments, not a census of global OT. [2]
13% is a warning about composition
Forescout found that only 13% of segments containing an OT device contained OT devices alone. The remaining 87% included at least one other device category. Medical-device segments were even more mixed: only 6% contained exclusively Internet of Medical Things (IoMT) devices. [2]
One square represents one percentage point, not one observed segment. 87% is the complement of the reported 13%. [2]
The denominator matters. This does not mean that only 13% of all OT devices are isolated, that 87% are internet-accessible, or that every mixed segment permits lateral movement. It also does not establish that OT-only segments are secure. A dedicated segment can still have permissive firewall rules, dual-connected hosts, shared credentials or an exposed maintenance route.
Conversely, a mixed segment may include additional enforcement that restricts communication. The next step is to inspect actual routes, allowed services and administrative privileges. Category mixing is a useful way to prioritize that investigation; it is not a substitute for it.
![Dedicated segments are uncommon around specialized devices Share of segments containing the named category or device type that contained only that category or type. OT-only 13% IoMT-only 6% IP cameras only 2% All bars use a 0–100% scale. Camera exclusivity is a device-type measure; OT and IoMT are broader category measures. These have separate denominators and should not be added together. [2]](https://www.timmcallister.io/images/writing/beyond-the-ot-isolation-assumption/dedicated-segments.png)
Why the headline average hides the problem
Across all segments, Forescout reports that 62% contained a single category, 29% contained two, and 9% contained three or more. A fleet-level summary can therefore look comparatively orderly while the segments surrounding sensitive devices remain highly mixed. The same research reports an average of 54 devices across four device types per segment. A device type is more specific than the four broad IT, OT, IoT and IoMT categories. [2]
![Across the complete sample 62% 29% 9% 62% one category 29% two categories 9% three or more Denominator: all 47,700 analyzed segments. This differs from the OT-containing denominator behind 13%. [2]](https://www.timmcallister.io/images/writing/beyond-the-ot-isolation-assumption/all-segments.png)
Exposure matters because operational impact is real
A separate dataset reinforces the need to investigate these paths. In its 2026 Year in Review announcement, Dragos reports tracking 119 ransomware groups targeting industrial organizations during 2025, compared with 80 in 2024, and 3,300 affected organizations. These figures describe industrial victims and adversary activity; they are not counts of confirmed controller compromises. [5]
Source: Dragos, February 17, 2026. The group count, victim count and advisory percentage describe different populations. They are not combined with Forescout’s segment statistics. [5]
Dragos also reports that 26% of advisories in its analysis contained no vendor patch or mitigation. That supports a practical need for compensating controls and supplier coordination. It does not establish that those vulnerabilities are all exploitable at a particular site. [5]
The architectural inference is straightforward: an operator needs ways to reduce exposure while a correction is unavailable or cannot yet be safely installed. Restricted management paths, limited credentials, monitored exceptions and recovery readiness provide different forms of protection during that interval. Neither dataset quantifies how much any particular design would reduce loss.
Protect the functions that can change the process
NIST SP 800-82r4 is an initial public draft, published September 21, 2026, with comments due November 30. Revision 3 remains the final published edition. The new draft is proposed guidance, not a completed replacement or a universal compliance mandate. [3] [4]
NIST identifies broader sector coverage, alignment with CSF 2.0, stronger enterprise-risk integration, expanded asset management and monitoring, and architecture focused on management functions and zero trust among its updates. These are extensions of established OT security practices, rather than the invention of segmentation. [3]
The strongest connection to Forescout’s findings appears in Section 5.2.1. Separating enterprise IT from OT is a baseline, but the draft also distinguishes management traffic from operational traffic. Engineering, patching, configuration and privileged access can alter the process; they deserve dedicated boundaries and policies instead of broad reach across the same infrastructure that carries deterministic control traffic. [6]
The draft describes zones for management functions, a DMZ for controlled access and file transfer, an OT authentication domain distinct from enterprise directory services, separate vendor entry paths, time-bounded privileged sessions and protected monitoring. Those controls are valuable because a compromise in one function should not automatically confer access to every function that can affect production. [6]
For example, moving a controller into a separate VLAN provides limited benefit if a general-purpose workstation still has unrestricted access to its programming service. The stronger design defines which engineering system may use that service, under which identity and approval, for what maintenance task, with what logging and recovery plan.
| Draft direction | Expected security benefit | What implementation must demonstrate |
|---|---|---|
| Asset management §4.1.1.1 | Identify consequential assets and unexpected neighbors before writing rules. | Inventory linked to process roles, owners, versions and approved flows; unknowns remain visible. |
| Management separation §5.2.1–5.2.2 | Constrain routes from enterprise or maintenance compromise into process control. | Rules reflect required functions; disallowed routes are safely checked; alternate connections do not bypass controls. |
| Credential and vendor separation §5.2.1 | Reduce the usefulness of stolen enterprise credentials and persistent third-party access. | Scoped entitlements, separate entry paths, session records and monitored exceptions. |
| Content validation §5.2.1; §5.3 | Reduce risk carried through approved update and file-transfer channels. | Staging, scanning, integrity checks, quarantine and coverage of maintenance media. |
| Zero trust and resilience §5.3.1–5.4 | Make access decisions explicit while preserving safe operation under failure. | Compatible devices, acceptable latency, independent failure handling and tested recovery. |
Interpretation of the NIST draft; expected benefits are qualitative and depend on implementation. [6]
Give permitted traffic a verifiable basis for trust
Segmentation determines where communication may go. A complete design also needs to establish who is communicating, what they are authorized to do, and whether the software or instructions crossing the boundary are appropriate. The following enhancements make that connection more testable. They are recommendations in this analysis, not claims that NIST has adopted every implementation detail.
Extend asset records to include trust dependencies
For each critical system, record the deployed product and version, safety and process role, device or gateway identity, certificate renewal dependencies, trusted authorities, signing keys or trust anchors, support end dates and required external services. Link the record to an owner and an approved change procedure.
This reveals failure relationships that a network diagram alone misses. Two redundant controllers may depend on the same authority, time service or renewal process. A gateway’s identity may authenticate the gateway without establishing the identity of every legacy device behind it. Those distinctions should be explicit when deciding what a connection is allowed to do.
Make certificate enrollment interoperable and maintainable
For new or substantially upgraded equipment that uses X.509 certificates and supports the necessary transport, an interoperable Enrollment over Secure Transport (EST) profile is a practical procurement option. RFC 7030 defines certificate enrollment and reenrollment exchanges between a client and an authorized service. It can reduce vendor-specific integration work, but the protocol alone does not complete the lifecycle. [7]
The equipment must securely establish initial trust, protect its keys, request only authorized identities, schedule renewal, install and activate the certificate, and demonstrate that the intended application uses it correctly. Operators should be able to configure the enrollment endpoint and test compatible PKI services. Traffic should use approved management paths; this does not require internet access or an enrollment listener on every controller interface.
Where legacy equipment cannot support modern authentication, isolate its exposure and document what the gateway or compensating control actually verifies. A certificate establishes an identity under a trust policy. It does not prove device health, approved firmware or permission to issue every command.
Verify updates at the point of use
An approved transfer path is not sufficient evidence that a file is the correct release. Preserve authenticated release information from the supplier through staging and installation: artifact identity, target model, version, dependencies and the site’s approval. Verify origin and integrity, then separately evaluate compatibility and operational safety.
A valid digital signature does not establish that a release is free of vulnerabilities or safe for every deployment. Recovery also needs explicit engineering: a controlled return to an approved earlier version, protection against unauthorized downgrade, and a plan for a compromised signing authority. Confirmation should include the actual installed state, rather than stopping at a successful upload.
Test security failures as operational events
NIST’s draft explicitly recognizes that many OT devices cannot fully participate in zero trust, and that added latency or unavailable security components can affect operations. Apply controls at suitable points and test the resulting behavior. [6]
Representative tests should include expired credentials, loss of enrollment or validation services, incorrect time, rejected firmware, interrupted installation and restoration from backup. Define behavior separately for new remote sessions, existing communications and safety-critical local control. A single rule to “fail open” or “fail closed” cannot resolve all three.
Acceptance evidence should show the physical process state, operator visibility, access available for recovery, recovery timing and remaining uncertainty. Security enforcement that unexpectedly interrupts a safety-critical function has not met the complete requirement.
Connect supplier assurances to the installed system
Procurement should obtain evidence tied to the exact product, version, supported configuration and expected operating life. Commissioning should check those assumptions against the actual integration. Changes in firmware, maintenance provider, ownership or essential services should trigger reassessment.
When a patch or security mechanism cannot be deployed safely, document the specific threat, the compensating measure, the person accountable for residual risk, the next review trigger and the funded transition plan. A temporary exception needs a condition for ending it.
Start with one consequential process
Forescout’s recommendations emphasize visibility, separation of critical operational assets, policy-based access and monitoring for segmentation drift. A practical first cycle applies those principles to one high-consequence process and then checks the identity and maintenance dependencies around it. [2]
Map the real paths
Reconcile inventory, network configuration, passive observations and engineering knowledge. Include vendor access, wireless links, maintenance laptops and removable media. Record uncertain reachability.
Define and stage the boundaries
Document required flows and privilege. Test proposed restrictions in a representative environment, agree a maintenance window, and prepare rollback with operations and safety engineers.
Exercise identity and change
Verify the enrollment, renewal and activation lifecycle for eligible equipment. Follow one update from supplier evidence through site approval to confirmation of installed state.
Prove recovery and monitor drift
Test loss of trust services and interrupted maintenance. Retain evidence of safe behavior, then watch for new connections, expanded rules and exceptions that outlive their purpose.
Measure unnecessary reachable paths removed; critical flows with verified authorization; privileged sessions with scoped access; eligible assets with tested renewal; updates with retained provenance; and exceptions with named owners and review dates. Define denominators and distinguish observed coverage from unknown coverage.
An increasing OT-only percentage may be informative, but a stronger outcome is demonstrated containment: a compromised neighboring device cannot use an unnecessary path, legitimate maintenance remains controlled, and a failed security dependency does not produce an unacceptable physical consequence.
The 13% finding challenges the assumption that separation already protects OT. The next step is to prove the boundaries—and the identities, changes and recovery procedures that make those boundaries meaningful.
Sources and reading notes
- Eduard Kovacs, SecurityWeek, September 22, 2026. Only 13% of OT Network Segments Are Fully Isolated: Analysis. The reporting that prompted this analysis.
- Forescout Research — Vedere Labs, September 22, 2026. What 47,700 Segments Reveal About Network Segmentation. Original research page directly examined for the sample size, category composition, device-type examples and mitigation recommendations. The raw dataset and enforcement configuration were not independently audited. Observational findings are not extrapolated to all OT.
- NIST, September 21, 2026. SP 800-82 Revision 4: Initial Public Draft. Official release status, comment deadline and stated revision highlights.
- NIST. SP 800-82 Revision 3: final edition. Final-publication baseline at the date of this article.
- Dragos, February 17, 2026. 2026 OT/ICS Year in Review announcement. 2025 ransomware group and victim figures; vulnerability-advisory findings. Report and supporting resources. This vendor dataset is separate from Forescout’s and does not establish a causal relationship between mixed segments and incidents.
- NIST SP 800-82r4 initial public draft. Guide to Operational Technology Security. Architecture: §5.2.1, printed pp. 116–119, lines 4136–4215; zero trust and resilience: §§5.3–5.4, especially pp. 125–126, lines 4343–4417. Supporting material: §§3.3.2, 4.1.1.1, 4.2.1, 4.2.2 and 4.2.3.1.3. Detailed discussion checked against the September draft text; this article is not an exhaustive redline against Revision 3.
- IETF RFC 7030. Enrollment over Secure Transport, especially §§2–4. The proposed OT implementation profile goes beyond protocol support; deployments must consider applicable updates and current transport policy.
Architecture diagrams are explanatory illustrations. Proposed implementation benefits are engineering judgments, not measured reductions in risk or claims of NIST endorsement. Figures and dates reflect the sources reviewed on September 22, 2026.