How an ATM Is Made: Safe, Dispenser, PC Core, XFS and PIN Pad

An ATM is made by bolting a burglary rated safe that holds the cash dispenser and cassettes under a "top hat" that holds an ordinary PC, a card reader, a PCI approved encrypting PIN pad, a receipt printer and a screen. The PC runs Windows, CEN/XFS or XFS4IoT middleware and the bank's application, and every one of those layers needs signed, scheduled updates.

This post walks through that build from steel to a live machine on a wall, then spends most of its length on the part that decides whether the machine stays safe after installation: the software stack and how it is kept current. It sits next to our build of a card payment terminal, which covers PCI PTS testing, tamper response and EMV kernels in detail (we do not repeat it here), and our guide to Windows 10 end of support on machines, kiosks and controllers, which covers the wider fleet problem. The keys an ATM uses are anchored in a processor's hardware security module.

Facts below come from PCI SSC, CEN, the European Association for Secure Transactions (EAST), UL, BSI, the US Access Board, Microsoft, NIST and the US Department of Justice. Threats are described only at the level official advisories use.

Key takeaways

• An ATM is two machines in one cabinet: a safe holding cash and the dispenser, and a head compartment ("top hat") holding a general purpose PC and the customer facing devices.
• The safe is rated under UL 291 (US) or EN 1143-1 (Europe). The PC compartment is not a safe and is the main target for logical attacks.
• The encrypting PIN pad (EPP) is the only part with a PCI device approval. There is no PCI certification for a whole ATM, only the 2013 PCI ATM Security Guidelines.
• The software stack is Windows, the maker's device service providers, CEN/XFS 3.x or XFS4IoT middleware, and a multivendor application that talks to the bank's host.
• XFS4IoT (CWA 17852) uses JSON over WebSockets with TLS and defines end to end (E2E) tokens so the dispenser only obeys dispense commands the host authorised.
• EAST lists 15 countermeasures against ATM malware and black box attacks, from head compartment monitoring to disk encryption, authenticated boot, application control and E2E authentication.
• Windows 10 IoT Enterprise LTSC 2021 leaves mainstream support on 12 January 2027 and extended support on 13 January 2032.

From steel to a live ATM: the step table

An ATM is assembled from subassemblies made by different specialist lines, and some are certified separately before they ever meet. The table follows one machine from raw material to first withdrawal.

Only some steps carry a certificate (safe grade, EPP approval, EMV approvals). The software image, PC hardening and application are governed by the deployer's own process and industry guidance. And the machine is not finished at the factory: steps 10 to 13 happen at the bank, installer and service company, so the final machine's security depends on several organisations.

What is inside an ATM?

Open the front of a typical through the wall ATM and you see two zones. The lower zone is the safe. The upper zone, which the industry calls the head compartment or top hat, holds everything the customer touches and the computer that runs it all. EAST's countermeasure list starts with exactly this split: "Ensure physical protection of the ATM head compartment," because that is where the PC lives.

The safe and its certification grades

The safe protects the cash and the dispenser mechanism. Two standards dominate.

UL 291, Automated Teller Systems. UL Standards and Engagement lists UL 291 as active, Edition 6, published 15 February 2012 and last revised and ANSI approved on 26 November 2025. Its scope covers "the construction and security of equipment intended to automatically dispense currency" and "a limited degree of protection against unauthorized removal of currency," with the same protection for deposits where the machine accepts them. The cabinet label shows the level tested; insurers usually set the level a site needs.

EN 1143-1, secure storage units. BSI lists BS EN 1143-1:2019 as current (published 30 April 2019). It classifies burglary resistance of safes, ATM safes, ATM bases, strongroom doors and strongrooms. Tool attack tests measure resistance to complete access, and for ATM safes also to partial access, expressed in resistance units that set the grade, with optional explosive (EX), gas explosive and core drilling tests. BSI notes the 2019 edition deleted the construction requirements for ATM safes of grade L, and that the standard does not cover ATM systems as a whole.

