# 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.

> **Read this first.** Whisper is *additive*: a network-layer identity, egress and attribution primitive that *complements* your 62443 program, your OPC UA TrustList, your 802.1AR / BRSKI onboarding and your MUD profiles. It is not a compliance product and it never "makes you compliant": NIS2, TSA and the CISA CPGs are organisational obligations, and Whisper supplies checkable evidence toward specific technical measures within them. Every mapping below is graded honestly, and every "shipped" claim is checkable today with `dig`, `curl` and one control-plane call.

## 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`:

```bash
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.
```

> `device_id` is generic: pass an OPC UA `ApplicationUri`, an 802.1AR IDevID serial, or a bare nameplate serial. A dedicated `--applicationuri` / `--mud` CLI flag is on the roadmap; asset provisioning is the control-plane call above, which **is** live. See [Asset & PLC identity](/docs/industries/ot/asset-identity) for the full derivation and [CLI & one-command](/docs/cli) for the shipped verbs.

*Diagram: one verifiable `/128` → the evidence seven frameworks ask for. One shipped primitive set (identity, default-deny egress governance, per-asset logs plus lookups, and revoke plus the transparency log) converges into a single keyless-verifiable, replayable evidence set, which maps to EU CRA Annex I 2(d)(i)(j)(l), IEC 62443-4-2 CR 1.2, IEC 62443-3-3 zones and conduits, CISA CPG 2.0, RFC 8520 MUD, NIST SP 800-82r3 with CSF 2.0 and NISTIR 8259A, and NIS2 with the TSA Security Directives. Additive to your existing 62443 program, IDevID/BRSKI, OPC UA TrustList and MUD, never a replacement.*

## 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.

| Framework & clause | What it asks | Whisper evidence (shipped) | Fit |
|---|---|---|---|
| **EU CRA**, Annex I Part I (2)(d): identity & access management | Protection from unauthorised access through authentication, identity or access-management systems; report on unauthorised access | Verifiable, revocable per-asset `/128` (DANE + RDAP); `revoke` = de-provisioning; `lookups` surfaces unauthorised enumeration | ● |
| **EU CRA**, Annex I Part I (2)(i) + (2)(j): minimise impact & limit attack surface | Limit external attack surface; reduce an incident's impact on other devices and networks | Default-deny egress governance bound to the `/128`: a MUD-style allow-list at asset granularity | ● |
| **EU CRA**, Annex I Part I (2)(l): record & monitor | Record and monitor access to, and modification of, the product's data, services and functions | Per-`/128` egress logs + lookups (network-side record) | ◐ (host / SIEM audit still required) |
| **EU CRA**, Annex I Part I (2)(f): integrity | Protect the integrity of stored/transmitted data, commands and configuration | DNSSEC + DANE protect the identity and channel setup, not the payload | ◐ |
| **EU CRA**, Annex I Part II (1): SBOM | Draw up a software bill of materials for the product | The OEM ships its own SBOM; Whisper produces none | ✗ |
| **IEC 62443-4-2**, CR 1.2: device identification & authentication | A component uniquely identifies and authenticates itself to any other (unique-ID at SL2; HW/PKI-backed at SL3 through SL4) | Globally-unique, externally-verifiable `/128` + a DANE pin of the asset's *existing* cert/key | ● identity / ◐ auth |
| **IEC 62443-4-2**, CR 1.1: human user I&A | Identify and authenticate human users | Out of scope: we identify assets and processes, not people | ✗ |
| **IEC 62443-3-3**, SR 5.1: zones & conduits | Segment the network; restrict data flow between zones through defined conduits | `/128`-per-asset + egress allow-list = a conduit at asset granularity, keyed to a verifiable identity | ● |
| **IEC 62443-4-1**: secure development lifecycle | A secure product-development lifecycle (SDLA) | Supplier-credibility context only, not evidenced by an asset's `/128` | ○ |
| **NIST SP 800-82r3** (OT security) | Device I&A, network segmentation, hardened remote access, monitoring | Direct alignment on all four via the primitives above | ● |
| **NIST CSF 2.0**: ID.AM + PR.AA | Asset management; identity, authentication and access control | `/128` = an IPv6-addressable asset register + a verifiable identity | ● |
| **NISTIR 8259A**: device identification | A unique logical identifier for the device | DNSSEC/DANE-anchored `/128` = a strong, externally-verifiable logical ID | ● |
| **CISA CPG 2.0**: asset inventory + segmentation | Maintain an IP/IPv6 asset inventory (incl. OT); segment logically by trust boundary, permitting only required communications | Near-verbatim: an IPv6-addressable asset register + default-deny egress | ● |
| **RFC 8520** (MUD) | A device declares its intended communications; a manager enforces a default-deny allow-list | Egress governance keyed to a verifiable `/128`, not a spoofable MUD URL | ● (needs a control point in the path) |
| **NIS2**: Art. 21(2) | Access control, asset management, network security, logging, supply-chain measures | Evidence for the access-control / network-security / logging measures | ◐ (an organisational obligation) |
| **TSA** Pipeline / Rail Security Directives | Network segmentation (OT survives IT compromise), access control / MFA, continuous monitoring | Per-asset segmentation + attribution + per-`/128` logs | ● segmentation / ◐ MFA |

