OT compliance: map identity, egress and attribution to your evidence

EU CRA, IEC 62443-4-2 and -3-3, NIST SP 800-82r3, CISA CPG 2.0, RFC 8520 MUD, NIS2 and the TSA Security Directives all press an OT program on the same three points. Which asset is this, what is it allowed to talk to and what did it reach, and can you prove it and cut it off across an org boundary?

A flat network that trusts an IP and a topology cannot answer any of them. A routable, DANE-provable, one-call-revocable IPv6 /128 per asset can. It produces the identity, the egress record and the kill-switch these frameworks ask for as evidence, not as a paragraph in an audit binder. This page is the honest crosswalk: where the shipped primitive is direct evidence, where it is only partial, and where it is out of scope and we say so before your assessor does.

What every framework is really asking

Read the OT frameworks side by side: a European market-access regulation, an ISA/IEC engineering standard, a NIST guide, a CISA goal set, an IETF RFC, a directive from a transport regulator. The same three questions surface in seven vocabularies:

• Identification & authentication: which asset or process is on the other end of this conduit, and can a peer operator, an integrator or a regulator verify it without being admitted to your local, per-site TrustList?
• Segmentation & monitoring: what is this asset permitted to communicate with, what did it actually reach, and can you show a continuous, per-asset record of it?
• Response: when one asset turns hostile, can you contain it, provably, fast, and across the vendor/integrator boundary?

None of these is a logging problem you close with more log lines. They are identity problems: you cannot attribute, segment or contain an asset that has no stable, provable identity in the first place. Whisper's job is to give every asset on the IP / DNS / transport boundary exactly that identity, then let the standard OT toolchain read the evidence off it. It does not reach into the Modbus, DNP3 or PROFINET wire and adds no authentication to those protocols. It changes who may reach and speak to an asset, and records what each asset did.

The evidence: real, and shipped

Everything this page maps to a framework is a surface that exists and answers today. Five shipped primitives do the work; each is checkable with dig, curl, or one control-plane call over the public API.

• A device-derived /128 identity: derived deterministically from the asset's public key (its SubjectPublicKeyInfo, the public half of an OPC UA application-instance certificate, an 802.1AR IDevID, a TPM or secure element) with the OPC UA ApplicationUri (or a bare asset serial) as the domain separator. The address is DNSSEC-anchored, DANE-EE 3 1 1 pinned and RDAP-registered. Property-level: deterministic (same key + id → same /128), tenant-bound (fleet-unlinkable across the vendor/integrator boundary), the id alone yields nothing without the key, the private key never leaves the device, and it is revocable worldwide at DNS-TTL.
• Default-deny egress governance: op:policy / op:firewall / op:budget, bound to the asset's /128, an allow-list at asset granularity, enforced where traffic actually leaves.
• Per-/128 logs + lookups: op:logs is the asset's own outbound trail. op:lookups is the reverse view, who resolved or RDAP-queried the asset's identity, a reconnaissance tripwire.
• One-call revoke: op:revoke tears down the /128, its PTR and its DANE pin worldwide at DNS-TTL speed, provably.
• The attribution graph + the transparency log: the read-only graph verbs return a signed, replayable JSON evidence chain; every mint and revoke lands in a public, append-only Merkle log (honest status below).

Provisioning is one control-plane call: POST https://graph.whisper.security/api/query with your X-API-Key. Hand it the device's base64 SPKI and the ApplicationUri; it returns the deterministic /128:

curl -sS https://graph.whisper.security/api/query \
  -H 'X-API-Key: whisper_live_xxx' \
  -H 'content-type: application/json' \
  --data @- <<'JSON'
{"query":"CALL whisper.agents({op:'connect', args:{tier:'wireguard', identity_public_key:'<base64 SPKI>', device_id:'urn:example-plant:line2:PLC7:server'}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error"}
JSON
# -> the deterministic /128 + a WireGuard config. Same key + ApplicationUri -> same /128 (idempotent).
#    A different device_id for a key already on your tenant -> 409; a non-string device_id -> 400.

The compliance map, at a glance

Each row is a framework clause, what it asks, the shipped evidence that answers it, and an honest fit grade. The deep sections below unpack each one.