EAST's physical attack terminology separates explosive attacks, in situ burglary (torch cutting, drilling, cutting, forcing, door rip outs), rip out theft and robbery. A higher safe grade buys time against those. It does nothing against logical attacks in the top hat, which is where the rest of this post focuses.

Cash dispenser and cassettes

Inside the safe sits the dispenser: a pick module that pulls notes from each cassette, sensors that catch double picks, a transport, a reject bin and a presenter that pushes notes through the shutter. Cassettes are lockable boxes swapped during replenishment; recyclers also accept notes and pay them back out.

The dispenser has its own controller and firmware and obeys commands from the PC over a cable inside the cabinet. XFS4IoT spells out the risk: dispensing is "authorized by an authorizing host which represents the owner of the cash," but the request passes through the client application, the XFS service and finally the device, and "any part of that process is vulnerable to an attack which could lead to the wrong amount of cash being dispensed." The safe protects the cash; only cryptographic protection of that command path protects the dispense decision.

Card reader

ATMs use motorised, dip or contactless readers, often combined. Readers are a favourite target for skimming devices, so they carry anti skimming features, and the XFS4IoT status interface reports an anti fraud module state such as "ok" or "deviceDetected" (a foreign device is present). The chip interface carries EMV Level 1 approval and the kernel software EMV Level 2; our card terminal post covers both.

Encrypting PIN pad

The EPP is a sealed secure module with its own processor, key storage and tamper sensing. The customer types the PIN on the EPP keypad, the EPP formats and encrypts the PIN block inside its boundary, and only the encrypted block ever reaches the PC. PCI SSC's PTS POI page lists among the device types it approves "Encrypting PIN pads (EPPs) that require integration into other devices such as ATMs," and names ATMs in the intended audience. The EPP is therefore the one ATM component you can look up on the PCI approved PTS device list.

Receipt printer, screen and camera

The printer, screen, function keys, audio jack and camera are ordinary peripherals behind XFS device classes. Each has a driver, and often firmware, so each is part of the attack surface.

PC core

The PC core is an industrial x86 motherboard with storage, a Trusted Platform Module (TPM) and USB and serial ports to the devices. It runs Windows. It is a general purpose computer in a cabinet whose lid opens with a key, which is the root of most logical attack risk. The DOJ's January 2026 announcement of charges in a US jackpotting case describes suspects opening "the hood or door of ATMs" before tampering with the PC's storage.

Sensors

ATMs carry sensors for the safe door, the head compartment door, vibration, heat, tilt and the anti skimming module, and they report through the sensors and indicators unit (SIU) device class in XFS 3.x and equivalent interfaces in XFS4IoT. EAST's second countermeasure is "ATM Monitoring regarding opening of the head compartment and loss of communication to security relevant devices." A sensor that is fitted but not monitored is decoration.

How is an ATM built and certified?

The ATM is certified piece by piece, and the pieces are certified by different bodies.

Assembly and safe certification

The safe, dispenser and top hat are built on separate lines and joined on the final line, where the maker loads a factory image and runs functional tests. The result is a working ATM with no bank application and no production keys. The safe design is type tested once under UL 291 or EN 1143-1, and production units carry the label for the tested level or grade.

PCI PTS for the PIN pad

The EPP goes to a PCI recognised laboratory for evaluation against PTS POI. PCI SSC published PTS POI v7.0 on 29 May 2025 with 59 requirement changes and 23 pieces of additional guidance, and its announcement says the standard "enhances security controls to defend against physical tampering and the insertion of malware." One v7.0 change requires terminal security keys such as firmware authentication keys to have an effective key strength of 128 bits or more. The card terminal post covers the evaluation and listing process; for an ATM the key point is that only the EPP (and, where used, a secure card reader) carries this approval.

PCI ATM Security Guidelines

