The framework stops governing the real risk surface. A vendor can still be rated, reviewed, and approved while its live credentials, integrations, and data access remain unchanged. When inventory and entitlement state diverge, the organisation loses the ability to prove who can reach what and why that access still exists.
When the framework does not track vendor access, what stops being true?
The answer is simple: the framework no longer describes actual exposure. Third-party risk can be scored on paper while live tokens, service accounts, API keys, and portal entitlements remain active. That creates a false sense of control because approval state and access state are now different things.
A useful Top 10 NHI Issues lens makes the same point from the identity side: visibility, inventory, ownership, and credential hygiene are not optional extras when vendors can still reach production systems.
Why does this break third-party governance in practice?
Governance fails when the control model is built around review events instead of live permissions. A vendor can be approved, renewed, and rated as low risk even after its integration scope expands, a contract changes, or a credential is copied into a new system. Without access tracking, the organisation cannot tell whether the vendor’s current reach still matches the risk decision that authorised it.
That matters because vendor access is often the mechanism that turns a paper relationship into real data exposure. A single stale token or overbroad integration can bypass the intent of procurement, security review, and periodic assessment. Slack GitHub breach 2022 and Salesloft OAuth token breach both show how third-party tokens can remain the real access path long after the nominal vendor relationship has been approved.
When entitlement state is invisible, reviews become retrospective paperwork instead of current control. The organisation can no longer prove who can reach what, whether the access was justified, or whether the justification still holds.
What operational gaps appear between approval, inventory, and revocation?
The main gap is drift. Inventory says the vendor exists, but not whether the vendor still has usable credentials. Approval says access was permitted, but not whether the permission was narrowed, rotated, or removed after onboarding. Revocation becomes weak as well, because teams often terminate the business relationship while leaving connected systems, OAuth grants, passwords, or API secrets untouched.
That is why vendor access has to be treated as a lifecycle problem, not a point-in-time assessment. BeyondTrust breach 2024, Microsoft verified publisher OAuth phishing 2022, and Uber breach 2022 each illustrate a different failure mode, stolen key material, deceptive consent, or compromised contractor access, but the underlying lesson is the same: if access is not continuously reconciled, the organisation cannot know what the vendor can still do.
Risk and Threat Considerations
When vendor access is not tracked, the main risk is unmanaged reach. The organisation may believe a supplier is low risk while that supplier still holds active credentials, broad API scopes, or dormant but usable integrations that can expose sensitive data or systems.
Failure mechanism: The third-party register, contract record, or review workflow is updated, but the live access layer is not. That leaves orphaned, overprivileged, or unreviewed access in place after business context has changed.
Impact: Compromise, misuse, or simple continued operation of those credentials can produce unauthorised access, lateral movement, data extraction, and an inability to demonstrate that access is still justified.
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 surface, NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Vendor access must be removed when the third-party relationship ends or changes. |
| NHI-05 — Overprivileged NHI | Tracked vendor access must be scoped to the minimum reach needed. | |
| NHI-07 — Long-Lived Secrets | Untracked vendor credentials often persist beyond the intended access window. | |
| Recommendation — Revoke unused vendor credentials and integrations promptly during offboarding. Reduce vendor entitlements to least privilege and review scope regularly. Rotate or expire vendor secrets instead of allowing indefinite access. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Vendor accounts must be inventoried, controlled, and removed when no longer needed. |
| AC-6 — Least Privilege | Vendor access should be limited to the minimum permissions required. | |
| IA-5 — Authenticator Management | Vendor secrets, tokens, and keys need lifecycle control to prevent stale access. | |
| Recommendation — Maintain a current account inventory and disable stale vendor access. Constrain vendor access to the least privilege needed for the approved task. Rotate and revoke vendor authenticators on a defined schedule and at offboarding. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Supplier governance must cover access that vendors retain into internal systems. |
| A.8.2 — Privileged access rights | Vendor privileged access must be controlled and periodically reviewed. | |
| Recommendation — Require supplier access to be reviewed, approved, and removed through the supplier lifecycle. Review and restrict privileged vendor access to the minimum necessary scope. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Third-party access needs ongoing management, not just one-time approval. |
| Recommendation — Track, review, and remove vendor access paths as part of access control management. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud third-party risk hinges on knowing and governing active vendor access. |
| Recommendation — Map every vendor identity and entitlement to an accountable owner and lifecycle state. | ||
Practitioner Guidance
What to verify: Reconcile vendor inventory against actual access paths, including human accounts, API keys, OAuth grants, service accounts, remote support tooling, and shared integrations. A vendor should not be treated as “closed” until those paths are either removed or explicitly re-authorised.
Decision rule: If you cannot point to the exact credential or entitlement that a vendor uses, treat the access as uncontrolled until proven otherwise. If a vendor can reach production data, rotate and scope that access before relying on the next review cycle.
Practitioner takeaway: Third-party risk control fails when it measures vendors as relationships instead of vendors as live access holders.
Related resources from NHI Mgmt Group
- How should organisations govern third-party access in a vendor risk policy?
- Which frameworks help govern third-party access and supply chain risk?
- Why do third-party access and vendor connections increase compliance risk in regulated financial environments?
- Which matters more for third-party risk, vendor approval or access scope?
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