Fit legend: ● strong: the shipped primitive is direct evidence · ◐ partial: real evidence, but the clause needs more than we supply · ○ stretch: we contribute context, not the control · ✗ not applicable: out of scope, stated plainly.

EU CRA: the deadline that turns hygiene into law

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is the urgency wedge. It converts OT security hygiene into binding CE-marking, market-access law for every product with digital elements: PLCs, RTUs, gateways, sensors and the software that runs on them. It entered into force on 10 December 2024; the vulnerability- and incident-reporting obligations (Article 14, with a 24-hour early-warning) apply from 11 September 2026; the main obligations and conformity assessment (the CE mark) apply from 11 December 2027; and non-compliance carries fines up to €15 million or 2.5% of worldwide annual turnover. For a device OEM's PSIRT this is the hardest deadline on the roadmap, and three of the essential requirements it sets are exactly the ones a network identity layer evidences.

The mapping into Annex I, Part I (2), the essential cybersecurity requirements relating to a product's properties:

• (2)(d): identity & access management (● strong). The requirement calls out "authentication, identity or access management systems" by name and asks that the product report on possible unauthorised access. A device-derived /128 is a verifiable, revocable per-asset identity; revoke is de-provisioning across the org boundary; and lookups turns "report on unauthorised access" into a real signal. You see an unknown party enumerating an asset's PTR/RDAP before the write, not in the post-mortem. This is the strongest hook the CRA gives us.
• (2)(i) + (2)(j): minimise impact & limit attack surface (● strong). Default-deny egress governance, bound to the /128, is a near-verbatim fit: it limits what a device may reach and reduces an incident's impact on other devices and networks. It is a MUD-style allow-list, but enforced at asset granularity and keyed to a cryptographic identity rather than a spoofable URL.
• (2)(l): record & monitor (◐ partial). Per-/128 egress logs and lookups are a continuous network-side record of access and communication. Honest boundary: this is network evidence, not host audit. Modification of on-device data, services or functions still needs the asset's own logging into your SIEM. We supply one half cleanly and say so.
• (2)(f): integrity (◐ partial). DNSSEC and DANE protect the integrity of the identity and the channel setup: a verifier catches any tampered /128, PTR or TLSA. They do not protect the OT payload on the wire; that stays with the asset's own transport security.
• Part II (1): SBOM (✗ not applicable). The software bill of materials is the OEM's to produce for its own product. Whisper generates no SBOM and makes no claim to; revoke is a mitigation lever, not a patch pipeline. We flag this plainly so no one plans a conformity file around a gap we don't fill.

The OEM message is narrow and honest: the CRA hands you a 2027 hard deadline on unique device identity (2(d)), attack-surface (2(i)/(j)) and security logging (2(l)); Whisper is the drop-in identity, egress and attribution layer that evidences those on day one, without touching your firmware, your SBOM or your patching, which remain yours.

IEC 62443: the OT lingua franca

Where the CRA is the law, IEC 62443 is the engineering standard an OT program is actually audited against, and the one the CRA's harmonised standards are most likely to lean on. Three parts matter here.

62443-4-2, CR 1.2: device identification & authentication (● identity / ◐ auth). CR 1.2 requires a component to uniquely identify and authenticate itself to any other component, with a unique-identifier enhancement at SL2 and hardware/PKI-backed identity at SL3 through SL4. The requirement is technology-neutral and organisation-scoped: silent on the identifier scheme and on cross-org, public verifiability. A globally-unique /128, DANE-pinning the asset's existing certificate key, satisfies the identity half with an identifier that also holds across conduits, the cross-zone, cross-vendor, remote-maintenance channels where a private TrustList can't be checked.

Be candid about the other half: the mutual-authentication handshake is still performed by the asset, its OPC UA application-instance certificate, its TLS stack. Whisper makes that identity globally verifiable and attributable; it does not replace the handshake, and it is not end-to-end CR 1.2 authentication. The precise claim is verifiable identity plus key-pinning, additive to the asset's own authentication.

