Notifications
Clear all
Topic starter
01/08/2026 8:56 pm
TL;DR: Zero trust is widely adopted, with 57% calling it a major consideration and 83% of internet traffic now described as API traffic in Salt Security’s webinar discussion, but the same controls can fail when APIs are unknown or abused by authenticated users. The governance gap is not trust alone, it is inventory, privilege, and exposure management across machine-access pathways.
NHIMG editorial — based on content published by SALT: a webinar discussion on API security and zero trust
By the numbers:
- 57% said zero trust is a major consideration in their current security architecture.
Questions worth separating out
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.
Q: Why do authenticated API users still create security risk?
A: Because valid credentials can still be abused.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read SALT's webinar analysis of zero trust and API security gaps →
API security and zero trust: where existing controls fall short?
Explore further
01/08/2026 9:04 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Zero trust does not solve API security gaps in hybrid environments
