PCI DSS 4.0 exposes the API inventory gap in security programmes

At a glance

What this is: This is Salt’s analysis of how PCI DSS 4.0 pushes API discovery, inventory, and posture checks into the centre of API security governance.

Why it matters: It matters because identity and security teams need a complete view of API access paths, data exposure, and authentication boundaries before they can enforce least privilege or verify compliance.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Salt’s analysis of PCI DSS 4.0 API inventory and posture rules

Context

PCI DSS 4.0 makes API inventory a governance issue, not just a technical discovery task. If APIs are custom software components and carry cardholder data or authentication traffic, security teams need to know where they exist, what they expose, and whether they are controlled consistently. That creates a direct identity and access management problem wherever API credentials, service accounts, or delegated access are involved.

Salt’s framing is that shadow APIs and incomplete change control undermine compliance before a vulnerability scan even starts. The broader lesson for IAM, PAM, and NHI teams is that API governance depends on knowing every credentialed entry point, then proving that each one follows secure development, encryption, and access control expectations. That starting position is now common, not exceptional.

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 compliance risk?

A: Shadow APIs create compliance risk because they can process sensitive data without being included in the organisation’s inventory, policy checks, or audit trail. Once an API is outside governance, teams lose visibility into authentication, logging, and data handling, which makes control failure hard to detect.

Q: How can security teams tell whether API discovery is actually working?

A: API discovery is working when newly created or changed endpoints appear quickly in the inventory, each has an accountable owner, and sensitive-data handling is visible in the same record. A healthy programme also shows that posture checks, encryption reviews, and access controls are triggered from the inventory rather than applied after incidents or audits.

Q: Who is accountable when an unmanaged API exposes sensitive data?

A: Accountability should sit with the service owner, the application security function, and the control owners responsible for inventory, access, and compliance evidence. Under PCI DSS 4.0, organisations cannot rely on the API existing outside governance. If it handles regulated data, it must be brought under the same accountability chain as any other production system.

Technical breakdown

Why API inventory is now a security control

PCI DSS 4.0 treats APIs as part of the software estate that must be discovered, tracked, and reviewed. That matters because undocumented APIs often inherit production data access without going through the same review gates as formally managed services. Inventory is therefore not a reporting exercise. It is the control layer that tells you which APIs exist, which ones process sensitive data, and which ones should be subject to authentication, scanning, and encryption requirements. In identity terms, the inventory must also map the credentials and service identities that invoke those APIs.

Practical implication: build an authoritative API inventory that includes ownership, data classification, and the identities that access each endpoint.

How shadow APIs create compliance blind spots

Shadow APIs are endpoints that exist outside standard development, review, or security workflows. They may be created during testing, exposed by integrations, or left behind after application changes. Once live, they can carry traffic, accept credentials, and process sensitive records without appearing in normal governance reports. Under PCI DSS 4.0, that creates blind spots in change control, vulnerability management, and encryption verification. The problem is not only exposure. It is the lack of assurance that an API has ever been assessed against the same standards as the rest of the application estate.

Practical implication: continuously detect new or changed APIs and route them into the same approval and risk review path as managed services.

Why API authentication and encryption belong together

API security under PCI DSS is not just about authenticating clients. It is about ensuring the right credentialed system reaches the right data over a protected channel. Authentication limits who can call the API, while encryption protects the data in transit and reduces interception risk if traffic crosses untrusted networks. For identity programmes, this also means service account hygiene matters, because stale or over-broad API credentials can bypass otherwise strong controls. When access control and transport security are separated, compliance becomes fragile and operationally easy to misjudge.

Practical implication: pair API authentication reviews with transport encryption checks and credential scope validation for every sensitive endpoint.

Threat narrative

Attacker objective: The attacker seeks to reach sensitive data or privileged application functions through APIs that the organisation has not fully inventoried or controlled.

1. Entry occurs when an undocumented or weakly governed API is exposed to production traffic without full security review.
2. Escalation follows when the API accepts overly permissive credentials or transmits sensitive data over insufficiently protected channels.
3. Impact is achieved through unauthorised access, data exposure, or compliance failure that the organisation cannot reliably evidence or contain.

NHI Mgmt Group analysis

