Giving outside IT admin rights near the EHR without a shared account

A shared admin account cannot produce an audit trail, because the log can only say the account did it, not which person did. If an outside IT provider works on workstations that reach your EHR, that gap is the first thing a reviewer or an investigator will hit. The fix is not to slow the provider down. It is to make every elevated session belong to a named person, for a limited time, with a record you actually read.

A clinic put the problem well in a question on r/healthcareIT. It uses an outside IT provider and wants named accounts, MFA, and an audit trail when a ticket touches a workstation connected to the EHR. The catch: some fixes need local admin rights and cannot wait for the internal IT lead to approve each step. They have about 40 clinical workstations and asked whether to grant a standing limited admin role or time-limited elevation per session, and whether the security team should review the provider's access log on a schedule or only after an incident.

That is one practitioner's question, not a survey. I am answering it because the tension in it is common to any small organization that outsources IT: speed against accountability. You can have both if you design for it.

Why the shared account keeps winning

Shared admin accounts survive because they are fast. A technician gets a ticket, logs in with the one credential everybody knows, fixes it, and moves on. Nobody waits for approval.

The cost shows up later. When something goes wrong on a workstation that touches patient data, the question is who made the change, when, and why. A shared account answers none of that. Rotation is painful, so the password lives for a long time. A technician who leaves the provider still knows it. MFA, when it exists, often gets tied to one person's phone and then quietly removed because it blocks everyone else.

An SC Media op-ed by Dakota Deter of Alias Intelligence makes the vendor-side point directly: "trust is not a security control," and a compromised vendor with broad system access can become an entry point into the networks it can reach. Deter argues for mapping vendor access during due diligence so that assumptions about third-party access become documented findings. A shared admin account is an assumption you cannot document.

The just-in-time pattern

Here is the pattern I would put in place for a clinic of that size. Five parts, each simple on its own.

1. Named accounts for every technician. Each person at the provider gets their own account in your directory, tied to their name and the provider's ticket system. When someone leaves the provider, the provider tells you the same day and you disable one account. Put that notice obligation in the contract.
2. MFA on every account, enforced at sign-in to your environment. Not a shared token. If a technician cannot complete MFA, they do not get in, and that is a ticket for the provider to fix on their side.
3. No standing local admin. The named accounts are standard users by default. Local admin rights come from time-boxed elevation: a request tied to a ticket number, approved by rule or by a person, that grants admin on the specific workstation for a fixed window (an hour is plenty for most fixes) and then expires on its own.
4. Session logging. Every elevated session records who, which device, which ticket, start and end time, and what was changed. If your remote support tool can record the session itself, turn that on for workstations that reach the EHR. Logs go somewhere the provider cannot edit.
5. A scheduled review. Someone on your side reads the elevation log on a calendar instead of waiting for an incident. Monthly is reasonable for 40 workstations. The review asks three things: did every elevation map to a real ticket, did any run long, and did anyone elevate on a device outside the ticket.

A local admin password tool that rotates a unique password per device also helps here, because it removes the one-credential-fits-all problem even for break-glass use.

Handling fixes that cannot wait

The clinic's real worry was speed. Approving each step by hand does not scale, and a clinician staring at a broken workstation cannot wait for the IT lead to get out of a meeting.

The answer is to pre-approve by rule rather than by person. Define a short list of routine fix types (printer drivers, a stuck EHR application update, a peripheral that will not enumerate) that get automatic elevation for a short window when tied to an open ticket. Everything else needs a named approver on your side, with a backup approver for after hours.

Then keep one break-glass account for true emergencies. Its password lives in a vault, it is rotated after every use, and every use generates an alert to your side the same day. Break-glass that nobody hears about is just a shared account with a dramatic name.

What the review should produce

The review is where this becomes evidence. Each month, write down the count of elevations, how many were pre-approved by rule versus approved by a person, any that did not match a ticket, and what you did about them. Keep it to half a page.

That half page answers the question in the clinic's post about scheduled versus after-incident review. After-incident review tells you what happened once. Scheduled review tells you whether the pattern is holding. It also gives you something concrete to hand an auditor, a cyber insurer, or a health system partner that asks how you control outside access. I made a related point in The tool you forgot to list: anything that can reach patient data belongs on your inventory and in your questionnaire answers. An outside technician's admin access is that kind of access.

A first step for next week

Ask your outside IT provider one question: how many people at your company can sign in to our workstations as an administrator right now, and can you send me their names? If the answer is "everyone uses the same account," you have found the place to start. Moving to named accounts and MFA is the first week. Time-boxed elevation and the monthly review can follow. Which part of your current setup would you be unable to explain from the logs?