--- title: "One ATM Was Contained. The Fleet Trust Path Was Not." description: "The final ATM assessment chapter: test remote support, software deployment, segmentation, monitoring, transaction integrity, containment, and reconciliation as fleet-wide control planes." date: 2026-09-03 author: Sevban Dönmez (@jankesec) canonical: https://jankesec.com/posts/atm-fleet-control-plane/ --- ## Fleet control planes in 60 seconds An ATM is one endpoint. Remote support, software deployment, secrets delivery, monitoring, asset inventory, and transaction routing are fleet control planes. A weakness in one terminal may be local; a weakness in a control plane can make every terminal the target of one identity, package, policy, or routing decision. The final assessment question is therefore: > Can the organisation constrain one compromised identity, package, terminal, or management > component to the smallest possible scope, preserve independent evidence, and return the fleet to > a reconciled state without trusting the compromised plane to certify itself? This chapter uses scoped test roles, synthetic packages, controlled network sinks, certification transactions, simulated health events, and tabletop recovery. It does not disrupt production terminals, move real cash, access cardholder data, or send unapproved transaction messages. ## The largest blast radius is usually outside the cabinet The terminal may have firmware protection, application control, least-privileged middleware, and strong physical controls. Those defenses can still be bypassed operationally if a remote-support role opens unrestricted sessions, a deployment service publishes broadly trusted packages, an inventory identity is duplicated, or monitoring accepts local “healthy” status after loss of trust. Control-plane security is not only authentication. It is target scope, approval, separation of duties, package integrity, policy integrity, network reachability, durable audit, rollback, containment, and reconciliation.

Fleet resilience depends on independent planes and a return-to-service gate that does not accept “healthy” from the recovered terminal alone.