API inventory is now an identity governance problem, not just an AppSec task. PCI DSS 4.0 forces organisations to account for every API that can move sensitive data or accept authenticated requests. That shifts the centre of gravity toward ownership, service identity tracking, and lifecycle control. In practice, teams that cannot map APIs to accountable owners also cannot prove least privilege or timely remediation.

Shadow API discovery exposes the governance gap that traditional review cycles miss. APIs often appear outside normal design review, especially in fast-moving development and integration work. Once they are live, they may carry production credentials and cardholder data without equivalent oversight. That means the control failure is not only technical exposure, but the absence of a reliable change-control boundary. Practitioners should treat discovery as continuous control assurance, not periodic hygiene.

Transport security and authentication must be assessed as one control plane. PCI DSS 4.0 links strong authentication with encrypted transport because either control alone can leave a sensitive API exposed. For NHI and IAM teams, the deeper lesson is that service credentials, API tokens, and certificate-based trust all need the same governance discipline as human access. Otherwise, the organisation ends up with authenticated exposure rather than protected access.

Requirement 6.3.2 makes bespoke API governance unavoidable. Custom software inventory obligations extend into the API layer because APIs are bespoke application components with direct security impact. That means the old assumption that APIs are just implementation detail no longer holds. Teams need to align application security, IAM, and compliance reporting around the same inventory record, or risk building separate versions of the truth.

PCI DSS 4.0 validates the shift toward continuous posture management. Compliance for APIs is increasingly about detecting drift as it happens, not reconstructing it after an assessment. That favours organisations that can connect discovery, access control, and encryption checks into one governance workflow. The implication is clear: the market is moving toward operational evidence, not static documentation, as the standard for trust.

What this signals

API inventory is becoming the practical boundary between compliance and guesswork. As more environments combine applications, service identities, and sensitive data flows, practitioners need one place to see which APIs exist and which identities can invoke them. That is the same governance pressure now driving stronger service account discipline, tighter token scope, and more frequent entitlement review.

Inventory-driven control models will outperform document-driven ones. When discovery feeds posture checks directly, teams can move from periodic evidence gathering to continuous assurance. That is the operating model PCI DSS 4.0 rewards, and it aligns with the broader shift toward continuous identity governance for APIs, workloads, and other non-human access paths.

For practitioners

• Implement continuous API discovery Maintain an authoritative inventory of all APIs, including shadow endpoints, and tie each one to an owner, data classification, and approval status.
• Map sensitive APIs to identity controls Link every API that processes cardholder or regulated data to the service account, token, or certificate used for access, then review scope and expiry.
• Automate change-control checks for new endpoints Trigger security review when a new API appears or an existing endpoint changes behaviour, routing it through the same controls used for managed software releases.
• Verify authentication and encryption together Test that authenticated API calls carrying sensitive data also use strong transport protection, and block endpoints that rely on outdated or unencrypted channels.

Key takeaways

• PCI DSS 4.0 turns API visibility into a compliance requirement, not a best-effort security task.
• Shadow APIs, weak change control, and unclear ownership create the governance gap that attackers and auditors both exploit.
• Security teams should connect discovery, identity scope, and transport protection into one continuous control process.

Key terms

• 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 Posture Rule: A policy check that evaluates an API against defined security or compliance requirements. In practice, posture rules help teams identify missing controls, such as weak authentication, unencrypted transport, or undocumented exposure, and then route those findings into remediation workflows.
• Software inventory: A current, authoritative record of the applications, versions, and dependencies running across an organisation. It is the baseline control for lifecycle management because teams cannot retire, patch, or isolate what they cannot reliably see.
• Service Identity: A service identity is a non-human identity used by applications, workloads, or automation to authenticate and access resources. It may be a role, token, key, or certificate, and it needs the same lifecycle discipline as any privileged identity because it can directly expose data.

What's in the full article

Salt's full analysis covers the operational detail this post intentionally leaves for the source:

• How Salt’s PCI DSS posture rules map to specific Requirement 6, 8, and 4 control checks
• How API Discovery identifies shadow APIs, data handling, and compliance gaps across the API estate
• How the platform integrates with development and change-control workflows during remediation
• How practitioners can use the inventory to prioritise vulnerability scanning and encryption fixes

👉 Salt’s full post covers the API discovery workflow, PCI DSS requirement mapping, and posture-rule examples.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners building stronger identity control programmes. It is designed for security and identity teams that need to connect operational controls to governance outcomes.