Field-provisioned solar inverters accept firmware and config over the air — how do you model that update path as an entry point?

## The system A manufacturer runs a fleet of grid-tied solar inverters installed on homes and small commercial roofs. Each unit accepts firmware images and configuration changes over the air. Installers commission units in the field using a credential that is the same across the installer base, and units sit on customer premises networks the manufacturer has no visibility into. ## The modeling move: the flow points inward Teams instinctively model telemetry — the device reporting outward to the cloud — and reason about who can read it. The update and provisioning path is the flow that matters, and it points the other way: data crossing a trust boundary *into* equipment that controls a physical process. Once you draw the arrow correctly, the question stops being "how does the cloud know it is talking to the inverter" and becomes "what does the inverter demand before it accepts an instruction that changes its behaviour". Both directions need answering, but only the inbound one can hurt someone. Drawing it also exposes the third participant. There are not two zones here but at least four: the manufacturer's back end, the update transport, the installer at commissioning time, and the premises network the unit lives on for the next fifteen years. ## Which threats dominate, and why that ordering is unusual The asset is the safe operation of a physical process and the availability of generation, not customer records. That reorders STRIDE relative to a typical web model: - **Tampering** (integrity) — an altered image or a changed setpoint makes the unit behave outside its safe envelope, or makes it stop exporting. - **Denial of Service** (availability) — a bad push that bricks units removes generation and needs a physical visit per unit to recover, which is the expensive kind of outage. - **Spoofing** (authentication) — something that is not the manufacturer persuades the unit to accept an update, or something that is not an authorised installer commissions a unit. - **Elevation of Privilege** (authorization) — a maintenance interface reachable from the premises network grants more than the local network deserves. - **Information Disclosure** ranks *low* here. Generation data is not the prize. Saying so out loud is part of a good answer, because a model that spends its effort on the least valuable asset is a failed model. ## The two structural properties worth calling out **A shared installer credential.** One value, used by every installer, embedded in commissioning tooling and passed between contractors. It never rotates because rotating it means retraining and re-tooling the field force. It cannot be revoked for one leak without stopping all commissioning. And it gives no attribution: when a unit is misconfigured you cannot tell which installer touched it, which is a Repudiation problem with real commercial consequence. The fix is per-installer or per-unit enrolment identity established at commissioning, with the shared value demoted to at most an identifier and never an authenticator. **Fleet-wide reach.** The update channel is the one mechanism that touches every unit simultaneously. That is exactly what makes it valuable to an attacker and dangerous when you are merely wrong: the blast radius of a compromised or mistaken push is the entire fleet, at once, on physical equipment. Model the channel itself as a high-value asset and design so that no single compromise or single mistake reaches everything — staged rollout by cohort, a halt condition based on health telemetry, and rate limits on how much of the fleet can change in a window. ## Device-side requirements the model produces The model does not need to specify mechanisms to state the requirements, and the requirements are what an interviewer wants: - The unit must be able to verify that an image or configuration originated from the manufacturer, using something it holds rather than something the sender asserts. - It must refuse to install an older version than it runs, because otherwise every fixed defect remains reachable by anyone who can offer the old image. - Configuration must be treated with the same suspicion as firmware. Setpoints, export limits and grid-protection parameters change behaviour just as effectively as code, and they are routinely protected far less. - Acceptance must be atomic with a fallback: a unit that fails mid-update should come back on its previous image, because the alternative is a physical visit. - Local maintenance interfaces must authenticate as strictly as remote ones. The premises network is not a trusted zone just because it is behind a home router. ## Attacker positions to enumerate Write them down explicitly, because each reaches a different part of the diagram: someone on the site's local network probing the unit's maintenance interface; a compromised update channel or the credentials that drive it; a departed installer still holding the shared commissioning secret; and the owner of the equipment, who may want to raise an export limit for their own benefit. That last one matters — as with any device in someone else's hands, the legitimate owner is a valid attacker position and a model that only imagines outsiders will miss half the misconfiguration it eventually sees. ## Residual The honest model ends with what remains: units already in the field with an older acceptance policy cannot be fixed by design changes to new units, so you need a migration plan and an inventory of which units are on which policy. The manufacturer's own signing and release process becomes a concentrated risk, and how that pipeline is protected is a separate discussion from this one — but the model should name it as a dependency rather than pretend it does not exist.