Notifications
Clear all
Topic starter
19/08/2026 3:39 pm
TL;DR: APIs now underpin app integration, mobile services, IoT, chatbots, and healthcare workflows, but the article’s core warning is that this same reach expands the attack surface and makes security controls harder to maintain, according to Pynt. The identity problem is not the API itself but the credentials, permissions, and trust relationships attached to it.
NHIMG editorial — based on content published by Pynt: 10 Amazing Facts About the API Revolution That Will Blow Your Mind!
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams govern API credentials in SaaS environments?
A: Treat API credentials as non-human identities with owners, purpose, scope, and expiry.
Q: Why do APIs create identity risk for IAM and PAM programmes?
A: Because APIs rarely operate without credentials, and those credentials often outlive the service they support.
Q: What do security teams get wrong about API perimeter controls?
A: They assume syntax inspection and request reputation are enough.
Practitioner guidance
- Map every API to an owning identity Create an inventory that links each API to its service account, token issuer, certificate, and business owner so revocation is always traceable.
- Move secrets out of code and pipelines Eliminate hardcoded API keys in source repositories, configuration files, and CI/CD variables.
- Constrain API permissions to task scope Review each API’s effective permissions and remove broad access to downstream services that the workload does not need.
What's in the full article
Pynt's full article covers the operational detail this post intentionally leaves for the source:
- Examples of how APIs support mobile, IoT, chat, voice, and healthcare integrations in practice.
- The article's broader explanation of where APIs sit in modern software architectures and business models.
- The source's discussion of how API security fits alongside innovation goals without slowing development.
- The vendor's own framing of why API growth changes the way teams should think about software delivery.
👉 Read Pynt's analysis of how APIs changed software integration and security risk →
API sprawl and security governance: what IAM teams need to know?
Explore further
19/08/2026 4:19 pm
API governance is identity governance once systems depend on secrets and delegated trust. The article describes APIs as a business enabler, but operationally every API call is a statement about who or what may act on behalf of a system. That makes API security inseparable from IAM, PAM, and NHI lifecycle management. The practitioner conclusion is simple: if you cannot govern the credential, you do not fully govern the API.
A question worth separating out:
Q: Which frameworks require stronger API governance and access control?
A: PCI DSS, GDPR, NIST SP 800-53, and Zero Trust guidance all expect organisations to know what they expose, limit access, and monitor use. For identity and security teams, the practical test is whether each API has a named owner, bounded access, and evidence of continuous control operation. If not, the framework requirement is only partially met.
👉 Read our full editorial: APIs expand attack surface and identity risk across modern systems
