PCI DSS 4.0 secrets management requirements for IAM teams

At a glance

What this is: This post explains how PCI DSS v4.0 turns secrets management into a compliance requirement for payment environments.

Why it matters: It matters because payment scope, privilege boundaries, and monitoring expectations now intersect with NHI, workload identity, and human access controls.

By the numbers:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.

👉 Read Infisical's guide to PCI DSS 4.0 secrets management requirements

Context

PCI DSS v4.0 treats secrets as part of the control surface, not just a technical implementation detail. For payment environments, the practical question is whether credentials, tokens, keys, and certificates are governed with enough discipline to satisfy least privilege, unique identity, rotation, logging, and audit expectations.

That matters for both human and non-human identities. When service accounts, CI/CD systems, and payment workflows rely on long-lived secrets, the compliance problem becomes a lifecycle problem as much as an encryption problem, which is why the NHI lifecycle perspective is central here.

Key questions

Q: How should security teams govern secrets for PCI DSS v4.0 compliance?

A: Security teams should treat secrets as governed identity assets, not configuration leftovers. That means mapping each credential to an owner, limiting access by business need, rotating sensitive material, logging every access, and removing secrets from static files and shared repositories. Compliance depends on lifecycle control, not vault adoption alone.

Q: When does secrets management become a PCI compliance issue?

A: It becomes a PCI issue whenever a secret can reach payment systems, cardholder data, or supporting infrastructure. If credentials are duplicated, shared across systems, or left active after a role or vendor change, the organisation has a compliance and exposure problem at the same time.

Q: What do teams get wrong about rotation and compliance?

A: Many teams treat rotation as the end state, but rotation is only one control. If the secret is still overprivileged, copied into multiple places, or not tied to a clear offboarding process, the underlying risk remains. A rotated secret can still be a poorly governed secret.

Q: Who is accountable for secrets in payment environments?

A: Accountability should sit with the system or service owner, not only the security team. For service accounts, pipelines, and vendor integrations, the owner must know where the secret is used, when it expires, and how it is removed when the business purpose ends. That is what makes PCI evidence durable.

Technical breakdown

How PCI DSS v4.0 treats secrets as controlled identity material

PCI DSS v4.0 does not treat secrets as simple configuration data. Credentials, API keys, certificate material, and encryption keys all behave like access-bearing identity artefacts because they grant or protect entry to cardholder environments. Requirement 3 focuses on stored data and key management, while Requirements 4, 7, 8, and 10 extend the control model into transmission, access restriction, authentication, and monitoring. In practice, this means secrets management is part of the compliance perimeter, not a separate DevOps concern.

Practical implication: classify secrets as governed access material and map them to PCI controls before they reach production.

Why just-in-time access and rotation matter in payment environments

PCI DSS v4.0 pushes organisations toward dynamic handling of sensitive material because standing secrets expand the attack window. If a key, token, or certificate is reused across systems or kept longer than necessary, the organisation inherits both exposure risk and evidence-gathering problems. Just-in-time injection, rotation, and separation of duties reduce how long a secret can be abused and make it easier to prove that only authorised systems touched the material. That is especially important where CI/CD, cloud workloads, and payment services share operational identity patterns.

Practical implication: reduce standing exposure by rotating secrets, injecting them at runtime, and separating storage from use.

How monitoring changes when secrets become audit evidence

Requirement 10 makes access telemetry part of the compliance story. It is not enough to know that a vault exists; organisations need to know who accessed which secret, from where, when, and in what context. That audit trail becomes evidence for investigations, recertification, and control testing. For NHI governance, the same pattern applies to service accounts and automation because the secret itself is often the only traceable identity marker tied to the action path.

Practical implication: retain access logs that tie each secret request to a specific identity, purpose, and execution context.

Threat narrative

Attacker objective: The attacker aims to turn a single exposed secret into sustained access to payment systems and cardholder data.

1. entry: attackers commonly enter payment-adjacent environments through exposed credentials, leaked API tokens, or reused secrets that were never removed from the runtime path.
2. escalation: once a secret is valid, the attacker can abuse standing privilege to reach cardholder data, move across connected systems, or harvest additional credentials from poorly segmented services.
3. impact: the result is unauthorized access to protected payment data, failed audit evidence, and a larger compliance breach than the original secret exposure suggests.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PCI DSS v4.0 exposes the limits of annual compliance thinking: the standard assumes secrets can be governed continuously, not just reviewed on a calendar. That assumption matters because credential exposure is often a runtime event, while many programmes still manage it as a periodic audit item. The implication is that payment security and identity governance now share the same operational clock.