PCI SSC published the ATM Security Guidelines Information Supplement on 30 January 2013. Its press release says it gives "guidance to ATM manufacturers" on security steps "to help prevent card data compromise at ATMs" and organises best practice around four areas: integration of hardware components to stop magnetic stripe compromise and PIN stealing, security of basic software, device management through manufacturing, storage and deployment, and ATM application management. The same release is explicit that the supplement "does not replace or supersede the PCI Standards, nor is it to be used as a set of security requirements for the formal certification of ATMs." In other words, there is no PCI certificate for a whole ATM. The release also points out that PTS POI provides the testing and approval of encrypting PIN pads and secure readers used in ATMs.

EMV approvals

The reader's interfaces need EMV Level 1 approval and the kernel software Level 2. The deployer and acquirer then run Level 3 (brand) testing of the whole configuration.

Accessibility

In the US, ATMs must meet section 707 of the 2010 ADA Standards, published by the US Access Board. It requires speech output for prompts, input verification, error messages and "all displayed information," through a mechanism such as an industry standard connector. Speech must be repeatable, interruptible and volume controlled, numeric keys must use a 12 key telephone style layout with a tactilely distinct five key, and speech users must get the same privacy as anyone else. Those rules shape the EPP keypad, the audio hardware and the application's screens.

What software runs on an ATM?

The software stack has five layers. Each comes from a different supplier, and each has its own update cadence.

A Windows based PC core, often on a long term servicing edition

ATMs run Windows largely because XFS 3.x is a Windows API and the makers' device drivers were written for it; making the interface "Operating System Agnostic" is one of XFS4IoT's stated goals. Microsoft's IoT Enterprise LTSC editions are a natural fit, because they receive security updates for many years without forced feature upgrades, which keeps a tested stack stable. Some fleets run standard Enterprise editions instead, and that choice decides their support dates.

CEN/XFS 3.x

XFS (eXtensions for Financial Services) is published by the CEN workshop on XFS as CEN Workshop Agreements. Release 3.40 is CWA 16926, with one part per device class (card reader, PIN pad, cash dispenser, sensors and indicators, vendor dependent mode and others); the card reader part, for example, is CWA 16926-4:2022, published 21 December 2022. In XFS 3.x the application calls a Windows API and a manager routes calls to the maker's service providers. Its binary data structures, the XFS4IoT authors later wrote, made new functionality "difficult due to compatibility issues."

XFS4IoT, the successor

XFS4IoT is published as CWA 17852; the 2024-03 release is issued as CWA 17852:2025. Its scope states that XFS4IoT "has been identified as a successor to XFS 3.x" and lists requirements including replacing the XFS and J/XFS standards, being "Operating System Agnostic," supporting multiple vendors' hardware, and supporting "end to end application level security."

The architecture is different from 3.x in ways that matter for security:

• JSON over WebSockets. Applications discover services on known ports and exchange JSON messages over WebSockets (RFC 6455), on one machine or across a network.
• TLS by default. The specification says "all connections in XFS4IoT should use the wss scheme using TLS encryption," with one exception: where the connection between client and service "can be physically secured, for example inside an ATM enclosure," clear communication is possible "and it is the responsibility of the hardware vendor to ensure that this is sufficient." Trust should not depend on vendor issued certificates; a bank's own certificate authority is one option.
• No compound devices. One service can expose several interfaces; a recycler exposes Common, CashManagement, CashAcceptor, CashDispenser and Storage.
• Device inventory in the protocol. Each service reports device information including model, serial number, firmware name and version, hardware revision and software name and version, and an endToEndSecurity status. That makes automated inventory far easier.
• A defined vendor mode. Maintenance or supervisor functions run under a Vendor Mode service, which the specification says "usually require operator intervention." Entry and exit are coordinated, so maintenance is a recorded state.
• A path from 3.x. A "3.x Migration" chapter covers each device class.

The multivendor application

On top of the middleware sits the ATM application: the screens, the transaction flow, the language and accessibility features, journaling and the host messaging. Because XFS abstracts the hardware, a deployer can run one application on machines from different makers, which is why it is called multivendor. Deployers also add security software in this layer, such as application control, device blocking and monitoring agents.

Host protocols to the processor

