PCI DSS 4.0 exposes the API inventory gap in security programmes

At a glance

What this is: Salt argues that PCI DSS 4.0 exposes a gap many programmes still have: they cannot secure APIs they have not inventoried, classified, and monitored.

Why it matters: This matters because API discovery now sits between compliance, data protection, and access governance, so identity and security teams need a complete view of which APIs exist, what data they touch, and how they are controlled.

Context

PCI DSS 4.0 sharpens the expectation that custom software, including APIs, sits inside a governed security and compliance lifecycle. The problem is that many programmes still treat APIs as a downstream technical detail rather than an inventory and control problem, which leaves shadow APIs outside change control, risk assessment, and monitoring.

For identity and security teams, the governance gap is not just whether an API authenticates correctly. It is whether the organisation can prove what exists, who or what can reach it, what data it handles, and whether those access paths remain aligned to policy as systems change.

Key questions

Q: What breaks when API inventory is incomplete under PCI DSS 4.0?

A: Incomplete API inventory breaks control assurance. Teams lose visibility into shadow endpoints, cannot consistently apply vulnerability management or encryption checks, and may miss where credentials or service identities are reaching sensitive data. In practice, that means compliance evidence becomes partial, remediation priorities are distorted, and hidden APIs can remain exposed long after formal review cycles have closed.

Q: Why do shadow APIs create a PCI DSS accountability problem?

A: Shadow APIs break accountability because the organisation cannot assign control ownership or prove which requirements apply to an endpoint it has not formally discovered. That means security, development, and risk teams are all operating with partial evidence when they certify compliance or assess exposure.

Q: What do teams get wrong about cryptographic API authentication?

A: They often assume that encryption and signing eliminate governance risk. In practice, the cryptography only proves message integrity and origin. It does not solve who owns the identity, where the private key lives, how long the refresh path remains valid, or how the integration is retired. Those are lifecycle and access-management questions, not protocol questions.

Q: How should organisations secure APIs to meet PCI DSS 4.0 requirements without leaving gaps in cardholder data protection?

A: Organisations should treat API security as a core PCI control, not a side issue. That means using strong authentication, role based access control, encrypted transport, secure configuration standards, logging, and regular vulnerability testing. PCI DSS 4.0 also expects an up to date inventory of bespoke and custom software, so teams can identify every API, assess its exposure, and track remediation before audit time.

Technical breakdown

API inventory as the control plane for PCI DSS 4.0

PCI DSS 4.0 pushes API security into the same governance model as other custom software. That matters because APIs are not just interfaces, they are access pathways to data, functions, and sometimes downstream identities or tokens. If an API is not in inventory, it cannot be assessed for development controls, change review, authentication requirements, or encryption exposure. Discovery therefore becomes the control plane for everything that follows. In practice, incomplete inventory is not a visibility issue alone. It is a control failure that makes compliance claims and security decisions unreliable.

Practical implication: treat API inventory as a prerequisite for every PCI DSS 4.0 control decision.

Shadow APIs and the collapse of change control

Shadow APIs emerge when teams deploy endpoints outside formal release, review, or security oversight. In that state, change control loses its anchor because the organisation cannot detect what was added, modified, or left exposed. PCI DSS 4.0 Requirement 6.4 assumes you can identify material changes before they reach production risk. Without discovery, the change management process becomes retrospective rather than preventive, and risk teams only see the API after exposure has already occurred. That is especially important where APIs carry credentials, customer data, or privileged workflow actions.

Practical implication: tie API discovery to release gates so undocumented endpoints cannot bypass change control.

Authentication and encryption depend on knowing the API surface

Requirement 8 and Requirement 4 only work when the organisation knows which APIs exist and which ones process sensitive data. Authentication can be configured correctly on a known endpoint and still miss a hidden one. Encryption can protect a documented data flow while leaving an undisclosed path in cleartext. The technical issue is not that authentication or TLS are weak controls. It is that they become partial controls when the attack surface is incomplete. That creates a governance blind spot for both identity assurance and data handling.

Practical implication: map each API to its authentication and encryption posture before assuming requirement coverage.

Threat narrative

Attacker objective: The attacker objective is to use undiscovered API exposure to reach data or functions that the organisation has not properly classified or controlled.

