API management and identity: what it means for IAM teams

TL;DR: Fragmented API management and identity controls create manual key handling, inconsistent token use, and hidden exposure for machine-to-machine access, according to Kong. Unifying those functions can reduce operational drag, but the core security problem is still governance of application identity, not just easier connectivity.

NHIMG editorial — based on content published by Kong: Merge API Management & Identity to Unlock Your API Platform's Potential

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

Questions worth separating out

Q: How should security teams govern API keys and tokens as machine identities?

A: Treat every API key, client secret, and token as an identity with an owner, scope, expiry, and revocation path.

Q: Why do separate API and identity systems create security risk?

A: Separate systems create duplicate policy logic, inconsistent token handling, and weak visibility into who can still access what.

Q: What do organisations get wrong about machine-to-machine access?

A: They often treat it as a connectivity problem instead of an identity problem.

Practitioner guidance

• Map machine identities to owners and expiry dates Build an inventory of every API key, client secret, and token issuer, then assign a business owner, technical owner, and enforced expiry.
• Centralise token issuance and scope policy Move access decisions into a single gateway or authorisation layer so scopes, claims, audiences, and revocation logic are enforced consistently.
• Eliminate static credentials from source and shared channels Scan repositories, CI/CD pipelines, and collaboration tools for embedded secrets, then replace them with managed identity flows and short-lived credentials.

What's in the full article

Kong's full blog covers the operational detail this post intentionally leaves for the source:

• The specific Konnect and Kong Identity capabilities for defining clients, scopes, and claims
• How dynamic claim templates are applied in the platform for machine-to-machine requests
• The product-level explanation of how per-region authorization servers are configured and used
• The implementation view of how API gateway enforcement reduces backend authentication logic

👉 Read Kong's analysis of merging API management and identity for machine-to-machine security →

API management and identity: what it means for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →