Notifications
Clear all
Topic starter
12/06/2026 12:39 am
TL;DR: Third-party access management is increasingly exposed by manual approvals, weak revocation, inconsistent controls, and limited visibility, according to Zluri’s analysis. For identity teams, the issue is not just external access volume but whether lifecycle, monitoring, and least-privilege controls actually hold once access leaves the core workforce boundary.
NHIMG editorial — based on content published by Zluri: Access Management Third Party Access Management: All You Need To Know
Questions worth separating out
Q: How should security teams govern third-party access in practice?
A: Security teams should govern third-party access as a lifecycle process, not a one-time approval.
Q: When does third-party access become a higher risk than it appears?
A: Third-party access becomes high risk when it is broad, difficult to monitor, or hard to revoke.
Q: What do organisations get wrong about third-party access reviews?
A: Many organisations review whether access was approved, but fail to verify whether it is still needed, still scoped correctly, or still tied to an active contract.
Practitioner guidance
- Define third-party access as a lifecycle-controlled identity class Create a separate approval, expiry, and ownership model for vendors, contractors, and partners so their entitlements are tracked from request through revocation.
- Automate expiry and deprovisioning for all external access Link every third-party grant to a time limit, a named business owner, and an automated removal workflow so access cannot outlive the task.
- Tighten segmentation around third-party task paths Limit external users to the smallest application, dataset, or environment slice needed for the engagement and prevent lateral movement into adjacent systems.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step policy handling for access requests, approvals, and revocation across third-party engagements
- Examples of temporary access workflows and how expiry is enforced in day-to-day operations
- Practical handling of encryption, segmentation, and IAM/AM tooling in external access management
- The vendor's examples of how its access management approach integrates with SaaS application access
👉 Read Zluri's guide to third-party access management best practices →
Third-party access management: where the governance gap starts?
Explore further
12/06/2026 10:03 am
Third-party access management is really lifecycle governance under an external trust boundary. The article is right to focus on requests, approvals, temporary access, and revocation because those are the control points that matter once outsiders need operational access. The discipline is not separate from IAM or PAM, it is IAM and PAM applied to non-employees with tighter expiry and review expectations. Practitioners should stop treating third-party access as an exception process and treat it as a governed identity class.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
A question worth separating out:
Q: Who is accountable when a third party keeps access after the work ends?
A: Accountability should sit with the business owner who requested the access and the system owner who approved and enforced it. If revocation fails, the organisation has a governance problem, not just a technical one. Frameworks such as the NIST Cybersecurity Framework 2.0 expect access control and oversight to be measurable, not informal.
👉 Read our full editorial: Third-party access management gaps are widening across hybrid estates
