Vendor Access Controls

HICP Practice 10.5 requires you to control vendor (and other third-party) technical connections with dedicated accounts, just-in-time (JIT) access, and session monitoring so external access is time-bound, attributable, and observable. Operationally, that means no shared vendor logins, no “always-on” VPNs by default, and documented evidence that access is granted, monitored, and revoked after each maintenance window. ¹

Key takeaways:

• Require dedicated, named accounts for third-party access; prohibit shared credentials.
• Shift to just-in-time, time-boxed access with automatic deprovisioning after the work window.
• Monitor vendor sessions (recording where feasible) and retain logs as audit evidence. ¹

“Vendor access controls” is one of those requirements that looks simple until you map it onto real operations: EHR support teams, medical device vendors, MSPs, cloud administrators, billing platforms, and incident responders all need access at inconvenient times, often under pressure. HICP Practice 10.5 sets a clear expectation: third-party connections must be strictly controlled through dedicated accounts, just-in-time provisioning, and session monitoring. ¹

For a Compliance Officer, CCO, or GRC lead, the goal is fast operational clarity: who can get in, how they get in, what they can do, how long they can do it, and how you can prove it after the fact. This page breaks the requirement into an implementable control set: access pathways (VPN, bastion, SaaS admin), identity model (account ownership and MFA), authorization (least privilege and approvals), monitoring (session logs/recording), and deprovisioning (automatic shutoff tied to a maintenance window). It also lists the artifacts auditors ask for and the failure modes that trigger findings.

Regulatory text

HICP Practice 10.5 excerpt: “Implement strict access controls for vendor connections including dedicated accounts, just-in-time access, and session monitoring.” ¹

Operator meaning: you must design third-party access so each session is (1) attributable to a specific identity, (2) time-bound to an approved need, and (3) monitored with evidence you can review later. The provided plain-language summary adds the practical elements most teams implement: dedicated accounts, JIT provisioning, session recording/monitoring, MFA, and automatic deprovisioning after maintenance windows close. ¹

Plain-English interpretation (what the requirement is really asking)

You need a controlled “front door” for vendor/third-party access. Every external party must:

• Authenticate as themselves (dedicated accounts; no shared “vendoradmin”).
• Get access only when needed (JIT, approved window, and a defined purpose).
• Be observed while connected (session monitoring, and recording where feasible).
• Lose access automatically when the window ends (no lingering accounts, tokens, or open firewall rules). ¹

If you have any third party with persistent network connectivity, standing admin roles, or credentials that your team cannot rapidly revoke, you are not meeting the control intent.

Who it applies to

Entity types (scope):

• Healthcare organizations (providers, payers, clinics, hospitals, health systems).
• Health IT vendors (including those operating healthcare platforms or handling patient/clinical workflows). ¹

Operational contexts where this shows up:

• Remote support for EHR/EMR, PACS, lab systems, billing, scheduling.
• Managed service providers administering servers, endpoints, network, identity, backups.
• Medical device manufacturers or integrators needing remote diagnostics.
• Cloud/SaaS administrators and professional services teams requiring privileged roles.
• Incident response retainers and forensics firms requesting emergency access.

What you actually need to do (step-by-step)

Use the steps below as a build checklist. Assign an owner for each step (IAM, Security Ops, IT Ops, GRC, Procurement), then track completion per third party.

1) Inventory all third-party access paths (start with reality, not contracts)

Create a single register of every way a third party can connect:

• VPNs and remote access gateways
• Bastion/jump hosts
• Direct inbound rules (IP allowlists, port forwards)
• SaaS admin consoles (tenant admin roles)
• API tokens, service accounts, SSH keys
• Remote support tools (screen sharing, RMM agents)

Output: “Third-Party Access Path Register” tied to third party name, system, method, privilege level, and business owner.

2) Enforce dedicated identities (kill shared accounts)

For each third party:

• Require named, unique accounts per technician/admin.
• Define account ownership: who sponsors the account internally and who approves access.
• Ban shared credentials and generic admin accounts unless you can show a compensating control with equivalent attribution (most teams cannot).

