TL;DR: API authentication still relies on static keys and shared secrets in 84% of organisations, while one survey found only one of 68 companies had deployed a fully modern hardened approach, according to Raidiam’s 2025 API security profiling study. That leaves machine identities governed as if they were human logins, which is the wrong control model for NHI security.
NHIMG editorial — based on content published by Raidiam: The API Security Gap: Why Most Enterprises Are Still Vulnerable API Security
By the numbers:
- Our recent industry survey found that about 84% of organizations rely on either bare API keys or basic shared secrets for API authentication.
- Only one out of 68 companies in that survey had implemented a fully modern, hardened API protection solution.
- non-human identities (applications, scripts, services) often outnumber human users by 45:1
Questions worth separating out
Q: How should security teams reduce risk from static API credentials?
A: Start by inventorying every API key, secret, and certificate, then assign ownership and expiry.
Q: Why do static API keys create more risk than human authentication?
A: Static API keys are usually reusable, long-lived, and easy to copy into code or configuration.
Q: What breaks when machine identities are not governed like other NHIs?
A: Access reviews become incomplete because the organisation cannot see which API credentials still exist, who owns them, or whether they are still needed.
Practitioner guidance
- Inventory all API credentials and owners Build a register of API keys, shared secrets, client certificates, and token issuers.
- Replace shared secrets on crown-jewel APIs Move the highest-value interfaces first to mutual TLS, PKI-based client certificates, or signed token flows.
- Enforce rotation and revocation as lifecycle controls Treat API credential rotation as a governance requirement, not an emergency task.
What's in the full article
Raidiam's full report covers the operational detail this post intentionally leaves for the source:
- Benchmark data on API key and shared-secret use across organisations, useful for comparing your own maturity.
- Practical examples of modern API protection patterns, including certificate-based authentication and signed-token approaches.
- Regulatory compliance considerations for API authentication and machine identity controls.
- The report's own survey evidence and source references behind the 2025 API security profiling study.
👉 Read Raidiam's analysis of the API security gap and machine identity risk →
API security gap: what IAM teams need to change now?
Explore further
Static API credentials are a machine-identity assumption failure, not a tooling gap. The article shows that enterprises still treat many API callers as if a permanent secret is enough to establish trust. That assumption was designed for low-friction automation, not for environments where credentials are embedded, replicated, and difficult to observe. The implication is that API security programmes must stop treating static secrets as normal state and treat them as residual risk by default.
A few things that frame the scale:
- Only one out of 68 companies in that survey had implemented a fully modern, hardened API protection solution, according to The State of Non-Human Identity Security.
- In the same research, 1.5 out of 10 organisations said they are highly confident in their ability to secure NHIs, showing that machine identity governance still trails human identity confidence.
A question worth separating out:
Q: Who is accountable when an exposed API credential is abused?
A: Accountability should sit with the service owner and the identity governance function, not just the platform team. API credentials are lifecycle assets, so control failure usually spans design, issuance, monitoring, and retirement. Frameworks like the NIST Cybersecurity Framework 2.0 help structure that ownership.
👉 Read our full editorial: API security gaps expose machine identities to static credential abuse