## Phase zero: map ownership and failure domains Identify each control plane, its owner, technology, credentials, keys, network paths, data stores, dependencies, operators, vendors, and recovery process. Record which terminals and functions one role, package, policy, or service can affect. Build failure domains around real authority, not organization charts. A vendor account and a bank operator may enter through different portals but converge on the same management relay. Two deployment products may trust the same code-signing key. Inventory and monitoring may read from the same endpoint agent and therefore are not independent sources of truth. Define production-safe tests and stop conditions with the acquirer, terminal operator, switch operator, monitoring team, branch operations, vendors, and incident commander. Every active transaction test belongs in a certification environment with synthetic accounts. Every deployment test uses an inert package and a dedicated terminal group. ## Phase one: prove terminal identity An IP address, branch subnet, hostname, or locally stored identifier is rarely sufficient terminal identity. Document how the service, deployment, monitoring, and transaction planes authenticate the device. Determine which identities are unique, hardware- or key-bound, rotated, revoked, and reissued after replacement or recovery. Test duplicate, stale, missing, and newly enrolled identities through administrative simulation or a lab terminal. The expected outcome is an explicit rejection or quarantine with a useful event. If two control planes use different identifiers, prove the mapping and ownership between them. Recovery is the critical moment. A reimaged terminal should not automatically regain every capability because it returns from the expected address. Re-enrollment must establish current platform, software, policy, and operational ownership before trust resumes. ## Phase two: constrain remote support Remote support should require a named operator, phishing-resistant authentication where the platform supports it, approved device posture, per-terminal or narrow-group targeting, time-bound elevation, business approval, session recording, command or function restriction, and independent audit. Use a scoped test role. Request one approved terminal and one explicitly forbidden terminal or function. Verify that the second request is denied before a session begins and that monitoring can identify the operator, approver, target, source, duration, functions, and result. Test emergency access separately. Break-glass is a resilience mechanism, not a permanent broad role. It needs narrow custodianship, a declared incident, short expiry, stronger monitoring, and post-use review. If the platform cannot record the session, the compensating approval and network controls should become stricter, not weaker. Also test the relay and vendor boundary. The organization must be able to revoke one vendor, account, source, or terminal without disabling the entire support plane. Shared credentials and always-on inbound paths turn a support incident into fleet risk. ## Phase three: treat software distribution as production authority The deployment system can deliberately introduce trusted code at scale. Map package creation, source review, build provenance, signing, storage, approval, targeting, scheduling, delivery, installation, policy change, rollback, and final reconciliation. Separate the ability to create, sign, approve, and target a package where practical. Verify that a valid signature does not allow an operator to deploy any signed package to any terminal. Code identity, approved version, target group, maintenance window, and change record should agree. Use inert packages to test wrong target group, expired approval, unexpected version, duplicate delivery, interrupted installation, rollback, and compromised health reporting. No package needs payload behavior. The policy decisions and resulting inventory prove the boundary. Limit blast radius operationally. Canary groups, staged rollout, concurrency bounds, automatic stop conditions, health gates, and independent rollback reduce the chance that one bad but validly signed change becomes an estate-wide outage. ## Phase four: validate segmentation with identity and flows Network segmentation is the enforced set of permitted flows, not a diagram or VLAN label. Create an allowlist for each terminal class and plane: transaction, management, deployment, monitoring, time, name resolution, key or certificate services, and explicitly approved dependencies. Test expected flows first, then low-impact negative connections to organization-controlled sinks. Verify denied east-west terminal paths, undeclared internet egress, branch-to-management shortcuts, and cross-plane access. Record DNS, proxy, firewall, service-mesh, and terminal telemetry. Identity should strengthen segmentation. A packet from the correct subnet is not proof of a known, healthy terminal. Conversely, a known terminal should not receive every route when its platform or software state is untrusted. Network policy and health policy need a documented relationship. Design quarantine before an incident. A quarantined terminal may need to send logs, receive time, reach a known-good recovery service, and communicate with an incident channel while service, deployment, and transaction authority are denied. “Disconnect everything” can destroy evidence and make controlled recovery harder. ## Phase five: make monitoring independent and actionable For every control-plane test, pair a prevention assertion with a detection assertion. Monitoring should identify the terminal, operator or service, control plane, action, policy, result, trusted time, and relevant correlation identifier. Test missing signals as well as bad signals. A terminal that stops attesting, logging, inventorying, or reconciling should not remain healthy indefinitely. Define heartbeat intervals, grace periods, severity, owner, degraded capability, and escalation. Exercise one simulated event from firmware, application control, middleware, remote support, deployment, network policy, and transaction reconciliation. Verify alert routing, triage context, containment decision, evidence preservation, and closure. A dashboard event without an owned response is not an operational control. Monitoring administration must also be protected. If a deployment or support administrator can silence alerts, change retention, and erase evidence without separate approval, the planes are not independent. ## Phase six: test transaction integrity in certification The transaction plane should authenticate terminal identity, protect message integrity, enforce freshness and sequence, handle duplicates, bind business authorization to the intended operation, and reconcile partial outcomes. Use only synthetic accounts and the acquirer's certification environment. Test stale, duplicate, out-of-order, timed-out, cancelled, and interrupted sequences. Observe which component owns final state and how local, switch, and issuer records converge. Stop at the protocol decision; do not attempt real value movement. Separate business authorization from local capability. A device being able to perform an action does not mean the switch authorised it. A switch approval does not prove the terminal completed it. The system needs explicit state transitions and reconciliation for both directions. ## Phase seven: rehearse containment and return to service Choose one lab or designated test terminal and simulate loss of trust. The operator should be able to remove remote-support, deployment, and transaction authority while preserving monitoring and a narrow recovery channel. Capture an evidence package: terminal identity, current and expected firmware, boot state, application policy, software versions, service history, deployment history, network flows, middleware events, transaction state, and trusted timestamps. Hash and preserve it according to the organization's incident process. Restore from a known-good source, rotate affected credentials or certificates, re-enroll identity, reapply policies, verify monitoring, and reconcile business state. The return-to-service gate should require independent agreement from platform health, configuration, inventory, monitoring, network policy, transaction owner, and operational owner. Then test fleet scope. Determine whether the same identity, package, key, role, or indicator exists elsewhere and whether the organization can query and contain it without touching unrelated terminals. ## Evidence matrix | Signal | What it proves | Safe negative control | Defender verification | | --- | --- | --- | --- | | Test support role reaches an out-of-group terminal | Support identity has a broader blast radius than its task | Request one explicitly forbidden lab target and stop at denial | Enforce per-terminal scope, approval, expiry, recording, and alerting | | Validly signed inert package can target an unapproved fleet group | Signing is being treated as deployment authorization | Submit wrong-group metadata through the test workflow | Separate sign, approve, target, stage, health gate, and rollback decisions | | Terminal is trusted by subnet or address after reimage | Network location substitutes for current device identity and health | Simulate stale or re-enrolled identity on a lab unit | Bind access to unique identity, current posture, and controlled enrollment | | Monitoring silence leaves the terminal healthy | Absence of evidence is being treated as evidence of health | Suppress one approved test heartbeat or use a simulator | Enforce grace period, degraded capability, owner, alert, and reconciliation | | Quarantine removes evidence and recovery paths with transaction access | Containment is improvised rather than engineered | Apply the lab quarantine policy and enumerate remaining allowlisted flows | Preserve logs, time, incident channel, and known-good recovery only | | Synthetic duplicate or timeout cannot be reconciled across terminal and switch | Business state has no authoritative resolution path | Run certification-only duplicate, cancel, and timeout cases | Correlate identity, sequence, decision, device result, and final ledger state | | Recovered terminal returns while inventory, policy, or monitoring disagrees | Availability is being mistaken for restored trust | Execute the approved lab recovery and compare every source | Require multi-owner reconciliation before customer service resumes | ## What a finding should look like > The scoped remote-support role could initiate a session on a lab terminal outside its approved > branch group. Strong authentication succeeded, but the platform did not require target-specific > approval, and monitoring recorded only the shared relay identity. No production terminal, > payment data, device operation, or transaction was accessed. Compromise of one support identity > would therefore have fleet-wide reach and weak attribution. Enforce terminal-group scope, > just-in-time approval, operator identity propagation, session recording, independent alerting, > and a regression test for denied out-of-group access. Strong authentication did not fail. Authorization, scope, and attribution did. That distinction makes the remediation precise. ## What I would not call proof - A network diagram presented as enforced segmentation. - MFA presented as complete remote-access control. - A signed package presented as authorised for every target. - A green endpoint heartbeat presented as platform integrity. - Local “healthy” status accepted after the local trust boundary failed. - A blocked test without evidence that security operations saw and handled it. - A production transaction used where certification state could prove the same control. - A recovered terminal returned to service before business and technical state reconcile. ## Defender priority order **First, minimise fleet-wide authority.** Scope support roles, deployment targets, keys, relays, and network routes so one compromise cannot address the estate. **Second, separate control planes.** Support, deployment, monitoring, inventory, and transaction systems need independent identities, policies, and evidence wherever possible. **Third, make health affect access.** Missing or untrusted evidence should produce a bounded degraded state, not indefinite normal operation. **Fourth, pre-engineer quarantine.** Preserve evidence and known-good recovery while denying the planes that could expand impact. **Fifth, gate return to service on reconciliation.** Technical health, business state, ownership, and monitoring must agree. ## Closing thought The ATM series began with a locked cabinet and ended outside it. That is the point. Platform trust, kiosk containment, device authorization, remote service, deployment, monitoring, and transaction integrity form one system even when different teams and vendors own the parts. The best assessment does not prove that one terminal can be made unsafe. It proves whether the organisation can stop one unsafe condition from becoming a fleet event—and whether it can restore trust without guessing. ## Public sources and standards context - [NIST SP 800-46 Rev. 2 — Enterprise remote access security](https://csrc.nist.gov/pubs/sp/800/46/r2/final) - [NIST SP 800-207 — Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) - [NIST SP 800-61 Rev. 3 — Incident Response Recommendations](https://csrc.nist.gov/pubs/sp/800/61/r3/final) - [NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment](https://csrc.nist.gov/pubs/sp/800/115/final) - [PCI Security Standards Council — Standards overview](https://www.pcisecuritystandards.org/standards/) - [PCI Security Standards Council — ATM Security Guidelines](https://listings.pcisecuritystandards.org/pdfs/PCI_ATM_Security_Guidelines_Info_Supplement.pdf) Applicable requirements depend on the ATM program, acquiring model, payment environment, vendor architecture, and jurisdiction. Confirm production authority and certification paths before any active validation.