Implementation note: If a vendor claims they “can only use one shared login,” treat it as a security exception that requires executive risk acceptance and an exit plan. The requirement explicitly calls for dedicated accounts. ¹

3) Add strong authentication (MFA) on the access front door

Implement MFA for third-party access to the environment, especially for privileged actions. The summary explicitly includes MFA as an expected element. ¹

Practical pattern: centralize authentication through your identity provider or privileged access management (PAM) gateway rather than letting each vendor bring their own authentication model.

4) Implement just-in-time access with time-boxed approvals

Design a workflow that answers five questions every time:

• Who is requesting access?
• What system(s)?
• What privilege level?
• What is the purpose and ticket/reference?
• What is the approved maintenance window?

Then implement JIT in one of these common ways:

• PAM JIT elevation: vendor authenticates, then receives time-bound privileged role assignment.
• Time-bound account enablement: account exists but remains disabled until approved.
• Time-bound network access: firewall/VPN entitlements open only during the window.

Control requirement anchor: the summary calls for JIT provisioning and automatic deprovisioning after maintenance windows close. ¹

5) Monitor and record sessions (at least for privileged access)

Define “session monitoring” in your environment:

• Log authentication attempts and session start/stop.
• Capture commands or administrative actions where feasible.
• Record screen sessions for remote GUI administration when feasible.
• Alert on anomalous behavior (unexpected systems, off-hours access without approval, privilege escalation).

Rule of thumb: prioritize session monitoring for any privileged access path (domain admin, cloud tenant admin, EHR admin, hypervisor admin). HICP explicitly names session monitoring, and the summary includes session recording. ¹

6) Auto-deprovision at the end of the window (make it hard to forget)

Relying on humans to remove access later is a repeat audit finding. Implement at least one automatic shutoff:

• Privileged role assignment expires automatically.
• Account disables at window end unless re-approved.
• VPN entitlement expires.
• Temporary firewall rule expires.

Tie the shutoff to the maintenance window in the ticketing system, so Security/IT can show why access was granted and when it ended. ¹

7) Establish a tight exception process (and shrink it)

You will have edge cases: legacy systems, devices that only support shared local accounts, vendors that cannot support MFA. Put those into a formal exception workflow:

• Document the constraint and risk.
• Add compensating controls (segmentation, jump host with recording, stricter time-boxing).
• Define an exit plan and an accountable owner.

8) Operationalize through procurement + third-party risk management

Bake these requirements into onboarding and renewals:

• Access method must go through your approved pathway.
• Dedicated identities required.
• MFA required.
• JIT required.
• Session monitoring/recording required for privileged access.
• Access removed automatically after work completion. ¹

Where Daydream fits naturally: Daydream can act as the system of record that ties third-party due diligence (who the vendor is), access approvals (why/when), and evidence collection (logs, tickets, access reviews) so you can answer audits without scrambling across IAM, ITSM, and security tools.

Required evidence and artifacts to retain

Auditors and internal assurance teams typically want proof of design and proof of operation. Retain:

• Third-Party Access Policy/Standard covering dedicated accounts, JIT, MFA, monitoring, deprovisioning. ¹
• Third-Party Access Path Register (inventory) with owners.
• Account listings showing unique vendor identities (no shared accounts) and sponsorship/approval fields.
• Access requests and approvals (tickets) tied to a maintenance window and scope.
• System logs for authentication and session activity (gateway, PAM, VPN, bastion, SaaS admin audit logs).
• Session recordings or monitoring outputs for privileged sessions, where feasible. ¹
• Deprovisioning evidence showing access removed after the window (role expiry logs, account disable logs, entitlement removal).
• Periodic access reviews specific to third-party accounts and entitlements.
• Exceptions register with compensating controls and expiry criteria.

Common exam/audit questions and hangups

Expect questions like:

