# Figure captions (English)

## fig01_attack_paths.svg
Attack paths from manufacturing to operation. An attacker reaches field equipment from manufacturing, software development, update servers and signing keys, the vendor cloud control plane, communication paths, admin accounts or the site network. JC-STAR★1 evaluates only the product functions at the right; every other point of reach is out of scope (IPA written answer, 26 July 2026).

## fig02_origin_vs_attack_path.svg
Country of manufacture, country of development, cloud location, attacker location and country of operation can all differ. Origin checks (blue dotted) cover the two left columns; intrusions (red) reach the operating system on the right through third-country clouds, compromised relays and legitimate admin accounts, without passing through the manufacturing country's products or firms.

## fig03_audit_scope_vs_operation.svg
Manufacturing, development, delivery, installation, operation and update on the horizontal axis. Audits of manufacturing and development (blue) cover the two left stages and product functions at one point in time; across the 15–20-year asset life, operation and update (red) retain the cloud control plane, admin accounts, communication paths, later-disclosed vulnerabilities, update delivery and service laptops as attack surface.

## fig04_cert_vs_boundary_models.svg
Left, the product-certification-centric model: the trust boundary sits on each device, and cloud plus update delivery connect to every unit directly, making them the common point of failure. Right, the boundary-protection-centric model: the trust boundary moves to the site and cloud commands are validated there; the common point of failure moves to the boundary device model, which must be diversified and updated in stages. Both have a common point of failure; the question is how many units it connects to directly.

## fig05_boundary_protected_der.svg
Traffic from several vendor clouds and a charging management system (CSMS) is checked at the site boundary for destination, protocol, function code and rate. Inside, a local EMS holds an output floor and the default behaviour on loss of communication; one boundary protects vendor-A and vendor-B PCS, a vendor-C battery and an OCPP charger. The grid operator's command path (blue) is separated from vendor maintenance paths (red). Whether each device supports this layout is in the public-specification table in Chapter 7.

## fig06_blast_radius.svg
Ceiling of capacity moved by one compromise under the assumptions fleet 10,000 MW, one cloud control plane holding 25%, boundary effectiveness ρ=0.9. A: 2,500 MW from one cloud compromise; B: 250 MW from the 10% of sites where the boundary fails. The B-specific common cause (a vulnerability in the boundary device model) reaches the whole fleet if every site uses one model and 2,000 MW with five models. Values change with `data/assumptions.csv`.

## fig07_cost_comparison.svg
Annual cost per kW (log scale) for four site classes. A: pass-through of certification cost plus lost generation when like-for-like replacement stops being a "minor change". B: annualised boundary device plus operations. At low voltage B is one to two orders of magnitude above A; at extra-high voltage they are comparable. All cost inputs except the two-year validity (IPA published value) are assumptions; the application fee (kind=to-confirm) is to be replaced with the published figure. Cheapness is a different axis from reach of protection (Chapter 8).