# Embedded compliance: the CRA, 62443, EN 303 645 & 802.1AR

**The EU Cyber Resilience Act, IEC 62443, ETSI EN 303 645 / the UK PSTI Act, FDA §524B and IEEE 802.1AR all ask one thing of a connected-device program: which device is this, is it authorised, and can you prove it and shut it off?**

This page maps Whisper's shipped evidence onto those frameworks. The honest disclaimers first: Whisper is not a certification, not a notified body, and not a compliance-automation product. It is a network primitive whose by-products (a per-device identity register, DANE pins, per-/128 egress logs, a publicly checkable revoke trail, signed attribution findings) happen to be exactly the artifacts these frameworks keep asking for. You file the evidence; we make it real.

## What every framework is really asking

Strip the clause numbers and the frameworks converge on four questions: **identity** (can you name each device, from a hardware root of trust, without shipped shared secrets?), **control** (can you constrain and observe what it talks to?), **response** (when one is compromised, can you cut it off, quickly and provably?), and **evidence** (can you show all of the above to someone who doesn't trust you?). The address-is-identity primitive answers all four with the same object: the device's `/128`, its DANE pin, its logs, and its revoke record.

## The map, at a glance

| Framework | What it demands (the relevant slice) | The Whisper artifact |
|---|---|---|
| **EU Cyber Resilience Act** (in force 10 Dec 2024; main obligations from 11 Dec 2027) | Secure by default, no known exploitable vulns at release, security updates for the support period, vulnerability handling & incident reporting | Per-device identity with no shipped shared secret · publicly checkable revoke · per-/128 monitoring logs · signed attribution findings for the reporting duty |
| **ETSI EN 303 645** & the **UK PSTI Act** (PSTI in force 29 Apr 2024) | No universal default passwords; unique per-device credentials; a vulnerability-disclosure route | The credential is structurally per-device (one leaf key, one /128) and no password exists to default. Met by construction, evidenced by the identity register |
| **IEC 62443-4-2 / -3-3** | Component & system identification and authentication control; least-privilege network flows | DANE-EE-pinned device identity · default-deny egress policy per /128 |
| **IEEE 802.1AR** | Secure device identity: an IDevID bound to the device in hardware | The IDevID key *is* the derivation input; Whisper is the public, routable projection of the 802.1AR identity you already provisioned |
| **BRSKI / RFC 8995** | Bootstrapping the IDevID into an owner relationship | Complementary: BRSKI establishes ownership at onboarding; the /128 + RDAP object is the public record of the owned identity thereafter |
| **FDA §524B** (cyber devices; premarket since Oct 2023) | For medical-adjacent device makers: a cybersecurity plan, postmarket monitoring, SBOM | Attributable per-device telemetry and egress logs · revoke as the documented compromise response. The SBOM itself is your build system's job, not ours |
| **NIST IR 8259A** | IoT device core baseline: device identification, configuration, data protection, interface access control | The /128 as the logical identifier bound to hardware · default-deny interface policy · per-identity audit trail |

## The EU CRA, in a little more depth

The CRA is the one with a countdown attached: hardware being specced now will still be on sale when the main obligations bite on **11 December 2027**. Three of its demands land directly on this platform's shipped surface:

- **Secure by default.** A product whose auth story is "a per-device key in a secure element, no shipped shared secret, no default password" is secure-by-default in the exact sense the regulation means, and the identity register plus per-device DANE pins are the evidence.
- **Vulnerability handling & incident reporting.** When a device or credential is found compromised, the response is one owner-thrown `revoke`, timestamped and publicly checkable in DNS: a response artifact you can put in the report. The attribution graph's signed findings document the who-and-how alongside it.
- **The support period, honestly.** Identity anchored in public DNS and registered address space keeps verifying for as long as you support the product, independent of any console's lifecycle: the quiet prerequisite under every other duty.

## The evidence: real and shipped

Every row above is backed by a live artifact you can generate today, not a screenshot:

```sh
# the identity register, per device: public, DNSSEC-signed, third-party checkable
dig -x 2a04:2a01:e5a7:41c9:04d0:c85f:3a1b:77e2 +short
dig +short TLSA _443._tcp.04d0c85f3a1b77e2.<tenant>.agents.whisper.online
curl -s https://whisper.online/ip/2a04:2a01:e5a7:41c9:04d0:c85f:3a1b:77e2 | jq

# the monitoring record, per device: every query and connection, keyed to the /128
CALL whisper.agents({op:'logs', args:{agent:'<the device /128>', kind:'conn', from:'-30d'}})

# the response record: revoke, provable by its absence
CALL whisper.agents({op:'revoke', args:{agent:'<the device /128>'}})
curl -s https://whisper.online/verify-identity/<the device /128>   # -> {"is_whisper_agent": false}
```

## SIEM & threat-intel export

Compliance evidence is only useful where your program already lives. The **Splunk**, **Microsoft Sentinel** and **OpenCTI** connectors ship today; findings arrive as signed, replayable JSON mapped to CEF and ECS fields. **STIX 2.1 over TAXII** export is on the roadmap, labelled as such, not yet available. A Splunk CIM mapping and a sample Sentinel analytics rule ship with the connectors.

## What this is (and is not)

- It **is** a per-device identity register, a monitoring record, a provable revocation mechanism, and an attribution evidence chain: the artifacts the frameworks presuppose.
- It is **not** a certification, a conformity assessment, an SBOM generator, or legal advice. Map the artifacts into your file with your assessor; the clause-level fit is yours to own.
- It is **additive and fail-open**: adopting it never makes Whisper a compliance-critical single point of failure. If we're unreachable, your devices keep working on your existing anchors.

## Next

- [Device & IDevID identity](/docs/industries/embed/device-identity): the identity register every row above rests on
- [Embedded recipes](/docs/industries/embed/embedded-recipes): generate the evidence artifacts hands-on
- [Compliance & audit](/docs/compliance) in the shared library: the platform-wide evidence model