• “Show me all third-party accounts with privileged access and who approved them.”
• “How do you prevent shared vendor credentials?”
• “Demonstrate JIT: pick a recent vendor ticket and show enablement, session logs/recording, and automatic shutoff.”
• “How do you monitor vendor activity once connected?”
• “What happens if a vendor needs emergency access outside a planned window?”
• “How do you confirm terminated vendor staff lose access?” ¹

Hangups that create findings:

• Access granted through “temporary” firewall rules that never get removed.
• “Named accounts” exist but are not tied to a real person (no validation of vendor personnel changes).
• Session logs exist but are not reviewed, or cannot be correlated to a ticket/change record.

Frequent implementation mistakes (and how to avoid them)

1. Allowing persistent vendor VPN for convenience
   Fix: require JIT entitlements and window-based access. Make the default “off.” ¹

2. Treating “vendor” as a special identity class outside IAM discipline
   Fix: manage third-party identities like workforce identities: lifecycle, approvals, MFA, logs, reviews.

3. Recording nothing because “the vendor won’t like it”
   Fix: record privileged sessions through your jump host/PAM. Put the requirement in contracts and SOW language. HICP calls for session monitoring. ¹

4. Manual deprovisioning after maintenance
   Fix: implement automatic expiry. If you cannot automate everywhere, prioritize privileged pathways first and track manual removals as exceptions. ¹

5. No linkage between access and a business record
   Fix: require a ticket/change ID for each access grant and store it with the session evidence.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, weak vendor access controls increase the likelihood and impact of unauthorized access, misuse of privileged credentials, and delayed containment during an incident. The control is designed to reduce blast radius through least privilege, time-bounding, and monitoring. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Stand up the Third-Party Access Path Register and identify the highest-risk pathways (privileged + remote).
• Freeze creation of new shared vendor accounts; require named accounts going forward.
• Require tickets for any third-party remote access and capture start/stop times in the ticket.
• Pick a single “front door” for remote admin (bastion/PAM/VPN) and route new access through it.

By 60 days (JIT and monitoring in production for priority vendors)

• Implement JIT for the top tier of vendors/third parties with privileged access.
• Turn on MFA for third-party access at the gateway/IdP.
• Enable session monitoring and start retaining logs centrally for those pathways.
• Draft and publish the Vendor/Third-Party Access Standard aligned to HICP 10.5. ¹

By 90 days (Operational proof and audit-ready evidence)

• Expand JIT + monitoring to remaining third parties based on risk.
• Implement automatic deprovisioning tied to the maintenance window for priority systems.
• Run the first formal third-party access review; remediate orphaned and excessive privileges.
• Formalize the exception register and require expiry criteria for each exception.
• If you use Daydream, configure it to track approvals, exceptions, and evidence attachments per third party so audit response is a workflow, not a scavenger hunt.

Frequently Asked Questions

Do we need a dedicated account for every vendor technician?

Yes for the control intent. HICP Practice 10.5 calls for dedicated accounts so actions are attributable to an individual, not a shared identity. ¹

What counts as just-in-time access in practice?

Access that is disabled by default and enabled only after approval for a defined purpose and window, then expires automatically. The HICP summary explicitly expects JIT provisioning and automatic deprovisioning after maintenance windows close. ¹

Is MFA mandatory for vendor access under this requirement?

The provided summary includes MFA requirements as part of meeting HICP 10.5 expectations. If a vendor cannot support MFA directly, route access through a gateway you control that enforces MFA. ¹

We can log connections, but we cannot record sessions. Are we noncompliant?

HICP names session monitoring, and the summary references session recording. If full recording is not feasible everywhere, prioritize recording for privileged access and document compensating monitoring controls and exceptions. ¹

How do we handle emergency vendor access outside a planned maintenance window?

Use an emergency access workflow with explicit approver, ticketing, time-boxed JIT enablement, and enhanced monitoring. Require a post-access review that confirms what changed and that access was revoked. ¹

What evidence is most persuasive to auditors?

A complete chain: approved ticket with maintenance window, proof the dedicated account was enabled, MFA logs, session logs/recording, and proof access expired after completion. That chain maps directly to dedicated accounts, JIT, monitoring, and deprovisioning. ¹

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices