Fleet Management Platforms (FM)

Fleet Management Platforms (FM), The Estate deck, Critical Infrastructure Threat Taxonomy: control-panel artwork showing one console wired to every site at once.

Taxonomies › Critical Infrastructure › FM · Fleet Management Platforms

One console running many sites: retail refrigeration, building management, charging, distributed energy, meters and telemetry. Part of The Estate deck, ranked Ace to 2 by severity in the game. This page is part of the Critical Infrastructure (Cyberwarfare) Threat Taxonomy, the reference for the Black Start card game.

FM Fleet Management Platforms taxonomy table, 13 entries: BKS-FM-A One command reaches every site; BKS-FM-K The platform is the master key; BKS-FM-Q Every controller function is remote; BKS-FM-J Sites cannot say no; BKS-FM-10 A firmware push bricks the fleet; BKS-FM-9 One vendor cloud, many operators; BKS-FM-8 The platform is the only view; BKS-FM-7 Commands unsigned end to end; BKS-FM-6 Integrations hold command rights; BKS-FM-5 No plan to cut the cord; BKS-FM-4 Alarms only travel through the platform; BKS-FM-3 Nobody can say who sent what; BKS-FM-2 Nobody knows what the fleet runs. Each row gives the threat, any public case, the mitigation principle and the design measures.

Mappings at a glance

STRIDE, CAPEC 3.9, CWE 5.0, ATT&CK for ICS v20.0, the Cyber-Informed Engineering principles (main one first) and standards, entry by entry. The same mappings are in each entry below and in the Excel, SKOS and STIX downloads.

FM Fleet Management Platforms mapping table, 13 entries: BKS-FM-A One command reaches every site; BKS-FM-K The platform is the master key; BKS-FM-Q Every controller function is remote; BKS-FM-J Sites cannot say no; BKS-FM-10 A firmware push bricks the fleet; BKS-FM-9 One vendor cloud, many operators; BKS-FM-8 The platform is the only view; BKS-FM-7 Commands unsigned end to end; BKS-FM-6 Integrations hold command rights; BKS-FM-5 No plan to cut the cord; BKS-FM-4 Alarms only travel through the platform; BKS-FM-3 Nobody can say who sent what; BKS-FM-2 Nobody knows what the fleet runs. Each row gives the STRIDE categories, CAPEC patterns, CWE weaknesses, ATT&CK for ICS techniques, Cyber-Informed Engineering principles and standards for the entry.

Entries

BKS-FM-A · One command reaches every site †

The platform lets one operator, or one stolen session, send a dangerous command to every site at once: a setpoint, a mode change, a forced defrost or a shutdown. Nothing in the design limits how many sites a single action can touch, so one decision becomes a national event.

Case: Supermarket refrigeration attacks, 2026.

Principle. The blast radius of any single command is bounded by design, not by who happens to be logged in.

Design measures.

  1. Cap the number of sites one command can reach, and require a second named approver above the cap.
  2. Roll fleet-wide changes out in waves that halt automatically when site telemetry moves away from normal.
  3. Enforce each site’s engineered safe envelope in the site controller, so out-of-range commands are refused locally.

Mappings: STRIDE T, D, E · CAPEC-212 · CWE-1220, CWE-799 · ATT&CK for ICS T0831, T0836, T0858 · CIE 1, 4, 2

BKS-FM-K · The platform is the master key †

The central console or vendor cloud holds standing authority over every connected site. Compromising the platform, its administrators or its hosting gives direct control of the whole estate without touching a single site’s own defences.

Case: Supermarket refrigeration attacks, 2026; Kaseya VSA and Coop Sweden, 2021.

Principle. No single system, account or provider holds unbroken authority over every site.

Design measures.

  1. Split the estate into independently administered cells, so one compromised cell cannot command the others.
  2. Keep platform administration on separate identities, devices and networks from day-to-day operation.
  3. Treat the platform as a crown-jewel asset: dedicated monitoring, privileged access review and tested compromise playbooks.

Mappings: STRIDE S, T, E · CAPEC-122 · CWE-653, CWE-250 · ATT&CK for ICS T0822, T0859, T0886 · CIE 3, 1, 5

BKS-FM-Q · Every controller function is remote †

The platform exposes every function the site controllers support, including defrost, test modes, factory reset, flushing and limit overrides, because exposing everything was easiest. Functions only an engineer standing at the plant should ever use become commands anyone on the platform can send.

