Notifications
Clear all
Topic starter
06/06/2026 2:04 am
TL;DR: PCI DSS 4.0 expands scope, formalises accountability, and directly tightens controls around non-human identities, especially system and application accounts with elevated privileges, hard-coded secrets, and third-party access, according to Oasis Security. Compliance now depends on treating NHI visibility, rotation, and lifecycle governance as audit controls, not background hygiene.
NHIMG editorial — based on content published by Oasis Security: Understanding PCI DSS 4.0: NHIM Essential Guide
By the numbers:
- PCI DSS 4.0 includes over 200 updates that reshape compliance expectations across in-scope environments.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: What breaks when NHI controls are not included in PCI DSS 4.0 scope?
A: Audits become incomplete because the organisation can prove human access governance while leaving service accounts, API keys, and deployment credentials outside the control set.
Q: Why do machine identities complicate PCI least-privilege reviews?
A: Machine identities are often provisioned once and then allowed to accumulate permissions as systems change.
Q: How do teams know whether NHI governance is working for PCI compliance?
A: Look for evidence that every machine identity has an owner, a defined business purpose, a review cadence, and a documented revocation path.
Practitioner guidance
- Inventory every payment-scope machine identity Build a register of service accounts, API keys, application logins, and certificates that can touch cardholder-data flows, deployment pipelines, or connected third parties.
- Re-run access reviews for NHI accounts on a fixed cadence Tie machine-identity recertification to the same review calendar used for regulated human access, then require explicit approval for any privilege that cannot be justified by current payment processing needs.
- Eliminate hard-coded secrets from code and delivery tooling Search repositories, config files, and CI/CD systems for embedded credentials, then move them into controlled secret storage with rotation and revocation procedures that are owned by the application team.
What's in the full article
Oasis Security's full blog post covers the operational detail this post intentionally leaves for the source:
- A requirement-by-requirement walkthrough of how PCI DSS 4.0 maps to machine identities and secrets.
- Specific examples of system components now in scope, including repositories and deployment tools.
- Practical guidance on visibility, security, governance, and reporting for compliance teams.
- The article's own suggested workflow for preparing a detailed PCI DSS 4.0 compliance plan.
👉 Read Oasis Security's guide to PCI DSS 4.0 and NHI governance →
PCI DSS 4.0 and NHI governance: what changes for IAM teams?
Explore further
06/06/2026 3:33 am
PCI DSS 4.0 turns NHI governance from an adjacent hygiene issue into a compliance control. The article is right to treat system and application accounts as materially in scope because payment environments fail when machine access is broad, unowned, or poorly evidenced. That is a governance problem, not just a technical one. Practitioners should read the standard as a demand for provable machine-identity control, not only stronger human account security.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
A question worth separating out:
Q: Who is accountable when a third-party NHI causes PCI scope exposure?
A: Accountability sits with the organisation that owns the payment environment and the business relationship, even if a vendor operates the access path. The practical question is whether the third-party identity is contract-bound, monitored, and revoked when the relationship changes. If not, the risk remains inside your control boundary.
👉 Read our full editorial: PCI DSS 4.0 makes NHI governance a compliance control
