Energy compliance: NERC CIP, IEC 62351 & Rule 21

NERC CIP, IEC 62351, CA Rule 21, EU NIS2 and the EU Network Code on Cybersecurity all press a DER control plane on one question: which party is on this connection, is it authorised, and can you prove it and cut it off?

A backend gated by OAuth bearer tokens and shared, NAT'd egress IPs cannot answer that. A routable, DANE-provable, one-call-revocable IPv6 /128 per party can. It produces the log, the attribution and the kill-switch those frameworks want as evidence, not as a paragraph in a policy binder. This page is the honest map of where that evidence fits (and, just as important, where it does not).

What every framework is really asking

Read the DER regulations side by side and the same three questions surface, phrased in five vocabularies:

• Identity: who or what is on the other end of this DER-to-cloud connection, and can a third party verify it without trusting your word for it?
• Attribution & monitoring: what did that party do, to which destinations, who is enumerating your fleet, and can you show a continuous, non-repudiable record?
• Response: when one party turns hostile, or a vendor's access should end, can you contain it, provably and fast, across every operator?

None of these is a logging problem you fix with more log lines. They are identity problems: you cannot attribute, monitor or contain an actor that has no stable, provable identity in the first place. The IEEE 2030.5 LFDI is a genuinely good key-derived name, but it lives in a private SERCA→MCA→MICA root, is allow-listed per-utility out-of-band, is not IP/DNS-addressable, and by its own managed-PKI rules cannot be revoked. Whisper's job here is to give every party on the cloud/IP boundary an identity that is addressable, publicly verifiable and revocable, then let the standard toolchain read the evidence off it.

Three verdicts, stated up front

Before a single row of the map, here's the grading rule: an energy-compliance page that claimed to "satisfy NERC CIP" would be lying. Whisper is a network primitive. Against a given control it does exactly one of three things, and we mark which:

The evidence: real, and shipped

Everything this page grades DIRECT-ADDITIVE rests on primitives that exist and answer today. Each is checkable with dig, curl, or one control-plane call over the public API: POST https://graph.whisper.security/api/query with your X-API-Key.

A device-derived /128 identity

A DER already holds a key: the public half of its IEEE 2030.5 EndDevice certificate, a SunSpec/Kyrio device cert, a TPM, or a secure element. Whisper derives a deterministic IPv6 /128 from that key's public SubjectPublicKeyInfo, with the LFDI (or a DER serial) as the domain separator. The address is tenant-bound (fleet-unlinkable to an outsider), DNSSEC-anchored, DANE-EE 3 1 1 pinned, and RDAP-registered. Re-deriving from the same key and LFDI yields the same /128; nothing new to store, nothing to steal that would let a scraper forge it.

