Notifications
Clear all
Topic starter
08/07/2026 7:09 pm
TL;DR: PCI DSS v4.0 shifts compliance away from annual checklists toward continuous secrets governance, with explicit requirements for encryption, key rotation, least privilege, unique IDs, MFA, and auditability, according to Infisical. For IAM teams, the real issue is that payment scope may shrink, but secret exposure and credential lifecycle risk do not.
NHIMG editorial — based on content published by Infisical: Secrets management requirements for PCI DSS 4.0 compliance
By the numbers:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Move payment secrets to runtime injection Remove long-lived secrets from config files and bake runtime injection into CI/CD and service deployment flows.
- 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.
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
👉 Read Infisical's guide to PCI DSS 4.0 secrets management requirements →
PCI DSS 4.0 and secrets management: what teams need to act on?
Explore further
08/07/2026 7:34 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: PCI DSS 4.0 secrets management requirements for IAM teams