The application talks to the deployer's host or processor over the network using an ATM message protocol agreed between the application and the host, and the host connects to card networks with its own interbank messaging. For the ATM side, EAST's countermeasure 13 sets the expectation: "Encrypt network traffic via Transport Layer Security (TLS), enable MACing for transaction and apply networking security best practises like network segmentation." Message authentication codes on the host messages, keyed from the EPP, let the host detect tampering with a transaction in transit.

How does the encrypting PIN pad handle keys?

The EPP is the ATM's cryptographic anchor. It holds keys that encrypt PIN blocks, authenticate host messages, and in XFS4IoT, authenticate the end to end security tokens for the dispenser.

Initial key loading

The traditional approach loads a terminal master key into the EPP in a secure environment under dual control and split knowledge: no single person sees a whole key, and each key component is entered by a different custodian. PCI PIN Security, assessed by Qualified PIN Assessors, governs how acquirers and their agents handle these keys. The host then sends working keys encrypted under the master key.

Remote key loading with certificates and TR-34

Modern EPPs also support remote key loading (RKL). The XFS4IoT KeyManagement interface documents three RKL methods: using signatures, using certificates, and using X9 TR-34. Under TR-34 (the specification references TR34-2019), the EPP and the host first exchange a BIND token, which the specification calls "a prerequisite for all other TR34 operations"; after that, symmetric keys travel in TR-34 KEY tokens using either a one pass or a two pass protocol, and the EPP advertises which it supports. As in payment terminals, the EPP holds a key pair and certificate from manufacture, and new keys are wrapped so only that EPP can unwrap them.

XFS4IoT also lists X9.143 key blocks (versions A to D), which bind each key to its permitted usage.

PIN block formats and the move from TDES to AES

PIN blocks are defined by ISO 9564-1. XFS4IoT's PinPad capabilities include "ISO 9564-1: 2017 Format-4," which it describes as using AES encryption, alongside older Triple DES based formats, and its PIN block algorithm list includes AES, DEA, RSA and Triple DEA. X9's AES DUKPT standard, ANSI X9.24-3-2017, derives a unique transaction key from an initial key and a transaction counter, with AES-128, AES-192 or AES-256 initial keys; XFS4IoT includes DUKPT commands and a DUKPT key serial number event. Triple DES PIN blocks and key hierarchies are being replaced by AES; the migration deadlines sit in PCI PIN Security and card brand rules, so confirm the dates for your network there.

Why the PIN never meets the PC in clear

The keypad is wired into the EPP's secure boundary. The PC can ask the EPP to collect a PIN and return an encrypted PIN block, but it cannot read keystrokes. That is why PCI approval covers the EPP and not the PC: the PC is untrusted for PINs. XFS4IoT E2E security extends the same thinking to the dispense decision.

What are logical attacks on ATMs?

This section stays at the level of public advisories and standards. It explains categories and controls, not methods.

Categories that official bodies use

EAST's Expert Group on All Terminal Fraud groups the logical threats as black box and malware attacks, and its countermeasures page lists them as "Jackpotting, Man-in-the-Middle, Software skimming," applying to "both online (onsite and remote) and offline attacks."

• Black box attacks. An unauthorised device is connected directly to the cash dispenser, bypassing the ATM's PC, to send dispense commands. The defence is to make the dispenser refuse commands that are not cryptographically authorised.
• Malware jackpotting. Malicious software on the ATM PC issues dispense commands through the normal middleware. The DOJ's 26 January 2026 announcement of an additional indictment in a Nebraska case, bringing the total to 87 defendants, said the malware's "primary purpose was to issue unauthorized commands associated with the Cash Dispensing Module." The release describes physical access to the head compartment and tampering with the PC's storage or connecting an external device, and malware designed to delete evidence of itself.
• Man in the middle. Traffic between the ATM and its host, or between the PC and a device, is intercepted or altered.
• Software skimming. Malware on the PC captures card data as it passes through.

The common thread is that each attack either uses the PC compartment's general purpose computer or bypasses it to reach a device directly. None of them breaks the safe. That is why the controls below are mostly about the top hat, the software stack and the device links.

