Why do third-party identities become a governance problem when assessment models change?

Why This Matters for Security Teams

Third-party identities stop being a routine access issue the moment the assessment model changes, because the question is no longer “does this vendor still need access?” but “can the organisation prove that access was removed when the risk decision changed?” That shift affects procurement, security review, audit evidence, and incident response at once. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward continuous governance, not one-time approval.

This is especially visible in OAuth-connected vendors, shared service accounts, and integration tokens that outlive the commercial relationship that created them. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means the governance problem is often already embedded before renewal, offboarding, or reassessment begins. When assessment models shift from periodic questionnaires to continuous or risk-based review, dormant access becomes a control gap rather than a paperwork issue. In practice, many security teams discover lingering third-party access only after a contract change, not through intentional revocation testing.

How It Works in Practice

Governance breaks when assessment, procurement, and identity operations are disconnected. A vendor may have been approved under one risk posture, then later reclassified because its data access expanded, its security score dropped, or the business stopped using the integration. If the identity layer is not tied to that reassessment, the access path stays active even though the approval basis no longer exists.

Practically, effective programs treat third-party identities as lifecycle objects. That means every external account, API token, OAuth grant, or service principal should have an owner, a business purpose, an expiry condition, and a revocation path. The control is not just inventory. It is the ability to connect a changed assessment decision to actual cleanup. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Ultimate Guide to NHIs — Regulatory and Audit Perspectives both reinforce that lifecycle control and auditability must move together.

• Link third-party onboarding to a named business owner and a renewal date.
• Require reassessment triggers for scope change, contract renewal, incident, or vendor churn.
• Automate revocation for OAuth grants, API keys, and service accounts when approval expires.
• Log evidence that the revocation request, technical action, and confirmation all completed.

Where this guidance is strongest is in environments with central identity tooling and clear vendor ownership. It breaks down when integrations are embedded in shadow IT, because no single team can reliably see, approve, and revoke the access path.

Common Variations and Edge Cases

Tighter third-party control often increases operational overhead, requiring organisations to balance stronger assurance against slower onboarding and more renewal friction. That tradeoff is real, especially when the business depends on many short-lived integrations or partner-managed automations.

There is no universal standard for how often every third-party identity must be reassessed, but current guidance suggests the cadence should match risk, not contract length alone. High-impact vendors may need continuous signals, while low-risk integrations can be reviewed on a scheduled basis if revocation is automated. The same principle applies to service accounts used by vendors inside customer environments: if the account cannot be linked to a current purpose, it should be treated as an orphan candidate.

One common edge case is the “approved forever” integration that survives because it sits inside a SaaS platform rather than a traditional IAM directory. Another is the shared account that multiple vendors use, which makes attribution and revocation difficult. NHIMG’s Top 10 NHI Issues highlights lifecycle and ownership as recurring failure points, while the The State of Non-Human Identity Security report shows how visibility gaps and weak rotation compound the risk. In practice, reassessment models fail when the organisation measures vendor risk in spreadsheets but removes access only by manual ticketing.

Related resources from NHI Mgmt Group

• When does an authentication platform become a governance problem?
• Third-party Assessment Organization
• When does a machine identity become a compliance problem?
• When does a service account become a compliance problem?