An ATM processes card data, so its network and surroundings are part of the cardholder data environment (CDE), and engineer access to it is assessed under PCI DSS. Version 4.0 raised the bar for authentication: multi-factor authentication is now required not just for administrators but for all access into the CDE — requirement 8.4.2, mandatory since March 31, 2025. An engineer at the service panel is access too.
What PCI DSS requires of engineer access
- a unique ID for every user before access is granted — 8.2.1; the standard states the intent plainly: every action must be attributable to an individual;
- multi-factor authentication: for non-console administrative access — 8.4.1, for all access into the CDE — 8.4.2;
- if passwords are used: at least 12 characters (8.3.6), and where a password is the only factor, a change every 90 days (8.3.9);
- shared accounts only as an exception, under strict conditions (8.2.2 — more on that below);
- logging of access to system components and protection of logs from tampering — requirement 10.
Why passwords fail on an ATM fleet
Start with the arithmetic of requirement 8.3.9. A password is the only factor, so it must change every 90 days. On a fleet of thousands of devices with no permanent connectivity, that means a mechanism that delivers a new password to every ATM four times a year and confirms the delivery landed. That mechanism usually doesn’t exist — and at assessment time it surfaces as expired passwords, or as one “eternal” service account for the whole fleet, which fails 8.2.1, 8.2.2 and 8.3.9 at once.
MFA adds a second dead end: one-time codes and push confirmations need connectivity at the moment of sign-in, which an ATM doesn’t have. A second factor on an offline device in practice means cryptography on a personal token.
The key to the ATM’s top box won’t become a second factor either: authentication factors are what is presented and verified at sign-in, while physical security is a separate requirement 9. Besides, the service-area lock is rarely unique even within a single fleet.
What passwordless sign-in changes
Tessera replaces the password with an X.509 certificate on a hardware token: the engineer inserts the token, enters a PIN, and the device verifies the signature of a random challenge — entirely locally, with no connection to a central server.
From a PCI DSS standpoint this is not “another password, only stronger” — it changes the set of applicable requirements:
- 8.3.6 and 8.3.9 leave the assessment scope. Length and rotation rules apply to passwords — where there are none, there is nothing to check and nothing to fail. Rotation is replaced by the credential’s validity period, which expires on its own, including on an offline device.
- 8.4.2 is satisfied on the device itself — and both factors are real. Possession is the token with a non-extractable key; knowledge is the PIN, verified by the token itself with a hardware retry counter. Compromising one factor does not expose the other: a shoulder-surfed PIN is useless without the token, a stolen token locks itself, and access cannot be “read out over the phone” to a colleague.
- No secret is transmitted or stored on the ATM. Challenge-response verification leaves neither a password nor its hash on the device — there is nothing to brute-force, and phishing disappears as an attack class.
- 8.2.1 is met literally. The unique ID is the certificate subject; it is verified cryptographically before access is granted and lands in every log record.
Shared accounts: 8.2.2 is on our side
Accounts on Tessera-protected devices are role accounts — and here PCI DSS is friendlier than you might expect. Requirement 8.2.2 permits shared accounts under conditions: use is justified and approved, the user’s identity is confirmed before access is granted, and every action is attributable to an individual.
The two technical conditions on that list are satisfied by the sign-in design itself: the role does not open without a personal credential, and the engineer’s name from the certificate is written to the log with every sign-in and sign-out. What remains is the business justification and management approval — paperwork, not engineering. For comparison: the analogous measure in Russia’s GOST R 57580 is stricter, and there the path runs through compensating measures.
Logs for requirement 10
Every sign-in, sign-out and role action is recorded on the device itself — with the engineer’s name, timestamp and result. The credential issuance journal is kept as a chained record: any after-the-fact tampering with history is visible. For the assessor this provides what requirement 10 calls an audit trail: a chain from a specific person to a specific action on a specific ATM — including the periods when the device was offline.
Honest boundaries
PCI DSS assesses an organization, not a product: the scope and applicability of requirements are determined by your QSA, and no security tool makes a bank “compliant” by itself. Tessera covers the technical side of the requirements listed above for engineer access to devices; network segmentation, cardholder data protection in processing, and vulnerability management are separate sections of the standard and separate tools. The product holds no PCI certifications, and we claim none.
If you run an ATM fleet and a PCI DSS assessment is ahead — write to us: we’ll show passwordless sign-in on a test bench and walk through your scenario with the assessor in mind.