The controls, mapped to EAST's countermeasures

EAST publishes 15 numbered countermeasures and uses them in its fraud alerts to show which apply to each attack. The table maps them to the ATM component they protect and to the standard or feature that implements them.

Why E2E security changes the model

Countermeasure 15 is the one that removes trust from the PC. XFS4IoT says it "has been designed to block attacks at any point between the authorizing host and the dispenser hardware." The host issues a token for each authorised dispense; the token travels through the application and middleware to the dispenser, which checks it with a key it shares with the host. Tokens carry a nonce, so the device can reject a replayed token, and an HMAC, so it can reject an altered one; the specification defines errors such as "invalidTokenNonce" and "invalidTokenHMAC."

The specification also closes the obvious bypass. When E2E security is enforced, "sensitive commands with no token defined will be blocked from executing," because otherwise someone could use another command that moves cash, such as a test command, instead of the protected dispense command. A dispenser that enforces E2E reports "required": "always" in its endToEndSecurity status. Query that field and record it in your inventory.

E2E does not make the PC irrelevant. Malware on the PC can still disrupt service, show fake screens or attempt software skimming. Layer it with the other countermeasures.

Firmware and boot hardening from NIST guidance

NIST SP 800-147 (April 2011) gives guidelines for "preventing the unauthorized modification" of BIOS firmware on PCs, and NIST SP 800-193 (May 2018) covers firmware resiliency: protection, detection of corruption and recovery. For an ATM that means authenticated firmware updates, a locked boot order, unique vaulted firmware passwords, and Secure Boot with the TPM used for measured boot and disk encryption.

Microsoft's BitLocker documentation describes the threat of someone "transferring the device's hard drive to a different device," the pattern in the DOJ release, and says a TPM lets BitLocker check that the device "hasn't been tampered with while the system is offline." Microsoft's App Control for Business documentation argues that relying only on detecting known bad files is not enough when new ones appear daily, which is the case for the allow listing that EAST's countermeasure 8 asks for.

How are ATM software and OS lifecycles managed?

ATMs live in the field for many years, often longer than the operating system they shipped with, so OS end dates tend to set the timetable for large ATM software projects.

The dates that matter

The table uses Microsoft's lifecycle pages. Microsoft lists end dates as the US Patch Tuesday on which support ends.

Windows XP is history, but its April 2014 end of support is the standing reminder that ATM fleets outlive their operating systems. The pattern repeats with Windows 10 Enterprise, retired on 14 October 2025. LTSC 2021 machines are better placed, with security updates until January 2032, though mainstream support ends in January 2027.

LTSC choices

LTSC trades new features for stability, which suits ATMs, where every OS change means regression testing of drivers, middleware, the application and often brand testing. The cost is that new hardware may need a newer LTSC release. Plan the next OS migration when you buy hardware, not when the end date appears in a vulnerability report.

Remote management and update windows

Deployers manage fleets with a software distribution system that pushes packages to machines in scheduled windows at low usage times and stages them so a bad update affects a small group first. EAST's countermeasures 3 and 5 set the expectation that the "whole ATM software stack" is updated frequently, with "a process for fast track deployment of security updates," and that updates are delivered securely "to prevent remote deployment of Malware." In practice that means:

• packages signed by the producer and verified on the ATM before installation;
• distribution servers treated as critical systems with strong authentication, because whoever controls them controls the fleet;
• an emergency path for urgent fixes that still keeps signing and testing;
• a record of exactly which version of each layer each machine runs, so an advisory can be matched to affected machines in minutes.

XFS4IoT adoption is a lifecycle project too: it touches every device service provider and the application, and estates will run 3.x and XFS4IoT side by side for years. Tie it to hardware refresh and OS migration.

ATM components, standards and controls in one table

Step by step: an operator's hardening and inventory check

These steps are for ATM deployers and their service providers. They are read only checks plus policy decisions; they do not change the machine. Make changes only through your maker's and software supplier's approved process, because changes to the stack can affect support and approvals. Run the PowerShell commands from an elevated session during a maintenance window, under your normal dual control procedure for opening the head compartment or logging on locally, or through your remote management tool.

