Many organisations should, because different customers and integrations have different control expectations. Supporting both can be sensible when one group needs simple self-service keys and another needs OAuth-based JWTs. The governance requirement is to keep the two models distinct in policy, inventory, and review so the controls do not blur.
Why This Matters for Security Teams
Supporting both api key and machine-to-machine applications can be the right product decision, but it creates two different trust models that must not be managed as one. API keys are usually simpler to issue and easier for customers to adopt, while M2M applications using OAuth and JWTs support richer policy, better scoping, and stronger lifecycle controls. The risk is not the coexistence itself, but the tendency to let review, inventory, and revocation practices blur.
That blur matters because secrets and tokens are now heavily targeted. NHIMG research in the State of Secrets Sprawl 2026 shows AI-related credential leaks surged 81.5% year-over-year in 2025, which is a useful signal that exposed credentials remain a fast-moving attack path. The broader lesson aligns with the NIST Cybersecurity Framework 2.0: identity, access, and monitoring have to be explicit and measurable, not implied by the application tier.
In practice, many security teams discover the weakness only after a leaked key or overbroad token has already been used to access production systems.
How It Works in Practice
The cleanest pattern is to treat API keys and M2M apps as separate product surfaces with separate governance. API keys work best for straightforward integrations where customers want quick onboarding, lower implementation friction, or legacy compatibility. M2M applications are better when the integration needs scoped authorization, JWT-based claims, token expiry, or federated identity between services. Current guidance suggests that these models should share policy principles, but not the same operational control path.
At minimum, organisations should distinguish them in the identity inventory, approval workflow, logging, and review cadence. That means each API key should map to a named customer, system, or use case, and each M2M app should have a distinct application registration, redirect or grant configuration where applicable, and defined scopes. A key should not be treated as a “poor man’s OAuth client,” and an M2M app should not be used merely to hide a long-lived secret.
- Use API keys for simple, low-complexity access where narrow function and rapid issuance matter.
- Use M2M applications for delegated service access, finer-grained scope control, and stronger auditability.
- Apply different rotation, expiry, and revocation rules to each model.
- Track both in a single inventory, but do not collapse their assurance requirements.
For control design, the Guide to the Secret Sprawl Challenge is a strong reminder that discovery without automated revocation leaves valid credentials exploitable, and the fastest path to compromise is often stale access that nobody remembers owns. These controls tend to break down when integration teams let customers choose either model without enforcing a unique owner, expiry, and monitoring standard.
Common Variations and Edge Cases
Tighter separation between API keys and M2M apps often increases onboarding overhead, so organisations have to balance user convenience against stronger assurance and auditability. That tradeoff is real, especially when a product supports both developer self-service and enterprise integration contracts.
One common edge case is migration. Legacy customers may only support API keys, while newer integrations demand OAuth-based M2M access. Best practice is evolving here: there is no universal standard for whether both models must eventually converge, but there should always be a documented migration path, not permanent ambiguity. Another edge case is automation tooling that uses API keys for initial bootstrap and then exchanges them for short-lived tokens. That can be acceptable if the bootstrap secret is tightly scoped and short-lived, but it becomes risky when the bootstrap key is effectively a permanent bearer credential.
Support both models only if the organisation can answer three questions without hesitation: who owns the credential, how is it scoped, and how is it revoked. If those answers differ between API keys and M2M apps, the distinction is meaningful. If they do not, one of the models is probably just masking weak governance. NHIMG’s Cisco DevHub NHI breach and BeyondTrust API key breach illustrate how quickly exposed or overprivileged non-human credentials become an operational incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Separates NHI types and reduces credential confusion across API keys and M2M apps. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access control must distinguish machine principals and their permissions. |
| NIST AI RMF | AI risk governance applies where autonomous integrations use keys or tokens dynamically. |
Document ownership, monitoring, and incident response for every machine integration before production use.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
