# For OT security — EU CRA 2027, IEC 62443 & the buyers who must sign off

> ot.whisper.online · for OT security & compliance

## The audit, the CRA file and the tabletop all ask one question — which asset was that, and can you shut it off?

In OT the network trusts an IP and a topology, not an identity. A valid-looking command from anywhere with reachability is obeyed as if it came from the plant operator — and when it goes wrong, you cannot prove which controller or session issued the write, nor revoke it across the vendor boundary. **EU CRA** and **IEC 62443** just turned that missing identity into a signed-off, audited, market-access problem. Four buyers now have to answer for it.

**We give every asset an identity it can prove — and an off-switch it never had.** The address **is** the asset: a routable, DNSSEC-anchored **/128** derived from the key your PLC, gateway or OPC UA server already holds — `DANE-EE` pinned, attributable across rotating egress, revocable worldwide in one call. **Micro-segment at the asset, not the VLAN. Zero firmware change. Zero downtime.**

`whisper verify --trustless` — anchored at the IANA DNS root. Our own API is not in the trust path.

**By the numbers**

- **145,000+** internet-exposed ICS services across 175 countries (Censys, 2024).
- **1,693** ransomware attacks on industrial orgs in 2024 — **+87%** year over year (Dragos).
- **25%** of OT ransomware forced a full site shutdown; 75% disrupted operations (Dragos).
- **~46,000** exposed Modbus devices — the FrostyGoop attack weaponized Modbus/TCP register writes to cut heat to 600+ apartment buildings for ~2 days in sub-zero winter.
- **55%** of OT environments run 4+ remote-access tools (33% run 6+) — a sprawling, un-attributable surface (Claroty Team82).
- **11 Dec 2027** — the EU CRA CE-marking deadline puts identity and attack-surface in law; fines up to €15M / 2.5% of turnover.

---

## Four sign-offs, one gap

OT identity isn't one buyer's decision. It's four sign-offs — and they use four different words for the same missing thing. The asset owner calls it a conduit. The OEM's PSIRT calls it an essential requirement. The integrator calls it commissioning. The CISO calls it blast radius. It's the same gap: no asset can prove who it is, and nothing outside the flat network can verify it. Here is each buyer, in their own words.

### Buyer A — Plant / asset-owner OT security lead

- **Trigger:** a 62443-3-3 SL-target program, an audit, or a ransomware tabletop that keeps landing on "which asset, and can we contain it?"
- **Vocabulary:** Purdue model · zones & conduits · SL-T · passive discovery · conduit · "don't touch the PLC"
- **Lead:** *Micro-segment at the asset, not the VLAN* — an identity-keyed conduit per device, additive to the zones you already drew. Turn the passive inventory your discovery tool already built into a **verifiable, revocable identity register** (CISA CPG 2.0 + CSF ID.AM). Contain a compromise in one call. Nothing inline, nothing that touches the PLC — zero firmware change, zero downtime.

### Buyer B — ICS / device-OEM PSIRT · CRA-driven · highest urgency

- **Trigger:** the EU CRA **11 Dec 2027** CE deadline (24-hour reporting from 11 Sep 2026), and RFPs now demanding 62443-4-2 / ISASecure.
- **Vocabulary:** essential requirements · Annex I · conformity assessment · CE marking · CR 1.2 · SBOM · PSIRT
- **Lead:** Ship **CRA Annex I 2(d) identity + 2(j) attack-surface + 2(l) logging** evidence in the box. Map to **62443-4-2 CR 1.2** with a hardware-key-derived, DANE-pinned identifier your certifier verifies *externally* — no commercial CA, no bespoke trust store. Publish a MUD profile your customers can actually enforce. You still own firmware, SBOM and patching; we make the identity and egress clauses a checkbox, not a redesign.

### Buyer C — System integrator / MSSP-OT

- **Trigger:** multi-site segmentation, secure-remote-access, or a 62443-2-4 engagement across a fleet of brownfield sites.
- **Vocabulary:** 62443-2-4 · commissioning · brownfield · change window · standardisation
- **Lead:** **One provisioning call per asset** — a repeatable identity-and-conduit primitive across every brownfield site. Prove segmentation with **per-/128 attribution and egress logs**, not a per-site pile of custom firewall rules. An additive overlay: no rip-and-replace, no appliance in the path. Turn a one-off project into a recurring managed-identity service.

