What breaks when third-party access is not governed as part of identity lifecycle management?

Why This Matters for Security Teams

Third-party access only works when it is tied to the identity lifecycle, not treated as a one-time onboarding task. If a vendor, contractor, or partner still has access after the business relationship changes, the organisation has an identity that is active without a current owner. That is especially dangerous for healthcare environments where claims platforms, patient records, and connected systems often sit behind shared integrations and service accounts.

NHIMG research shows that 92% of organisations expose NHIs to third parties, and the risk becomes much harder to contain when revocation is delayed or never completed. The problem is broader than access review. It includes sponsorship, approval, scope, expiry, and offboarding. Current guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both point toward continuous control, but many teams still manage third-party identity as procurement paperwork rather than living access governance.

In practice, many security teams discover third-party access only after a contract ends, a supplier changes scope, or an old integration is reused in production.

How It Works in Practice

Identity lifecycle management for third parties should cover the full path from request to removal. That starts with a named business sponsor, a documented purpose, and a defined expiry date. It continues with least-privilege access, periodic recertification, and a revocation process that reaches both human user accounts and non-human identities such as API keys, service accounts, and tokens. The NHI Lifecycle Management Guide and Ultimate Guide to NHIs both emphasise that governance must include provisioning, monitoring, rotation, and offboarding, not just account creation.

A practical control stack usually includes:

• Time-bound access approvals with explicit renewal rather than open-ended standing access.
• Role or purpose-based scoping so vendors receive only the systems and data required for the task.
• Inventory of all third-party identities, including service-to-service credentials and delegated admin paths.
• Automated offboarding triggers tied to contract end dates, procurement closure, or sponsor attestation.
• Logging and review of third-party activity so anomalous use can be detected before broad exposure occurs.

This is where NHI management and third-party risk management converge. If access is issued through CI/CD pipelines, APIs, or embedded credentials, the control needs to reach the secrets layer as well. NHIMG notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a reminder that lifecycle controls often fail at the exact point where non-human access is most persistent. These controls tend to break down when third parties inherit production integrations without a clean inventory because no single team can prove what still works or why.

Common Variations and Edge Cases

Tighter third-party governance often increases operational overhead, requiring organisations to balance faster onboarding against stronger control over who can still reach sensitive systems later. That tradeoff becomes sharper in healthcare, where suppliers may need emergency access, EHR connectivity, or device support that cannot wait for a full manual review. Best practice is evolving, but there is no universal standard for emergency third-party access yet, so many programmes rely on compensating controls such as short-lived access, elevated logging, and named approvers.

One common edge case is the shared vendor account. It is convenient, but it destroys accountability because no one can tie activity to a single external identity. Another is the dormant integration that remains in place because a service still depends on it, even though the original vendor relationship is gone. NHIMG’s Top 10 NHI Issues highlights how excessive privileges and weak offboarding combine to create long-lived exposure.

In mature programmes, third-party access is treated as part of identity governance, secrets governance, and vendor risk management at the same time. When those domains are separated, access often survives the contract, the offboarding checklist misses the token, and the organisation keeps an external path open long after the business need has disappeared.

Related resources from NHI Mgmt Group

• Why do third-party relationships complicate identity and access management?
• What breaks when third-party access is not tightly governed in supply chain environments?
• What breaks when DNS administration is not governed as privileged access?
• How should banks govern DNS as part of identity and access security?