An M2M access token is a bearer credential used by one machine or service to call another service without a human user present. It usually carries scoped permissions and a limited lifetime, and is presented to an API or resource server for authentication and authorisation.
What a machine-to-machine access token is for
An M2M access token is the runtime credential that lets one workload call another without a person signing in. Its value is not just that it authenticates a caller, but that it does so in a way that can be narrowly scoped to a service, API, or action.
That makes the token a security boundary, not just a transport detail. In a well-designed system, the token expresses who or what is calling, what it may access, and for how long that access should remain valid.
How M2M access tokens are issued and presented
Most M2M flows rely on an upstream trust decision, then hand the calling service a token it can present to a resource server. Common patterns include OAuth 2.0 client credentials, workload identity federation, mTLS, and token exchange, depending on how the system establishes trust between services.
The important design point is that the token is usually bearer material unless it has been sender-constrained. That means possession is enough to use it, so the issuance path, storage path, and transport path all matter. RFC 6749: The OAuth 2.0 Authorization Framework defines the core OAuth model used by many machine-to-machine implementations.
Where stronger binding is needed, organisations often move toward proof-of-possession or certificate-bound approaches so stolen tokens are harder to replay. RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens and RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) show two common ways to reduce replay value.
Security properties that make the token safe or unsafe
Three properties matter most: scope, lifetime, and audience. Scope limits what the token can do, lifetime limits how long it is useful, and audience limits where it can be presented. If any of those are too broad, the token becomes a portable privilege rather than a tightly governed session.
That is why M2M tokens are often treated as part of access governance as much as authentication. A service token that can be reused across environments, APIs, or tenants creates far more blast radius than one that is tied to a single target and expires quickly. RFC 8707: Resource Indicators for OAuth 2.0 is relevant because audience restriction is one of the main ways to keep a token from being accepted everywhere.
In practice, the token’s safety depends on adjacent controls as well: secret storage, key protection, rotation, logging, and the ability to revoke or replace credentials after compromise. For that reason, many organisations pair token design with broader guidance on token handling and session security, such as Token and Session Security Guide.
Common failure modes and why they matter
The most common failures are long-lived tokens, overbroad scopes, weak client authentication, and token leakage through code, logs, CI/CD systems, or memory. Once a bearer token is exposed, an attacker often does not need to break the application again, only to replay the token before it expires or is revoked.
That is why this credential class is so often involved in lateral movement and data access after initial compromise. A compromised M2M token can let an attacker impersonate a trusted workload, move through service boundaries, or query data and functions that were never intended for an external actor.
RFC 9700: Best Current Practice for OAuth 2.0 Security is useful here because it reflects current defensive thinking on token theft, replay, and sender-constrained deployments. Real-world breach reporting, including Internet Archive breach 2024 and Sourcegraph breach 2023, shows how an exposed token can turn into durable access if it is not rotated and contained quickly.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | M2M access tokens are credentials whose issuance, rotation and revocation fit authenticator lifecycle control. |
| IA-9 — Service Identification and Authentication | This term is about machine or service authentication between systems, which IA-9 directly addresses. | |
| AC-6 — Least Privilege | Token scope determines what the machine can access, so least privilege is central to the subject. | |
| Recommendation — Manage token issuance, expiration, rotation and revocation so service credentials stay short-lived and controlled. Authenticate services with a method that binds the token to the calling workload and prevents unsafe reuse. Limit token scopes to the smallest set of API actions and resources the service actually needs. | ||
| OWASP ASVS | V10 — OAuth and OIDC | The subject commonly uses OAuth-based machine-to-machine flows and token handling requirements. |
| Recommendation — Verify OAuth client authentication, audience restriction and token handling rules for machine-to-machine flows. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | M2M tokens authenticate non-human callers, so insecure token authentication is a direct failure mode. |
| Recommendation — Use stronger client authentication and token binding so a stolen bearer token cannot be reused easily. | ||
Practitioner Guidance
Why practitioners should care: Treat M2M access tokens as short-lived, tightly scoped privileges, not as disposable implementation details. The main governance question is whether each token can be traced to one workload, one purpose, and one bounded trust relationship.
What to watch for: Large blast radius usually appears first as token reuse across environments, broad API reach, missing sender constraints, or weak revocation discipline. If a token can outlive the workload or be copied into places the workload itself should not reach, the design is already too permissive.
Practitioner takeaway: The safest M2M token is one that is hard to steal, hard to replay, and easy to replace.
Related resources from NHI Mgmt Group
- Guide: NHI Authentication Guide
- Should organisations prioritise token controls before expanding SaaS access?
- What is the difference between access token abuse and refresh token abuse?
- What is the difference between OAuth and token exchange for AI agent access?
- Should applications use one OAuth access token for multiple APIs?