TL;DR: Unmanaged vendor access creates a high-risk path into internal systems because third parties often need privileged remote access, and a healthcare study cited by Imprivata found 56% of organisations experienced a third-party related breach in the past year. This is a governance problem, not just an access problem: standing privilege, weak visibility, and manual approvals all widen the blast radius.
NHIMG editorial — based on content published by Imprivata: vendor privileged access management and third-party access control
By the numbers:
- In healthcare, 56% of organizations experienced a third-party related breach within the past year.
- Roughly two-thirds expect the number of data breaches to rise over the next 12 to 24 months.
Questions worth separating out
Q: How should security teams govern vendor access to critical systems?
A: Treat vendor access as a privileged identity lifecycle, not a remote support exception.
Q: Why does vendor access increase breach risk compared with internal access?
A: Vendor access often sits outside normal device, network, and authentication controls, yet it still reaches high-value systems.
Q: What breaks when third-party privileged access is not monitored?
A: Without session monitoring and audit logs, security teams lose the ability to prove what happened during a vendor session.
Practitioner guidance
- Eliminate shared vendor admin accounts Assign each third-party user a unique identity, then tie access to a named person, approved system, and approved task so you can revoke it cleanly when the engagement ends.
- Move vendor privilege to task-scoped approvals Require just-in-time elevation for remote support, with policy conditions based on system criticality, request reason, and ticket linkage rather than standing access.
- Record every privileged third-party session Capture session video, commands, and audit logs for all external administrative activity, and retain the evidence long enough to support incident review and compliance checks.
What's in the full article
Imprivata's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step session brokering flow for vendor connections into internal systems
- Specific examples of secure credential vaulting and credential injection for third parties
- Automated approval workflow patterns for policy-based vendor access requests
- Session monitoring and recording capabilities that support audit and incident review
👉 Read Imprivata's analysis of vendor privileged access management and third-party risk →
Vendor access management: are your third-party controls keeping up?
Explore further
Vendor access is a privileged identity class, not a connectivity feature. The article is correct to frame vendor access as a governance problem because external users often need elevated access while remaining outside the organisation’s direct control plane. That combination makes identity proof, session containment, and accountability the real control surface. Practitioners should stop treating third-party access as a remote support exception and govern it as a high-risk identity population.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- A separate finding shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which reinforces how external identity sprawl weakens governance.
A question worth separating out:
Q: Who is accountable when a vendor account is misused?
A: Accountability should sit with the business owner of the access, the system owner, and the security team that approved the entitlement. If the relationship is governed well, the vendor can be identified, the session can be reconstructed, and the approval path can be reviewed against policy.
👉 Read our full editorial: Vendor privileged access management and the third-party trust gap