1. Inventory the operating system

# Edition, version and build
Get-ComputerInfo -Property WindowsProductName, WindowsEditionId, OsVersion, OsBuildNumber

# Most recent updates installed
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, InstalledOn

Record the edition exactly. "Windows 10 IoT Enterprise LTSC 2021" and "Windows 10 Enterprise" have very different support dates, and the difference decides whether the machine still gets security fixes.

2. Inventory XFS, firmware and application versions

For XFS 3.x stacks, use the maker's tools or your monitoring agent to export the XFS manager version and each service provider's version. For XFS4IoT services, the Common capabilities and status messages carry the data you need. The CEN specification's example looks like this (values are the specification's placeholders):

{
  "common": {
    "serviceVersion": "1.3.42",
    "deviceInformation": [{
      "modelName": "AcmeModel42",
      "firmware": [{ "firmwareName": "Acme Firmware", "firmwareVersion": "1.0.1.2", "hardwareRevision": "4.3.0.5" }],
      "software": [{ "softwareName": "Acme Software Name", "softwareVersion": "1.3.0.2" }]
    }],
    "antiFraudModule": false,
    "endToEndSecurity": { "required": "always", "hardwareSecurityElement": true, "responseSecurityEnabled": "always" }
  }
}

Collect the same fields for every device on every machine, plus the application version and the EPP model and firmware so they can be matched against the PCI approved PTS device list.

3. Confirm dispenser communication and E2E security

Record the dispenser's endToEndSecurity "required" value. "always" means the dispenser enforces tokens. Any other value, or no E2E support at all, means tokens are not always required; ask your maker and software supplier for the plan to enable it. Also confirm with the maker that the link between PC and dispenser is encrypted and authenticated (EAST countermeasure 6), and how that is shown in their tools.

4. Check boot and disk protection

# Secure Boot enabled? Returns True when UEFI Secure Boot is on
Confirm-SecureBootUEFI

# TPM present and ready
Get-Tpm | Select-Object TpmPresent, TpmReady

# BitLocker status of the system drive
manage-bde -status C:

In firmware setup, confirm that booting from USB and network is disabled, that the boot order is locked and that the firmware administrator password is unique per machine and stored in your privileged credential vault. Do this through the maker's documented process.

5. Check application control and device blocking

# App Control for Business policies (Windows 11 2022 Update and later include CiTool)
CiTool --list-policies

# USB mass storage driver start type (4 means disabled)
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\USBSTOR' -Name Start

# Host firewall profiles and default inbound action
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction

If your fleet uses a different application control or device control product, export its policy state instead. The question is the same: does the machine run only known software, and does it refuse unknown storage devices?

6. Check the update channel

List the distribution servers each machine trusts, confirm that packages are signed and verified on the ATM, and confirm who can approve a package for release. Test the emergency path on a pilot group at least once a year.

7. Test tamper and door sensors

With the monitoring team watching, open the head compartment under dual control on a test machine and on a sample of live machines, and confirm the alert arrives with the right machine ID and time. Disconnect a non critical device during a maintenance window and confirm the "loss of communication" alert (EAST countermeasure 2). Record the test and its result.

8. Compare the inventory with your policy

Put the results in one file per fleet and compare it with your policy automatically. This short script reads a CSV export and flags machines that fail basic rules. It uses only the Python standard library.

import csv, datetime

# Extended support end dates from Microsoft's lifecycle pages
EXTENDED_END = {
    "Windows 10 IoT Enterprise LTSC 2019": datetime.date(2029, 1, 9),
    "Windows 10 IoT Enterprise LTSC 2021": datetime.date(2032, 1, 13),
    "Windows 11 IoT Enterprise LTSC 2024": datetime.date(2034, 10, 10),
    "Windows 10 Enterprise": datetime.date(2025, 10, 14),
}
today = datetime.date.today()