# Provision a DER identity from the key it already holds (control plane, live).
# identity_public_key is the base64 SPKI of the EndDevice / SunSpec-Kyrio / TPM key.
CALL whisper.agents({op:'connect', args:{
  tier:'wireguard',
  identity_public_key:'<base64 SPKI of the device key>',
  device_id:'3F2504E04F8911D39A0C0305E82C33018B2E44F9'   // the IEEE 2030.5 LFDI
}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error
# -> deterministic /128 + a WireGuard config. Same key + LFDI -> same /128 (idempotent).
#    A different LFDI on the same tenant -> 409; a non-string device_id -> 400. Never a 500.

Per-/128 logs, and who's looking back

Because each party owns a dedicated /128, every DNS lookup and connection it makes is unambiguously its, with no shared-IP noise to reconstruct. And because the identity resolves through Whisper's own authoritative DNS and RDAP, you can also ask who is enumerating you: a reconnaissance tripwire the LFDI's private, out-of-band registry never offered.

# The DER's OWN outbound activity, per-event: timestamp, kind, destination, decision, bytes
CALL whisper.agents({op:'logs',    args:{agent:'2a04:2a01:5e0::50c', kind:'conn', from:'-24h'}})

# Reverse observability: WHO resolved this DER's PTR/AAAA/TLSA or hit its RDAP object, and when
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:5e0::50c', window:'24h'}})
curl -s https://whisper.online/ip/2a04:2a01:5e0::50c/lookups | jq   # same view, keyless

One-call revoke

Containment, and the end of a vendor's access, is a single call. It tears down the /128, its PTR and its DANE record worldwide at DNS-TTL speed, and the teardown is provable with the same public tools that proved the identity.

CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:5e0::50c'}})
# after the TTL:
dig -x 2a04:2a01:5e0::50c +short                          # -> empty
curl -s https://whisper.online/verify-identity/2a04:2a01:5e0::50c   # -> {"is_whisper_agent": false}

The attribution graph

Turning a raw destination (or a suspicious controller in your logs) into "known-bad C2" or "clean CDN" is a read-only query against the public graph API. Attribution survives IP rotation because it fingerprints the operator and the tooling (ASN and hosting genealogy for cloud rotation, a JA4/JA3 client fingerprint for a residential-proxy swarm), not the ephemeral egress IP.

curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  --data-urlencode "q=CALL whisper.identify('34.90.x.x')"
# -> what the address is, who operates it, threat-intel reputation, relationships:
#    a reproducible, replayable JSON evidence chain your OT SOC, PSIRT and a regulator can replay.

The read-only verbs (identify, origins, walk, variants, history) run the same way, over an infrastructure-and-threat-intelligence graph of billions of nodes. That is the enrichment that turns a per-DER egress log into a detection.

The map, at a glance

Each row is a framework, the control it asks for, our verdict, and the shipped evidence behind it. The deep sections below unpack each group. Read the verdict column first: it is the load-bearing part.

^¹ DIRECT-ADDITIVE against the published articles of Reg. (EU) 2024/1366; the binding control lists finalise around 2027 (see the caveats below).

DIRECT-ADDITIVE: the evidence we produce

Where a control asks a question the four shipped primitives answer, Whisper is a concrete input to your compliance package. Never the whole standard. One verifiable control, with reproducible artifacts.

NERC CIP-005-7 R3: determine & disable active vendor remote access

CIP-005-7 added the vendor-remote-access requirements the sector had been missing: R3.1 requires a method to determine active vendor remote-access sessions (including system-to-system), and R3.2 requires a method to disable them. That is precisely a determine-then-disable loop, and it maps one-to-one onto shipped ops. It is the strongest fit on this page.

# R3.1: determine which vendor identities are active on your tenant, and who's looking
CALL whisper.agents({op:'list',    args:{kind:'agent'}})
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:5e0::50c', window:'24h'}})

# who is the operator behind a session? (attribution survives egress rotation)
curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
  --data-urlencode "q=CALL whisper.identify('34.90.x.x')"

# R3.2: disable it. One call, worldwide, at DNS-TTL, and provable afterward.
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:5e0::50c'}})

Honest scope. CIP-005 R3 is written for the Responsible Entity's own EACMS and Electronic Security Perimeter. Whisper anchors at the cloud/IP boundary and supplies the determine and disable evidence there; it is one control in your RSAW, additive to your ESP architecture, not a replacement for it.

NERC CIP-013-2 R1.2.3 & R1.2.6: supply-chain risk controls

CIP-013-2 R1.2 obliges a supply-chain risk-management plan that addresses, among other items, R1.2.3 (notification when vendor remote or onsite access should no longer be granted) and R1.2.6 (coordination of controls for vendor-initiated Interactive Remote Access and system-to-system remote access). A per-device identity you can revoke in one call, with a tamper-evident record of exactly when access was granted and removed, is a direct artifact for both. The transparency log is what makes the "we removed access on date X" claim non-repudiable rather than a database row an auditor must take on faith.

EU NIS2: Article 21 risk-management measures

NIS2 (Directive (EU) 2022/2555) Art.21 requires essential and important entities (energy squarely among them) to take measures including access-control and asset-management policies, security in network and information systems acquisition and maintenance, and logging. A per-/128 identity gives you machine-level access control at the cloud boundary; op:logs and op:lookups give you the continuous, per-party record; op:revoke plus the transparency log give you the supply-chain offboarding evidence. Evidentiary and additive: one measurable input to the Art.21 posture.

EU Network Code on Cybersecurity: Reg. (EU) 2024/1366, Art.33

The NCCS is the electricity-sector network code adopted in 2024; Art.33 points at zero-trust access and traceability across the ICT lifecycle. An identity that is per-device, attributable on egress, and whose issuance and revocation live in an auditable lifecycle log is a natural fit for both. The honest caveat: the NCCS's binding control lists and the classification of high- and critical-impact entities are still being finalised. Completion is expected around 2027. We map to the published articles today and will track the control text as it lands; we make no claim against text that does not yet exist.

NISTIR 7628 r1: SG.IA & SG.AU

The NIST smart-grid security guidelines organise controls into families. Two land directly: SG.IA (Identification and Authentication), where the device /128 is a cryptographic device identifier, publicly verifiable and bound to the key the device already holds, and SG.AU (Audit and Accountability), where the per-/128 logs, op:lookups, the signed graph evidence chains, and the append-only transparency log are exactly the reviewable, accountable record the family asks for.

Sandia SAND2019-1490: DER cybersecurity guidance

Sandia's DER cybersecurity work (SAND2019-1490 and the follow-on 2021-0977) recommends, in plain words, to verify the identity of devices and enforce access control on DER communications. The device-derived /128 is that verifiable identity; source-bound egress governance (default-deny, allow only the DERMS head-end and OTA endpoint) is that access control. Guidance-additive: a concrete implementation of an advisory recommendation.

COMPLEMENTARY: we sit alongside, we don't satisfy the cert

Several frameworks mandate the sector's own PKI or a certificate. Whisper does not, and must not claim to, satisfy those. It complements them: it keeps the good property they already have (a key-derived name), adds the two they lack (public verifiability and DNS-TTL revocation), and where a certificate is in play it can DANE-pin that exact certificate to DNSSEC to cut single-CA trust risk.

• CA Rule 21 / IEEE 2030.5 CSIP. Rule 21 mandates IEEE 2030.5 (SEP2) with the LFDI and the CSIP managed-PKI cert. Whisper binds that existing LFDI to a public /128 and can DANE-pin the head-end's 2030.5 endpoint certificate; it never issues or replaces the CSIP cert.
• UL 1741-SB. A type-test of an inverter model against IEEE 1547-2018 grid-support functions, not a live, per-unit, revocable identity. Whisper adds exactly that live per-unit layer next to the model certification.
• SunSpec / Kyrio SERCA→MCA→MICA PKI. The private device-certificate root. Whisper keeps its key-derived LFDI property, adds public verifiability and DNS-TTL revocation, and never cross-signs into the private root.
• IEC 62351-9. Key management, revocation and credential lifecycle for power-system communications. Whisper's DNS-TTL revocation and transparency log complement 62351-9 at the IP/DNS boundary; it does not implement 62351 on the substation bus.
• ISO 15118 / OCPP 2.0.1. Plug&Charge's contract-certificate PKI and the charger↔CSMS protocol. Whisper gives each EVSE a revocable network identity alongside the 15118 PKI, never inside the charging handshake.
• NIST IR 8498. Cybersecurity for grid-edge smart-inverter systems. The per-/128 logs map to its logging goal (G3) and the DANE-pinned, source-bound egress to its protect-connections goal (G7): a complementary control mapping, not a conformance claim.

STRETCH: what we do NOT claim

The most useful rows on a compliance page are often the ones a vendor omits. These controls exist, they matter, and Whisper is honestly the wrong tool for them. We list them so nobody plans against an over-claim:

• NERC CIP-010: configuration change management, security baselines and vulnerability assessment. Whisper is not a configuration-baseline or vuln-assessment tool.
• NERC CIP-005-7 R2: Interactive Remote Access routed through an Intermediate System with encryption and multi-factor authentication. Whisper is not an Intermediate System and provides no MFA. (Note the deliberate split: R3 vendor-remote-access is DIRECT-ADDITIVE; R2 IRA/MFA is not claimed.)
• NERC CIP-007-5 R5: system access control, account and authentication management on BES Cyber Systems. Whisper is not an account or authentication manager.

Two caveats we state up front

Buyer trust is built by naming the limits before the sales call does:

• NERC CIP scope is the Bulk Electric System. CIP obligations attach at the utility / aggregation / registered-entity / vendor-access layer, not to most behind-the-meter residential DER. A Whisper /128 is useful at both layers, but only the BES layer is in CIP scope; we do not pretend a rooftop inverter is a BES Cyber Asset. Where CIP maps, it maps at the aggregator↔utility↔vendor boundary, which is exactly where Whisper sits.
• EU NCCS control lists finalise around 2027. Reg. (EU) 2024/1366 is adopted, but its binding cybersecurity control lists and impact-classification are still being worked out. We map to the published articles today and treat the detailed control text as forthcoming: no claims against undecided text.

Nothing issued in the dark: the transparency-log audit trail

Every identity mint and every revocation lands in a public, append-only Merkle transparency log (RFC 6962 tlog-tiles), with Ed25519-signed C2SP checkpoints, each root anchored to Bitcoin via OpenTimestamps. That gives a regulated operator something a database row cannot: a non-repudiable answer to "when was this vendor's access granted, and when was it removed", provably not back-dated, provably in order.

# An identity's ordered lifecycle (issuance, any rotations, revocation), keyless
curl -s https://whisper.online/ip/2a04:2a01:5e0::50c/transparency | jq

# The signed log checkpoint + its Bitcoin anchor: the tamper-evidence root
curl -s https://whisper.online/checkpoint
# -> a C2SP signed note; the root is OpenTimestamps-anchored to Bitcoin

Evidence you can hand an auditor

The point of every primitive above is that the auditor does not have to trust Whisper. Each artifact is reproducible from the internet's own records with stock tools: the same --trustless walk any resolver could run. A per-control evidence bundle for an RSAW or a NIS2 review looks like this, and every line is checkable without an account:

# IDENTITY (SG.IA / CIP-013): the identity is genuine and current, verified to the IANA root
whisper verify --trustless 2a04:2a01:5e0::50c
✓ DNSSEC chain valid to the IANA root   ✓ DANE-EE (TLSA 3 1 1) matches the key
✓ RDAP: registered under AS219419 · 2a04:2a01::/32   identity: VERIFIED (our API never trusted)

# MONITORING (CIP-005 R3.1 / SG.AU): the per-party record and who enumerated it
CALL whisper.agents({op:'logs',    args:{agent:'2a04:2a01:5e0::50c', kind:'conn', from:'-30d'}})
CALL whisper.agents({op:'lookups', args:{agent:'2a04:2a01:5e0::50c', window:'30d'}})

# DISABLE + NON-REPUDIATION (CIP-005 R3.2 / CIP-013 R1.2.3): the offboarding, provable and timestamped
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:5e0::50c'}})
curl -s https://whisper.online/ip/2a04:2a01:5e0::50c/transparency   # the timestamped lifecycle leaf

And because telemetry can be bound to (and 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, which is the non-repudiation those audit families ultimately want.

SIEM & threat-intel export

The evidence above is pullable now via op:logs, op:lookups and the graph API, and it exports to Splunk today as signed, replayable JSON mapped to CEF / ECS fields. Broader connectors are on the roadmap, labelled honestly so nobody plans against vapour:

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

What this is, and is not

Whisper anchors one boundary: the cloud/IP interface between a DER (or an aggregator-API consumer) and the backend. It is deliberate about what it does not touch.

• It is not your CSMS, DERMS, or SUMS: it is the identity-and-attribution layer those systems consume. It complements them; it does not replace them.
• It does not sit inside the IEC 61850 GOOSE/MMS bus, the DNP3 outstation link, or the ISO 15118 charging handshake. Those keep their own PKIs; a Whisper DANE-anchored identity complements them at the network layer without cross-signing.
• These platform mappings are proposed, not vendor-endorsed, and no operator is named as a breach victim. The exposure classes on this page are drawn from public research and advisories at the class level only.

Everything 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 whole contract of this page.

Next

• DER & inverter identity: how the device-derived /128 is computed from the key a DER already holds, and why the LFDI is the natural domain separator.
• Grid-API-abuse cure: the same identity, applied to the stolen-aggregator-token problem at the API ingress (the BOLA root cause).
• Telemetry · egress · attribution: runnable recipes that generate exactly the artifacts this page maps to a control.