Topic starter
25/06/2026 2:54 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Imprivata: “Russell fields five: Answers to five key questions on managing third-party vendor access risks”.
By the numbers:
- 47% of organisations experienced 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 organisations weren’t sure if vendor access was the breach cause.
Key questions
Q: What breaks when third-party access is not reviewed continuously?
A: The break is that access stays active long after the business relationship, vendor task, or application purpose has changed.
Q: Why do vendor access breaches keep happening even when organisations monitor remote access?
A: Monitoring alone does not fix vendor risk if the underlying access model still grants too much privilege or leaves shared accounts in place.
Q: What are the biggest mistakes teams make with manual access governance?
A: The common mistakes are letting manual handling become permanent, accepting inconsistent evidence quality, and allowing each application to develop its own process.
Practitioner guidance
- Implement named vendor identities Eliminate shared third-party support accounts and require each vendor session to map to a unique named identity with attributable activity.
- Constrain vendor access to task scope Grant only the minimum access needed for the support task, then expire it when the work is complete or the contract changes.
- Tie reviews to lifecycle events Revalidate vendor access on onboarding, role change, inactivity, and offboarding, with explicit ownership for each entitlement.
Bottom line: Third-party access becomes dangerous when it is treated as a convenience layer instead of a governed identity surface with clear ownership and revocation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 4:06 pm
Third-party access is a privileged identity class, not a convenience channel: Organisations keep treating vendor access as an operational exception, but the article shows it behaves like any other high-risk identity surface. Once a vendor can touch production systems, the question becomes whether that access is bounded, attributable, and revocable. The practitioner conclusion is to govern vendor access as privileged identity, not as informal support.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
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