The set of controls that decide which software identity can call which API, under what conditions, and with what data scope. It is a governance problem as much as a technical one, because service accounts, tokens, and partner integrations need ownership, review, and revocation.
Expanded Definition
Machine-to-machine authorisation is the policy layer that determines whether a software identity can invoke an API, exchange data, or trigger an action. In practice, it sits between authentication of the calling workload and enforcement of the exact permissions, scopes, and conditional checks that apply to the request. At NHI Management Group, this is treated as an identity governance issue, not just an API design choice, because service accounts, workload tokens, and partner integrations require ownership, periodic review, and timely revocation.
The term is often used alongside OAuth, service-to-service tokens, and workload identity, but it is broader than any single protocol. Definitions vary across vendors when they blur authorisation with authentication or when they describe static API keys as if they were full governance controls. For a control-oriented view, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it frames access control, account management, and auditability as separable responsibilities. The most common misapplication is treating possession of a valid token as sufficient authorisation, which occurs when organisations fail to bind scopes, context, and lifecycle ownership to the calling identity.
Examples and Use Cases
Implementing machine-to-machine authorisation rigorously often introduces more policy overhead, requiring organisations to weigh reduced blast radius against operational complexity in automation-heavy environments.
- A payment service can call a ledger API only for write operations on a specific tenant namespace, with approval tied to a named workload identity.
- A CI/CD pipeline uses short-lived credentials to deploy only to approved environments, with separate scopes for read, build, and release actions.
- A partner integration can retrieve customer records only through a narrow API scope, with monitoring and revocation mapped to the business owner of the relationship.
- An internal microservice is allowed to read configuration from one service and publish events to another, but cannot enumerate broader platform resources.
- A privileged automation job uses conditional authorisation that checks environment, source workload, and time window before permitting a destructive action.
These patterns align with control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls and with identity-assurance thinking from NIST SP 800-63 Digital Identity Guidelines when software identities are issued, bound, and revalidated as part of a trust decision.
Why It Matters for Security Teams
Security teams need this concept because machine-to-machine access tends to expand quietly through automation, vendor links, and service accounts that outlive the systems that created them. If authorisation is not explicit, the organisation inherits hidden dependencies, overly broad scopes, and weak revocation paths that are difficult to unwind during incident response. This is especially important where Non-Human Identity governance is involved, because workloads often receive standing access without the ownership, approval, and review disciplines applied to human users.
From a governance perspective, weak machine-to-machine authorisation undermines segmentation, makes audit trails less reliable, and increases the impact of secret leakage or token replay. The issue is not only whether an API request is technically accepted, but whether the calling identity should still exist, still hold the same scope, and still be trusted in the current environment. Related control thinking also appears in NIST SP 800-63 Digital Identity Guidelines when assurance, binding, and lifecycle management are considered together. Organisations typically encounter the real cost only after a token, service account, or partner connection is abused, at which point machine-to-machine authorisation becomes operationally unavoidable to address.
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, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Access control governs which identities can reach which resources and under what conditions. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management covers creation, ownership, review, and disabling of software identities. |
| NIST SP 800-63 | AAL2 | Digital identity guidance informs assurance and binding for credentialed access decisions. |
| OWASP Non-Human Identity Top 10 | Non-human identity governance addresses service accounts, tokens, and their lifecycle risks. | |
| NIST Zero Trust (SP 800-207) | Zero trust requires explicit verification of each request, including service-to-service calls. |
Verify every machine request dynamically instead of trusting network location or prior access.
