Platform integrations

Whisper sits beside the energy stack you already run and anchors exactly one thing: a routable, verifiable identity at the DER↔cloud IP boundary. That's the layer where a stolen aggregator token or a scraped head-end API today looks identical to the real inverter.

Everything below is a proposed integration pattern: our design, not a vendor endorsement. Every one is written the same way: Whisper complements the mechanism you have; it never replaces it. We do not sit inside IEC 62351 on the substation bus, we do not authenticate the DNP3 outstation link, and we do not intercept the ISO 15118 Plug & Charge handshake at the connector. Those live on the bus and at the plug, and they are already someone's job. Whisper's job is the network identity of whatever is talking to your cloud: the inverter's communication card, the EVSE, the DERMS/aggregator-API consumer, the OpenADR VEN. It's expressed as an IPv6 /128 that DNSSEC, DANE and RDAP can prove and one call can revoke.

Anchor the boundary, not the bus

A distributed energy resource carries several trust mechanisms, each correct for its own layer. The mistake is to imagine a new identity system has to displace one of them. It doesn't. Whisper is deliberately confined to the one place none of them cover: the moment a network endpoint claims to be a particular inverter, EVSE, or sanctioned aggregator, and the receiver has only a bearer token or a private-CA certificate to go on.

Read the last row as the whole thesis: at the IP boundary, identity today is a claim carried in a header: a bearer token, or a certificate only the utility's own SERCA→MCA→MICA root can validate. Whisper turns it into a network fact: the source address itself, forward-confirmed in DNS, pinned in DANE, registered in RDAP.

IEEE 2030.5 / CSIP head-ends: the keystone

An IEEE 2030.5 (SEP2) server (the utility or DERMS head-end a fleet of EndDevices talks to under the CSIP profile) terminates TLS with a certificate that chains to the private SERCA→MCA→MICA (SunSpec/Kyrio) root. That is deliberately not Web PKI: nothing outside the utility's ecosystem can validate it, and, per the managed-PKI model, its certificates are "life-long … cannot be updated or revoked." A DER trusts the head-end because a SERCA anchor was baked into it at the factory: a single-root trust with no public cross-check.

The integration is to publish a DANE TLSA record over DNSSEC that pins the head-end's endpoint certificate (the exact leaf key), so any relying party validates it against the IANA DNS root instead of trusting one private CA on faith. Same profile the rest of Whisper uses: DANE-EE 3 1 1, SPKI/SHA-256. Nothing in the 2030.5 transport, the CSIP function sets, or the EndDevice resource model changes; you are only making the head-end's certificate independently checkable and cutting single-CA trust risk.

# Pin the CSIP head-end's leaf key in DNSSEC-signed DNS: no reliance on one private root.
dig +dnssec TLSA _443._tcp.headend.der.<tenant>.agents.whisper.online
;; flags: qr rd ra ad          ← ad = DNSSEC-authenticated
;; _443._tcp....agents.whisper.online. 300 IN TLSA 3 1 1 b653a4ef...fcb82d1d

The keystone is also where the shipped spine attaches. The 2030.5 EndDevice certificate (whose key material is already hashed into the LFDI) is exactly the birth certificate the /128 is derived from: submit the device's public SPKI, pass the LFDI as device_id, and the head-end can authorize a forge-proof address instead of a portable token. The private key never leaves the device; the derivation is deterministic and tenant-bound, and the full mechanics live on DER & inverter identity.

# The spine: derive the DER's /128 from the EndDevice key it already holds + its LFDI.
CALL whisper.agents({op:'connect', args:{
  tier:                'wireguard',
  identity_public_key: '<base64 SPKI of the EndDevice key>',
  device_id:           '3F2504E04F8911D39A0C0305E82C33018B2E44F9'   // the IEEE 2030.5 LFDI
}}) YIELD op, ok, status, result, error
   RETURN op, ok, status, result, error

DERMS & VPP platforms: attribute and revoke behind the aggregator

A DERMS or VPP platform consumes the manufacturer's LFDI and authorizes an operation with a bearer token or an OAuth grant: "many small devices, one control plane." That is efficient and it is exactly the wedge: a minted or reused token behind the aggregator is the fleet authority, and a compromised device can only be contained by rotating a credential that reaches the whole fleet. The platform can't attribute a hijacked token across rotating egress, and it can't cut off one inverter without a fleet-wide reset.

Whisper adds two things beside the platform, changing nothing in its dispatch logic. First, per-device revocation: each DER behind the aggregator has its own forge-proof /128, so a single compromised unit is one op:'revoke' away from having no network identity anywhere. No fleet-wide credential rotation needed. Second, operator attribution: the read-only graph names whoever is really behind a suspicious controller, stitched across the Amazon → Google → Azure hops a raw last-IP loses, with a residential-proxy swarm collapsed by a JA4 client fingerprint.

# Name the operator behind a hijacked aggregator token across rotating egress.
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\")"}' | jq .
# -> operator fingerprinted across AWS / GCP / Azure; residential swarm collapsed by JA4

# Contain ONE device behind the aggregator: no fleet-wide credential reset.
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:5e0::50c'}})

See who's enumerating your fleet before the dispatch lands. Because every DER's name resolves through Whisper's own authoritative DNS and RDAP, the owner can ask who looked: a reconnaissance tripwire the LFDI's private, out-of-band registry never gave you. op:'lookups' returns who resolved or RDAP-queried a device's identity, so you catch an attacker iterating your fleet's addresses in recon, not in the post-mortem:

# who has been resolving / RDAP-querying this DER's identity, and when
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:5e0::50c', window:'24h'}})

