Payment security is mostly about narrowing an environment and proving who can reach it. The controls an identity layer decides — unique identification, multi-factor entry, least privilege, reviews and an attributable log — are the ones an assessor spends the most time on.
Before any control is chosen, the question is where the environment ends and who can reach into it. The identity system sits in the middle ring — which is why it is inside the assessment rather than next to it.
The population with no business reason to reach cardholder data. The control is not a rule written somewhere: it is being able to show, six months later, that the list of people who could reach the environment did not quietly grow.
Administrators on jump paths, monitoring tools, directories, the identity provider itself. In scope because compromising them reaches the environment — which is why the identity system is inside the assessment, not adjacent to it.
Where account data is stored, processed or transmitted. Every access into it needs a uniquely identified actor and more than one factor — administrative or not, remote or on the console.
The standard has twelve. These are the ones whose outcome is decided by how identity and access are run, rather than by how the network is built.
Least privilege, defined by role, approved by someone entitled to approve it, and reviewed periodically — the standard expects user accounts and privileges to be reviewed at least every six months. A review that gets approved in bulk satisfies nobody twice.
Unique identification for every user, shared accounts as a documented exception rather than a habit, and multi-factor authentication for all access into the environment. Sessions time out on inactivity and require re-authentication rather than being left open on a shared terminal.
Every access to system components and to account data is attributable to an individual. Logs are retained for a year with the most recent months immediately available — which only works if the actor in the log is an identity somebody owns, not a generic name.
Documented policies, named accountability, and a scope validated at least annually. Most of this is organisational, and the part the access layer settles is whether the documented model and the enforced one are the same thing.
Human accounts get attention because people complain about them. Application and system accounts do not complain, do not leave, and hold standing access to the environment — which is why the standard now addresses them explicitly.
Application and system accounts should not be used to log in interactively, and where a person genuinely needs to, the use has to be justified, attributable and time-limited. The shared operations password in a wiki is the canonical finding.
Passwords for these accounts have to be protected and changed on a defined basis, informed by risk. That is difficult when nobody knows how many exist, and impossible when they are hardcoded in scripts written by people who have left.
A service account with no manager and no leaving date is never reviewed out of existence. Giving it an owner who confirms annually that it is still needed is the cheapest control on this page.
Support access granted to a vendor, a payment integrator, a terminal maintainer. Same rules, more turnover, and usually no visibility of who at the supplier is actually using the account.
Governance treats these as a population with a lifecycle, like any other: an owner, a recorded purpose, a review, and a removal that actually happens.
Roles, entitlements and policies are held centrally and applied at the point of access, so the model an assessor reads in a document is the model the systems actually run. Approvals and grants keep their history, which is what turns a claim into evidence.
WebAuthn, FIDO2 and passkeys as native factors, with step-up bound to the action rather than the front door — so entering the environment is expensive and reading a dashboard is not.
Certification campaigns scoped by risk or application, with segregation-of-duties rules that block conflicting combinations before they are granted. Six-monthly becomes a job that runs rather than a spreadsheet somebody chases.
Monokee is not a payment application and does not store, process or transmit cardholder data. Encryption of account data, network segmentation, vulnerability scanning and the assessment itself sit elsewhere. What an identity layer settles is requirements 7, 8 and part of 10 — a meaningful share of the effort, and not the whole standard.
This page describes how an identity layer supports parts of the Payment Card Industry Data Security Standard. It is not legal advice, not an assessment, and not a certification claim: compliance is established by a qualified assessor or a self-assessment questionnaire against the environment as it is actually built.
Every payment estate has one, and it usually exists because the supported alternative was worse. That is the conversation, not the finding.
Talk to an expert