Accountability sits with the organisation that allows the trust path to exist and remain active. Security teams should require documented access ownership, test revocation, and verify that supplier access is auditable across the full lifecycle, not just at onboarding.
Why This Matters for Security Teams
When a third-party identity can reach critical infrastructure, the question is not only whether access was approved. The real issue is who owns the trust path, who can revoke it, and who is accountable when that path is abused. In practice, supplier access often survives onboarding checks long after the business need has changed, which is why NHI Management Group stresses lifecycle control in the Ultimate Guide to NHIs.
This matters because third-party identities are usually embedded in service integrations, CI/CD workflows, and infrastructure automation, not just interactive admin sessions. Once a supplier account has a route into production systems, accountability must extend to approvals, monitoring, revocation testing, and audit evidence. The 2026 infrastructure identity Survey found that 92% of organisations expose NHIs to third parties, which means this is a common operational exposure, not an edge case. Security teams that rely on onboarding paperwork alone often discover the failure only after access has already persisted beyond contract scope.
That pattern has shown up repeatedly in incidents documented across the 52 NHI Breaches Analysis and in public guidance such as the CISA cyber threat advisories. In practice, many security teams encounter supplier access risk only after a vendor relationship changes or an incident has already occurred, rather than through intentional lifecycle review.
How It Works in Practice
Accountability should follow control, not just contract language. The organisation that permits the connection is responsible for defining the access path, approving the privilege level, and proving that revocation works. That means third-party access needs the same rigor applied to internal NHIs: named ownership, time-bounded access, audit logs, and an explicit offboarding trigger. NHI Management Group’s What are Non-Human Identities guidance is useful here because it frames NHIs as operational assets with lifecycle obligations, not one-time integrations.
Practically, teams should treat the supplier as a delegated operator and the customer organisation as the risk owner. A defensible operating model usually includes:
- documented business justification for the trust path and a named internal owner
- least-privilege scoping for every third-party identity, including service accounts and API keys
- just-in-time access where possible, with short-lived credentials and automatic expiry
- regular proof that revocation removes access from production, backup, and management planes
- separate logging for issuance, use, rotation, and termination events
This aligns with the OWASP Non-Human Identity Top 10, which highlights overprivileged and poorly governed machine identities as a recurring failure mode. It also fits the reality that secrets and tokens are often retained far longer than intended, especially when multiple teams share integration responsibility. Best practice is evolving toward continuous verification rather than periodic attestation alone, because a dormant trust path can still reach critical systems.
For critical infrastructure, the control owner should be able to answer three questions at any time: who approved the access, what exactly can the third party reach, and how quickly can that access be removed without manual escalation. These controls tend to break down when supplier access is embedded in legacy automation and no single team owns the full revocation path.
Common Variations and Edge Cases
Tighter third-party controls often increase operational friction, requiring organisations to balance resilience against integration speed. That tradeoff is most visible when suppliers manage infrastructure directly, support incident response, or run shared automation pipelines. In those environments, shared responsibility language can blur accountability unless it is translated into specific control ownership and evidence requirements.
There is no universal standard for this yet, but current guidance suggests that critical paths should use context-aware approval, ephemeral access, and continuous review rather than standing credentials. Where vendors insist on persistent access, the customer organisation should still own the decision to allow it and the proof that it remains justified. The 2026 Infrastructure Identity Survey reports that only 44% of organisations have policies for AI agents, and 67% still rely heavily on static credentials, which is a warning signal for any third-party model that depends on long-lived identity material.
Edge cases include emergency support accounts, managed service providers, and cross-border operations where multiple legal entities touch the same system. In those cases, accountability must be written into contracts, technically enforced in identity controls, and validated through revocation testing. For many teams, the hardest part is not granting access, but proving the trust path can be fully removed before the relationship ends. When that proof is missing, the organisation has effectively outsourced risk without retaining control.
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-03 | Third-party access must be rotated and revoked on lifecycle changes. |
| NIST CSF 2.0 | PR.AC-4 | Limits and monitors remote access by external identities. |
| NIST AI RMF | Governance needs accountable oversight for third-party autonomous access. |
Use AI RMF governance practices to define ownership, monitoring, and escalation for delegated access.
