Zero trust does not solve API security gaps in hybrid environments

At a glance

What this is: This webinar analysis argues that zero trust alone does not close API security gaps because APIs must remain reachable and can be abused through legitimate access.

Why it matters: It matters to IAM practitioners because API access is often granted to users, services, and workloads that sit outside traditional perimeter assumptions, creating identity and privilege risk that zero trust by itself cannot resolve.

By the numbers:

• 57% said zero trust is a major consideration in their current security architecture.
• 83% of internet traffic is API traffic, according to Roey Eliyahu in the webinar.
• 42% of organisations say outdated APIs are their biggest API security worry.
• 35% said zero trust is not yet a consideration but they are moving toward it.

👉 Read SALT's webinar analysis of zero trust and API security gaps

Context

Zero trust is a security model that assumes network location no longer proves trustworthiness. In API-heavy environments, that matters because access is frequently machine-to-machine, dynamic, and difficult to govern with perimeter-era controls. The primary API security issue is not whether access exists, but whether identities, permissions, and exposure are still controlled once access is granted.

This webinar frames the real gap as governance, not visibility alone. The identity intersection is clear: APIs depend on user credentials, service accounts, and keys, so IAM, PAM, and non-human identity controls become part of API security whether teams treat them that way or not. That starting position is typical for modern hybrid estates, not an edge case.

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 risk controls are actually working?

A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why. If the control is effective, suspicious traffic should be slowed, challenged, or blocked before it reaches core systems, while legitimate integrations continue to function normally.

Q: Who is accountable when an exposed API credential is abused?

A: Accountability should sit with the service owner and the identity governance function, not just the platform team. API credentials are lifecycle assets, so control failure usually spans design, issuance, monitoring, and retirement. Frameworks like the NIST Cybersecurity Framework 2.0 help structure that ownership.

Technical breakdown

Why zero trust struggles with API authentication

Zero trust reduces implicit trust, but it does not remove the need for authenticated access. APIs are designed to be consumed by applications, integrations, and users that must present credentials or tokens to function. That means the security model often shifts from blocking access to controlling what an authenticated caller can do. In practice, the hard part is not identity proof at the front door, but limiting scope, validating intent, and detecting abuse after authentication succeeds.

Practical implication: treat API authentication as only one control point, and pair it with least-privilege authorization and runtime abuse detection.

Shadow APIs and lifecycle blind spots

Unknown, obsolete, or duplicate APIs create a governance problem because no control can protect an asset the organisation has not inventoried. Shadow APIs often appear when development, testing, and deployment move faster than security review, while zombie APIs remain exposed after business use ends. That creates a lifecycle gap similar to unmanaged non-human identities: the asset still exists, still accepts requests, and still carries data access even when no one is actively governing it.

Practical implication: tie API discovery to asset lifecycle controls so exposed interfaces are reviewed, retired, or restricted continuously.

Authenticated abuse is the core API risk

Many API incidents do not involve bypassing authentication. Instead, attackers obtain valid user keys, tokens, or credentials through phishing, social engineering, or theft, then use the API exactly as designed to retrieve data or trigger actions. This is why identity assurance and privilege design matter as much as perimeter defence. When legitimate access becomes the abuse path, the control question changes from 'can they log in' to 'what can they do once they do'.

Practical implication: monitor authenticated API behaviour for excessive data access, unusual sequencing, and token misuse patterns.

Threat narrative

Attacker objective: The attacker aims to exploit legitimate API access paths to steal data or perform unauthorised actions while appearing authenticated.

1. Entry occurs when attackers obtain valid API keys, tokens, or credentials through social engineering or other theft methods.
2. Escalation happens when those authenticated callers use legitimate API functions to reach data or actions beyond intended use.
3. Impact follows when abused API access enables unauthorised data exposure or exfiltration without triggering perimeter-style blocks.

NHI Mgmt Group analysis

Zero trust is necessary but insufficient when APIs become the access layer. This webinar reinforces a pattern NHIMG sees across modern environments: access control can be technically sound while still failing operationally if the organisation cannot govern the machine-facing interfaces that carry most of the business traffic. APIs expose the identity gap between authentication and effective control, especially where user, workload, and service identities overlap. The practitioner conclusion is straightforward: zero trust must be paired with API discovery and privilege governance, not treated as a complete answer.

