In OT, a device can't prove who it is — so anyone who can reach it is obeyed.
This isn't a bug you can patch. It is the OT default: trusted, not authenticated. A controller obeys a well-formed command from anything on a network segment it trusts; the protocol underneath — Modbus, DNP3, much of OPC UA — proves nothing about the machine on the other end; the plant is flat, so a foothold that owns an IP inherits the plant's trust; and when a destructive write lands, no one can say which controller or session did it, or revoke the party that sent it across the vendor boundary. IT, OT and connected-device networks have converged, and the address of an asset carries no identity at all.
ApplicationUri or serial it already carries, that no one can forge, that the integrator, vendor and asset owner can each verify, and that you revoke worldwide in a single call. Give every asset an identity it can prove — across the org boundary no VPN ever closed.
whisper verify --trustless — anchored at the IANA DNS root. Our own API is not in the trust path.
Four structural facts. Every one of them is a missing identity.
OT wasn't breached into this state; it was built into it. The protocols were designed for isolated, physically-guarded networks, and the assets outlive the software that secures them. Strip the sector's incidents down and they rest on the same four conditions — none of which a patch can close, because none of them is a bug.
The asset outlives its own security
Controllers, RTUs and IEDs run 10–20-year operational lifecycles against 3–5 years of OS and patch support. Assets run years past end-of-life, unpatchable by design — a known-exploited CVE often simply cannot be closed by patching. Identity has to come from an overlay, not a firmware update the device will never receive.
The controller authenticates a claim, not a machine
A PLC, RTU or IED obeys a well-formed command from anything that can reach it. Modbus, DNP3-base and PROFINET carry no authentication; the wire proves nothing about who — or what — is speaking. The credential, where one exists at all, is a default password or a pre-shared key: a claim, never the identity of the machine behind it.
The network trusts topology, not identity
Flat, IP/VLAN-segmented plants authorize by position: a foothold that owns a trusted address inherits the plant's trust. 13% of mission-critical OT assets have an insecure internet connection, and 36% of exposed engineering-workstations and HMIs — the crown jewels — carry a known-exploited vulnerability (Claroty Team82).
IT, OT and IoMT have converged
The air gap is folklore. An IT ransomware or vendor-account foothold flows straight into OT because there is no independent identity boundary to stop it — and remote-access sprawl (55% of sites run 4+ tools, 33% run 6+) widens the bridge every year. Convergence without identity is just a bigger flat network.
Each fact is the same sentence in a different register: the asset has no identity it can prove, and nothing on the wire checks one. So authority collapses to reachability — and reachability is exactly what the internet, remote-access tools and IT/OT convergence hand an attacker for free.
How a flat network with no device identity gets weaponized — no zero-day required.
The 2023–25 wave dropped the barrier from nation-state (Stuxnet, Industroyer) to opportunistic commodity crews mining exposure at internet scale. Every step below leans on a missing identity, not an exploit.
The plant is already indexed
145,000+ internet-exposed ICS services sit on the open internet across 175 countries (Censys, 2024). Opportunistic actors scan for exposed VNC/HMI at internet scale (CISA AA25-343A). No entry to find — the front door is on Shodan.
No credential worth the name
Default, weak or absent passwords. In one documented class, a commodity crew compromised 75+ internet-exposed PLCs using the vendor's default password — or none at all (CISA AA23-335A). Auth, where it exists, is a bearer secret anyone can copy.
IT compromise flows into OT
Ransomware or a vendor-account foothold laterals into OT because no independent identity boundary separates them. Remote-access sprawl widens the bridge — 55% of OT run 4+ remote-access tools, 33% run 6+ (Claroty Team82).
Segmentation is already defeated
IP/VLAN boundaries trust an address, not an identity, so a foothold that owns a trusted IP is indistinguishable from the operator. The engineering workstation and HMI — reachable and exposed — are the crown jewels.
Plaintext, spoofable, replayable
Modbus, DNP3-base, PROFINET and much of OPC UA have no authentication. Of 14,220 exposed OPC UA servers, over half allow unauthenticated access and ~80% support the plaintext “None” mode (Bitsight TRACE). The command is simply obeyed.
The write lands — and no one can say who
A FrostyGoop-class attack weaponized Modbus/TCP :502 register writes to cut heating to ~600 apartment buildings for ~2 days in sub-zero temperatures. 25% of OT ransomware forces a full site shutdown — and with no device identity, the operator can't say which controller or session did it, nor revoke across the vendor boundary.
Strip it to the recurring pattern — the one every one of these incidents shares.
(a) default or no credential on an internet-reachable device; (b) an unauthenticated protocol that can't verify the authority of the speaker; (c) no device identity and no attribution — the network trusts an IP and a topology, never an identity, so it can neither prove which asset did what nor revoke the party responsible across an org boundary. Close those three and the chain has nowhere left to stand.
Invisible at the network layer by design: the destructive write looks exactly like a legitimate setpoint, from an address the segment already trusts, sent over a remote-access session whose egress is disposable. This is not hypothetical — it is the shape of the majority of 2023–25 OT incidents.
Stop trusting reachability. Prove the asset — with its own key.
Detection tells you that an asset is misbehaving, at the app layer inside your own plant — necessary, and where that picture stops. The strictly-stronger move is to change what the network trusts: not a position on a flat segment, but an identity the asset holds and demonstrates cryptographically.
Authority is a position. If a packet reaches the controller from an address the segment trusts, the command is obeyed — and the credential, where one exists, is a default password or a pre-shared key the protocol can't even bind to a machine. So a foothold that owns an IP, or a vendor session that rotates its egress, is indistinguishable from the plant operator, and the source address that might have narrowed it down is disposable.
Tomorrow · the plant authorizes an asset that proves itself. Bind authority to an identity the asset holds and can demonstrate with its own key — verifiable by anyone across the org boundary, not a position on a network. Now a request either proves it is the asset (or the party) it claims to be, or it has no authority at all — before a single detection rule runs.
Whisper has one primitive: the address is the identity. A routable IPv6 /128 out of 2a04:2a01::/32 (announced by AS219419), deterministically derived from a key, DNSSEC-anchored, DANE-EE pinned, RDAP/WHOIS-registered — re-derivable and verifiable by anyone with dig. whisper verify --trustless checks it against the IANA root; our own API is not in the trust path.
Point it at the asset. Derive each PLC's, gateway's or historian's /128 from the key it already holds — the OPC UA ApplicationInstanceCertificate, an IEEE 802.1AR IDevID, a TPM or secure element — with the OPC UA ApplicationUri or the asset serial as the domain separator. The private key never leaves the asset; the address is a one-way function of its public half and that identifier. No re-flashing a brownfield plant: you bind the identity the asset was born with.
“Owns an IP → trusted” stops working
Authority is the asset's key, not its place on the segment. A foothold that inherits a trusted address inherits nothing it can prove — every forgery is a DNSSEC/DANE inconsistency any verifier catches.
Verifiable across the org boundary
The asset owner, the integrator and the vendor each verify the same /128 from public DNS — no shared flat network, no shared private CA, no VPN or jump-host in the middle. The gap none of those ever closed.
Rotating egress becomes irrelevant
Identity is not the source IP. A remote-maintenance session that hops clouds or residential proxies changes nothing it can prove — the “last IP” was never the credential.
One revoke kills a compromised asset worldwide
At DNS-TTL speed: dig -x returns nothing; verify returns false. The cross-org revocation a local CRL or TrustList edit — invisible outside the plant — never gave you.
BadCertificateUriInvalid) — genuinely good key-derived naming, but it lives in a local per-site TrustList and its revocation is a local CRL edit no one outside the plant sees. Pass that ApplicationUri (or the asset serial) as the device_id; the /128 is bound to the asset's key and that identifier, so the ApplicationUri alone yields nothing — you cannot go ApplicationUri → /128 without the key, there is no enumerable directory, and RDAP/reverse-DNS return the registry object, never the asset's whereabouts. Because the derivation is tenant-bound, the same asset under two operators yields two unrelated /128s. Shipped today: pass your ApplicationUri or serial as device_id; a first-class typed --applicationuri argument is on the roadmap.revoke. A module swap re-keys to a new /128 and revokes the old one; a change of integrator or asset owner is one revoke and a re-register to the new party. Compromise one asset and you've compromised that asset, not the plant. And nothing is issued in the dark: every mint and every revoke lands in a public, append-only Merkle transparency log (RFC 6962, Ed25519-signed, Bitcoin-anchored via OpenTimestamps). Honest status: tamper-evident today; independent witnessing is the next step.“OPC UA already binds an ApplicationUri into every instance certificate. Why isn't that enough?”
Because it's trapped in a local, private root and can't be revoked across the org boundary. The URI-to-cert binding is enforced only against a per-site TrustList; the spec explicitly discourages commercial CAs; revocation is a local CRL edit no integrator or vendor outside the plant ever sees; and the identity isn't addressable. Whisper keeps the key-derived binding and makes it publicly verifiable, addressable, and revocable at DNS-TTL — from the same key the asset already holds.
Maps to IEC 62443-4-2 CR 1.2 (unique device identification) and 62443-3-3 zones & conduits, the EU CRA Annex I identity/attack-surface/logging clauses (CE deadline 2027), CISA CPG 2.0's IPv6 asset inventory, and NIST SP 800-82r3 — delivered as a network primitive, not a compliance binder. See the compliance map →
A device that already declares what it may talk to — made verifiable, and enforced at its own /128.
An identity you can prove is also an identity you can govern. OT already has the right idea for egress; it just never had a way to make the declaration portable, verifiable, or enforced anywhere but the nearest switch.
RFC 8520 Manufacturer Usage Description — an IETF Internet Standard — lets a device emit a URL (via DHCP option 161/112, an LLDP TLV, or the X.509 id-pe-mud-url extension that co-locates with an 802.1AR IDevID) declaring the exact hosts it should ever talk to: “my manufacturer's cloud, my controller, the local subnet — nothing else.” It is one of the sharpest ideas in OT security. Its fatal weakness: the declaration is only a suggestion, validated and enforced at the nearest hop by a local MUD manager — spoofable, site-scoped, with no portable identity behind it and no shared revocation.
Whisper fixes exactly that. Bind the declaration to the asset's globally-verifiable /128 and enforce it as egress governance at that /128. The manufacturer-declared intent becomes cryptographically pinned, externally checkable, and enforced wherever the traffic actually egresses — default-deny by construction, keyed to a verifiable identity instead of a spoofable URL. A direct implementation of RFC 8520 (NIST NCCoE SP 1800-15) and a near-verbatim fit for CISA CPG 2.0's “permit only required communications.”
# default-deny at the asset's own /128 — the MUD manifest, made enforceable
$ whisper policy set 2a04:2a01:a55::502 --default deny \
--allow historian.example-plant.internal,scada-ctrl.example-plant.internal,ota.vendor.com
✓ egress governed at /128 — 3 destinations allowed, everything else denied
# cap a runaway asset; cut a compromised one off worldwide
$ whisper budget set 2a04:2a01:a55::502 --cap 50MB/day --then revoke
# who checked this asset's identity? a recon tripwire, not a post-mortem
$ whisper lookups 2a04:2a01:a55::502
⚠ 1 source RDAP-queried 214 distinct asset identities in 9m — enumeration
→ run whisper identify on the source, or op:revoke the enumerated setWho checked this asset is a query
op:lookups returns who resolved or RDAP-queried an asset's identity — an early tripwire that someone is enumerating your plant, before the write lands, not a post-mortem after it.
Govern, cap, and kill per asset
op:policy + op:firewall enforce default-deny by host, cidr or port; op:budget caps a runaway; op:revoke cuts a compromised asset off worldwide in one call — micro-segmentation at the asset, not the VLAN.
Non-repudiable telemetry
Bind each telemetry stream and setpoint acknowledgement to the asset's forge-proof /128 so the historian, the integrator and a regulator trust the numbers came from the real asset — not a spoofed outstation.
MUD declared what an asset may talk to; the declaration was only a suggestion at the nearest switch. Whisper binds it to a globally-verifiable identity and enforces it wherever the traffic egresses — the standards-native wedge no incumbent makes.
Identity stops the next forgery. The graph names whoever already got in.
You won't re-key a brownfield plant by Monday, and there is remote-access abuse in your logs right now. So the same platform back-traces the operator behind a rotating remote-maintenance session — attribution that survives the rotation, because it fingerprints the operator and the tooling, not the ephemeral egress IP.
A live internet-infrastructure graph — 7.44B nodes and 39.3B relationships of fused BGP, DNS, WHOIS, TLS, hosting and threat intelligence, answering in under 300 ms — fingerprints the operator, not the IP. Two levers, kept honestly separate: for cloud rotation it clusters shared ASN, hosting and certificate lineage into one infrastructure genealogy; for a residential-proxy swarm — where a subscriber IP gives an infra graph nothing to grab — a JA4/JA3 client fingerprint travels with the tooling regardless of the exit and collapses the swarm to one operator.
And it's a question, not a signature. Express asset enumeration directly — “one source touching N distinct asset-identities in a window” — as read-only Cypher, and the graph returns the operator with a reproducible evidence chain your OT SOC, your auditors and a regulator can replay. That's remote-access and enumeration abuse caught by its shape across the plant, not by a pattern you had to know in advance.
# ask the graph the business-logic question directly — read-only Cypher over the public graph API
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
-H 'content-type: application/json' -d '{"query":"MATCH (src)-[t:TOUCHED]->(a:AssetIdentity)
WHERE t.window = \"15m\" WITH src, count(DISTINCT a) AS assets
WHERE assets > 50 RETURN src, assets ORDER BY assets DESC"}'
operator <fingerprinted> 1 source → 214 distinct asset identities / 15m
egress: AWS eu-central → GCP europe-w4 → Azure westeu (collapsed to 1)
ja4: same tooling across 41 residential exits → 1 operator
reproducible, replayable JSON evidence chain → your SIEM“When a vendor session rotates residential proxies and fresh cloud IPs, can you actually attribute it — or just rate-limit an IP and move on?”
Attribute it. Infrastructure genealogy collapses the cloud rotation; a JA4 client fingerprint collapses the residential swarm. The egress IP is the one thing we don't rely on — and the finding feeds your SIEM (the Splunk connector ships today; Microsoft Sentinel and STIX 2.1 / TAXII export are on the roadmap).
The verbs your analysts run (or your agent runs for them): identify(ip) (who really operates a host, even behind a CDN) · origins(prefix) + walk(node,depth) (cluster rotating IPs into one genealogy) · history / watch (a timeline and a standing sentinel over a suspect operator). Every answer is reproducible, replayable JSON: the audit trail for a cross-org remote-access finding, not a screenshot.
Identity is the cure; the graph is how you clean up what got in before it, and catch the operator who tries anyway. Detection made durable, on top of a root-cause fix.
Don't take our word for it — our API isn't in the trust path.
Two tiers, by design. No key: anyone — asset owner, integrator, vendor, regulator — can verify an asset's identity, resolve it, and back-trace a suspicious host, trustless, anchored at the IANA root. Your key: bind an asset to the ApplicationUri it carries, govern its egress, revoke it worldwide.
# keyless — re-derive and verify any asset's identity, trustless, across the org boundary
$ whisper verify --trustless 2a04:2a01:a55::502
✓ DNSSEC chain valid to the IANA root
✓ DANE-EE (TLSA) leaf matches the asset's key
✓ RDAP: registered under AS219419 · 2a04:2a01::/32
identity: VERIFIED — and our own API was never trusted
# the address is the asset — reverse DNS names it
$ dig -x 2a04:2a01:a55::502 +short
uri-3f2a4e0.line3.example-plant.ot.whisper.online.
# who really operates a suspicious remote-access host — the public graph API, a CALL whisper.identify()
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
-H 'content-type: application/json' -d '{"query":"CALL whisper.identify(\"34.90.x.x\")"}'
operator: <fingerprinted> · seen across AWS / GCP / Azure
residential swarm collapsed by JA4: same tooling, 41 exit IPs → 1 operator# bind an asset to the ApplicationUri it already carries, and govern it
$ export WHISPER_API_KEY=whisper_live_xxx
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: $WHISPER_API_KEY" --data-urlencode "q=CALL whisper.agents({op:'connect', args:{tier:'wireguard',
identity_public_key:'<base64 SPKI of the asset key>',
device_id:'urn:example-plant:opcua:line3.plc-42'}})" # device_id = the OPC UA ApplicationUri
→ identity 2a04:2a01:a55::502 DNSSEC + DANE live
$ whisper policy set --default deny --allow historian.example-plant.internal,scada-ctrl.example-plant.internal
$ whisper kill --revoke 2a04:2a01:a55::502 # worldwide, at DNS-TTLA forge-proof address is a real cure — and it is not the whole cure. Here is exactly where the line is.
We will say this before your assessor does. Identity governs who may reach and speak to an asset, attributes them, and revokes them across the org boundary. It does not reach inside the plant's insecure protocols. Read both columns.
Forge-proof asset identity — kills “trusted because it's on the segment / owns an IP.” A foothold that inherits a trusted address inherits nothing it can prove.
Publicly verifiable across the org boundary — asset owner, integrator and vendor each verify the same /128 without a shared flat network or a shared private CA. The gap no VPN or jump-host ever solved.
Attribution + cross-org revocation — name the operator behind a rotating remote-access session, and tear an asset's identity down worldwide at DNS-TTL — not a local CRL edit invisible outside the plant.
MUD-style egress governance — constrain an asset to only its declared destinations, keyed to a verifiable identity: contains C2, exfil and lateral movement, and attacks the convergence-bridge and remote-access-sprawl surfaces directly.
It does not stop a purely-internal insecure-protocol write once an attacker already has an OT-segment foothold and the controller can't verify command authority. Closing that requires identity enforced in the command path — at the PLC, a protocol-aware broker-gateway, or the engineering workstation — or the FrostyGoop-class local Modbus write still lands.
It does not add authentication to Modbus, DNP3 or PROFINET on the wire. Whisper changes who may reach and speak to the asset, not what the asset accepts once reached. The protocol's plaintext, spoofable, replayable nature is unchanged.
It does not fix the unpatchable CVE, produce the asset's SBOM, patch its firmware, or cover human identity/MFA (IEC 62443 CR 1.1) or host-level audit logging. Those stay with your existing stack.
And it is additive, never a replacement — the asset still performs its own OPC UA / TLS handshake; Whisper makes that identity globally verifiable, attributable and revocable. It does not remove a stolen-but-legitimate enrolled identity, a supply-chain implant, or a physical/insider console, and a legitimate operator can still send a catastrophic setpoint.
Net: Whisper converts OT from “anyone with reachability is trusted” to “only cryptographically-identified, egress-governed, attributable, cross-org-revocable parties are trusted” — neutralizing the access, convergence-bridge, flat-network, remote-access and attribution stages that carry the majority of 2023–25 incidents. Candid about the last inch: the insecure-protocol write must be enforced in-path. We complement that layer; we never claim to be it.
Your OT sensor sees what is on the network. Whisper proves who an asset is — verifiable by anyone, revocable everywhere.
The OT-detection incumbents — Dragos, Claroty, Nozomi, Armis, Forescout — are excellent at what's on your network and whether it's behaving, and that's necessary. But their device identity is observational — inferred from behavior, scoped to the monitored network, non-verifiable off-box. The OT zero-trust/identity platforms give assets a real identity, but it is private-rooted and overlay-scoped: it lives in their fabric, is enforced at their nodes, and needs the mesh in the path. Whisper adds the two layers no one else owns: a publicly verifiable, key-derived asset identity — addressable and revocable at DNS-TTL from the asset's own key with no new appliance inline — and an internet-scale attribution graph that names the operator across rotating clouds and residential proxies. Exactly the gaps OT exposure exploits.
| OT detection | OT zero-trust identity | Whisper | |
|---|---|---|---|
| OT visibility & anomaly detection | ✓ | — | additive feed |
| Publicly verifiable identity (DNS/DANE, no vendor platform in loop) | — | — | ✓ |
| Derived from the asset's own key, no new agent/appliance inline | — | — | ✓ |
| Cross-org revocation at DNS-TTL | — | in-fabric only | ✓ |
| Operator attribution across rotating egress | — | — | ✓ |
It's depth on top of the stack you already run — it consumes your passive inventory and turns it into cryptographic identity, and it lands as a machine-readable feed into your SIEM: the Splunk, Microsoft Sentinel and OpenCTI connectors ship today, with STIX 2.1 / TAXII on the roadmap. It doesn't replace your OT-detection stack, and it doesn't add a console your analysts babysit.
Give every asset an identity it can prove.
The address is the asset — routable, DNSSEC-anchored, bound to the ApplicationUri it already carries, verifiable across the vendor boundary, revocable worldwide in one call. Keyless to try, one call to provision, one more to revoke. The OT exposure that no rate-limit ever caught simply runs out of forgeries.
Or run whisper verify --trustless right now.