### Buyer D — Critical-infrastructure CISO

- **Trigger:** NIS2 board accountability, TSA security directives, the CPGs, cyber-insurance, IT/OT convergence.
- **Vocabulary:** essential/important entity · TSA SD · CPG · zero trust · blast radius · defence-in-depth
- **Lead:** **Zero-trust identity for OT**, aligned to CPG + NIS2 + TSA in one control. Attribution you can hand the regulator — who was this asset, what did it talk to, and when was it revoked. Reduce blast radius *without OT downtime*. Additive to **Dragos, Claroty and Nozomi** — it complements the SOC, it doesn't replace it.

Four buyers, one primitive: **the address is the asset.** The rest of this page is how it closes the gap all four just named — and the honest map of exactly which clauses it satisfies, and which it does not.

---

## Two gaps. Every OT program has both.

Strip the incident down and it isn't a hundred CVEs. It's two structural gaps — and a socket the asset already carries. Every stage of an OT compromise — exposure, the convergence bridge from IT, the flat network, the un-attributable session — leans on exactly two gaps. Close both and the access, lateral-movement and attribution stages have nowhere left to stand.

### Gap 1 · you can't attribute the session when the egress rotates

A malicious session arrives over a shared or rotating egress with no device identity behind it. Rate-limit an IP and it spins up a fresh one; the last IP *was never the operator*. So you block noise, and across the vendor/integrator boundary you can't even say which controller or which session issued the destructive write.

**The answer — the graph.** A live internet-infrastructure graph — billions of nodes and 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** a `JA4/JA3` client fingerprint travels with the *tooling* regardless of the exit and collapses the swarm to one operator. Every answer returns a reproducible evidence chain your OT SOC, your auditors and a regulator can replay — behavioral OT detection stops at the Purdue boundary; this doesn't.

> **"Our discovery tool sees who's on the network. Can you tell me who's *behind* a session when it rotates across clouds and residential proxies?"**
>
> Yes, that's the half your visibility stack can't reach. 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 lands in your SIEM as a reproducible, replayable evidence chain, and the **Splunk, Microsoft Sentinel and OpenCTI connectors ship today**.

### Gap 2 · the asset can't prove who it is, so reachability is trust

On a flat OT segment, anything that owns an IP inherits trust: an EWS, an HMI, a foothold that crossed the convergence bridge from IT. The PLC has no identity to check the speaker against, and the operator has no identity to verify the PLC against across an org boundary — which is exactly why a VPN or a jump-host doesn't close it.

