Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Machine-to-machine API security: what practitioners need to change


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 5855
Topic starter  

TL;DR: API traffic is expanding quickly, with 25% of businesses saying the number of APIs they manage doubled or more last year, while machine-accessed endpoints remain exposed to credential stuffing, scraping, and abuse according to Arkose Labs and Salt's State of API Security Report 2025. Browser-era controls do not translate cleanly to machine-to-machine traffic, so identity, rate, and risk controls must move to the edge.

NHIMG editorial — based on content published by Arkose Labs: machine-to-machine API security and edge protection

By the numbers:

Questions worth separating out

Q: What breaks when browser-based controls are used to protect machine-to-machine APIs?

A: Browser-based controls often fail because machine clients do not generate the same telemetry, user interaction, or client-side signals that those tools expect.

Q: Why do machine-to-machine APIs increase abuse risk in enterprise environments?

A: They increase risk because they expose high-value functions directly to automated clients, often with long-lived tokens or broad access scopes.

Q: How can security teams tell whether API risk controls are actually working?

A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why.

Practitioner guidance

  • Map machine API clients to named identity owners Inventory service accounts, application tokens, and integration keys separately from user identities, and require an accountable owner for each client path.
  • Enforce rate and risk controls at the API edge Apply throttling, contextual scoring, and request inspection before traffic reaches backend services so abusive automation can be slowed or blocked early.
  • Remove browser-dependent assumptions from machine flows Audit any control that depends on JavaScript, browser fingerprinting, or interactive user behavior and replace it with machine-appropriate enforcement points.

What's in the full article

Arkose Labs' full article covers the operational detail this post intentionally leaves for the source:

  • Concrete examples of how edge protection inspects and classifies machine-to-machine API traffic
  • The article's specific set of countermeasures for credential stuffing, scraping, and inventory abuse
  • Operational detail on how risk-based authentication is applied without breaking legitimate integrations
  • A fuller explanation of how Arkose Edge integrates with existing API gateways and management platforms

👉 Read Arkose Labs' analysis of machine-to-machine API security and edge protection →

Machine-to-machine API security: what practitioners need to change?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 1 month ago
Posts: 5343
 

Machine-to-machine API traffic exposes an identity gap, not just an application gap. The article is right to focus on the edge, but the deeper issue is that machine access is often governed as connectivity rather than identity. When service accounts, tokens, and integration keys are treated as plumbing, abuse detection becomes a late-stage network concern instead of an identity control. The practitioner conclusion is that API protection and NHI governance need to converge.

A few things that frame the scale:

  • 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
  • Only 5.7% of organisations have full visibility into their service accounts, which shows how limited machine identity oversight remains in many programmes.

A question worth separating out:

Q: Who should be accountable for machine API security when business services depend on it?

A: Accountability should sit with the team that owns the client identity, the API policy, and the downstream business function together. If ownership is split across platform, application, and security teams, abuse paths tend to survive because no one controls the full lifecycle of the credential or the edge policy.

👉 Read our full editorial: Machine-to-machine API security is lagging behind enterprise growth



   
ReplyQuote
Share: