Requirement 8 of PCI DSS covers the whole lifecycle of a person’s access to systems in the cardholder data environment: how accounts are created, authenticated, locked, and ended. Most of its controls assume something an unattended device does not have — a directory reachable at the moment of sign-in, able to lock an ID, expire a session, or cut off access the moment someone leaves.

An ATM or a self-service kiosk authenticates the engineer standing in front of it, often with no connectivity at all. Read literally, several Requirement 8 controls cannot be implemented there.

PCI DSS 4.0 added a route that earlier versions lacked. Next to the defined control, most requirements carry a Customized Approach Objective — a statement of what the control is for. An entity may design its own controls to meet the objective instead of implementing the defined control as written.

What the customized approach is not

It is not a lighter path. Requirement 12.3.2 attaches the cost:

A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach, to include: • Documented evidence detailing each element specified in Appendix D: Customized Approach (including, at a minimum, a controls matrix and risk analysis)…

Per requirement: a documented risk analysis, a controls matrix, and an assessor who validates the objective is met. Fewer boxes to tick is not the outcome; different controls, documented and defended, is.

The option also has a hard boundary: requirements without a stated Customized Approach Objective are not eligible at all. Every Requirement 8 control discussed below carries one — worth checking before building an argument on it.

Met as written, no argument needed

Two controls are satisfied literally by a certificate on a personal hardware token, and it is worth separating them from the rest before reaching for anything customized.

8.3.11 Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used: • Factors are assigned to an individual user and not shared among multiple users. • Physical and/or logical controls ensure only the intended user can use that factor to gain access.

The certificate is issued to a named engineer, the token holds the private key, and the PIN is verified by the token itself. Sharing the factor is not something that can be done by telling a colleague a secret — it requires physically surrendering the token, which policy prohibits and the sign-in record attributes to the certificate’s owner.

8.5.1 MFA systems are implemented as follows: • The MFA system is not susceptible to replay attacks. • MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period. • At least two different types of authentication factors are used. • Success of all authentication factors is required before access is granted.

Challenge-response matches the first bullet by construction: the token signs a fresh random challenge and the device verifies it, so a captured exchange is worthless next time. Possession and knowledge are two different factor types, and neither alone opens the session.

Where the customized approach earns its keep

8.3.4 — lockout. The defined control reads: lock the user ID after not more than 10 invalid attempts, for a minimum of 30 minutes or until identity is confirmed. A hardware token counts PIN attempts in its own firmware and blocks itself after its configured limit. It does not unlock after 30 minutes; on the common models it does not unlock on a timer at all, and an administrator has to unblock it. So the defined control is not implemented: there is no user-ID lockout and no 30-minute duration.

The objective for 8.3.4 is “An authentication factor cannot be guessed in a brute force, online attack.” A counter that never resets on its own meets that more strictly than one which reopens the door after half an hour. The substitute control is also easy to evidence: the retry limit is a property of the token documented by its manufacturer, not a setting an operator can quietly relax.

8.2.5 — access for terminated users. The defined control is one sentence: “Access for terminated users is immediately revoked.” On a connected system, revocation is a directory update. On offline devices, the equivalent is a revocation list plus a short credential validity period: the device stops accepting a credential once the list reaches it, and every credential expires on its own regardless.

The objective is “The accounts of terminated users cannot be used.” Two properties are worth stating plainly to an assessor. Revocation is targeted — one engineer’s credential stops working without touching anyone else’s access on any device. And there is a propagation window: until the list reaches a given device, that device does not yet know. The window is bounded by how often lists are distributed and by the credential’s remaining validity — exactly the residual risk a targeted risk analysis exists to quantify. Compared with rotating a shared service password across a fleet and confirming it landed, that window is short and, more importantly, measurable.

What the sign-in mechanism does not address

Requirement 8 contains controls that a sign-in mechanism has no business claiming.

8.2.8 requires re-authentication after 15 minutes of idle time. That is a property of the operating system’s session and screen-lock configuration, not of how the engineer authenticated, and it is evidenced separately.

8.6.1 through 8.6.3 cover accounts used by systems and applications — interactive use, hardcoded passwords in scripts and configuration files, password strength for service accounts. On a self-service device these belong to the terminal software, a different problem with a different owner.

One applicability note is easy to misread in the entity’s favour. Both 8.3.4 and 8.2.8 state that they are “not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.” That describes a POS terminal processing a payment. A service engineer’s session on an ATM is neither a POS terminal nor limited to one card number, and the note does not extend to it.

Honest boundaries

PCI DSS assesses an organization, not a product. Scope, applicability, and whether any customized control meets its objective are decisions for your QSA — no tool is “PCI compliant” on its own, and a customized approach that has not been through a targeted risk analysis and validation is not an approach, only an intention. Tessera holds no PCI certifications and claims none.

What is described above covers engineer access to devices. Network segmentation, protection of card data in processing, and vulnerability management are separate sections of the standard with separate owners.

If you run unattended devices and an assessment is ahead, write to us — we will walk through which arguments apply to your setup.

Sources