Because access granted for a project, integration, or service relationship often persists beyond the period when it was needed. If review and revocation do not keep pace with contract changes, the access becomes standing exposure. The risk is not the vendor alone, but the organisation’s failure to retire the identity when the business need ended.
Why third-party access becomes ongoing exposure after onboarding
Third-party access is easy to justify at onboarding because the business need is visible, bounded, and usually time-limited. The risk changes after that moment. Unless ownership, review, and expiry are treated as lifecycle controls, the access outlives the contract, the project, or the support window and quietly becomes standing exposure.
That is why third-party access is not a one-time approval decision. It is an access governance problem that must be managed from grant to retirement, including sponsorship, periodic review, and revocation when the relationship changes. A useful starting point is NHIMG’s IAM and IGA Basics, which frames access reviews and entitlement governance as part of the identity lifecycle.
The practical failure mode is simple: business teams remember why access was granted, but no one owns the moment when the reason stops being true. When that happens, the third party may still authenticate successfully, still hold active entitlements, and still inherit permissions that were only safe during implementation. NHIMG’s Third-Party, B2B and Contractor Access Guide is useful here because it treats time limits and offboarding as first-class controls rather than administrative cleanup.
Why the exposure persists in real environments
Third-party access often persists because the access path is embedded in operational reality. Vendors, suppliers, contractors, and integrators may use federated access, API keys, tokens, support portals, or shared workflows that are convenient to keep alive once service delivery starts. Over time, that convenience creates drift between the original approval and the current business need.
That drift is especially dangerous when access is tied to dormant integrations, long-lived secrets, or accounts that are reused across projects. The identity may still be valid even after staff change, contracts roll over, or the vendor relationship narrows. NHIMG’s NHI Lifecycle Management Guide captures the core operational issue well: lifecycle control must cover provisioning, rotation, visibility, and offboarding, not just creation.
In practice, the organisation also creates a false sense of safety when the third party is trusted. The access can remain technically legitimate while becoming operationally stale. That is why stale third-party access is often less visible than a classic compromise but just as dangerous, because it expands the number of active paths into sensitive systems without any current business justification.
What makes it a security problem instead of an admin task
Once onboarding is complete, the question is no longer whether the third party was vetted. The question is whether the access still matches the current risk boundary. If contract changes, scope reductions, or service termination do not trigger entitlement review, then the organisation has effectively turned temporary delegated access into permanent exposure.
That is why review, offboarding, and entitlement cleanup are security controls, not paperwork. They determine whether access is still bounded by purpose, whether old permissions are still active, and whether a former provider can be used as a forgotten entry point. For a broader pattern of identity drift and over-retention, the Joiner-Mover-Leaver (JML) Guide is a strong reference point, even though third parties are not employees, because the same retirement logic applies.
The problem is compounded when multiple teams share responsibility. Procurement may track the contract, operations may keep the integration running, and security may assume the owner will request removal. Without a named owner for review and revocation, access can survive simply because no control path is responsible for ending it.
Risk and Threat Considerations
Persisting third-party access creates residual attack surface long after the original justification has disappeared. If the vendor, contractor, or integrator is later compromised, the attacker can inherit a live access path that the business no longer actively watches, which makes stale accounts, tokens, and support channels attractive targets.
Failure mechanism: Review cycles lag contract changes, so unused permissions, tokens, or federated sessions remain valid after the relationship should have ended.
Impact: The organisation retains standing exposure, increasing the chance of unauthorised access, lateral movement, data access, or abuse through a trusted third-party path.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Third-party access must be provisioned, reviewed, and revoked on change. |
| IA-5 — Authenticator Management | Long-lived tokens and secrets keep third-party access alive after onboarding. | |
| AC-6 — Least Privilege | Ongoing third-party access often keeps more privilege than current work requires. | |
| Recommendation — Enforce periodic access reviews and revoke third-party accounts when the business need ends. Rotate and expire third-party authenticators before they become standing exposure. Reduce third-party entitlements to the minimum necessary for the current task. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Third-party access risk is fundamentally an access control and review issue. |
| A.5.18 — Access rights | Persisting third-party access arises when access rights are not timely removed. | |
| A.8.5 — Secure authentication | Third-party sessions and credentials must remain tightly controlled over time. | |
| Recommendation — Define and enforce access rules that require removal when the need ends. Review and withdraw third-party access rights when contracts or roles change. Use strong authentication and tightly managed authenticators for external access. | ||
Practitioner Guidance
What to verify: Confirm that every third-party access grant has an owner, an expiry condition, and a documented revocation trigger tied to contract, project, or service changes. If you cannot identify who is accountable for removal, the access is already weakly governed.
Decision rule: If the access is tied to a live business function, keep it time-bound and reviewed; if the business function has ended or changed materially, revoke first and investigate later. The safe default is to remove stale privilege before trying to prove it was abused.
What good looks like: Access reviews produce actual removals, not just acknowledgements, and expired third-party entitlements are retired on schedule across human, service, and integration paths. NHIMG’s third-party access guidance and IAM and IGA Basics both support that operating model.
Practitioner takeaway: Treat third-party access as a lifecycle control, not a one-time approval, because the real risk begins when the original business reason for access is no longer being actively enforced.
Related resources from NHI Mgmt Group
- Why do third-party vendors create ongoing IAM and governance risk after onboarding?
- Why do third-party identities create persistent breach risk even after onboarding controls are in place?
- Why do third-party OAuth integrations create persistent access risk even after an app appears deleted?
- Why does third-party access become a security risk after a vendor relationship ends?