How to Audit Whether Your APIs Actually Enforce Zero Trust

Start with a plain list, not a diagram: every public endpoint, every internal service-to-service call, every admin route, every webhook a partner can hit, and every path CI/CD uses to deploy or roll back. Teams that skip this step end up auditing the five endpoints they remember and missing the internal billing service that still takes an unauthenticated call from "trusted" infrastructure.

Pull this list from your API gateway config, your service mesh (if you run one), and your load balancer rules, not from memory or an old architecture doc. Cross-check it against actual traffic logs for a week; anything receiving requests that isn't on your list is itself a finding.

Two categories get missed almost every time: health-check and metrics endpoints that were never meant to be reachable from outside the cluster but ended up exposed by a misconfigured load balancer rule, and old API versions that engineering assumed were retired but a handful of clients are still quietly calling. Add both to your list explicitly rather than assuming they're covered by "everything else."

Pick ten endpoints across different services and actually attempt the bypass: call one with an expired token, one with the right token but the wrong scope, one over plain HTTP where mTLS should be required, one from an IP outside your expected ranges. Write down what happened, not what should have happened.

This is where most audits find the gap between the architecture doc and production. A service that "requires" a valid JWT will often still process the request and only fail on a later step, quietly leaking data before the rejection.

Zero trust means no service gets a pass because it's "inside the VPC." Go through your service-to-service calls and flag any that skip authentication because the caller is on the same subnet, in the same Kubernetes namespace, or behind the same load balancer. This pattern survives longest in older internal tools: an admin dashboard, a reporting job, a batch script someone wrote three years ago and never touched again.

For each one you find, decide whether it gets a real identity and authentication now or goes on a dated remediation list. Don't leave it undecided.

A firewall rule is not an identity. Check whether each service authenticates as itself (a workload certificate, a signed service token, a SPIFFE identity) or whether it's sharing a static API key with five other services. Shared keys are the most common finding in this kind of audit: they're easy to rotate on paper and almost never actually rotated, because nobody can list everything that would break.

Separately, check human access: are engineers using personal accounts with MFA to reach production APIs, or is there a shared "ops" credential floating around in a password manager? Those need different fixes.

A quick way to find shared keys without reading every config file is to look at your traffic logs for a single credential making calls from more than one service's network location; that pattern almost always means the key is shared rather than scoped to one workload.

An audit that ends in a report nobody reopens didn't happen. Every finding needs a named owner, a target date, and a severity that maps to how exposed it is: an unauthenticated internal-only endpoint is not the same severity as a public API accepting expired tokens. Federal patch guidance for internet-facing, critical vulnerabilities sets a genuinely tight remediation window, and it's a reasonable anchor for how fast your own public-facing findings should move¹.

Put the list somewhere your team already looks, a sprint board, not a shared drive folder, and revisit it on a fixed schedule rather than waiting for the next audit to notice it never got fixed.

Run the audit in this order:

1. List every public endpoint, internal call, admin route, webhook and deployment path, using gateway config and traffic logs rather than memory.
2. Attempt real bypasses on a sample of endpoints, using expired tokens, wrong scopes, plain HTTP and unexpected IP ranges, and record what happened.
3. Flag every service call that skips authentication because the caller sits on the same subnet, namespace or load balancer.
4. Check whether each service authenticates as itself or shares a static API key with other services.
5. Assign every finding a named owner, a target date and a severity based on how exposed the affected endpoint is.