with open("atm-inventory.csv", newline="") as f:
    for row in csv.DictReader(f):
        problems = []
        end = EXTENDED_END.get(row["os_edition"])
        if end is None:
            problems.append("unknown OS edition")
        elif end <= today:
            problems.append("OS past extended support")
        elif (end - today).days <= 730:
            problems.append("OS support ends within two years")
        if row["e2e_required"] != "always":
            problems.append("dispenser E2E not enforced")
        for field in ("bitlocker_on", "secure_boot_on", "app_control_on", "usb_storage_blocked"):
            if row[field].lower() != "yes":
                problems.append(field + " is not yes")
        last_patch = datetime.date.fromisoformat(row["last_patch_date"])
        if (today - last_patch).days > 45:
            problems.append("no security update in 45 days")
        if problems:
            print(row["atm_id"], "; ".join(problems))

Run it after each inventory export and send the output to the people who own the fixes. The thresholds (two years, 45 days) are examples; set your own in policy.

Common mistakes

• ATMs on flat networks. An ATM that can reach the office network, or be reached from it, turns any office compromise into a fleet problem. Put ATMs on their own segment with only the host and management connections they need (EAST countermeasures 13 and 14).
• Default or shared BIOS and service passwords. One firmware password for the whole fleet is effectively no password once it leaks. Make them unique and vault them.
• Operating systems past support. Machines still on Windows 10 Enterprise or older editions no longer receive security fixes. Know which machines they are and what the plan is.
• Unencrypted disks. Without full disk encryption, anyone who can remove the disk can read and change it offline, which is the pattern described in public law enforcement releases.
• Service mode reachable without dual control. Vendor or supervisor mode should require operator intervention under a recorded process. XFS4IoT makes Vendor Mode a defined state, so log every entry and exit.
• E2E security available but off. A dispenser can support token based dispense authorisation without being configured to require it. Check the status field rather than the brochure.
• Monitoring that nobody tests. Door and device alerts that never reach a person are not a control.
• Treating the EPP approval as approval for the ATM. PTS POI covers the EPP. The rest of the machine is your responsibility, guided by the PCI ATM Security Guidelines and EAST countermeasures.
• No inventory of software versions. Without per machine versions for firmware, OS, middleware and application, you cannot answer "which machines are affected?" when an advisory lands.

FAQ

What operating system do ATMs run?

Most ATMs run Windows. Long term servicing editions such as Windows 10 IoT Enterprise LTSC 2021 and Windows 11 IoT Enterprise LTSC 2024 suit their long service lives. XFS4IoT is designed to be operating system agnostic, so other platforms are possible as the industry migrates.

What is CEN/XFS and what is XFS4IoT?

CEN/XFS is the standard interface between ATM applications and devices, published as CEN Workshop Agreements (release 3.40 is CWA 16926). XFS4IoT, published as CWA 17852, is its successor: JSON messages over WebSockets, TLS by default, and end to end security tokens for sensitive commands such as dispense.

Are ATMs PCI certified?

Not as a whole. The encrypting PIN pad is approved under PCI PTS POI, and key handling is governed by PCI PIN Security. PCI SSC's ATM Security Guidelines (2013) are guidance and state that they are not a set of requirements for formal certification of ATMs.

What safe rating does an ATM need?

That depends on the site and the insurer. In the US, ATMs are tested under UL 291; in Europe, ATM safes are graded under EN 1143-1, with optional explosive resistance testing. Ask your insurer and your maker which level or grade the site requires.

What is ATM jackpotting?

It is the term law enforcement uses for forcing an ATM to dispense cash without a legitimate transaction, either with malware on the ATM PC or with an unauthorised device connected to the dispenser (a black box attack). The main defences are head compartment protection and monitoring, disk encryption, authenticated boot, application control, device blocking and end to end authentication between the host and the dispenser.

How are ATM PIN pad keys loaded?

Either directly in a secure environment under dual control and split knowledge, or remotely using certificates and protocols such as X9 TR-34, in which keys are wrapped so that only the target PIN pad can unwrap them. AES DUKPT and AES PIN block formats are replacing Triple DES schemes.

