{
"slug": "fleet-command-authorization",
"topic_id": "TOPIC-131",
"cluster": "Electric Grid, Water & OT Identity",
"tier": "Tier A",
"title": "Who told 40,000 inverters to curtail? Authorization in aggregated DER",
"summary": "A single API call can curtail tens of megawatts across thousands of privately owned assets. The call is authenticated by a platform credential. Nothing names the human who authorised that magnitude of action.",
"lede": "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.",
"date": "2025-11-28",
"category": "Vertical",
"author_id": "nadia-ferreira-strand",
"tags": [
"DER",
"virtual power plant",
"FERC Order 2222",
"aggregation",
"inverter",
"grid services"
],
"image": "https://cdn.twc.sh/images/igcache/Fleet%20Command%20Authorization/1200_630/blog.jpg",
"schema": "Article",
"key_takeaways": [
"DER platforms authenticate the caller. They do not bound the magnitude of what the caller may command.",
"Express the ceiling cryptographically: a delegation carrying a megawatt cap, asset class scope and expiry, signed by a named human.",
"Asset owners currently have no independent record that their equipment was commanded under a legitimate instruction. They should."
],
"body": [
{
"type": "h2",
"text": "Prerequisites"
},
{
"type": "diagram",
"kind": "flow",
"alt": "One call, tens of megawatts, thousands of owners",
"caption": "The aggregation model is the value. It is also the blast radius.",
"nodes": [
{
"label": "Aggregator holds device authority",
"note": "by contract"
},
{
"label": "API call issued",
"note": "platform credential",
"bad": true
},
{
"label": "40,000 devices respond",
"note": "as designed",
"bad": true
},
{
"label": "Owners unaware",
"note": "no visibility",
"bad": true
}
]
},
{
"type": "p",
"html": "Before starting, collect three things. Without them the rest of this is theory."
},
{
"type": "ul",
"items": [
"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."
]
},
{
"type": "h2",
"text": "Step 1 — Compute capacity per credential"
},
{
"type": "p",
"html": "This is the number that determines everything else. For each credential with dispatch authority, sum the nameplate capacity of every asset it can address."
},
{
"type": "p",
"html": "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."
},
{
"type": "table",
"caption": "Worked example. Substitute your own figures; the shape is what matters.",
"head": [
"Credential",
"Assets reachable",
"Nameplate reachable",
"Human named in the record"
],
"rows": [
[
"Market dispatch service",
"38,400",
"192 MW",
"None"
],
[
"Operations support",
"41,900",
"209 MW",
"None"
],
[
"Partner integration",
"6,200",
"31 MW",
"None"
],
[
"CI deployment token",
"41,900",
"209 MW",
"None"
]
]
},
{
"type": "h2",
"text": "Step 2 — Decide the ceiling per authority class"
},
{
"type": "p",
"html": "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."
},
{
"type": "ol",
"items": [
"Scheduled market dispatch within a cleared bid: no ceiling needed, because the bid itself bounds it. Bind the delegation to the bid reference.",
"Operational curtailment outside a cleared position: ceiling at the megawatt level your operations team can explain to a distribution utility on a phone call.",
"Fleet-wide firmware or configuration push: no automated authority at all. Human signature per push, without exception.",
"Emergency response to a utility instruction: ceiling raised, with the utility's instruction reference carried in the delegation."
]
},
{
"type": "h2",
"text": "Step 3 — Express the ceiling as a delegation"
},
{
"type": "p",
"html": "The constraint belongs in the credential, not in application logic, because application logic is what an attacker or a defect bypasses."
},
{
"type": "code",
"text": "delegation:\n issuer: [operations lead, hardware credential]\n delegate: [dispatch service key]\n scope: action = curtail | dispatch\n asset_class = [residential_pv, residential_storage]\n region = [ISO zone]\n limits: max_mw = 25\n max_assets = 8000\n notAfter: [24 hours]\n depth: 0 # may not be re-delegated"
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "Step 4 — Give asset owners their own receipt"
},
{
"type": "p",
"html": "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."
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "Step 5 — Verify the failure path"
},
{
"type": "p",
"html": "Do not deploy without testing what happens when authorisation fails. Three cases, all of which must be exercised before production:"
},
{
"type": "ol",
"items": [
"Ceiling exceeded — the instruction is refused, an alarm is raised, and no partial dispatch occurs. Partial dispatch is worse than none.",
"Delegation expired — scheduled dispatch fails safe and escalates rather than silently skipping a market obligation.",
"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."
]
},
{
"type": "h2",
"text": "What this does not address"
},
{
"type": "p",
"html": "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."
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "Two consequences worth separating"
},
{
"type": "table",
"caption": "Grid effect and property effect",
"head": [
"Consequence",
"Who bears it"
],
"rows": [
[
"Aggregate grid impact",
"The system operator, and every connected customer"
],
[
"Individual asset behaviour",
"The owner, who did not see the instruction"
],
[
"Financial settlement",
"Owner and aggregator, later"
],
[
"Safety in an islanded condition",
"Local, and potentially severe"
]
]
},
{
"type": "p",
"html": "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."
},
{
"type": "h2",
"text": "Objections and honest limits"
},
{
"type": "p",
"html": "“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."
},
{
"type": "p",
"html": "“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."
}
],
"faq": [
{
"q": "Would a ceiling break legitimate large dispatches?",
"a": "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."
},
{
"q": "Does this add latency to dispatch?",
"a": "Verification is local and sub-millisecond. Scheduled dispatch runs under a pre-signed delegation, so no human is in the real-time path."
},
{
"q": "Is this a FERC Order 2222 requirement?",
"a": "No. Order 2222 concerns market participation by aggregated resources. Authorisation architecture is not addressed, which is why it has not been built."
},
{
"q": "What should asset owners actually receive?",
"a": "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."
},
{
"q": "Don't owners consent contractually?",
"a": "They consent to participate in a programme — a category. That is not visibility into or refusal of a specific instruction."
},
{
"q": "Why gate by magnitude?",
"a": "Because curtailing one asset and curtailing the fleet are the same command with a different selector."
},
{
"q": "What is missing from the current model?",
"a": "Any representation of the individual owner, whose asset changes behaviour on an instruction they cannot see or verify."
}
],
"sources": [
{
"t": "IEEE 1547 — interconnection of distributed energy resources",
"u": "https://standards.ieee.org/ieee/1547/5915/"
},
{
"t": "NERC — CIP reliability standards",
"u": "https://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx"
}
],
"related": [
{
"slug": "ot-authorization-boundary",
"title": "MFA proves the login, not the breaker",
"category": "Vertical"
},
{
"slug": "magnitude-bounded-connectivity",
"title": "IoT SIM fleets: who authorized a change on 200,000 devices?",
"category": "Vertical"
},
{
"slug": "delegation-depth-policy",
"title": "Agent-to-agent delegation depth",
"category": "Developer"
}
],
"wordcount": 1018,
"url": "/blog/fleet-command-authorization.html",
"reading_time": "5 min read",
"image_title": "Fleet Command Authorization",
"seo_title": "Authorization in aggregated distributed energy",
"meta_description": "One API call can curtail tens of megawatts across thousands of privately owned assets, authenticated by a platform credential naming no human.",
"hub": {
"slug": "topics/ot-identity",
"title": "Grid, water and OT identity"
},
"answer": "A platform credential. A single API call can curtail tens of megawatts across thousands of privately owned assets, and the call is authenticated by an aggregator's key. Nothing in the record names the human who decided, and the assets belong to people who never see the instruction.",
"answer_q": "Who told 40,000 inverters to curtail?",
"glossary": [
{
"term": "DER",
"def": "Distributed energy resource — a small generating or storage asset, typically privately owned and aggregated."
},
{
"term": "Curtailment",
"def": "Reducing output, which for an owner is lost revenue and for the grid is a stability action."
},
{
"term": "Aggregator",
"def": "The party holding contractual authority to dispatch many owners' assets as one resource."
}
],
"checklist": {
"title": "Bounding fleet commands",
"id": "fleet",
"desc": "Four steps.",
"steps": [
{
"name": "Gate by magnitude, not by command type.",
"text": "Curtailing one asset and the fleet are the same command."
},
{
"name": "Require a named signature above a threshold.",
"text": "Derived from your own distribution."
},
{
"name": "Give owners a verifiable record.",
"text": "Of instructions affecting their asset."
},
{
"name": "Enforce revocation at the device.",
"text": "So a withdrawn consent is effective, not advisory."
}
]
},
"cta": {
"title": "Where this fits in Manav",
"html": "Manav binds the operator to the exact command, session or two-person act, verifiable offline at the console or the gateway — which is the condition OT and field work actually run in.",
"href": "../docs.html",
"label": "See offline verification"
}
}