# CR 1.2, the verifiable-identity half: keyless, no account, no shared CA
whisper verify --trustless opcua-plc7.asset.<tenant>.agents.whisper.online
✓ DNSSEC chain valid to the IANA root
✓ DANE-EE (TLSA 3 1 1) leaf matches the asset's OPC UA cert key
✓ RDAP: registered under AS219419 · 2a04:2a01::/32
identity: VERIFIED (our own API was never trusted)

62443-4-2, CR 1.1: human user I&A (✗ not applicable). Human identification and authentication is out of scope. Whisper identifies assets and processes, not people; CR 1.1 stays with your IAM.

62443-3-3, SR 5.1: zones & conduits (● strong). SR 5.1 (Restricted Data Flow) mandates network segmentation and defined conduits between zones. A /128-per-asset plus a default-deny egress allow-list is a conduit, but at asset granularity, keyed to a verifiable identity rather than a VLAN tag a foothold inherits. It complements your zone model; it does not replace your firewalls.

# A conduit at asset granularity: this PLC may reach ONLY its historian, controller and vendor OTA
CALL whisper.agents({op:'firewall', args:{agent:'2a04:2a01:7a2::4840',
  deny:['0.0.0.0/0'], allow:['historian.example-plant.com:4840','controller.line2.local:4840']}})
CALL whisper.agents({op:'budget', args:{agent:'2a04:2a01:7a2::4840', max_mb_per_day:50}})

62443-4-1: secure development lifecycle (○ stretch). The SDLA is about how the product is built: a supplier-credibility control, not something an asset owner evidences with a /128. Whisper contributes context (a verifiable identity primitive you integrate) but does not stand in for a 4-1 assessment.

NIST: SP 800-82r3, CSF 2.0, NISTIR 8259A

• SP 800-82r3, Guide to OT Security (● strong). The guide leans on four pillars: device identification and authentication, network segmentation, hardened remote access, and continuous monitoring. They align directly with the primitives above. It also sanctions exactly our shape: where a device cannot do per-device identity itself, use compensating controls (segmentation, protocol-aware firewalls, session logging). An overlay identity layer is the recommended pattern, not a workaround.
• CSF 2.0, ID.AM + PR.AA (● strong). The Asset Management (ID.AM) and Identity Management, Authentication & Access Control (PR.AA) categories map onto a /128 that is simultaneously an IPv6-addressable, authoritative asset register and a verifiable identity.
• NISTIR 8259A, IoT device capabilities (● strong). Its very first capability is device identification: a unique logical identifier for the device. A DNSSEC/DANE-anchored /128 is a strong, externally-verifiable logical ID, checkable by anyone from the internet's own records.

CISA CPG 2.0: the near-verbatim fit

The CISA Cross-Sector Cybersecurity Performance Goals 2.0 read almost like a spec for this primitive. Two goals in particular: maintain an IP/IPv6 asset inventory that includes OT and is refreshed regularly; and segment logically by trust boundary, permitting only required communications. A per-asset /128 is an IPv6-addressable asset register that updates itself at provisioning and revoke; default-deny egress governance is the segmentation-by-trust-boundary control. This is the mapping where the framework's words and the product's mechanism line up most closely.

# The asset register, straight from authoritative DNS + RDAP: no spreadsheet to drift
dig -x 2a04:2a01:7a2::4840 +short
opcua-plc7.asset.<tenant>.agents.whisper.online.
curl -s https://whisper.online/ip/2a04:2a01:7a2::4840 | jq
# -> the registry object: who holds the address, under which allocation, since when

RFC 8520 MUD: the device's declaration, made enforceable

Under MUD (RFC 8520), a device already declares what it should communicate with: a manufacturer-signed manifest of from-device and to-device ACLs, emitted over DHCP (options 161/112), an LLDP vendor TLV, or the id-pe-mud-url X.509 extension co-located with an 802.1AR IDevID. Whisper enforces that declaration as default-deny egress governance, bound to the asset's verifiable /128 and checkable cross-org: a genuine strengthening over a manifest pinned to a spoofable manufacturer URL and enforced only at the nearest switch (● strong).

NIS2 & TSA: organisational obligations we supply evidence for

