Healthcare organisations should move away from shared VPN and directory credentials and use individual, tightly scoped vendor accounts with strong authentication, session control, and clear time limits. The goal is to keep credentials out of users’ hands, reduce lateral movement, and preserve accountability. A PAM-led model is stronger because it centralises access governance and limits what a vendor can reach once inside.
Why shared VPN and directory credentials are the wrong control for vendor access
Shared credentials collapse identity, intent, and accountability into one reusable secret. That makes it hard to tell who connected, what they reached, and whether access still matches the business need. For healthcare, the operational problem is not only convenience; it is that a single compromise can expose multiple systems, access governance, and regulated data paths.
Vendor access should be treated as a controlled exception with a clear subject, scope, and expiry. Individual accounts, rather than shared logins, let teams bind access to a person, a vendor, a ticket, and a time window. That is the minimum needed to preserve identity lifecycle discipline and make later review meaningful.
What a safer third-party access model looks like in practice
A stronger design uses per-vendor accounts with tightly scoped permissions, strong authentication, and session controls such as approval, recording, command filtering, or step-up checks where appropriate. The goal is to keep the vendor from using a standing shared path into the environment and instead make each access event attributable and limited.
Where possible, use just-in-time access, short-lived credentials, and environment-specific entitlements so access is activated only when needed. This reduces blast radius if a vendor endpoint is compromised and makes it easier to revoke access cleanly at the end of work. The same logic applies to static versus dynamic secrets: long-lived shared material is the pattern to avoid.
Healthcare organisations also benefit from central policy enforcement rather than ad hoc exceptions. A PAM-led model can broker access, enforce approval, capture session evidence, and reduce direct credential exposure to internal directories and sensitive assets. That matters most when vendors need elevated access to EHR, imaging, admin, or integration systems.
How to govern vendor access so it stays auditable and revocable
Access governance should start with ownership: who approved the vendor, what systems they may reach, what data they may touch, and when the access expires. If those answers are not captured up front, the organisation will struggle to prove that access was necessary or properly removed later.
Revocation is as important as provisioning. The best test is whether you can disable a vendor account, rotate the associated credentials, and confirm that no other team still depends on that path. That is why shared directory credentials are such a poor fit, they make offboarding partial at best and invisible at worst.
Healthcare teams should also separate vendor access for production, support, and testing so a contractor working on one system cannot move laterally into another. This is easier to enforce when each account is individually owned and narrowly bound to one purpose.
Risk and Threat Considerations
Shared VPN and directory credentials create a single high-value target, and they make lateral movement much easier after compromise. In healthcare, that can turn a vendor support account into a path toward multiple clinical or administrative systems, especially when access is broad, persistent, or poorly reviewed.
Failure mechanism: one reusable credential is stolen, phished, reused, or shared beyond its intended audience, then used to reach multiple systems without clear attribution or timely revocation.
Impact: organisations lose accountability, increase the odds of unauthorised access to sensitive patient or operational data, and widen the blast radius of any vendor compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Vendor access must be removable when work ends or risk persists. |
| NHI-02 — Secret Leakage | Shared VPN and directory credentials are secrets that can be exposed and reused. | |
| NHI-05 — Overprivileged NHI | Vendor accounts should be tightly scoped to limit blast radius and lateral movement. | |
| Recommendation — Revoke vendor access promptly and confirm all shared paths are eliminated. Eliminate shared secrets and rotate any exposed credential immediately. Grant only the minimum vendor permissions needed for the approved task. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Named vendor users need individual authentication instead of shared credentials. |
| AC-2 — Account Management | Third-party access depends on provisioning, review, and removal of individual accounts. | |
| AC-6 — Least Privilege | Vendor access should be tightly scoped to reduce what a compromised account can reach. | |
| Recommendation — Require unique authentication for each vendor user. Manage vendor accounts through formal provisioning, review, and deprovisioning. Limit vendor permissions to the minimum necessary access. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Per-session, scoped third-party access aligns with verified, bounded trust decisions. |
| Recommendation — Enforce continuous verification and narrow access per session. | ||
| CIS Controls v8 | CIS-5 — Account Management | Vendor access requires unique accounts, lifecycle control, and removal of shared credentials. |
| CIS-6 — Access Control Management | Tight scoping and session restrictions are core access control outcomes for third parties. | |
| Recommendation — Track, review, and remove vendor accounts through a formal account process. Restrict vendor access paths to approved systems and functions only. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Third-party access needs formal access rules, review, and enforcement. |
| Recommendation — Define and enforce access rules for all vendor access. | ||
Practitioner Guidance
What to prioritise: Replace shared access first where the vendor can reach production systems, administrative consoles, or regulated data. Those paths create the largest combination of exposure and difficulty in proving who did what.
What to verify: Every vendor session should map to one named account, one approved purpose, and one expiry condition. If you cannot show that linkage during review, the control is still too loose.
Common mistake: treating MFA alone as a substitute for access governance. Strong authentication helps, but without per-user scoping, session control, and revocation, the organisation still has a shared-path problem.
Practitioner takeaway: The real objective is not simply to block shared logins, but to make third-party access attributable, time-bound, and removable without collateral dependence on a shared secret.
Related resources from NHI Mgmt Group
- How should organisations secure remote access to high-performance workloads in Azure without relying on broad VPN access?
- How should regulated organisations implement secure third-party collaboration without weakening access control?
- How should organisations secure privileged access for remote workers without relying on broad VPN access?
- How can organisations secure third-party privileged access in hybrid environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