**The answer — identity.** Give the asset a forge-proof **/128** derived from the key it *already holds*. The industry has already built the socket twice: **OPC UA** binds a globally-unique `ApplicationUri` into the application-instance certificate SAN (a session fails with `BadCertificateUriInvalid` if they don't match), and **RFC 8520 MUD** lets a device declare what it may talk to. Both are trapped in a private, per-site, non-revocable-cross-org trust store. Whisper takes the identifier the asset already carries — `ApplicationUri`, an 802.1AR IDevID, or the nameplate serial — and makes it a globally resolvable, publicly verifiable, DNS-TTL-revocable name, with **no commercial CA and no appliance in the path**.

> **"If an attacker is already on my OT segment, does a /128 stop them writing to a Modbus PLC?"**
>
> Honestly — no, not that last inch. We change *who can reach and speak to* the asset, and make every session attributable and cross-org revocable; we do **not** add authentication to Modbus, DNP3 or PROFINET on the wire. Stopping a purely-internal write once the foothold exists needs enforcement *in the command path* — at the PLC, a protocol-aware gateway, or the EWS. We neutralise the access, convergence-bridge, flat-network and attribution stages, and we tell you plainly where that line is. Complements the in-path controls; never claims to replace them.

### Diagram — micro-segment at the asset, not the VLAN

On a flat network, trust equals reachability: a compromised EWS that owns an IP reaches the PLC, the RTU and the OPC UA server alike. With Whisper, each asset carries its own routable /128 and a default-deny egress allow-list, so a *conduit* is keyed to a verifiable identity rather than a VLAN. The PLC's /128 (`2a04:2a01:0c2::a55e`) is allowed only to its historian; the OPC UA server's /128 (`2a04:2a01:0c2::71b3`) only to the engineering workstation; a compromised host that merely reaches an asset — but holds no matching identity — is denied. Additive to the zones you already drew; nothing inline.

### Diagram — the socket bind

An asset's own key, named by its OPC UA `ApplicationUri`, 802.1AR IDevID or nameplate serial (the key never leaves the asset; only the public SPKI is an input), derives a routable **/128** (`2a04:2a01:0c2::a55e`). DNSSEC and DANE-EE anchor it into a name anyone can verify with `whisper verify --trustless` — no commercial CA, and our API is never in the trust path. One `op:revoke` tears it down cross-org at DNS-TTL — the revocation an OPC UA local TrustList never had. *Complements the OPC UA handshake; never replaces it.*

---

## Three planes on one primitive — and all three exit into the stack you already run

The primitive is one line: **the address is the asset** — a routable IPv6 /128 out of `2a04:2a01::/32` (announced by **AS219419**), DNSSEC-anchored, DANE-EE pinned, verifiable by anyone with `dig`. Point it at your plant and you get three planes, no new silo.

| Plane | What it gives you |
| --- | --- |
| **Identity** | Each asset's /128 is derived from the key it already holds — the OPC UA `ApplicationUri`, an 802.1AR IDevID, a TPM, or the nameplate serial as the domain separator. Deterministic, **tenant-bound** (the same asset under two operators yields two unrelated /128s), enumeration-resistant (the identifier alone yields nothing without the key). *Who is this, provably.* |
| **Attribution graph** | The operator fingerprint across rotating clouds and residential proxies (infrastructure genealogy plus JA4/JA3) with a reproducible, replayable evidence chain on every answer. Behavioral OT detection stops at the Purdue boundary; this follows the operator across the internet. *Who's really behind this, when the egress rotates.* |
| **Egress governance** | A graph-first resolver and source-bound egress enforce **default-deny** per asset — the RFC 8520 MUD declaration, finally bound to a verifiable identity and enforced at the /128. `op:firewall`, `op:budget`, one `op:revoke`. *What may talk to what — and the off-switch.* |

**See who's enumerating your asset register — before the write lands.** An identity you can prove is also one you can *watch*. Because every asset's name resolves through Whisper's own authoritative DNS and RDAP, `op:lookups` (keyless: `GET /ip/<addr>/lookups`) returns *who* resolved or RDAP-queried an asset's identity — a reconnaissance tripwire that catches a scanner or an aggregator mapping your fleet *before* a command is ever sent, not a post-mortem after it. The private OPC UA TrustList never gave you that visibility.

**Nothing is issued in the dark.** Every identity mint and every `revoke` lands in a public, append-only **RFC 6962 Merkle transparency log**, Ed25519-signed and anchored to Bitcoin via OpenTimestamps — an auditable, non-repudiable issuance-and-revocation trail you can hand a CRA or NIS2 assessor. *Honest status:* tamper-evident, signed and Bitcoin-anchored today; it speaks the C2SP `tlog-witness` protocol so an external witness can co-sign, but it is **not yet independently witnessed** — we state that plainly rather than overclaim.

### Diagram — three planes into your stack

The three planes — Identity, Attribution graph, Egress governance — rest on one primitive (**the address is the asset**, AS219419 · `2a04:2a01::/32`) and exit into the stack you already run: your OT detection stack (Dragos, Claroty, Nozomi) as an **additive feed**, your SIEM (Splunk and Microsoft Sentinel today), and your compliance file (EU CRA Annex I, IEC 62443, CISA CPG 2.0). No new console.

---

## The honest compliance map

Every capability lands on a clause and produces an artifact — and we mark, plainly, where it only lands partway. A strong fit is ●, a partial fit is ◐, out-of-scope is ✗. We would rather you find the gaps here than in front of your assessor.

| Standard / clause | What it requires | Fit | Evidence artifact |
| --- | --- | :---: | --- |
| **EU CRA** — Annex I 2(d) | Protection from unauthorised access via authentication, *identity or access management* | ● | Verifiable, revocable per-asset /128 register; one-call `revoke` = de-provisioning |
| **EU CRA** — Annex I 2(i)+(j) | Minimise impact on other devices/networks & *limit the attack surface* | ● | MUD-style default-deny egress per asset (`op:policy` / `op:firewall`) |
| **EU CRA** — Annex I 2(l) | Record & monitor access to / modification of the product | ◐ | Per-/128 egress logs + attribution evidence chain — *network-side; host audit logs still needed* |
| **EU CRA** — Annex I Part II(1) | Provide a software bill of materials (SBOM) | ✗ | You ship your own; `revoke` is a mitigation lever, not a patch pipeline |
| **IEC 62443-4-2** — CR 1.2 | Software-process & device identification and authentication | ● id / ◐ auth | HW-key-derived, DANE-pinned, externally-verifiable identifier — *the asset still does its own handshake* |
| **IEC 62443-3-3** — SR 5.1 | Zones & conduits / restricted data flow (segmentation) | ● | Per-asset /128 + egress allow-list = identity-keyed conduits |
| **NIST SP 800-82r3** | OT device I&A, segmentation, session monitoring (overlay for identity-less assets) | ● | Overlay identity + micro-segmentation + attributable sessions |
| **NIST CSF 2.0** — ID.AM + PR.AA | Asset management + identity, authentication & access control | ● | IPv6-addressable asset register + verifiable per-asset identity |
| **NISTIR 8259A** | Device identification (a unique logical identifier) | ● | Externally-verifiable logical ID (DNSSEC/DANE /128) |
| **CISA CPG 2.0** | IP/IPv6 asset inventory + segment by trust boundary (permit only required comms) | ● | IPv6-addressable register + default-deny egress — a near-verbatim fit |
| **RFC 8520 MUD** | Device-declared intended communication, enforced default-deny | ● | MUD intent bound to a verifiable identity, enforced at the /128 |
| **NIS2** — Art. 21(2) | Access control, network security, logging (org obligation) | ◐ | Evidence for the access-control / network / logging controls — *you run the program* |
| **TSA** — Pipeline / Rail SDs | IT/OT segmentation, access control, continuous monitoring | ● seg / ◐ MFA | Per-asset segmentation + attribution feed |

### The caveats — say them before the assessor does

- **NERC CIP scope is the Bulk Electric System.** Where you operate BES cyber assets we align to CIP-005/CIP-013 vendor-remote-access controls, but we don't claim CIP for non-BES OT.
- **The CRA↔62443 harmonised-standards crosswalk is still settling.** Map to 62443 today; treat the CRA columns as the essential-requirement fit, not a finalised harmonised-standard citation.
- **Identity is not full authentication.** The asset performs its own OPC UA / TLS handshake — we make its identity globally verifiable and attributable and pin its key; we don't replace the handshake, and we add no auth to Modbus, DNP3 or PROFINET on the wire.
- **MUD at OT scale needs a control point in the path.** Brownfield rarely emits a MUD URL — our value is the verifiable identity plus an externally-managed profile that plain RFC 8520 lacks, enforced where traffic actually egresses.
- **The product is evidence, not auto-compliance.** NIS2, the TSA SDs and the CPGs are organisational obligations. We produce the artifacts your program files; we don't make you compliant on our own.

**The Splunk connector ships today** (signed JSON → CEF / ECS); Microsoft Sentinel, OpenCTI, STIX 2.1 over TAXII and a machine-readable per-sector export are on the roadmap. A first-class typed `--mud` / `--opcua` argument is also on the roadmap — today you pass the `ApplicationUri` or serial as `device_id`.

---

## Where Whisper fits — additive, availability-safe

Your OT sensor sees *that* an asset is misbehaving. Whisper proves *who* it is — and follows the operator when the egress rotates.

The OT-detection incumbents — Dragos, Claroty, Nozomi, Armis, Forescout, Tenable OT — 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, and non-revocable off-box. The OT zero-trust fabrics secure the identity *inside* their own overlay. Whisper adds the two layers no one else owns: an **internet-infrastructure attribution graph** that fingerprints the operator across rotating clouds and residential proxies, and a **publicly verifiable, DNSSEC/DANE-rooted device identity**, derived from the asset's own key with nothing new inline, revocable internet-wide at DNS-TTL.

| | OT visibility / detection | OT zero-trust fabric | Whisper |
| --- | --- | --- | --- |
| OT protocol visibility, discovery & anomaly detection | ✓ | — | additive feed |
| Per-asset identity, rooted how | inferred | private CA / overlay | DNSSEC + DANE, public |
| **Publicly verifiable by a third party** (no vendor platform in the loop) | — | — | ✓ |
| Derived from the asset's existing key, nothing new inline | — | needs mesh / broker | ✓ |
| Cross-org attribution across rotating egress | in-network only | — | ✓ |
| Revocation — reach | quarantine on-switch | in-fabric only | internet-wide, DNS-TTL |

> **"We already run an OT zero-trust fabric. Why add this?"**
>
> Because that identity lives inside your fabric — private-rooted, enforced at the fabric's own nodes. Whisper makes identity verifiable *outside* it: DNSSEC-anchored, DANE-pinned, derived from the key the asset already holds, with nothing new inline. A regulator, an insurer or a peer operator can verify an asset without ever logging into your platform — and revoke it internet-wide, not just in-fabric. Same zero-trust spirit, opposite root of trust.

- **Availability-safe by construction.** It rides existing DNS/IPv6 and adds no inline OT chokepoint. If a head-end authorizes against the DANE/verify path, that plane is built to **fail open** — a Whisper outage never bricks an asset; the check degrades to the anchors you already ship. Anycast on AS219419, no single node in the path.
- **On-prem, in your jurisdiction.** Run the graph and the per-asset logs on-prem or in your own tenant, where your regulator requires. No chatty external dependency on the resolution/verification hot path; nodes are self-contained and keep serving.
- **A minimal, published surface.** Standard ports and standard tooling — `dig`, `kdig`, `curl`. Strict on what it emits, liberal in what it accepts. The identity primitive is verifiable without trusting us: `whisper verify --trustless` anchors at the IANA root.
- **Real address space, operated as such.** Identities live in production IPv6 (`2a04:2a01::/32`, **AS219419**) that we announce and run — registry-anchored, RDAP-resolvable space, run by people who ran a regional internet registry and operated one of the DNS root servers.

---

## Prove it in 60 seconds · no account

Two tiers, by design. **No key:** anyone on your team can verify an asset's identity, see who's been enumerating it, and back-trace a suspicious controller — trustless, anchored at the IANA root. **Your key:** bind an asset to the `ApplicationUri` it already carries, govern its egress MUD-style, feed findings into your SIEM, and revoke it worldwide.

### verify, name & catch recon — no key required

```console
# keyless — re-derive and verify any asset's identity, trustless
$ whisper verify --trustless 2a04:2a01:0c2::a55e
  ✓ 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 (from its OPC UA ApplicationUri)
$ dig -x 2a04:2a01:0c2::a55e +short
  plc-04.line3.acme-plant.assets.whisper.online.

# who has been enumerating your asset register — a recon tripwire, keyless
$ curl -s https://whisper.online/ip/2a04:2a01:0c2::a55e/lookups
  14 PTR/TLSA lookups in 6 min from one operator — before any command reached the PLC

# who really operates a suspicious controller — the graph API (needs your key)
$ 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
```

### provision, govern MUD-style & revoke — with your key

```console
# bind a PLC to the OPC UA ApplicationUri it already carries in its cert SAN
$ 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:acme-plant:line3:PLC-04'}})"   # device_id = ApplicationUri (or serial)
  → identity 2a04:2a01:0c2::a55e   DNSSEC + DANE live

# MUD-style default-deny egress — the RFC 8520 declaration, enforced at the /128
$ whisper policy set --default deny \
    --allow opcua.acme-plant.internal,historian.acme-plant.internal
$ whisper logs 2a04:2a01:0c2::a55e     # the asset's own outbound — per-/128, for your CRA 2(l) file
$ whisper revoke 2a04:2a01:0c2::a55e   # cross-org, worldwide, at DNS-TTL
# STIX/TAXII → your SIEM and a 62443/ATM export are on the roadmap; the Splunk connector ships today
```

---

## Additive to your 62443 program. Mapped to your standards. Priced so you can say yes.

A verifiable, revocable /128 per asset — micro-segmented at the asset, attributable across rotating egress, mapped to EU CRA Annex I, IEC 62443, CISA CPG 2.0 and RFC 8520 MUD — for the four buyers who have to sign off. Zero firmware change, zero downtime, additive to Dragos, Claroty and Nozomi. Keyless to try, one call to provision, one more to revoke.

- **Secure your assets:** https://console.whisper.security/sign-up
- **See pricing:** /pricing
- Or run `whisper verify --trustless` right now.

---

Identity on the wire for industrial assets. AS219419 · 2a04:2a01::/32 · © viaGraph B.V. (dba Whisper Security)