When does Windows 10 IoT Enterprise LTSC 2021 support end?

Microsoft lists mainstream support ending on 12 January 2027 and extended support ending on 13 January 2032.

How do ATMs get software updates?

Through the deployer's software distribution system, which pushes signed packages in scheduled windows and stages them across the fleet. EAST recommends frequent updates of the whole software stack, a fast track path for security fixes and a secure delivery process.

Where Safeguard fits, honestly

Safeguard does not certify safes, test PIN pads, load keys, harden ATM operating systems, manage ATM fleets, scan firmware or generate hardware bills of materials, and it is not a PCI assessor or laboratory. It does not replace the maker's or the software supplier's update process, and nothing in this post should be read as Safeguard making an ATM or a deployer compliant.

The overlap is the software your teams build around the ATM. Monitoring dashboards, software distribution portals, host side services, XFS4IoT client integrations, the mobile apps that start cardless withdrawals and the back office services that process journals are applications with open source dependencies. If that code lives in repositories or container images, Safeguard can scan it (safeguard scan --dir . on a repository, safeguard scan --image with an image name), match components against vulnerability databases, rank findings with reachability analysis so the code paths your services actually call come first, evaluate policies and gates in CI, and open fix pull requests when you switch autonomous remediation on. The effect of reachability depends on the codebase and is worth measuring during an evaluation. Gold Open Source at gold.safeguard.sh gives free CVE intelligence with affected and fixed versions.

ATM security depends on knowing which software version runs where, and the services that distribute and monitor that software are built from open source dependencies like any other application. Keeping those dependencies current is the indirect but real part of the chain where the practices below apply.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session asked to fix a lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow applies to a JavaScript fleet monitoring dashboard or a software distribution portal that your team maintains for its ATM estate.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Banks that keep ATM host integration code inside their own network can scan it locally in the same way.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. A team asking an assistant about its ATM back office services can limit it to the read and scan tools it needs.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• PCI SSC, PTS Point of Interaction (POI)
• PCI SSC, PIN Security
• PCI SSC blog, Just Published: PTS POI v7.0
• PCI SSC press release, PCI Security Standards Council Publishes ATM Security Guidelines (30 January 2013, PDF)
• CEN, CWA 17852:2025, XFS4IoT Specification, 2024-03 release (PDF)
• BSI Knowledge, CWA 16926-4:2022, XFS Release 3.40 Identification Card Device Class Interface
• EAST, Countermeasures against ATM Malware and Black Box Attacks
• EAST, Terminal Physical Attack Definitions and Terminology
• EAST, Terminal Fraud Definitions
• UL Standards and Engagement, UL 291 Automated Teller Systems
• BSI Knowledge, BS EN 1143-1:2019 Secure storage units: safes, ATM safes, strongroom doors and strongrooms
• EMVCo, What are EMV Level 1 and Level 2 Testing?
• X9, X9.24 Part 3 Test Vectors for AES DUKPT
• US Access Board, ADA Accessibility Standards, section 707 Automatic Teller Machines and Fare Machines
• Microsoft Learn, Windows 10 IoT Enterprise LTSC 2021 lifecycle
• Microsoft Learn, Windows 10 IoT Enterprise LTSC 2019 lifecycle
• Microsoft Learn, Windows 11 IoT Enterprise LTSC 2024 lifecycle
• Microsoft Learn, Windows 10 Enterprise and Education lifecycle
• Microsoft Learn, Windows XP lifecycle
• Microsoft Learn, BitLocker overview
• Microsoft Learn, App Control for Business
• NIST SP 800-147, BIOS Protection Guidelines (April 2011)
• NIST SP 800-193, Platform Firmware Resiliency Guidelines (May 2018)
• US Department of Justice, Investigation into International ATM Jackpotting Scheme results in Additional Indictment and 87 Total Charged Defendants (26 January 2026)

Last reviewed: 25 October 2026. Standards and lifecycle dates change; check the linked PCI SSC, CEN and Microsoft pages before you plan around a specific version or date.