Knowing who, and proving it.
Requirement 8 is about identifying users and authenticating access: every user has a unique ID, access is authenticated, and multi-factor authentication is required for access into the cardholder data environment. The point is that you can tie an action to a person and that a stolen password alone is not enough to get in. Much of it is decided in your auth code and config.
The shapes the same control failure takes.
Requirement 8 weakens when a change makes it easier to get in, or harder to attribute who did. The recurring shapes:
MFA is removed or made optional
A multi-factor check on access into the cardholder data environment is dropped or gated behind a flag, so a password alone is enough again.
A shared or generic account appears
A shared login or generic service account is introduced where individual identification is required, so actions can no longer be tied to a person.
Strong auth is weakened
A path that required multi-factor or strong authentication is changed to accept a password only, or a weaker factor.
An auth step is bypassed
A code path (an internal route, an automation, a debug shortcut) reaches sensitive functionality without going through authentication.
Default or static credentials are left in
A default, hardcoded, or never-rotated credential stays in place, which is an unauthenticated door in practice.
MFA removed from admin access.
The multi-factor step is slowing down admins, so a change removes the second-factor check on the admin login that reaches the systems handling cardholder data. Logins get faster, and now a password alone gets an admin into the cardholder data environment.
async function adminLogin(user, password, otp) { if (!verifyPassword(user, password)) return deny()- if (!verifyOtp(user, otp)) return deny() return grantAdmin(user)}Removing the second-factor check means admin access into the cardholder data environment now needs only a password, which Requirement 8 expects multi-factor authentication to protect. Keep the factor; if it is too slow, improve the second-factor experience rather than dropping it.
Authentication is checked at the access paths that matter.
A PCI assessment looks at how access is identified and authenticated, especially into the cardholder data environment: unique IDs, multi-factor where required, no shared accounts, no default credentials. A change that removed an MFA check, added a shared account, or bypassed authentication is the concrete gap behind that, and it is visible in the diff to the auth code or policy.
A review, not your identity provider.
heygrc flags changes that touch Requirement 8 and cites the requirement so the fix happens in the pull request. It does not run your authentication or manage your identities. It catches the moment a change weakens how access is authenticated, at the diff. heygrc is in early access.