Who told 40,000 inverters to curtail? Authorization in aggregated DER

Run the arithmetic before the argument. A mid-size virtual power plant aggregates forty thousand residential inverters at roughly five kilowatts each. That is two hundred megawatts of dispatchable capacity behind one platform credential, with no magnitude ceiling anywhere in the authorisation model.

Part of Grid, water and OT identity

Prerequisites

Before starting, collect three things. Without them the rest of this is theory.

• An inventory of platform credentials with write access to dispatch endpoints, including service accounts and CI tokens.
• Nameplate capacity reachable by each credential — not asset count, capacity.
• Your market obligations: which dispatch instructions carry settlement consequences and which are advisory.

Step 1 — Compute capacity per credential

This is the number that determines everything else. For each credential with dispatch authority, sum the nameplate capacity of every asset it can address.

Most platform teams have never computed it because the platform is organised by customer or by program, not by credential. Expect the result to be larger than anyone expected, and expect at least one credential — usually an operations or support account — to reach the entire fleet.

Step 2 — Decide the ceiling per authority class

A ceiling is a policy decision, not a technical one. Set it against the consequence you are willing to absorb without a human in the loop.

1. Scheduled market dispatch within a cleared bid: no ceiling needed, because the bid itself bounds it. Bind the delegation to the bid reference.
2. Operational curtailment outside a cleared position: ceiling at the megawatt level your operations team can explain to a distribution utility on a phone call.
3. Fleet-wide firmware or configuration push: no automated authority at all. Human signature per push, without exception.
4. Emergency response to a utility instruction: ceiling raised, with the utility's instruction reference carried in the delegation.

Step 3 — Express the ceiling as a delegation

The constraint belongs in the credential, not in application logic, because application logic is what an attacker or a defect bypasses.

delegation:
  issuer:   [operations lead, hardware credential]
  delegate: [dispatch service key]
  scope:    action = curtail | dispatch
            asset_class = [residential_pv, residential_storage]
            region = [ISO zone]
  limits:   max_mw = 25
            max_assets = 8000
  notAfter: [24 hours]
  depth:    0          # may not be re-delegated

An instruction exceeding max_mw produces no valid authorisation. The platform cannot execute it, regardless of what the application code believes, and the failure is visible rather than silent.

Step 4 — Give asset owners their own receipt

This is the step most platforms skip and the one that will matter commercially. The homeowner whose battery was discharged at 6pm has a contractual relationship with the aggregator and no independent evidence of anything.

A per-command receipt, verifiable by the asset owner offline, changes the dispute posture entirely. It also pre-empts the regulatory question that arrives the first time a consumer complains to a state commission about an unexplained discharge.

Step 5 — Verify the failure path

Do not deploy without testing what happens when authorisation fails. Three cases, all of which must be exercised before production:

1. Ceiling exceeded — the instruction is refused, an alarm is raised, and no partial dispatch occurs. Partial dispatch is worse than none.
2. Delegation expired — scheduled dispatch fails safe and escalates rather than silently skipping a market obligation.
3. Issuer key rotation mid-window — both keys valid, no interruption. Test this deliberately; it is the failure that will otherwise find you at 4pm on a settlement day.

What this does not address

There is no public record of a malicious fleet-wide DER dispatch, and this article does not imply one has occurred. The risk here is structural rather than demonstrated: the authorisation model places no bound on magnitude, and the capacity behind a single credential is growing faster than the governance around it.

It also does not address device-level security on the inverters themselves, communications integrity, or the market rules that determine whether a dispatch was economically appropriate.

Two consequences worth separating

Most discussion of DER security focuses on the first row. The second is the one that has no representation at all in the current model: a privately owned asset changes behaviour on an instruction its owner cannot see, verify or refuse.

Objections and honest limits

“Owners agreed to this by contract.” They agreed to participate in a programme. That is a standing consent to a category, which is different from visibility into a specific instruction, and it is the same scope-versus-instance distinction that appears everywhere in delegation.

“Magnitude limits already exist.” In some programmes, as platform configuration. Configuration is not an authorisation record, and it is set by the party issuing the commands.

Bounding fleet commands

1. Gate by magnitude, not by command type. Curtailing one asset and the fleet are the same command.
2. Require a named signature above a threshold. Derived from your own distribution.
3. Give owners a verifiable record. Of instructions affecting their asset.
4. Enforce revocation at the device. So a withdrawn consent is effective, not advisory.

Terms used here

DER

Distributed energy resource — a small generating or storage asset, typically privately owned and aggregated.

Curtailment

Reducing output, which for an owner is lost revenue and for the grid is a stability action.

Aggregator

The party holding contractual authority to dispatch many owners' assets as one resource.

Frequently asked questions

Would a ceiling break legitimate large dispatches? Only if set below your operating envelope. Set ceilings from your own dispatch history — the 99th percentile of legitimate instructions — and raise them deliberately through a signed act rather than accidentally through an unbounded credential.

Does this add latency to dispatch? Verification is local and sub-millisecond. Scheduled dispatch runs under a pre-signed delegation, so no human is in the real-time path.

Is this a FERC Order 2222 requirement? No. Order 2222 concerns market participation by aggregated resources. Authorisation architecture is not addressed, which is why it has not been built.

What should asset owners actually receive? A verifiable record that their asset was commanded, when, under whose authority, and within what program. Most platforms currently send an app notification, which is not the same thing.

Don't owners consent contractually? They consent to participate in a programme — a category. That is not visibility into or refusal of a specific instruction.

Why gate by magnitude? Because curtailing one asset and curtailing the fleet are the same command with a different selector.

What is missing from the current model? Any representation of the individual owner, whose asset changes behaviour on an instruction they cannot see or verify.

Sources and further reading

• IEEE 1547 — interconnection of distributed energy resources
• NERC — CIP reliability standards