Case: Supermarket refrigeration attacks, 2026.

Principle. Expose remotely only the functions remote operation needs; dangerous functions stay local or need local confirmation.

Design measures.

  1. Classify every controller function by consequence and disable remote access to the dangerous class by default.
  2. Require a physical action at the site, such as a key switch or button, before hazardous modes start.
  3. Limit how long, how often and how far any built-in cycle such as defrost can run, in the controller itself.

Mappings: STRIDE T, E · CAPEC-212, CAPEC-36 · CWE-749, CWE-1188 · ATT&CK for ICS T0858, T0836, T0821 · CIE 4, 2, 1

BKS-FM-J · Sites cannot say no †

Site controllers execute whatever the platform sends. They have no local check of whether a command is safe now (store open, tank low, demand peaking) and no local override that the platform itself cannot switch off, so the site’s own knowledge never gets a vote.

Principle. The site that bears the consequence keeps a veto over commands that would harm it.

Design measures.

  1. Give each site controller interlocks that reject commands unsafe for its current process state.
  2. Provide a hard-wired local override that returns the site to safe standalone control and cannot be disabled remotely.
  3. Report every refused command back to the platform and to the site operator as a security event.

Mappings: STRIDE T, E · CAPEC-212 · CWE-807, CWE-863 · ATT&CK for ICS T1692.001, T0831 · CIE 2, 1, 5

BKS-FM-10 · A firmware push bricks the fleet †

The platform can push firmware and configuration to every device it manages. A malicious, corrupted or wiping image sent through that channel disables the fleet in one operation, and recovery means a person visiting every site with replacement hardware.

Case: Viasat KA-SAT modems, 2022.

Principle. Mass updates are signed, staged and reversible, and no single push can reach the whole fleet.

Design measures.

  1. Accept only firmware signed by keys held off the platform, and verify the signature on the device.
  2. Deploy updates in rings with a hold period, and stop automatically when early rings report failures.
  3. Keep a protected recovery image on every device that a remote push cannot overwrite.

Mappings: STRIDE T, D · CAPEC-186, CAPEC-669 · CWE-494, CWE-347 · ATT&CK for ICS T1693, T0800 · CIE 9, 10, 4

BKS-FM-9 · One vendor cloud, many operators

A single vendor platform serves many operators: competing retailers, several water companies, utilities in different countries. A failure of tenant isolation, or a compromise of the vendor’s own administration plane, reaches every customer at once and across borders, which looks like a coordinated campaign against a whole sector.

Case: Supermarket refrigeration attacks, 2026.

Principle. An operator’s sites are isolated from other customers and from the vendor’s own administrators by default.

Design measures.

  1. Require contractual and technical tenant isolation, with vendor administrative access to your tenant off unless you grant it.
  2. Ask vendors for evidence of how their administration plane is separated, monitored and tested.
  3. Map which suppliers’ platforms are shared with others in your sector, and plan for losing each one.

Mappings: STRIDE E, I, D · CAPEC-122, CAPEC-180 · CWE-653, CWE-863 · ATT&CK for ICS T0859 · CIE 9, 7, 3

BKS-FM-8 · The platform is the only view †

Operators see temperatures, pressures and levels only through the fleet dashboard. If the platform is compromised it can show normal values while sites fail; if it is down, nobody can see the sites at all. There is no second, independent way to know what is happening.

Case: Stuxnet, 2010.

Principle. Critical process state can be confirmed through a path the platform does not control.

Design measures.

  1. Fit independent alarm sensors at each site that report through a separate channel.
  2. Cross-check platform readings against independent measurements and alarm on disagreement.
  3. Write procedures for verifying site state locally when the dashboard cannot be trusted.

Mappings: STRIDE T, D · CAPEC-148 · CWE-1293 · ATT&CK for ICS T0832, T0815, T0829 · CIE 5, 10, 1

BKS-FM-7 · Commands unsigned end to end †

Commands travel from the console through brokers, gateways and cloud relays before reaching the site, and the site trusts whatever arrives from the last hop. Anyone who controls a relay can inject, alter or replay commands that the site accepts as genuine.

Principle. A site acts only on commands it can verify came, unaltered and fresh, from an authorised operator.

