Series · 5 partsATM Security AssessmentPart 4 · You are here
- 1The ATM Was Locked Down. The Transaction Path Was Not.
- 2The BIOS Had a Password. The Boot Chain Still Needed Trust.
- 3The Desktop Was Hidden. The Execution Boundary Was Not.
- 4The Device API Was Standard. Authorization Was Assumed.You are here
- 5One ATM Was Contained. The Fleet Trust Path Was Not.
Device authorization in 60 seconds
Financial-service middleware makes specialised devices usable through common interfaces. That interoperability is operationally valuable, but a standard request format does not answer the security question: who is allowed to ask, in which transaction state, for which terminal, and with what evidence?
The dangerous assumption is that a process may use a device because it can reach the local broker. Connectivity becomes authority. The better invariant is:
A peripheral operation is accepted only when caller identity, application integrity, terminal state, transaction state, device identity, and policy all agree—and the decision is recorded outside the endpoint.
This methodology proves that invariant with emulators, vendor test modes, harmless status operations, and expected denials. It does not issue live cash commands, capture PIN material, alter cryptographic keys, retain card data, or publish command sequences for controlling deployed devices.
Middleware is a policy boundary
CEN XFS defines APIs and service-provider interfaces so applications can work with financial peripherals through an XFS Manager. The architectural value is separation: the application does not need vendor-specific logic for every device. The security risk is also separation: the policy decision may be split across the application, manager, service provider, driver, device, and upstream transaction system until no component clearly owns authorization.
A connection to the manager proves that two components can communicate. A successful open or status request proves that an interface exists. Neither proves that a sensitive operation was bound to the approved application or a legitimate transaction.
Phase zero: define capability classes and stop conditions
Create a capability catalogue before testing. Separate read-only status, customer-input handling, media movement, receipt output, sensor state, maintenance, cryptographic functions, and cash- affecting operations. Assign an owner, required caller, required business state, permitted environment, expected telemetry, and safe test substitute to each class.
The highest-risk capabilities should never be proven through a real-world effect. Use the vendor’s simulator, certification environment, or test mode. If none exists, validate the authorization decision at the broker or policy layer and record the lack of a safe validation environment as a testability gap.
Explicitly prohibit plaintext PIN collection, cryptographic-key access, real cardholder data, uncontrolled media movement, live cash state changes, destructive tamper events, and denial of service. Define a named device owner and switch operator who can stop the test and reconcile state.
Phase one: build the caller-to-capability graph
Inventory every client of the middleware: kiosk application, diagnostics, service tools, health agent, remote support, updater, recovery utility, and vendor components. Record executable identity, signer, account, integrity policy, local IPC endpoint, requested logical service, and reachable operation classes.
Then inventory the manager, service providers, drivers, device configuration, logical-to-physical mapping, and peripheral identifiers. Compare the deployed state with the approved baseline. A logical name that silently points to a replacement or diagnostic provider can change the authority model without changing the application.
Draw edges only when evidence shows reachability. Annotate each edge with the component that makes the authorization decision. If an edge has no named policy owner, the architecture is probably relying on location, process convention, or obscurity.
Phase two: validate caller identity at the broker
Test whether the manager or an adjacent policy component distinguishes the approved application from another local process with equivalent network or IPC reachability. Use a vendor harness or minimal inert client that requests only harmless status or an intentionally denied test operation.
Capture how the caller is identified: operating-system token, service SID, certificate, executable signer or hash, package identity, authenticated channel, broker-issued capability, or a combination. A process name, filesystem path, window title, or source address alone is weak identity.
Repeat the test across normal, maintenance, update, and recovery states. A diagnostic tool may legitimately need broader capability, but that authority should require a named operator, approval, limited terminal scope, expiry, and a stronger audit trail. A vendor tool installed on the host is not automatically an authorised caller.
Phase three: bind operations to transaction state
Caller identity answers who; it does not answer why now. A device operation should also depend on the terminal state and the expected transaction sequence.
Model a state machine for the approved workflow: session begins, input is collected, upstream authorization is requested, a bounded response is received, the relevant device action becomes eligible, completion is recorded, and business state is reconciled. Include timeout, cancel, partial failure, duplicate message, device unavailable, reboot, and network loss.
Use synthetic transactions and simulated devices. Submit a harmless request at the wrong state, repeat a previously completed request, present a stale authorization context, and interrupt a test sequence. The expected result is denial or a safe recovery state, not a device effect. Record whether the middleware, application, device, or upstream system owns each transition.
Rate and freshness belong to the policy. Even an approved caller should not be able to repeat a sensitive class indefinitely or reuse old state. Detection should identify unusual order, rate, caller, terminal, and outcome.
Phase four: protect service providers and configuration
Service-provider binaries and configuration translate abstract operations into vendor-specific device behavior. They therefore sit on the trusted path and need application control, protected storage, signed updates, least-privileged execution, and rollback governance.
Review who can replace a provider, edit logical service mapping, change device parameters, register a diagnostic component, or alter load order. Use inert configuration markers and signature checks; do not replace a production provider. Confirm that a lower-trust identity cannot place content in a directory later loaded by the manager or privileged service.
Test failure behavior with vendor-supported simulations: provider unavailable, invalid configuration, device mismatch, stale version, and partial initialization. The system should not fall back to an ungoverned provider or mark an unknown device healthy merely to preserve availability.
Phase five: keep the PIN domain separate
The encrypting PIN pad belongs to a dedicated security and compliance domain. The general host should not receive plaintext PIN material or gain cryptographic-key authority. PCI PIN Security governs secure PIN processing and key-management requirements; formal validation belongs with the qualified program and assessor responsible for those controls.
The pentest can still verify the host-side boundary. Confirm approved device identity and lifecycle state, authenticated communication where the architecture provides it, tamper status visibility, controlled replacement, and the absence of sensitive authentication data in application logs, support bundles, crash dumps, monitoring, or tickets.
Use synthetic input and vendor test modes. The safe claim is that an unapproved host caller cannot obtain plaintext PIN data or cryptographic capability, and that unexpected device state is denied and alerted. Never enter, retain, or report a real PIN to prove the boundary.
Phase six: make device identity and state authoritative
Logical service names are convenient, but the policy must ultimately refer to a known physical device and acceptable state. Compare peripheral serial or attested identity where available, firmware version, approval status, configuration, tamper state, replacement record, and terminal binding.
Test replacement and recovery workflows in the lab. A newly attached or reset device should not inherit trust solely because it appears at the expected interface. Enrollment should require an approved workflow and update inventory, monitoring, and ownership together.
For ordinary peripherals without a strong cryptographic identity, document the compensating controls: physical custody, port restrictions, signed firmware, configuration integrity, tamper detection, service approval, and frequent reconciliation. Do not describe a weak identity as a strong one.
Phase seven: correlate decision, effect, and reconciliation
The strongest evidence chain links the application request, caller identity, policy decision, service provider, device identity, device result, transaction state, and off-host record under one correlation identifier. If each layer logs a different clock and identifier, the organization may be unable to tell a legitimate retry from an unauthorised sequence.
Exercise denied requests, timeouts, simulated device faults, and recovery. Verify that monitoring shows what was attempted and what actually occurred. Then verify business reconciliation: a local success with an upstream failure must not leave ambiguous state, and an upstream approval with no device completion must follow a documented resolution path.
Evidence matrix
| Signal | What it proves | Safe negative control | Defender verification |
|---|---|---|---|
| Another local process reaches the manager and receives the same capability as the approved app | Local connectivity is being treated as caller authorization | Request harmless status or a denied test operation through a vendor harness | Bind policy to strong caller identity, app integrity, terminal, and operating state |
| Approved caller can request an operation outside the expected transaction state | Identity exists but business authorization is missing | Use a simulator to submit an out-of-order or stale request | Deny and correlate caller, state, sequence, freshness, policy, and result |
| Lower-trust identity can alter provider or logical-service configuration | Writable configuration can redirect trusted device authority | Place an inert marker or attempt a denied configuration change | Protect files, sign policy, record changes, and verify deployed mapping off-host |
| Unknown or replaced peripheral inherits the logical service’s trust | Logical naming is substituting for device identity | Use a vendor-approved replacement simulation | Require enrollment, approved state, inventory update, and terminal binding |
| PIN-domain state or sensitive data appears in general host logs | The cryptographic boundary leaks into a lower-assurance plane | Use only synthetic input and review approved test logs | Remove sensitive data, restrict diagnostics, and validate support-bundle handling |
| Device result, policy decision, and transaction record cannot be correlated | Operations cannot be reliably investigated or reconciled | Run a synthetic timeout, cancel, and duplicate sequence | Use common correlation, trusted time, terminal identity, and explicit final state |
What a finding should look like
In the vendor lab, an inert test client running under the standard kiosk account could request a harmless device state transition through the middleware broker without presenting the approved application’s identity or a synthetic transaction context. The broker logged the logical service but not the caller identity or policy decision, and central monitoring received no event. No cash operation, PIN input, key material, cardholder data, or production device was used. Device capability is therefore authorised by local reachability rather than caller and business state. Require a strongly identified client, operation-level policy, transaction-state binding, off-host decision logging, and a regression test using the same denied request.
The finding is about missing authorization, not the name of an API call.
What I would not call proof
- An XFS endpoint or logical service discovered on the host.
- A successful status query presented as evidence of cash-device control.
- A vendor-signed component assumed safe without file, configuration, and update governance.
- A process name presented as authenticated caller identity.
- A simulated result presented as a production transaction.
- A device effect with no linked policy decision or business reconciliation.
- PIN or cardholder data collected to increase severity.
Defender priority order
First, put authorization at the broker boundary. Validate caller, application integrity, operation, terminal state, transaction state, freshness, and rate.
Second, narrow every client. Diagnostics, monitoring, support, and update components need explicit capability sets rather than inherited local trust.
Third, protect providers and mapping. Signed binaries are not enough; configuration, load paths, logical-service mapping, and rollback need integrity.
Fourth, preserve the PIN boundary. Keep plaintext PIN and key authority outside the general host, and keep sensitive data out of diagnostics.
Fifth, reconcile every ambiguous outcome. The device, middleware, application, and upstream system must converge on one final state.
Closing thought
Standard interfaces make a complex ATM estate manageable. They do not make its operations authorised. The security boundary is the decision that connects a named caller and a fresh business state to one narrowly defined device capability.
If the architecture cannot show where that decision is made, the pentest has already found the most important question.
Public sources and standards context
- CEN-CENELEC — XFS workshop and releases
- CEN CWA 16926-61:2025 — XFS Manager command-programming reference
- PCI Security Standards Council — PIN Security
- PCI Security Standards Council — ATM Security Guidelines
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
Middleware versions, vendor implementations, device classes, and compliance obligations differ. Use the applicable specifications and vendor certification environment for the assessed estate.
How current is this note?
The latest source-review, content-update, or publication date is shown.
Primary public records were checked. Environment-specific behavior remains outside the claim unless separately reproduced.