Zero trust does not solve API security gaps in hybrid environments

At a glance

What this is: Salt’s webinar analysis says zero trust by itself does not solve API security in hybrid environments because APIs must remain reachable, hidden APIs escape governance, and authenticated misuse still creates exposure.

Why it matters: IAM, PAM, and cloud security teams need to treat API access as a governed exposure problem, not just an authentication problem, because trusted users and unseen assets can still become breach paths.

By the numbers:

• 57% said zero trust is a major consideration in their current security architecture.
• 83% of Internet traffic is API traffic.
• 42% of organisations say outdated APIs are their biggest API security worry.

Context

Zero trust is a security model that assumes no implicit trust across a perimeter, which is why it fits hybrid environments where users, services, and data are accessed from many locations. The problem is that API traffic does not behave like a normal user access pattern, so authentication alone does not establish safe use.

In this article’s framing, the governance gap is not whether an organisation has adopted zero trust, but whether it can inventory, classify, and constrain the APIs that still need to be reachable. That is where machine-access pathways, delegated credentials, and shadow APIs create a control problem that perimeter-era thinking does not solve.

Key questions

Q: What breaks when zero trust is applied to APIs without lifecycle and inventory controls?

A: Zero trust does not fail because the access model is wrong. It fails when teams assume authentication alone is enough. If an API is unknown, outdated, or overexposed, there is no reliable way to enforce scope, monitor use, or remove access when business need ends. The result is governed access on paper and uncontrolled exposure in practice.

Q: Why do authenticated API users still create security risk?

A: Because valid credentials can still be abused. Attackers often steal keys, tokens, or user credentials and then use the API exactly as designed, which makes the activity look legitimate at the protocol level. The risk sits in what the caller can access and how much data they can retrieve, not just in whether they passed authentication.

Q: How can security teams tell whether API exposure is becoming a governance problem?

A: Look for endpoints that return personal data without a clear identity decision, weak logging around record retrieval, and approval gaps between development and production. If the team cannot show who authorised the interface, what data it can expose, and how misuse is detected, governance is already failing.

Q: Should organisations treat zero trust and API security as separate programmes?

A: No. They are linked but not interchangeable. Zero trust governs how access is verified, while API security governs what reachable services can expose and how they can be abused after authentication. Teams should align the two so identity controls and API lifecycle controls reinforce each other.

Technical breakdown

Why zero trust struggles with API access in hybrid environments

Zero trust is designed to remove implicit network trust and force continuous verification, but APIs still require access to function. In hybrid environments, that creates a tension: the service must be reachable, yet the access path must stay tightly governed. If teams treat API traffic like ordinary user access, they miss the fact that machine-to-machine interactions often depend on service credentials, tokens, or delegated authorisation that remain valid across many calls. The control problem shifts from perimeter trust to exposure management, identity assurance, and runtime permission scope.

Practical implication: Treat API access as a governed machine-access pathway, not as a generic zero trust exception.

Unknown and zombie APIs create the largest control blind spot

An unknown API cannot be protected in practice because there is nothing to inventory, inspect, or policy-check. That is the central governance failure Salt highlights with shadow and outdated APIs: if the asset is missing from the control plane, zero trust policy never reaches it. In fast-moving hybrid estates, APIs are created, modified, and retired faster than manual tracking can keep up with. That makes discovery, ownership, and lifecycle control foundational security activities rather than administrative hygiene.

Practical implication: Build API discovery and ownership into security governance before relying on policy enforcement.

Authenticated users can still abuse legitimate API paths

Zero trust validates identity, but identity validation alone does not prevent misuse of authorised API functions. Attackers can obtain valid credentials through social engineering or abuse an existing user context, then use the API exactly as designed to access data or trigger actions outside the intended business use. This is why authenticated abuse remains a major API risk: the request is legitimate at the transport and identity layer, but malicious at the intent and data-access layer. The control gap sits in authorisation scope, data exposure, and behavioural monitoring.

Practical implication: Add authorisation and exposure controls that detect misuse after authentication succeeds.

Threat narrative

Attacker objective: The attacker aims to use legitimate API access paths to extract data or abuse services without triggering perimeter-based assumptions.