API exposure management is becoming a non-human identity problem in disguise. APIs are consumed by keys, tokens, service accounts, and workloads, so every unmanaged endpoint creates an identity and entitlement risk. That makes lifecycle, rotation, and offboarding controls just as relevant to API security as network policy. A useful named concept here is authenticated exposure drift: the condition where an API remains reachable and authorised long after the organisation has lost practical control over its use. Practitioners should treat that drift as an identity governance failure, not only a security architecture issue.

Shadow APIs create control debt that perimeter-era strategies cannot repay. If teams cannot inventory interfaces, they cannot set scope, monitor usage, or retire stale access paths. That gap aligns directly with NIST CSF functions for identify and protect, and with OWASP NHI thinking whenever APIs are backed by machine credentials. The practitioner conclusion is that discovery is not a side task, it is the prerequisite for every downstream control.

Authenticated abuse is the most realistic API attack pattern because it works with the system, not against it. Attackers do not need to defeat the API model when they can exploit its intended behaviour. That means detection has to focus on anomalous use, data volume, and sequence patterns rather than simple login success. The practitioner conclusion is to assume valid access can still be malicious and design for that failure mode explicitly.

What this signals

API-heavy environments are forcing identity programmes to absorb responsibilities that used to sit in application teams. The practical shift is toward continuous discovery of machine-facing access, tighter scoping of tokens and service accounts, and better separation between approved traffic and accepted risk. For teams already working from the Ultimate Guide to NHIs , Key Challenges and Risks, this topic reinforces that interface visibility and credential governance are now inseparable.

Authenticated exposure drift: the longer an API remains live without active governance, the more likely it is to behave like an unmanaged identity surface. That is why API security programmes need to align with NIST SP 800-207 Zero Trust Architecture but not stop there. The reader-level signal is simple: if your monitoring cannot tell authorised use from abusive use, your controls are still too coarse.

For practitioners, the next phase is less about perimeter language and more about operational control of the full access path. Inventory, deprecation, token scoping, and authenticated anomaly detection should be treated as one programme rather than separate disciplines. Where workload identity and service access are involved, the Guide to SPIFFE and SPIRE is a useful adjacent reference for strengthening machine identity governance.

For practitioners

• Inventory all exposed APIs continuously Build automated discovery across production, test, and deprecated environments so security teams can identify shadow and zombie APIs before they become blind spots. Tie findings to asset owners and retirement dates so unowned endpoints cannot persist indefinitely.
• Bind API access to least-privilege scopes Review tokens, keys, and service accounts to ensure each API caller can reach only the endpoints and fields required for its task. Reduce broad read permissions and separate administrative functions from routine application traffic.
• Monitor authenticated behaviour, not just authentication events Detect excessive data extraction, unusual request sequencing, and atypical use from valid identities because many attacks will present as legitimate API traffic. Feed those signals into alerting and investigation workflows.
• Retire stale interfaces and credentials together When an API is deprecated, remove the interface, revoke the related keys or tokens, and confirm no downstream integrations still depend on it. Treat API decommissioning as an access removal exercise, not only a release-management task.

Key takeaways

• Zero trust reduces implicit trust, but it does not solve API governance when interfaces are unknown, stale, or overexposed.
• Authenticated API abuse is a realistic attack path because valid credentials can still be used to extract data or trigger unauthorised actions.
• The control priority is discovery plus privilege scoping plus runtime monitoring, because one control alone does not secure an API-heavy environment.

Key terms

• 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.
• 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.
• Authenticated Abuse: The misuse of legitimate credentials or sessions to perform actions that are technically allowed but operationally unsafe. In API environments, this often means an attacker uses valid keys, tokens, or accounts to access data or trigger functions in ways that bypass perimeter thinking.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

SALT's full webinar write-up covers the operational detail this post intentionally leaves for the source:

• The webinar discussion between Roey Eliyahu and Ed Amoroso on why API security and zero trust diverge in practice.
• The survey results and live commentary around where practitioners currently place zero trust in their security architecture.
• The specific examples of shadow, zombie, and authenticated API abuse discussed during the session.
• The source article's framing of how API design, access, and exfiltration intersect in real deployments.

👉 SALT's full article expands on the survey findings, API abuse examples, and the zero trust limits discussed in the webinar.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, secrets management, and workload identity. It helps practitioners connect machine access patterns to identity controls across hybrid environments.