NIS2, Article 21(2) (◐ partial). For important and essential entities (manufacturing and critical manufacturing among them), Article 21 requires access control, asset management, network security, supply-chain measures and logging, backed by fines up to €10M or 2% of turnover. These are organisational obligations on the entity, not product controls. Whisper supplies checkable technical evidence toward the access-control, network-security and logging measures; it does not, and cannot, make an organisation NIS2-compliant on its own.

TSA Pipeline & Rail Security Directives (● segmentation / ◐ MFA). The SD-Pipeline-2021-02 series and the 2024 rail rulemaking require network segmentation so OT survives an IT compromise, access control with MFA, and continuous monitoring. Per-asset segmentation, attribution and per-/128 logs serve the segmentation and monitoring measures strongly; MFA is a partial fit: Whisper governs machine-to-machine identity and egress, and the operator-facing MFA controls stay with your access stack.

The audit trail: nothing issued in the dark

Every identity mint and every revoke lands in a public, append-only Merkle transparency log (RFC 6962 tlog-tiles with C2SP signed-note checkpoints), Ed25519-signed and anchored to Bitcoin via OpenTimestamps. For a regulated OT program that is a non-repudiable issuance-and-revocation trail an assessor can replay independently: the provenance of every asset identity, and the exact moment a compromised one was cut off.

# the signed checkpoint (the log's current root): anyone can fetch and verify it
curl -s https://whisper.online/checkpoint

# one asset identity's ordered lifecycle: mint -> (governance changes) -> revoke
curl -s https://whisper.online/ip/2a04:2a01:7a2::4840/transparency | jq

SIEM & threat-intel export

The evidence above is pullable now via the logs op and the graph API, and it exports to Splunk today (signed, replayable JSON → CEF / ECS fields). Broader connectors are on the roadmap, labelled honestly so nobody plans a control around vapour:

Until the roadmap items land, the same records are already reachable. The exports are a convenience layer over evidence you can pull today, not a prerequisite for it.

What this is, and is not

Whisper anchors one boundary: the IP / DNS / transport interface between an asset and whatever it talks to. It is deliberate about what it does not touch, and every mapping on this page inherits these caveats:

• Additive, never a replacement. It complements your 62443 program, your OPC UA application-instance certificate and its local TrustList, your 802.1AR IDevID and BRSKI onboarding, your MUD profiles and your TPM/HSM anchors. It replaces none of them.
• Identity is not full authentication. The asset still performs the handshake; the claim is verifiable identity plus key-pinning, not end-to-end CR 1.2 device authentication.
• Network-side logging is not host audit. Per-/128 logs record what an asset reached and who looked at it, not modification of on-device data, which needs the asset's own audit into your SIEM.
• No SBOM, no patching. We produce no software bill of materials and remediate no vulnerabilities; revoke is a containment lever, not a patch pipeline.
• Human I&A is out of scope. We identify assets and processes; CR 1.1 and operator MFA stay with your IAM.
• NIS2, TSA and the CISA CPGs are organisational obligations. The product is evidence toward specific technical measures: it never "makes you compliant."
• The last inch is enforced in the command path. Egress governance changes who may reach and speak to an asset; it does not add authentication to Modbus, DNP3 or PROFINET on the wire, and it does not stop a purely-internal manipulation by an attacker who already holds an OT-segment foothold. Closing that needs identity enforced at the PLC, a protocol-aware broker-gateway or the EWS, not at the network boundary. We never position Whisper inside that closed command path.

Everything on this page described as working is checkable today with dig, curl and one control-plane call; everything on the roadmap is labelled as such. That is the point of the whole exercise: not a paragraph asserting a control, but a routable identity, an egress record and a revoke you (or your integrator, or your assessor) can independently replay. Evidence you can hand an auditor, not a promise you ask them to take on faith.

Next

• Asset & PLC identity: how the device-derived /128 is computed from the OPC UA ApplicationUri (or IDevID / serial) an asset already holds
• OT-exposure cure: why a reachable socket on a flat network is the whole exploit, cured at the identity layer
• OPC UA · MUD · 62443: the proposed integrations at the asset/IP boundary, each additive to the stack it names