1. Entry occurs when an attacker obtains legitimate user credentials or an authorised API key through social engineering or similar abuse.
2. Credential access is then used to call APIs in a way that appears valid to zero trust controls because the identity has already been authenticated.
3. Exfiltration or misuse follows when the attacker uses the API’s normal business functions to pull data or trigger unauthorised actions.

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 security is not solved by zero trust alone: zero trust changes how access is verified, but it does not eliminate the need to know which APIs exist, who owns them, and what data they expose. The article’s core lesson is that authenticated reachability is not the same as governed access. Practitioners should treat API discovery, authorisation scope, and exposure management as first-class identity controls, not downstream technical details.

Unknown API inventory is the real governance gap: if an API is not discovered, it is outside policy by definition. That creates a control failure that zero trust cannot repair after the fact because the asset never entered the trust model in the first place. This is a classic lifecycle problem for IAM and cloud teams, and it becomes sharper as APIs proliferate across hybrid environments.

Authenticated abuse is the blind spot many programmes miss: identity verification can be satisfied while business intent remains malicious. That means API security programmes must separate authentication from permitted data use, especially where service credentials, delegated tokens, and human-operated credentials intersect. The practitioner conclusion is clear: access validation alone does not equal access governance.

Shadow and zombie APIs are a governance debt, not just a technical backlog: outdated interfaces preserve unintended access long after owners assume they are gone. This is the exact kind of exposure that turns hybrid architecture into a control sprawl problem. Teams should frame API lifecycle discipline as part of zero trust operations, not as a separate hygiene task.

Zero trust needs an identity-to-data control layer in API estates: the model works best when it is paired with explicit API inventory, least-privilege scope, and telemetry on anomalous use. Without that layer, the organisation can authenticate requests while still losing control of what those requests can reach. Practitioners should align zero trust programmes with API authorisation and data exposure governance.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Zero Trust Identity Guide

What this signals

Zero trust programmes need an API inventory discipline: hybrid environments make it easy to authenticate everything and still lose sight of what is actually exposed. That means security leaders should treat discovery, ownership, and retirement of APIs as part of the zero trust operating model, not as a separate application task.

API exposure management is becoming an identity problem as much as a cloud problem: delegated tokens, service accounts, and authorised users can all reach sensitive functions when scope is too broad. Practitioners should expect zero trust to remain necessary but insufficient unless it is paired with explicit authorisation and visibility controls. This is exactly the kind of control layer that aligns with NIST SP 800-207 zero trust principles.

Excessive API reach creates governance debt: once obsolete or shadow APIs remain accessible, the organisation is carrying unseen exposure that can outlive the applications they support. Teams should fold API retirement, permission scoping, and anomalous-use detection into operational governance before the attack surface becomes too large to manage.

For practitioners

• Implement continuous API discovery Maintain an authoritative inventory of internal, external, and partner APIs, with named owners and retirement dates, so shadow and zombie interfaces cannot sit outside policy.
• Tighten API authorisation scope Review service tokens, user keys, and delegated permissions to ensure each API path only exposes the data and actions required for its business function.
• Separate authentication from data-use controls Apply monitoring for unusual query patterns, excessive data access, and function misuse even when requests are authenticated and accepted by zero trust policy.
• Retire outdated APIs on a fixed lifecycle Assign explicit decommissioning steps for obsolete APIs so old endpoints do not remain reachable after the business no longer uses them.

Key takeaways

• Zero trust improves verification, but it does not automatically solve API exposure, lifecycle, or misuse problems in hybrid environments.
• Salt’s webinar discussion points to two persistent gaps: unknown APIs and legitimate credentials being used in ways the business did not intend.
• The practical response is to combine zero trust with API discovery, tighter authorisation scope, and continuous monitoring for unusual data access.

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.
• Zombie API: A zombie API is a deprecated or abandoned interface that remains accessible after the organisation believes it should be retired. It is risky because old permissions, secrets, or backend trust can survive the business purpose, turning legacy access into an active exposure.
• Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
• API authorization scope: The set of data and actions an API is allowed to access after authentication succeeds. Scope matters because a valid identity alone is not enough to make access safe. If the scope is too broad, a single abused token or endpoint can expose far more than intended.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to connect identity controls to broader security architecture. It gives IAM, PAM, and security leaders a common operating model for governing machine identities and delegated access.