## 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.

*Diagram: the EU CRA timeline. 10 Dec 2024, CRA enters into force → today sits shortly before 11 Sep 2026, when reporting obligations begin (24-hour early-warning, Art. 14) → 11 Dec 2027, full application and CE conformity assessment, fines ≤ €15M / 2.5% turnover. The identity clause 2(d), the attack-surface clauses 2(i)/(j) and the logging clause 2(l) can be evidenced now, with no firmware re-spin.*

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.

> **The CRA ↔ 62443 crosswalk is still settling.** The harmonised standards that will presume CRA conformity are not final, and much of industry expects IEC 62443 to carry that weight. Until they land, map your evidence to **62443 today** (the section below) and treat the CRA clauses as the outcome those 62443 controls satisfy.

## 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.

```bash
# 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.

```bash
# 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.

```bash
# 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).

> **The honest MUD caveat.** MUD at OT scale needs a *control point in the path*: egress governance enforces where traffic leaves via the asset's `/128`, so the asset must route through Whisper egress for enforcement to bite. Much brownfield gear never emits a MUD URL at all. Our value there is the verifiable identity plus an externally-managed profile that plain RFC 8520 lacks; the enforcement point is a deployment decision, not a given.

## 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](/docs/transparency) (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.

```bash
# 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
```

> **Honest status.** The log is tamper-evident, Ed25519-signed and Bitcoin-anchored today, but *not yet independently witnessed* (co-signing across our own nodes is availability, not independence). It already speaks the C2SP `tlog-witness` protocol, so an external witness can co-sign; independent witnessing is the next step, and we state it plainly rather than imply an audit guarantee we haven't earned.

## 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:

| Destination | Status |
|---|---|
| Splunk (CEF / ECS) | **Shipped** |
| Microsoft Sentinel connector | **Shipped** |
| OpenCTI | **Shipped** |
| STIX 2.1 over TAXII | Roadmap |
| Sector-ISAC (E-ISAC / WaterISAC) machine-readable JSON export | Roadmap |

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](/docs/industries/ot/asset-identity): how the device-derived `/128` is computed from the OPC UA `ApplicationUri` (or IDevID / serial) an asset already holds
- [OT-exposure cure](/docs/industries/ot/ot-exposure-cure): why a reachable socket on a flat network is the whole exploit, cured at the identity layer
- [OPC UA · MUD · 62443](/docs/industries/ot/ot-integrations): the proposed integrations at the asset/IP boundary, each additive to the stack it names