The warning signs are shared credentials, unmanaged service accounts, opaque integrations, and vendor workflows that cannot be fully traced to an owner. When offboarding does not touch machine credentials or partner-linked access, the programme is missing the identity layer. That gap usually shows up only after an incident, when teams discover they did not know who or what still had access.
How the identity layer shows up when third-party risk is incomplete
The first sign is that third-party risk is being managed as a vendor list, not as an access graph. If the programme cannot tell which shared credentials, API keys, service accounts, or delegated tokens belong to which partner workflow, it has lost the ability to answer a basic control question: who can act, through what trust path, and under whose ownership?
That gap is easiest to spot in operational friction. Offboarding only removes the contract or disables the portal login, but leaves machine credentials, integrations, and inherited access untouched. In practice, the identity layer is missing whenever the team can describe the supplier relationship but cannot describe the identities and entitlements that relationship actually uses.
A related warning sign is weak ownership. When a vendor workflow exists but no internal team can name the account, system, or business process responsible for it, access tends to persist by default. Top 10 NHI Issues is useful here because visibility gaps, shared accounts, and offboarding failures are often the practical markers that the identity layer has not been brought into the third-party review.
What failed controls usually reveal the problem
The pattern usually includes shared credentials, unmanaged service accounts, opaque integrations, and stale trust relationships that outlive the business need. If those artefacts are not inventoried, rotated, or tied back to an owner, the programme has a blind spot even if the supplier itself is “approved”. The problem is not just that access exists, it is that the organisation cannot prove where that access starts, where it ends, or who is accountable for it.
Identity-layer gaps also show up when integrations are treated as static configuration instead of active privileges. OAuth apps, remote support tools, partner APIs, and SaaS connectors can all carry standing access that bypasses normal user review. Salesloft OAuth token breach and BeyondTrust breach 2024 both illustrate why third-party access must be governed as an identity problem, not only as a procurement or security review item.
When the organisation cannot trace a vendor action to a named service identity, to a scoped permission set, and to a revocation path, it is usually relying on trust in the supplier brand rather than on enforceable access boundaries. Ultimate Guide to NHIs, Key Challenges and Risks is relevant because unmanaged credentials, excessive permissions, and lifecycle gaps are exactly the control failures that make third-party access hard to govern at scale.
Why incident response exposes the blind spot
The clearest proof is often found after an incident. Teams discover that they know which vendor was involved, but not which credential, token, support path, or machine account was actually used. That delay matters because third-party compromise frequently propagates through legitimate access, which looks normal until investigators try to reconstruct ownership and scope.
Where identity is missing, offboarding becomes partial and incident response becomes guesswork. The programme may disable a named supplier user, while leaving automation accounts, partner-linked tokens, and embedded secrets active in downstream systems. Slack GitHub breach 2022, GitHub OAuth token breach 2022, and Vercel Context.ai OAuth Supply Chain Breach all point to the same lesson: compromised or unmanaged third-party access tends to survive ordinary vendor offboarding because the identity artefact was never fully governed.
That is why the problem is usually invisible until detection or containment is underway. By then, the question is no longer whether the vendor was trusted, but whether every active integration, secret, and delegated permission can be found fast enough to contain blast radius.
Risk and Threat Considerations
Missing the identity layer turns third-party risk into standing exposure. Shared credentials, long-lived tokens, and unmanaged service accounts give attackers and careless insiders a durable path that often survives contract termination, password resets, or a normal vendor review.
Failure mechanism: The organisation tracks suppliers and applications, but not the identities, secrets, and delegated permissions that connect them. As a result, access remains active after ownership changes, offboarding, or incident containment.
Impact: A compromise can spread through legitimate trust paths, obscure attribution, and leave the organisation unable to prove which partner workflow still has access to production data or systems.
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, CSA Cloud Controls Matrix and CIS Controls v8 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 | Third-party offboarding gaps often leave machine credentials and partner access active. |
| NHI-02 — Secret Leakage | Shared credentials and unmanaged tokens are central signs of missing identity governance. | |
| NHI-07 — Long-Lived Secrets | Durable tokens and keys keep third-party access alive after ownership changes. | |
| Recommendation — Revoke every supplier-linked credential and account when the relationship ends. Inventory and rotate exposed secrets tied to vendor workflows. Shorten credential lifetimes and require regular renewal for partner access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Third-party access depends on lifecycle control of credentials, tokens, and keys. |
| AC-6 — Least Privilege | Opaque integrations become dangerous when vendor access is broader than needed. | |
| IA-9 — Service Identification and Authentication | Service accounts and automated partner access are part of the identity layer here. | |
| Recommendation — Track issuance, rotation, and revocation for every supplier credential. Limit third-party accounts to the smallest necessary permissions. Authenticate non-human integrations with distinct service identities and controls. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Supplier relationships must include security requirements for identities and access paths. |
| Recommendation — Define identity and access obligations in supplier security terms. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Cloud third-party risk depends on governing identities, entitlements, and lifecycle. |
| SEF — Security Incident Management, eDiscovery, and Forensics | Incident response must trace third-party access back to the actual credential or token used. | |
| Recommendation — Map supplier access to owned identities, entitlements, and revocation points. Preserve evidence that links supplier activity to specific identities and secrets. | ||
| CIS Controls v8 | 5 — Account Management | Third-party access becomes visible when accounts and service identities are centrally managed. |
| Recommendation — Maintain an inventory of every supplier-facing account and service identity. | ||
Practitioner Guidance
What to verify: Confirm that every third-party workflow has a named owner, a scoped identity, and a documented revocation path. If you cannot map a supplier touchpoint to a specific credential, token, or service account, treat it as unmanaged access until proven otherwise.
Decision rule: If offboarding only disables human login but does not revoke machine credentials, partner tokens, and embedded secrets, the review is incomplete. Prioritise the identity artefacts that can still execute actions over the contractual status of the vendor relationship.
Practitioner takeaway: Third-party risk management is missing the identity layer when it can describe the supplier but not the access. The practical test is whether every external trust path can be owned, traced, and revoked before an incident forces the question.
Related resources from NHI Mgmt Group
- What are the signs that third-party risk management is not working well enough?
- What are the signs that third party identity management is breaking down?
- What are the signs that third-party cyber risk management is not working in a federal environment?
- What are the signs that a third-party risk management programme is too shallow to detect real exposure?
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 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org