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) | Products with digital elements: 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 (the update/end-of-support kill-path) · 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 (the component authenticates itself cryptographically) · 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 (the postmarket monitoring record) · 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:
# 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: the identity register every row above rests on
- Embedded recipes: generate the evidence artifacts hands-on
- Compliance & audit in the shared library: the platform-wide evidence model