What is normal?
Every detection platform in your plant learned what "normal" looks like by monitoring your network. That was the only option available to it. No one handed it a document describing which devices are supposed to talk to which other devices, in what protocol, on what schedule, because in most OT environments that document does not exist. (In fact, I am not sure I have ever seen one that is completely documented out)
So the monitoring and visibility solutions build one through observation. They watch for weeks, they form a statistical picture of ordinary behavior, and now they tell you when something departs from that picture.
This works well for the loud things. It works considerably less well for an attacker using your own tools, over your own paths, in your own protocols, which is the entire premise of living off the land.
A learned baseline can only describe what it saw
The reason living off the land is hard to catch is not that detection vendors are bad at their jobs. Nozomi, Claroty, Dragos, and Darktrace all build genuinely good products, and we partner with all of them. The reason is an information problem that sits underneath all of them.
An adversary (and/or malicious insider) using legitimate credentials, legitimate remote access, and native engineering tools produces traffic that falls inside the learned distribution, because the learned distribution was assembled from exactly that kind of traffic. There is no anomaly to surface. The behavior is not unusual.
That gap is structural. A monitoring platform can answer "is this unusual" with real precision. It cannot answer "is this permitted," because nothing ever told it what was permitted.
Enforcement changes the question, not the volume
Least-privilege segmentation is, before it is anything else, a declaration. It is a written statement of which flows are allowed to exist. That statement is the thing the learned baseline was trying to reconstruct by inference, and it does not have to be inferred if somebody writes it down.
Once it is written down, three things follow.
The first is that unauthorized flows stop completing. They are not scored, ranked, or triaged. They are denied.
The second is that the denial is recorded. In BlastShield, both failed and permitted access attempts are logged, and those logs can be exported via syslog streaming, API, local storage, or CSV, so they can land in the same platform you already use for detection. A denied attempt is not a statistical outlier requiring interpretation. It is a specific identity attempting a specific thing it was not permitted to do, with a timestamp.
The third is the one that matters most for the subtle attacks. The set of traffic allowed to exist gets smaller and, more importantly, more explicit. Your detection platform stops being the only thing in the environment that has an opinion about what should be happening.
I am not telling you your alert count drops by some specific percentage. This is architectural reasoning rather than a measured result. What I am telling you is that the character of what reaches your analysts changes, because ambiguous inferred signals are replaced by unambiguous declared ones.
What actually stops being generated
Network Cloaking stops the response, not the probe. When an unauthenticated packet arrives at a protected asset, BlastShield drops it silently. Not refused, not reset, not returned with an error. Nothing is sent back, so a scanner cannot distinguish a protected address from empty address space.
Those scan packets still cross your network, and a passive sensor on a SPAN port still sees them. What disappears is everything downstream of a reply: the open ports discovered, the service banners returned, the reachable-service inventory, the completed session. The reconnaissance still happens. It stops producing a result.
That is a narrower claim than "less noise."
The noise floor is rising, and it is not going to stop
The reason this matters more in 2026 than in 2022 is that reconnaissance is no longer expensive.
It used to require a human with time, skill, and patience, which meant attackers had to choose their targets and most plants were never chosen. Scanning is now free, continuous, and universal, so everything discoverable is enumerated constantly by something that does not get bored.
This is observable rather than theoretical. Dragos research, relayed by J.P. Morgan in its July 2026 Patchmageddon report, records that KAMACITE, the access development team feeding ELECTRUM, "conducted sustained reconnaissance of internet-exposed industrial devices across the United States between March and July 2025." That is five months of continuous enumeration against American infrastructure by one group. Worth noting the source is a vendor threat report relayed by a bank, so treat it as directional rather than as a census.
Every one of those probes that reaches a device that answers becomes something your platform has to represent, rank, and eventually explain to a person. The volume of that traffic is set by the attacker's economics, which have improved dramatically.
Detection finds it. Enforcement acts on it.
These are two different jobs, and an OT program needs both.
BlastShield has been deployed in customer networks alongside Nozomi Networks, Claroty, Dragos, and other monitoring and visibility platforms, whether or not those vendors are formal partners of ours. Their platforms find what is on your network. An export from any of them can be imported into BlastShield as the baseline for a deployment, so the assets they discovered become the assets that stop answering.
To be precise, what exists is a one-time import of that export to seed the deployment baseline, refreshed by a manual re-import when you choose. There is no live synchronization, no automatic policy generation, and no enforcement triggered by a detection event, and BlastShield performs no asset discovery of its own.
The detection platform enumerates the estate. That inventory seeds the segmentation policy. From that point, anything outside the baseline is blocked and logged when it attempts to communicate, which means the log becomes an evidence feed of precisely what the inventory missed. Each tool does the thing it is genuinely good at, and the seam between them is an artifact an assessor can inspect.
What this does and does not do for living off the land
It does not detect it. We do not make detection claims, and any vendor telling you their segmentation product catches living off the land is describing a different product than the one they sell you.
What it does is reduce the surface the technique operates on. Living off the land depends on the malicious use of a legitimate tool being indistinguishable from its authorized use. Least privilege attacks the second half of that sentence. A compromised engineering workstation that could previously access most of the plant can now access only what its operator's role requires. The technique still works. Its reach does not.
And every attempt to go beyond that boundary fails and is written down, as an identity, a destination, and a time, rather than as a deviation from a curve.
This is what we mean by "Asset-Enforced Zero Trust", and it is the phrase worth putting in your internal memo. Not because it is a new product. Because it names where the enforcement happens: at the asset, as a property of the asset, rather than in a console that has to be consulted after the fact.
Your detection platform will still have work to do. It will just be doing it against a network that finally told it what was supposed to be true.
FAQs
What is a learned baseline in OT cybersecurity?
A learned baseline is a statistical picture of normal network behavior built by observing communications over time. Detection and visibility platforms use that baseline to identify activity that appears unusual. The limitation is that the baseline reflects what the platform observed, not necessarily what the organization explicitly authorized.
Why can living-off-the-land attacks hide inside a learned baseline?
Living-off-the-land attacks use legitimate credentials, native engineering tools, approved protocols, and existing network paths. Because those same activities may already exist inside the learned baseline, malicious behavior can resemble ordinary authorized traffic and may not appear anomalous.
What is the difference between detection and enforcement in OT security?
Detection asks whether activity looks unusual or suspicious. Enforcement asks whether that activity is permitted at all. Least-privilege segmentation explicitly defines which users, devices, and systems are allowed to communicate, then blocks communications that fall outside those policies.
How does least-privilege segmentation reduce the risk of living-off-the-land attacks?
Least-privilege segmentation limits the systems a compromised user or workstation can reach. An attacker may still be able to misuse legitimate tools within an authorized segment, but attempts to move beyond the permitted boundary are blocked and logged.
Does BlastShield detect living-off-the-land attacks?
No. BlastShield is not presented as a living-off-the-land detection platform. Its role is to reduce the attack surface by enforcing least-privilege access, blocking unauthorized communication, and recording attempts to cross defined policy boundaries.
How does Network Cloaking affect reconnaissance?
Network Cloaking stops protected assets from responding to unauthenticated probes. The scan packet may still traverse the network and may still be visible to passive monitoring tools, but the protected asset does not return information such as open ports, service banners, or a completed connection.
Can BlastShield work alongside OT monitoring platforms?
Yes. BlastShield can be deployed alongside monitoring and visibility platforms such as Nozomi Networks, Claroty, Dragos, and others. An export from a monitoring platform can be imported into BlastShield to seed the deployment baseline. This is a one-time import that can be refreshed through manual re-import; it is not live synchronization or automatic policy generation.
What is Asset-Enforced Zero Trust?
Asset-Enforced Zero Trust describes an architecture in which access policy is enforced at the protected asset rather than relying only on monitoring or post-event analysis. Communication outside the defined policy is denied, while permitted and failed access attempts can be logged for review.
How To: Reduce the Reach of Living-Off-the-Land Attacks in OT
1. Inventory the OT environment
Use your existing monitoring or visibility platform to identify devices, systems, and communications across the OT environment. This inventory provides the starting point for defining what should be allowed.
2. Define permitted communication explicitly
Document which users, devices, and systems are supposed to communicate, including the destinations and access relationships required for normal operations. The goal is to replace inferred assumptions about normal behavior with declared policy.
3. Build least-privilege segmentation policies
Create segmentation policies that allow only the communications required for each role, device, or system. Avoid giving engineering workstations, remote users, or other endpoints broader access than their operational responsibilities require.
4. Import the baseline into BlastShield
Use an export from the existing monitoring or visibility platform to seed the BlastShield deployment baseline. Update it later through manual re-import when the environment changes.
5. Enforce the policy at the asset
Configure BlastShield so communications outside the defined baseline are blocked rather than simply observed or scored. This turns policy violations into denied access attempts instead of additional behavioral anomalies for analysts to interpret.
6. Use Network Cloaking to limit reconnaissance
Protect assets so unauthenticated probes receive no response. This prevents scanners from obtaining information such as reachable services, open ports, or service banners from protected systems.
7. Send enforcement logs to existing security tools
Export permitted and failed access attempts through available logging methods such as syslog streaming, API, local storage, or CSV. These records can be sent into the same monitoring or analysis platform already used by the security team.
8. Review denied attempts as evidence
Treat blocked communication attempts as evidence that a user, device, or process attempted something outside the declared policy. Use those records to identify missing inventory, overly broad access expectations, or potentially malicious activity.
9. Keep detection and enforcement working together
Continue using monitoring platforms to identify abnormal or suspicious activity while using segmentation and Asset-Enforced Zero Trust to restrict what communications are allowed to occur. Detection finds suspicious behavior; enforcement limits what that behavior can reach.
Jaguar Land Rover’s cyberattack shut production for five weeks. The lesson: limit blast radius with network cloaking, segmentation, and verified access to OT.
Explore the complete analysis of 23 OT attacks that defeated firewalls, VPNs, and air gaps.
Less than 8% of OT and ICS Companies Have Robust AI Deployment, According to new Nozomi Networks and BlastWave-Sponsored Takepoint Research
.svg)
.svg)
