How should platform teams implement service discovery across both gateway-managed and unmanaged APIs?

Why This Matters for Security Teams

service discovery is the control point that determines whether platform teams can see every API that exists, who owns it, and whether it is governed consistently. Gateway-only views miss shadow endpoints, internal services, and legacy APIs that bypass the gateway entirely. That creates duplicate services, unknown exposure, and policy gaps that persist long after the original deployment has changed.

Current guidance suggests treating discovery as a continuously reconciled inventory problem aligned to governance, not a one-time catalog exercise. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is a useful proxy for the visibility gap that also affects API ownership and runtime accountability. NIST CSF 2.0 reinforces this operationally by placing visibility and continuous monitoring at the centre of a defensible program through NIST Cybersecurity Framework 2.0.

In practice, many security teams discover unmanaged APIs only after an incident review, when the service was already live, externally reachable, and outside the normal approval path.

How It Works in Practice

Effective service discovery pulls from multiple sources and reconciles them into one authoritative view. Gateway logs tell you what is fronted and enforced. Code repositories reveal services before they are deployed. Incident tools and observability platforms expose what is actually running. Cloud inventory, container orchestrators, and DNS records help close the gap between intended and observed exposure. The discovery layer should normalize these signals into a single record per service, with ownership, runtime status, authentication method, and policy coverage attached.

A practical model is to treat discovery as a continuous join between control-plane and runtime data. Gateways remain important for policy enforcement, but unmanaged APIs still need to be found through telemetry and infrastructure signals. That means ingestion from CI/CD, OpenAPI specs, service meshes, cloud metadata, and logging platforms, followed by deduplication and ownership resolution. Where the organisation already maintains NHI lifecycle controls, the same inventory discipline should extend to API credentials and machine-to-machine access, as described in the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

• Collect from gateways, repos, service meshes, cloud assets, and observability tools.
• Match services by name, route, certificate, cluster identity, and owning team.
• Mark whether a service is gateway-managed, unmanaged, or partially governed.
• Attach required controls such as auth, secrets handling, and policy coverage.
• Flag drift when runtime services appear without a matching approved record.

NIST SP 800-53 Rev. 5 is useful here because it supports inventory, monitoring, and configuration discipline through NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down when discovery depends only on gateway registration because services deployed through sidecars, direct cluster networking, or legacy integrations never enter the managed path.

Common Variations and Edge Cases

Tighter discovery often increases engineering and operations overhead, requiring organisations to balance completeness against the cost of maintaining a clean inventory. That tradeoff becomes real in hybrid environments, where some APIs are intentionally unmanaged for latency, partner integration, or legacy compatibility.

Best practice is evolving, but current guidance suggests separate classification for “unknown,” “unmanaged,” and “out of policy” rather than forcing every API into the same workflow. This avoids blocking legitimate services while still surfacing risk. API gateways should not be treated as the source of truth when teams run multiple gateways, regional deployments, or service-to-service traffic that never traverses an edge control. In those cases, discovery should rely on runtime telemetry and ownership mapping instead of assuming a single enforcement plane.

For organisations already tracking NHI risk, discovery also supports audit and lifecycle decisions, especially where secrets, service accounts, and API keys are tied to APIs with different control levels. NHI Mgmt Group’s research on Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks is relevant because unmanaged APIs often become the path through which unmanaged credentials persist.

Discovery breaks down most often in fast-moving microservice estates, where ephemeral services appear and disappear faster than ownership records are updated.

Related resources from NHI Mgmt Group

• How should security teams balance managed API gateway simplicity with cloud and regulatory constraints?
• What breaks when API gateway teams rely on one size fits all managed configurations?
• How should security teams make NHI best practices usable across the business?
• How should security teams govern Active Directory service accounts?