TL;DR: Third-party remote access is now a mainstream breach vector, with 47% of organisations reporting a vendor-access breach in the past year and 64% expecting those incidents to stay flat or rise, according to Imprivata and Ponemon Institute research. The core issue is not vendor connectivity itself but unmanaged privilege, weak oversight, and missing lifecycle control.
NHIMG editorial — based on content published by Imprivata: an analysis of third-party remote access risk and vendor privileged access governance
By the numbers:
- 47% of organizations experiencing a breach involving vendor network access in the past year.
- 64% expect these breaches to increase or remain constant over the next year.
- 35% of organizations weren’t sure if vendor access was the breach cause.
Questions worth separating out
Q: How should security teams govern third-party remote access without creating standing privilege?
A: Security teams should treat every vendor connection as time-bound, task-scoped access with a named sponsor, explicit expiry, and full session attribution.
Q: Why do vendor accounts create so much risk in privileged access programmes?
A: Vendor accounts often sit outside the normal employee governance path, so they are easier to over-provision, harder to review, and more likely to retain access after the work is done.
Q: What do organisations get wrong about third-party access monitoring?
A: They often confuse having logs with having accountability.
Practitioner guidance
- Inventory every third-party identity and sponsor Create a single inventory of vendors with network or privileged access, and assign a business owner to each relationship.
- Bind access to task and contract boundaries Grant vendor access only for a defined task window, then remove it when the work ends, the contract changes, or the support need lapses.
- Require named-session attribution Prohibit generic shared accounts for vendors and capture who accessed which system, why they accessed it, what they changed, and whether data moved.
What's in the full article
Imprivata's full article covers the operational detail this post intentionally leaves for the source:
- The survey-backed breakdown of why organisations struggle to monitor vendor access in practice.
- The full set of best-practice questions used to vet vendors before privileged access is granted.
- The article’s operational guidance on delegated approval, logging, and access review workflows.
- The supporting analyst findings behind the third-party access statistics cited here.
👉 Read Imprivata's analysis of third-party access risk and vendor PAM →
Third-party remote access: what IAM teams need to change now?
Explore further
Third-party access is an NHI governance problem before it is a vendor management problem. The article shows that external identities fail when they are treated as exceptions rather than as governed non-human identities with explicit ownership, scope, and review. That is why vendor access often slips past employee-centric IAM controls. Practitioners should treat every vendor connection as a governed identity relationship, not a convenience channel.
A few things that frame the scale:
- Only 50% of organizations maintain a comprehensive inventory of third parties with network access, according to The State of Third-Party Access in Cybersecurity.
- 35% of organizations weren’t sure if vendor access was the breach cause, which shows how weak attribution becomes an operational problem, not just an audit gap.
A question worth separating out:
Q: Who should approve vendor access requests and why does it matter?
A: Approval should sit with the business owner or operational team that understands the real need, not with a generic IT queue. That reduces unnecessary privilege, improves context for review, and makes it easier to reject access that is broader than the task requires. It also improves accountability when the access is later audited.
👉 Read our full editorial: Third-party access risk exposes gaps in vendor privilege governance