Treat supplier-issued tokens, service accounts, and API keys as scoped access that must expire, be monitored, and be revoked when the commercial or technical relationship changes. Supplier governance only works when offboarding includes credential removal, not just contract closure or ticket closure.
What third-party machine access means in an ISO 27001 programme
Third-party machine access is not just a vendor issue, it is an access-governance issue. Under an ISO 27001 programme, supplier-issued tokens, service accounts, API keys, and similar access material should be treated as controlled credentials with an owner, purpose, expiry, and revocation path. The control objective is to keep external access bounded, reviewable, and removable when the relationship changes.
For teams that need a practical operating model, the key question is whether the access material is tied to a named business purpose and a known supplier relationship. That is where ISO 27001 discipline matters most: access should be issued only for a justified need, limited to the minimum scope, and managed through its full lifecycle rather than left to contract language alone. See also ISO/IEC 27001:2022 Information Security Management and ISO/IEC 27002:2022 Information Security Controls.
That same lifecycle view is why third-party machine access should be treated as part of identity governance, not just procurement or service management. If a supplier can authenticate to systems, the organisation must know who owns the access, what it can reach, how it is monitored, and when it is expected to expire. For a deeper practitioner lens on third-party access patterns, Third-Party, B2B and Contractor Access Guide is the most direct internal reference.
How to scope, monitor, and revoke supplier-issued credentials
The safest pattern is to issue the narrowest credential possible for the shortest practical period. That means separate credentials per supplier, per environment, and per use case where feasible, with logging enabled from day one. If a token or API key is shared across multiple integrations, the blast radius becomes harder to contain and revocation becomes risky because one change can break unrelated services.
Monitoring matters because many third-party credentials fail quietly. A token can remain valid long after the business team thinks a contract has ended, or after the technical integration has been replaced. Good practice is to inventory these credentials, review their last use, confirm their owner, and test that revocation actually removes access from the target system. Internal case material such as Salesloft OAuth token breach and GitHub OAuth token breach 2022 shows why token scope, rotation, and revocation discipline matter in real third-party access chains.
Revocation should be part of the offboarding checklist, not a separate optional task. When the commercial relationship ends, the technical relationship must end too, including credentials, federation trust, service accounts, and any stored secrets that can still authenticate. If you only close the contract or the ticket, the access may still exist.
What teams should verify before they trust third-party machine access
Teams should verify four things before treating supplier access as acceptable: the credential has a clear owner, the scope matches the approved use case, the expiry and rotation process are defined, and revocation has been tested. If any one of those is missing, the access is not fully governed even if it is technically working.
It also helps to separate operational convenience from control quality. Long-lived tokens and broad reusable keys reduce friction, but they increase persistence risk and make incident response slower. Where the supplier is using machine-to-machine access, the team should confirm whether the integration can support audience restriction, certificate binding, short-lived tokens, or other constraints that reduce dependence on a static secret. The OAuth 2.0 foundation at RFC 6749: The OAuth 2.0 Authorization Framework is useful background, and RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens and RFC 8707: Resource Indicators for OAuth 2.0 describe stronger constraints that can reduce token misuse.
Risk and Threat Considerations
Third-party machine access creates a durable trust path that attackers like because it often survives normal user offboarding and can be hard to spot in ticketing records. If supplier credentials are stale, over-scoped, or reused across services, compromise of one partner account can become a direct path into internal systems or data stores.
Failure mechanism: The usual failure is lifecycle drift, the business relationship changes, but the access path remains valid because no one rotates or revokes the credential, or because multiple systems depend on the same secret.
Impact: That drift can enable unauthorized access, data exposure, persistence after offboarding, and delayed incident containment, especially where third-party tokens are embedded in automations or shared across environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
ISO/IEC 27001:2022 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.15 — Access control | Supplier machine access must be scoped and revoked under access control. |
| A.5.19 — Information security in supplier relationships | Directly governs security expectations for supplier-issued access and offboarding. | |
| A.5.20 — Addressing information security within supplier agreements | Contract terms should require credential lifecycle and revocation obligations. | |
| Recommendation — Limit third-party credentials to approved access and remove them when the need ends. Define supplier access, review it regularly, and require secure offboarding. Bake credential expiry, monitoring, and revocation duties into supplier terms. | ||
Practitioner Guidance
What to prioritise: Put supplier-issued credentials on the same review path as privileged internal access. If a third party can reach production data or administrative functions, require a named owner, expiry date, and documented revocation trigger.
What to verify: Confirm that offboarding removes the credential itself, not just the supplier record. Test revocation in the target system so the team knows the token, key, or service account actually stops working when the relationship ends.
Common mistake: Treating contract closure as access closure. In practice, technical access often outlives the commercial agreement unless the deprovisioning step is explicit and independently checked.
Practitioner takeaway: Third-party machine access is only acceptable when the organisation can prove it is scoped, observable, and removable on demand, otherwise it is just latent access waiting for the next relationship change.
Related resources from NHI Mgmt Group
- What happens when third party access is not tightly controlled under ISO 27001?
- How should security teams govern non-human identities for ISO 27001?
- How should security teams handle standing access for third-party vendors?
- How should security teams handle third-party access that looks legitimate after a supplier breach?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org