Should third-party access be governed like an identity lifecycle issue?

Yes. Once a vendor has authenticated access, the organisation is managing an external identity with a lifecycle of its own, including issuance, approval, review, and revocation. Treating it as a procurement-only problem leaves accounts, tokens, and integrations outside proper ownership and makes residual privilege much harder to remove.

Third-Party Access Is an Identity Lifecycle, Not a One-Time Approval

Vendor access becomes an external identity problem the moment authentication is granted. The practical question is no longer only whether the contract allows access, but who owns the account, how long it should exist, what it can reach, and how it is reviewed and removed. That is why third-party access governance belongs with lifecycle, entitlement, and offboarding controls.

What makes this different from ordinary procurement is the continuing operational obligation. A vendor login, API token, or delegated integration can survive staff turnover, contract changes, tool replacement, or a forgotten escalation path, so the control problem is ongoing rather than transactional. IAM and IGA Basics is useful here because it frames third-party access as provisioning, review, entitlement management, and revocation.

The lifecycle view also explains why access should be attached to business purpose and ownership from the start. If an external account cannot be tied to a named sponsor, a scope, and an expiry condition, it tends to become residual privilege, especially across SaaS integrations and shared platforms. In practice, that means access creation and access removal must be designed together, not treated as separate processes.

Where Third-Party Access Breaks Down in Practice

The most common failure is not the original approval, but the incomplete cleanup afterwards. Contracts end, integrations are replaced, or a vendor no longer needs production access, yet tokens, service accounts, and federation links remain active. Third-Party, B2B and Contractor Access Guide addresses this directly through sponsorship, least privilege, time limits, reviews, and third-party offboarding.

A second failure mode is treating all third-party access as the same. A human contractor, a support partner using SSO, and an application-to-application integration have different approval paths, evidence requirements, and revocation mechanics. The right governance model distinguishes the actor type and the access mechanism, then applies the right review cadence and owner. That is why lifecycle controls need to cover identities, not just contracts.

A third issue is hidden reuse across environments. Vendors often receive access in one system and then inherit similar access elsewhere through copied groups, duplicated service accounts, or shared credentials. The result is privilege creep that is hard to see until an audit or incident forces a full inventory. A lifecycle approach makes inventory, ownership, and recertification part of the control model rather than an afterthought.

What Good Governance Looks Like for Vendor Identity Lifecycle

Strong practice starts with a clear decision rule: if the vendor can authenticate, then the organisation must manage that access as an identity with a start date, a purpose, a reviewer, and an end state. NHI Lifecycle Management Guide is a good match for this model because it covers provisioning, rotation, offboarding, and visibility as one control chain.

Good governance also means the access record stays connected to real ownership. The sponsor, system owner, and business owner should be able to answer three questions quickly: why the access exists, what would break if it were removed, and who is accountable for revocation when the work ends. If none of those answers is clear, the access is already drifting into unmanaged territory.

For third parties, expiry and recertification matter as much as initial approval. Short-lived access, periodic review, and explicit deprovisioning reduce the chance that a dormant vendor path becomes a standing back door. Joiner-Mover-Leaver (JML) Guide reinforces the operational point that deprovisioning has to include the tokens, keys, and agents left behind when the relationship changes.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Third-party access depends on managing vendor tokens, keys, and other authenticators over time.
	AC-2 — Account Management	Vendor access requires account provisioning, review, and prompt removal when the relationship changes.
	AC-6 — Least Privilege	Vendor access should be constrained to the minimum scope needed for the approved purpose.
Recommendation — Track, rotate, and revoke third-party authenticators on a defined lifecycle. Assign owners and remove third-party accounts when business need ends. Limit third-party permissions to the smallest set needed for the task.
CIS Controls v8	CIS-5 — Account Management	Third-party access needs controlled creation, review, and deprovisioning of external accounts.
Recommendation — Inventory, review, and remove vendor accounts on a defined cadence.
ISO/IEC 27001:2022	A.5.15 — Access control	Third-party access governance is an access-control problem requiring defined approval and revocation.
Recommendation — Define and enforce access rules for external identities.

Practitioner Guidance

What to verify: Every third-party account, token, and federation link should have an owner, a business purpose, a review date, and a defined revocation trigger. If any one of those is missing, treat the access as incomplete governance rather than an approved exception.

What to prioritise: Start with access that can reach production data, privileged admin functions, or long-lived integrations, because those paths create the largest blast radius when a vendor relationship changes. Then move to dormant accounts, shared credentials, and non-expiring tokens.

Common mistake: Teams often close the procurement record and assume the security problem is finished. That leaves active access outside the normal lifecycle, where nobody feels accountable for review, rotation, or removal.

Practitioner takeaway: The right test is not whether the vendor was approved once, but whether the organisation can still explain and remove that access cleanly today.