Design measures.

  1. Sign commands at the point of authorisation and verify them in the site controller, not in an intermediate gateway.
  2. Include sequence numbers and expiry in every command so replays and delayed commands are rejected.
  3. Bind each command to the operator identity that approved it, and log that identity at the site.

Mappings: STRIDE S, T · CAPEC-94, CAPEC-148 · CWE-924, CWE-940 · ATT&CK for ICS T0830, T1692.001 · CIE 3, 2

BKS-FM-6 · Integrations hold command rights

Energy optimisation, analytics, ticketing and ERP integrations call the platform API with long-lived keys or service accounts that can change setpoints or send commands. Nobody watches them as closely as human operators, and one leaked key works against every site the integration can reach.

Principle. Machine accounts get the least authority their purpose needs, and command rights are never granted for convenience.

Design measures.

  1. Give integrations read-only access unless a named owner justifies each write or command scope.
  2. Use short-lived, rotated credentials for API access, scoped to specific sites and functions.
  3. Alert on any command issued by a service account outside its expected pattern or hours.

Mappings: STRIDE S, E · CAPEC-21, CAPEC-122 · CWE-272, CWE-522 · ATT&CK for ICS T0871, T0859 · CIE 3, 8

BKS-FM-5 · No plan to cut the cord †

When an advisory says to disconnect affected controllers, the operator finds there is no tested way to take sites off the platform quickly and run them safely standalone. Sites stay connected while the attack continues, or are disconnected into an unsafe state.

Case: Supermarket refrigeration attacks, 2026.

Principle. Every site can be isolated from central management quickly and continue in a safe, known local mode.

Design measures.

  1. Design and document a standalone mode for each site type that keeps the process safe without the platform.
  2. Provide a single, tested action that severs a site or a whole region from the platform.
  3. Rehearse fleet disconnection at least yearly and time how long it takes.

Mappings: STRIDE D · ATT&CK for ICS T0827 · CIE 10, 1

BKS-FM-4 · Alarms only travel through the platform †

Site alarms are routed to people only through the fleet platform’s notification service. When the platform is attacked, overloaded or switched off, alarms stop reaching anyone, often at night when sites are unattended and damage builds for hours unnoticed.

Case: Supermarket refrigeration attacks, 2026.

Principle. Critical alarms reach a person even when central management is unavailable.

Design measures.

  1. Send high-priority alarms over a second path that does not depend on the platform.
  2. Treat a silent site as an alarm: raise an alert when expected heartbeats stop arriving.
  3. Test end-to-end alarm delivery regularly, including at night and at weekends.

Mappings: STRIDE D · CAPEC-603 · CWE-1320 · ATT&CK for ICS T0878, T0815 · CIE 5, 7, 10

BKS-FM-3 · Nobody can say who sent what

The platform logs commands without the human operator’s identity, source location or approval trail, and keeps the logs only in the vendor’s cloud. After an incident the operator cannot tell which commands were legitimate, which sites were touched or when the attack began.

Principle. Every command is attributable to a person and recorded where the operator can keep and query it.

Design measures.

  1. Log operator identity, source address, target sites and the before and after values for every command.
  2. Stream platform logs to the operator’s own monitoring, outside the vendor’s control.
  3. Protect logs against deletion and alteration by platform administrators.

Mappings: STRIDE R · CAPEC-268 · CWE-778, CWE-223 · ATT&CK for ICS T0872 · CIE 6, 8

BKS-FM-2 · Nobody knows what the fleet runs

The platform’s inventory does not reliably record which firmware, model and exposure each site has. When a vulnerability is announced, the operator cannot say which sites are affected, so it either disconnects everything or guesses, and the guess is slower than the attacker.

Case: Supermarket refrigeration attacks, 2026.

Principle. The operator can answer which sites run what, and how they are reached, within an hour.

Design measures.

  1. Keep an authoritative inventory of model, firmware and connectivity per site, reconciled automatically against the devices.
  2. Subscribe to advisories for every model in the fleet and match them to the inventory automatically.
  3. Record which sites are reachable from the internet, and why, as part of the inventory.

Mappings: STRIDE I · CWE-1104 · CIE 8

Public cases cited in this suit

© 2026 Jonathan Brett Crawley. Licensed under CC BY-NC-ND 4.0 with additional permissions: see the licence on the overview. † marks a physical-safety consequence.