What should IAM teams prioritise when third-party access takes months to close?

Why long third-party closures become an IAM control problem

When a third-party account takes months to close, the real issue is not the calendar delay, it is control drift. Access that should have ended with a role change, contract end, or remediation step remains live, so the organisation is still carrying a governed relationship that no longer has a clear business owner. That is how stale access becomes normalised.

Long closure cycles usually indicate the IAM team is managing exceptions without a reliable view of active usage. If nobody can confidently say whether the account is still being used, the closure workflow is no longer just an offboarding task, it is a visibility and ownership failure that affects access review, entitlement cleanup, and accountability.

For the practical structure behind that lifecycle view, NHIMG’s IAM and IGA Basics explains how provisioning, access review, and entitlement governance fit together when access changes do not happen in a single step.

What should get prioritised first when closure drags on

The first priority is ownership, because a stalled third-party account is often stuck between teams, not blocked by technology. The IAM team should make the owning business function explicit, identify who approved the access, and confirm who is accountable for the decision to keep or remove it. Without that handoff, closure timetables tend to stretch indefinitely.

The second priority is active usage, because a dormant-looking account and an unused account are not the same thing. Teams need enough evidence to tell whether the external identity still authenticates, performs work, or is tied to an integration that has not been retired. That distinction matters more than the age of the ticket.

The third priority is permission aging. If the account remains open while review stalls, the entitlement set should be treated as time-sensitive risk rather than stable access. The longer closure takes, the more likely it is that the permissions no longer match the current business need, especially where third parties change staff, contracts, or toolchains faster than internal governance cycles.

NHIMG’s Third-Party, B2B and Contractor Access Guide is useful here because it frames sponsorship, time limits, least privilege, and offboarding as one governance problem rather than separate tickets.

Where the account is tied to a non-human integration or token, the same logic applies. Lifecycle processes for managing NHIs becomes relevant because the closure signal is not “someone stopped logging in”, it is whether the access path still has a legitimate owner and a current purpose.

What good closure looks like in a third-party access workflow

Good closure is not measured by how many reminders were sent. It is measured by whether the team can prove who owns the access, whether the account is still active, and whether the permission set has been reduced or removed in line with the latest business reality. If those three things are missing, the workflow is still open in governance terms even if the ticket says otherwise.

A mature process also separates remediation from assurance. One team should be able to revoke or reduce access quickly, while another validates that the third party no longer depends on the account for a live function. If those steps are merged, closure becomes slow because every removal needs a bespoke investigation.

At the operational level, the most useful sign of improvement is shorter time between change and entitlement update. That can come from better recertification cadence, clearer sponsor ownership, or more reliable discovery of orphaned accounts. For broader identity governance context, Top 10 NHI Issues highlights why visibility, ownership, and rotation problems often cluster together instead of appearing as isolated defects.

Risk and Threat Considerations

Long third-party closure windows create a standing exposure window that can be abused if the external account is compromised, shared, or simply forgotten. The risk is higher when access is tied to production systems, customer data, or privileged workflows, because the account can keep working long after the original business justification has disappeared.

Failure mechanism: The organisation loses track of which external identity is still active, so a stale account retains permissions after the sponsor, contract, or remediation state has changed. In practice, that means offboarding becomes dependent on memory, ticket chasing, or manual discovery instead of a controlled lifecycle.

Impact: Unused-but-live access can become a persistence path for attackers, a source of unintended data exposure, or a route for privilege abuse through an account nobody is actively watching. It also weakens auditability because the business can no longer show that access removal kept pace with the underlying change.

Practitioner Guidance

What to prioritise: Escalate any third-party account that remains open after role end, contract end, or remediation completion, and require a named owner before the closure date is extended again. If ownership is unclear, treat that as the blocker, not the ticket ageing.

What to verify: Confirm whether the account is still authenticating, whether any automation or integration depends on it, and whether its permissions are broader than the current business need. If you cannot verify active use, do not assume the account is harmless just because the closure has been delayed.

Practitioner takeaway: Slow closure is usually a visibility and ownership failure first, and an access problem second, so the most effective response is to make every lingering third-party account provably owned, actively justified, and ready for rapid removal.

Related resources from NHI Mgmt Group

• How should security teams design third-party access to cloud IAM so an external integration cannot escalate privilege if it is compromised?
• How do supply chain attacks change third-party access governance for security and IAM teams?
• How should security teams prioritise identity hygiene when cloud, remote work, and third-party access keep expanding the identity surface?
• How can IAM teams tell whether third-party access is overexposed?