1. Entry occurs through an undocumented or shadow API that was never brought under formal security review or inventory.
2. Credentialed or unauthorised access can then target the exposed endpoint because its authentication, data handling, and logging posture are not consistently governed.
3. The impact is unauthorised access to cardholder data, weak compliance evidence, or a control gap that attackers can exploit before the organisation notices the API exists.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API inventory is now a governance control, not an architectural nicety. PCI DSS 4.0 makes the inventory question explicit because custom software obligations only work when the organisation can see the full API estate. Where shadow APIs exist, compliance evidence becomes incomplete and security decisions become speculative. Practitioners should treat discovery as the front door to both IAM and application governance.

Shadow API exposure creates an accountability gap that compliance language cannot fix. Requirement 6, change control, and periodic risk assessment all assume the security team knows what is changing. Undiscovered endpoints move outside that assumption and can carry cardholder data, workflow privileges, or machine-to-machine trust. The practitioner conclusion is simple: if the API is invisible, the control is already degraded.

API inventory is the named concept this article exposes. It is the operational discipline of knowing every API, what it handles, and which policy domain governs it. That concept is especially important for identity teams because API reachability often substitutes for identity assurance in modern architectures. The field implication is that API security and identity governance are converging at the same control point: discovery.

PCI DSS 4.0 is forcing teams to think in terms of data-path governance rather than point controls. Authentication, encryption, secure development, and risk review all lose strength if the API surface is incomplete. That is why discovery, classification, and monitoring now sit upstream of almost every other safeguard. Practitioners should re-evaluate whether their control ownership model actually spans API sprawl.

This is also a reminder that security posture fails first at the boundary of what teams do not know exists. The strongest controls in the catalogue still leave blind spots if undocumented interfaces are allowed to appear outside release and inventory processes. For identity, PAM, and cloud security teams, the conclusion is that governance must follow the API lifecycle, not just the API platform.

From our research library:

• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: API Key Management Guide

What this signals

API inventory gap: security programmes that cannot enumerate their API estate will continue to miss the controls PCI DSS 4.0 now expects. That affects more than compliance because the same blind spot weakens ownership, access governance, and data-flow assurance across the broader application stack.

For teams already working on identity and access modernisation, the practical shift is to bring API discovery into the same operating rhythm as lifecycle management and privileged access review. APIs that are not classified cannot be reliably tied to policy, and that is where drift begins.

For practitioners

• Define a formal API inventory baseline Catalog every custom and bespoke API, including shadow endpoints, and assign an owner, data classification, and authentication method.
• Bind API discovery to change control Require new or changed APIs to pass a discovery check before production release so undocumented interfaces cannot bypass review.
• Map APIs to cardholder data flows Identify which APIs handle cardholder data, then verify encryption, logging, and access controls against that data path.
• Prioritise authentication on exposed APIs Focus MFA or strong authentication on APIs that expose sensitive data or privileged functions, especially where machine access is involved.
• Use periodic reviews to find drift Reassess the API estate regularly for undocumented additions, stale endpoints, and changes that alter compliance posture.

Key takeaways

• PCI DSS 4.0 turns API inventory into a control requirement, not just a documentation task, because undiscovered endpoints cannot be governed consistently.
• Shadow APIs weaken change control, risk assessment, authentication coverage, and encryption assurance at the same time.
• The practical response is to connect discovery, ownership, and data classification to the API lifecycle before release and during review.

Key terms

• API Discovery: API discovery is the process of finding and cataloging APIs across an environment so security teams know what exists, what data it exposes, and how it behaves. It is essential because shadow, zombie, unmanaged, and third party APIs are frequent blind spots that attackers can exploit without being noticed.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• API Inventory: An API inventory is the authoritative record of what interfaces exist, who owns them, what data they touch, and how they are authenticated. For identity governance, it is the baseline control that makes review, monitoring, offboarding, and risk prioritisation possible across distributed services.
• Custom Software Component: A custom software component is application logic developed or adapted by the organisation rather than obtained as a standard off-the-shelf package. Under PCI DSS 4.0, APIs can fall into this category, which means they inherit secure development, change control, and risk review expectations.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps practitioners connect identity controls to the operational systems and workflows that depend on them.