Series · 5 partsATM Security AssessmentPart 2 · You are here
- 1The ATM Was Locked Down. The Transaction Path Was Not.
- 2The BIOS Had a Password. The Boot Chain Still Needed Trust.You are here
- 3The Desktop Was Hidden. The Execution Boundary Was Not.
- 4The Device API Was Standard. Authorization Was Assumed.
- 5One ATM Was Contained. The Fleet Trust Path Was Not.
Firmware trust in 60 seconds
A BIOS or UEFI password can stop an unauthorised person from casually changing a setting. It does not, by itself, prove that the ATM starts from an approved state. It says nothing about who can invoke the vendor recovery path, whether a reset is attributable, whether external boot is still possible, whether Secure Boot keys can be changed, whether storage unlock is bound to the measured platform state, or whether the security team learns that any of those things happened.
The stronger question is not “Can the password be bypassed?” It is:
Can the platform enter an unapproved boot state through any normal, service, recovery, update, or hardware-maintenance path—and if it can, will the estate prevent, detect, contain, and recover from that transition?
This part turns that question into a defensible test plan. It is designed for a vendor-approved lab terminal or a decommissioned unit with known ownership, recovery media, and rollback support. It deliberately omits master-password lists, board-level reset locations, EEPROM procedures, electrical manipulation, firmware flashing recipes, and instructions for defeating a deployed ATM. Those details would create an attack manual while adding little to the quality of the finding. The evidence that matters is the control decision at the trust boundary.
A password is a gate, not a root of trust
Firmware configuration passwords are useful. They should be unique or centrally governed, protected from default reuse, managed through an accountable lifecycle, and required before security-relevant settings can be changed. But the password sits inside a larger system.
That system includes the firmware code, mutable configuration, signing-key databases, boot-device policy, option ROMs, recovery behavior, update verification, rollback rules, the TPM, storage encryption, the operating-system loader, and remote health assessment. It also includes people: the field engineer who needs a supported recovery procedure, the team that holds recovery keys, the vendor that signs an update, and the security operator expected to notice loss of trust.
A terminal can therefore have a strong firmware password and still fail in several ways:
- the same service or recovery path that helps an engineer also resets a security control without strong identity, approval, or a durable audit record;
- boot order looks locked in the normal interface but a different supported operating state uses a weaker policy;
- Secure Boot is enabled, yet ownership of the platform key and allowed-signature databases is unknown or changes are not monitored;
- the operating system starts only from signed components, but an approved signature authorises a component the terminal baseline does not intend to trust;
- storage is encrypted, yet the unlock path is not coupled to the expected platform state or its recovery secret is too broadly available;
- the terminal records a configuration or integrity change locally, where the same loss of trust can erase the only evidence.
The test should not treat any one checkbox as proof. It should follow the chain from power-on to application readiness and require an independent assertion at each transition.
Phase zero: define the safe experiment
Firmware testing can change the state from which every other control depends. That makes the rules of engagement part of the technical control, not paperwork around it.
Use a lab terminal or decommissioned unit that matches the deployed model and baseline. Record the serial number, board revision, firmware version, expected configuration profile, storage state, TPM ownership, approved Secure Boot state, recovery-key custodian, and vendor-supported recovery procedure. Capture the original state through the management plane and locally before any negative control is attempted.
The stop conditions should be explicit. Do not proceed if the terminal contains production keys, real cardholder data, unreconciled cash state, customer connectivity, or a recovery path that has not been rehearsed by the owner and vendor. Do not perform destructive tamper testing or invent a board-level procedure. If the supported recovery method cannot restore the test unit, that is evidence about resilience and testability—not permission to experiment on production hardware.
For each test, predefine four expected results:
- the local prevention or recovery decision;
- the off-host event, with terminal identity and trusted time;
- the containment state if trust cannot be established;
- the method that returns the terminal to its approved baseline.
Without those expectations, a reboot that “worked” proves only availability. It does not prove integrity.
Phase one: inventory every authority over firmware
Start by mapping who can change what. The answer is rarely “the BIOS administrator.” Platform state may be influenced by the terminal owner, ATM vendor, motherboard vendor, operating-system deployment team, field service provider, firmware update pipeline, recovery-media custodian, and key-management team.
For each authority, record the identity mechanism, approval boundary, target scope, credential or key lifecycle, audit destination, and emergency process. Ask who owns the platform key and allowed signature databases; who can authorise a firmware package; who can place a terminal into recovery; who can retrieve a storage-recovery secret; and who is notified when any of those actions occurs.
This step exposes the most common design error: a control is technically enabled but nobody owns its lifecycle. “Secure Boot: On” is not enough if key enrollment, revocation, firmware servicing, and certificate rollover are unmanaged. “Password: Set” is not enough if a vendor recovery path is shared across the estate or cannot be attributed to one approved intervention.
The output should be an authority graph, not a screenshot collection. Every state-changing path needs a named owner and an independent evidence source.
Phase two: validate password and recovery semantics
The goal is to test whether configuration authority survives all supported operating states. Use only the vendor-approved workflow and test accounts or secrets issued for the engagement. The assessor does not need to discover a secret bypass to establish that the recovery design is weak.
First, verify that the password protects every security-relevant change the owner believes it protects: boot source, Secure Boot state, key enrollment, firmware update policy, device security, and recovery configuration. Then verify the failure behavior. Repeated invalid authentication should produce a bounded, documented response without creating an uncontrolled denial of service.
Next, review the legitimate recovery path as a privileged business process. Does it require a named identity? Is approval specific to one terminal and one maintenance window? Is the response unique or centrally governed? Does the action generate an off-host event before local state can be changed? Does recovery preserve or deliberately re-establish Secure Boot, boot-order, TPM, and storage-encryption policy? Can the organization distinguish a support intervention from tampering?
A recovery feature is not a vulnerability merely because it exists. It becomes a finding when it can cross the same security boundary with weaker identity, broader scope, missing telemetry, or an unsafe post-recovery default.
Phase three: prove the boot policy, including negative controls
The expected boot path should be written as a policy: approved firmware transfers control only to an approved boot source; that source presents an acceptable signed loader; the accepted key set is owned and governed; and failure does not silently continue through a weaker path.
In the lab, use benign, organisation-controlled media designed only to reveal the decision. One artifact can represent the approved baseline; another can be correctly formed but outside the terminal’s approved trust set. The result to capture is the firmware decision, not code execution. The unapproved artifact should be rejected before it gains authority, and the rejection or unexpected-source event should be visible off-host where the terminal cannot erase it.
Check every supported state: normal startup, authorised maintenance, vendor recovery, update failure, and return from service. A policy that holds only during ordinary boot is not a platform policy. Also verify that a change in boot-source priority, Secure Boot state, setup mode, or key database cannot occur silently and does not leave the machine operational as if it remained healthy.
Secure Boot provides signature-based enforcement, but signature validity and terminal approval are not identical. The platform may trust a broadly issued signing authority while the ATM estate intends to trust a much narrower image set. Document that gap and identify which later control—an allowlist, image measurement, attestation policy, or deployment gate—makes the trust set specific enough for the terminal.
Phase four: bind measured boot to a business decision
Measured boot is evidence, not prevention by itself. The TPM can record security-relevant measurements from firmware through early boot, but somebody must appraise those measurements and decide what an unhealthy terminal may do.
Capture the known-good measurement or attestation result for the approved baseline. Then use a vendor-supported, reversible configuration change in the lab to produce a different state. Verify that the remote verifier sees the difference, identifies the correct terminal, and applies the documented policy. Depending on the architecture, that may mean quarantine, blocked management actions, application refusal, or a maintenance-only state. It should not mean “the dashboard color changed while the ATM continued to be trusted everywhere else.”
Test freshness and identity as well as measurement content. A stored healthy result must not be reusable as proof for a later untrusted boot. The verifier must know which terminal produced the evidence, when it was produced, which baseline was used, and how baseline changes are approved.
Finally, test what happens when measurement evidence is missing. Loss of the attestation service, network, or agent should not automatically convert absence of trust into trust. The business may choose a bounded degraded state for availability, but that exception needs explicit duration, scope, alerting, and reconciliation.
Phase five: couple storage encryption to platform state
Full-disk encryption protects data at rest only if the unlock authority is as strong as the state it is meant to protect. On TPM-backed Windows systems, BitLocker platform validation can use TPM measurements, including Secure Boot state, when the system is correctly configured. The assessment should verify the terminal’s actual policy rather than infer it from the presence of an encryption icon.
Record the protector type, intended platform-validation profile, recovery-key owner, escrow location, retrieval approvals, rotation process, and audit destination. Use a reversible, vendor-supported lab change that is expected to alter the validated state. Confirm that automatic unlock no longer proceeds as though nothing changed and that the controlled recovery process is both available and attributable.
The negative control stops at the pre-boot decision. There is no need to extract a key, copy a volume, or access terminal data. A blocked automatic unlock, correlated with a changed platform state and an audited recovery workflow, is stronger evidence than opening a filesystem.
Also test the recovery operation as a high-value administrative action. If one support role can retrieve recovery material for every terminal, or if retrieval is invisible to the security team, the encryption may be technically correct while the control plane remains dangerously broad.
Phase six: test firmware update and rollback integrity
NIST’s platform-firmware guidance frames resilience around protection, detection, and recovery. The update channel has to satisfy all three. A firmware package should be authenticated before it is accepted, applied through an authorised process, protected against inappropriate rollback, and recoverable when installation fails.
Map the full path from vendor publication to terminal installation: package origin, signature verification, approval, staging, targeting, maintenance window, installation result, version inventory, rollback decision, and off-host audit. Validate the control with vendor-provided test packages or metadata in a non-production environment. The objective is to observe rejection of an unauthorised or out-of-policy update—not to construct a malicious firmware image.
Pay special attention to equivalence between update paths. A centrally managed package may be well governed while a local service workflow, emergency recovery image, or replacement board accepts a different trust set. Every legitimate path that can establish firmware state belongs in the same assurance model.
Recovery also needs a known-good target. “The terminal booted again” is not sufficient if the restored image is old, its signing keys are revoked, its security settings are defaults, or the management plane still believes the previous version is installed. Recovery is complete only when local state, remote inventory, attestation, storage policy, monitoring, and operational ownership agree again.
Phase seven: make physical and firmware events remotely visible
Physical access changes the threat model, but it should not erase the defender’s view. The test should verify vendor-supported chassis, service-door, boot-policy, recovery-entry, configuration, TPM, and firmware-update events without performing destructive manipulation.
Each event needs terminal identity, event type, result, trusted time, operator or workflow identity where available, and enough context to distinguish planned service from unexpected change. Delivery should occur to a system outside the terminal’s write authority. If the endpoint is offline during the event, the design should define durable buffering, later reconciliation, and the maximum acceptable blind period.
Then rehearse the response. Can the operator isolate one terminal without disabling a branch? Can they preserve the event trail, compare the terminal against its baseline, determine whether recovery secrets were used, and return the unit to service through an approved image? Detection without an executable recovery path is only a notification.
Evidence matrix
| Signal | What it proves | Safe negative control | Defender verification |
|---|---|---|---|
| Firmware settings prompt for a password, but the supported recovery path has weaker identity or no approval | The password protects one interface, not configuration authority | Exercise only the documented recovery workflow on a lab unit and stop before unsupported hardware intervention | Require named identity, per-terminal approval, bounded scope, expiry, and an off-host event |
| Boot priority or Secure Boot state can change in a maintenance or recovery state without equivalent controls | The normal UI is not authoritative across operating states | Use a vendor-approved lab state and attempt one harmless policy change expected to be denied | Compare local state, remote inventory, change record, and alert; quarantine unexpected state |
| An organisation-controlled artifact outside the approved trust set reaches a boot decision other than rejection | Signature policy or boot-source policy is broader than the ATM baseline | Present inert, non-production test media; do not execute a payload | Capture firmware decision, trusted key path, terminal identity, and remote detection |
| TPM measurements change but the terminal retains full trust | Measurement exists without a relying-party policy | Create one reversible, supported lab configuration change | Verify fresh attestation, correct baseline, terminal binding, and quarantine or maintenance-only state |
| Automatic storage unlock continues after a change expected to violate the validation profile | Encryption is not bound to the platform state the owner assumes | Make a supported reversible change and stop at the unlock decision | Confirm protector policy, recovery audit, restoration, and key-custodian approval |
| Firmware update rejection, rollback, or recovery is visible only locally | The terminal can lose or rewrite the sole evidence of platform change | Submit vendor test metadata or an out-of-policy package through the approved lab workflow | Correlate signature result, actor, target, version, policy, time, and final inventory off-host |
| Recovery returns a bootable terminal but configuration, attestation, inventory, or monitoring disagree | Availability was restored without restoring trust | Run the approved recovery image and compare every control-plane assertion | Require a reconciliation gate before production service resumes |
What a finding should look like
Avoid a finding titled “BIOS password bypass.” That title focuses attention on a technique and often overstates what was proved. Report the failed security invariant instead.
A stronger finding reads like this:
On the authorised lab terminal, the documented firmware-recovery workflow allowed the service role to restore setup access without a terminal-specific approval. The action did not produce an event in central monitoring, and the terminal returned to normal service while remote inventory continued to report the previous firmware-security state. No board-level procedure, external boot payload, storage access, PIN material, peripheral command, or cash state was used. A compromised service identity could therefore change the platform trust policy without timely detection or reconciliation. Require per-terminal approval, bind recovery to a named operator, forward the event off-host, and block return to service until firmware configuration, attestation, storage policy, and inventory agree.
This wording identifies the vulnerable authority, the missing control, the observed evidence, the deliberately limited test, and the regression condition. It gives engineering more value than a list of ways to reset hardware.
What I would not call proof
- A firmware password prompt shown in a photograph.
- Secure Boot reported as enabled without key ownership, change control, and negative validation.
- An encrypted volume without evidence of its protector and platform-validation policy.
- A TPM present in inventory without a fresh measurement, verifier, baseline, and relying-party decision.
- A successful reboot after recovery without state reconciliation.
- A local audit record controlled by the same terminal whose trust is in question.
- A lab result presented as evidence that production terminals have the same board, firmware, configuration, or service procedure.
- A destructive hardware demonstration when a safe control decision would prove the same risk.
The quality of the assessment is measured by how precisely it proves loss of trust—not by how close it comes to damaging the device.
Defender priority order
First, govern recovery as a privileged control-plane action. Firmware recovery and storage-key retrieval need named identity, per-terminal approval, limited duration, independent logging, and reconciliation. Their legitimate purpose does not make them low risk.
Second, make the boot policy explicit. Define the approved boot source, signature trust set, firmware configuration, option-ROM policy, measurement baseline, and failure behavior. A checkbox is not a policy.
Third, connect measurements to enforcement. Remote attestation should produce a current, terminal-bound result that changes what an unhealthy or silent device is allowed to do.
Fourth, bind encryption and recovery to the same trust model. Automatic unlock should depend on the expected platform state; recovery material should have narrow custodianship and a durable audit trail.
Fifth, engineer firmware recovery before it is needed. Maintain a known-good image, rehearse the process, detect inappropriate rollback, and require all local and remote sources of truth to agree before service resumes.
Closing thought
The BIOS password matters, but it is not the security boundary. The boundary is every authority that can decide what firmware runs, what configuration is accepted, what source may boot, what measurement is trusted, what storage may unlock, and what recovery returns the terminal to service.
A strong ATM firmware assessment does not teach someone how to defeat a box. It proves whether the organisation can maintain trust when the box is serviced, reset, updated, measured, isolated, and recovered.
The question to leave with the defender is simple: if the password disappeared tomorrow, which independent controls would still prevent an unapproved boot—and which remote evidence would prove they worked?
Public sources and standards context
- NIST SP 800-193 — Platform Firmware Resiliency Guidelines
- NIST SP 800-147B — BIOS Protection Guidelines for Servers
- UEFI 2.10 — Secure Boot and Driver Signing
- Microsoft — Secure the Windows boot process
- Microsoft — BitLocker preboot recovery
- PCI Security Standards Council — ATM Security Guidelines
The PCI ATM document is an information supplement rather than a replacement for the applicable PCI standards or vendor procedures. Exact control availability varies by terminal generation, firmware vendor, operating system, deployment architecture, and acquiring institution. Validate the production design with the owners of those systems; keep active firmware and recovery tests in the authorised lab.
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.