And because each dispatch and telemetry stream can be signed under the DER's forge-proof /128, the ISO, the utility, and your own market settlement can trust the numbers came from the real device: non-repudiable telemetry, not a spoofed feed the VPP has no way to tell apart.

OpenADR 3.0: VTN & VEN

OpenADR coordinates demand-response and DER dispatch between a VTN (the server) and its VENs (the clients). OpenADR 3.0/3.1 identifies a VEN by a venID and authorizes it with an OAuth2 JWT bearer over server-authenticated TLS (2.0b used mTLS). Two exposures follow from that shape: a VEN trusts the VTN only as far as it trusts whatever CA signed the VTN's cert, and a JWT bearer, once minted, is portable: replay it from anywhere and it still authenticates.

The integration closes both at the network boundary, and touches neither the OAuth model nor the OpenADR message set. DANE-pin the VTN's TLS endpoint so a VEN confirms it is talking to the real VTN trustlessly, against the DNSSEC root, rather than any-CA-will-do. And source-bind each VEN's egress to its /128, so the VTN allowlists a network identity that a replayed JWT from a random IP simply cannot present.

# A VEN confirms the real VTN before it ever presents its JWT: trustless, from the DNS root.
whisper verify --trustless vtn.grid.<tenant>.agents.whisper.online
dnssec   pass   DNSSEC-root   AAAA, PTR and TLSA(3 1 1) all DNSSEC-validated to the IANA root
dane     pass   DNSSEC-root   served leaf SPKI-SHA256 == TLSA pin
CRYPTOGRAPHICALLY PROVEN, trust anchor: DNSSEC root (IANA) + DANE-EE

# The VTN allowlists the VEN's source /128, not a portable bearer.
whisper policy set --agent 2a04:2a01:5e0::a11 --default deny --allow vtn.grid.<tenant>.agents.whisper.online

AWS IoT Core & Azure IoT Hub

On AWS IoT Core or Azure IoT Hub, every device authenticates into your account with an X.509 certificate and mutual TLS, and your account's registry (or DPS) is the certificate authority. That is exactly right for getting the inverter or gateway into your tenant. It says nothing to anyone outside your cloud account: a partner utility, an ISO, an auditor, a DER buyer, a neutral market operator, who wants to confirm that a given endpoint really is that device without being handed your private CA.

Whisper adds that out-of-tenancy identity beside the vendor mTLS, not in place of it. The device keeps its IoT certificate and its MQTT mTLS untouched; you additionally derive a /128 from the same hardware key and publish its DANE pin and RDAP record in public DNS. Now the account-internal trust and the externally-verifiable trust share one root (the device's key), but no one outside needs your CA to check the second one.

# Anyone outside your cloud account verifies the endpoint trustlessly:
# DNSSEC + DANE, Whisper's own API NOT in the trust path.
whisper verify --trustless lfdi-3f2504e0.der.<tenant>.agents.whisper.online

# Or the keyless RDAP record for the address: who holds it, since when.
curl -s https://whisper.online/ip/2a04:2a01:5e0::50c | jq '.handle, .parentHandle'

The SIEM feed: Splunk, Sentinel & OpenCTI today

Identity and attribution are only useful to a grid SOC if they land in the tools it already runs. Whisper emits every finding as a signed JSON evidence chain (a whisper.identify attribution result, an op:'lookups' enumeration alert, an identity mint or revoke from the transparency log), so it is machine-readable enrichment for your OT sensor and threat-intel, not another console an analyst babysits.

The Splunk connector is shipped today. It maps each signed finding onto CEF and ECS fields and forwards it into Splunk, so a fleet-enumeration tripwire or a rotating-egress attribution becomes a correlatable event beside your Dragos / Claroty / Nozomi telemetry:

# The signed finding the Splunk connector maps to CEF / ECS and forwards.
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\")"}' | jq '.result.evidence'
# -> a replayable, signed evidence chain -> CEF: deviceVendor=Whisper cs1=operator …
#    (the connector emits one event per finding; the chain re-verifies offline)

The Microsoft Sentinel connector and OpenCTI threat-intelligence integration ship today, mapped onto Sentinel's connector framework and OpenCTI's knowledge graph for continuous-monitoring workflows. STIX 2.1 over TAXII with E-ISAC machine-readable export is on the roadmap, not shipped. It is listed honestly under On the roadmap below.

Shipped today vs proposed

Honesty about what runs matters more here than anywhere. The identity primitive under every integration is live and provable right now; the integration guides themselves are proposed patterns for wiring that primitive into each platform.

On the roadmap

These feed grid-security evidence into the tools a utility SOC and an OEM PSIRT already run. They are roadmap, not yet shipped, listed here so you can see where this goes:

• Microsoft Sentinel connector: shipped today, alongside the Splunk connector.
• OpenCTI threat-intelligence integration: shipped today.
• STIX 2.1 over TAXII + E-ISAC machine-readable export: roadmap. Maps identity and egress evidence onto standard TI transports and E-ISAC sharing for NERC CIP continuous-monitoring workflows.
• First-class typed --lfdi / --der-serial argument: roadmap. Today the generic device_id already accepts an LFDI, an SFDI, or a bare DER serial.
• Independent witnessing of the transparency log: roadmap. Tamper-evident and Bitcoin-anchored today; external co-signing via C2SP tlog-witness is the next step.

Next

• DER & inverter identity: the shipped derivation these integrations all build on
• Grid-API-abuse cure, the primary wedge: identity at the aggregator-API ingress
• NERC CIP · IEC 62351 · Rule 21: where the evidence lands for audit and vendor-remote-access controls