Secret sprawl is the real control problem behind payment compliance: once credentials are duplicated across pipelines, vaults, tickets, and apps, the organisation no longer has a single control point. That is why Requirements 3, 4, 7, 8, and 10 behave like one lifecycle chain rather than separate checklist items. Practitioners should read this as a governance signal, not a tooling preference.

Unique identity for systems is not enough if the secret lifecycle is unmanaged: PCI explicitly recognises that service accounts and automated systems need traceability, but traceability collapses when the underlying secret is shared, stale, or overexposed. This is where NHI governance and payment compliance converge. The practitioner takeaway is to treat lifecycle ownership as part of access control.

Identity blast radius becomes the practical metric that matters most: the question is no longer whether a credential exists, but how far it can travel before detection or rotation intervenes. Dynamic injection, scoped access, and audit-ready logs reduce blast radius, while duplicated secrets and long-lived keys amplify it. Payment compliance should therefore be evaluated by containment, not by vault presence alone.

Lifecycle offboarding is the control gap many payment programmes still miss: access does not end when a vendor, app, or pipeline changes, yet PCI-style environments often retain tokens far beyond their useful life. That creates governance debt that survives the original business relationship. Practitioners should map every payment-adjacent secret to an owner, expiry point, and offboarding event.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• For teams building the control plane behind this risk, the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the natural next step for ownership, rotation, and offboarding design.

What this signals

Identity blast radius is the metric payment teams should watch. When a single secret can unlock multiple systems, compliance evidence becomes secondary to containment. The operational question is whether each credential has a bounded purpose, a clear owner, and an enforced expiry path, especially in CI/CD and service-to-service flows.

The shift to continuous controls means secret governance now sits alongside IAM and PAM rather than beneath them. Teams that still rely on static review cycles will miss the point of PCI DSS v4.0 because the risk is not just access, but how long access persists after its business need has ended.

Payment programmes should align secret lifecycle controls with lifecycle governance for human and non-human identities. The same change management discipline that offboards users must also remove service account access, revoke tokens, and verify that no stale integration continues to carry privilege.

For practitioners

• Map PCI requirements to each secret class Tag credentials, API keys, certificates, and encryption keys by where they live, who can use them, and which PCI requirement they support. This makes it possible to prove control coverage instead of assuming the vault solves the whole problem.
• Move payment secrets to runtime injection Remove long-lived secrets from config files and bake runtime injection into CI/CD and service deployment flows. Secrets should exist only when a workload needs them, not as persistent artefacts in repositories or images.
• Tie audit logs to secret use events Log each secret access request with identity, purpose, and environment context, then keep those records aligned with recertification and incident response. That gives auditors evidence and gives security teams a way to spot unexpected access patterns.
• Apply offboarding to non-human identities Revoke unused tokens, remove shared secrets, and confirm that vendor or application changes do not leave old access paths behind. Offboarding must include service accounts and automation, not just human accounts.

Key takeaways

• PCI DSS v4.0 turns secrets management into a core compliance control, not a backend hygiene task.
• The biggest practical risk is not only exposed secrets, but duplicated, stale, and overprivileged secrets that survive offboarding.
• Teams should measure compliance by lifecycle containment, auditability, and runtime control, not by whether a vault exists.

Key terms

• Secrets Management: Secrets management is the controlled storage, distribution, rotation, and revocation of credentials such as API keys, tokens, certificates, and passwords. In payment environments, it is also an identity control because the secret often becomes the thing that proves authority to access systems or data.
• Standing Privilege: Standing privilege is access that remains available without needing just-in-time approval or renewal. For secrets, it usually means long-lived credentials that can be reused repeatedly, which increases exposure windows and weakens the evidence trail for compliance and incident response.
• Offboarding: Offboarding is the process of removing access when a person, service, vendor, or workload no longer needs it. For non-human identities, it must include token revocation, secret deletion, and dependency checks, because unused access often survives long after the original business relationship ends.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Requirement-by-requirement guidance for mapping PCI DSS v4.0 to secrets controls in real environments
• Examples of how to handle TLS keys, MFA seeds, and API tokens across payment workflows
• Product-level implementation patterns for RBAC, runtime injection, and audit trails
• A practical view of how teams can pair secrets management with compliance evidence collection

👉 The full Infisical post covers the specific PCI requirements, control examples, and secrets handling patterns in more depth.

Deepen your knowledge

NHI governance, secrets management, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or access governance in your organisation, it is worth exploring.