Notifications
Clear all
Topic starter
24/06/2026 8:53 pm
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
25/06/2026 5:45 am
API identity is now a governance domain, not a gateway feature. The article describes a common enterprise pattern where API management, human identity, and machine identity sit in different silos. That separation creates lifecycle gaps, inconsistent scoping, and weak revocation behaviour. The practical conclusion is that machine-to-machine access must be governed as identity, not treated as a transport concern.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: How do IAM and platform teams share responsibility for API security?
A: IAM teams should own entitlement model, lifecycle policy, and review standards, while platform teams enforce those decisions in gateways and service controls. The goal is not split accountability, but one operating model for machine access that both teams can measure and enforce consistently.
👉 Read our full editorial: API management and identity merge for machine-to-machine security
