Who let the vendor in? Per-session authorization for medical device service access

In July 2026, threat actors reached internet-exposed controllers at water utilities across a dozen states, changed credentials and locked operators out of their own plants. Clinical engineering runs a structurally similar architecture — vendor remote access to safety-critical equipment — with considerably less governance and no regulator asking for session evidence.

Part of Hospital and clinical identity

The architecture, stated plainly

A health system operates tens of thousands of networked devices: infusion pumps, ventilators, imaging consoles, laboratory analysers, dialysis machines, physiologic monitors. Most are serviced remotely by the manufacturer's field service organisation under a support contract.

The access path is typically a manufacturer-supplied remote support tool, a jump host, or a site-to-site tunnel. The credential is an account belonging to the manufacturer. Multiple engineers use it. The approval to enter is an email or a service ticket. Session boundaries are enforced by the vendor's own tooling, and the resulting log lives in the vendor's system.

None of that is negligence. It is the arrangement the procurement contract specified, and it exists because devices need servicing and manufacturers employ the only people qualified to do it.

The read-across from operational technology

Other critical-infrastructure sectors have already been made to confront this. In the electric sector, NERC CIP-005 obliges registered entities to determine active vendor remote access sessions and to have a method to terminate them and control reconnection; CIP-003-9 extended vendor remote-access controls to low-impact systems from 1 April 2026. Whatever one thinks of the compliance burden, the obligation forced utilities to be able to answer a simple question: who is in our equipment right now?

Ask a healthcare technology management director the same question about imaging consoles and the honest answer is usually that they would need to ask the vendor.

Three questions a hospital cannot currently answer

Those three gaps combine badly. After an unexplained device behaviour, the hospital's investigation depends on the cooperation of the party whose engineer was last inside it.

The Clinical Vendor Session Receipt

The control is a delegation, issued by a named hospital approver to a named vendor engineer, scoped and time-bounded, producing a receipt that all three parties hold.

1. Request. The vendor engineer requests access naming the device or device group, the work order, and the intended scope of change.
2. Authorization. A named hospital approver — typically clinical engineering, not IT — signs a delegation carrying the device identifiers, the permitted scope, and an expiry measured in hours.
3. Session. The engineer signs an assertion against that delegation at session start. The access path checks the delegation before permitting the connection.
4. Close. At session end the engineer signs a statement of what was changed. The receipt chain verifies offline against published keys.

The chain verifies to a human on each side. The hospital holds evidence it produced. The manufacturer holds evidence protecting its engineer from an unfounded allegation. A regulator or a plaintiff can verify both without access to either party's systems.

Revocation is the operationally interesting part

Standing access is the real exposure, and it persists because revoking it is administratively painful. A delegation with an expiry inverts the default: access ends unless renewed, rather than persisting unless revoked.

For the cases where you need to cut a session immediately — an engineer working on the wrong device, a contract terminated, an incident in progress — revocation propagates in well under a second and is itself a signed act, so the decision to cut access is as attributable as the decision to grant it.

Counting your exposure first

Before proposing anything, produce the number. Most HTM departments undercount vendor sessions by an order of magnitude because they count contracts rather than connections.

1. Pull firewall or remote-access logs for one modality for 90 days.
2. Count distinct sessions, not distinct accounts.
3. Cross-reference against work orders. The unmatched sessions are the finding.
4. Multiply by modality count for a site-level estimate, then present the ratio of sessions to documented approvals.

That ratio is usually what moves a capital committee, because it is not a security argument. It is a control-environment argument that an internal auditor will recognise immediately.

What this is not

This is not a medical device security product, and it makes no claim about device firmware, network segmentation, or premarket cybersecurity obligations — all of which matter and none of which this addresses. It is an evidence layer for one specific, currently unrecorded act: a human inside the hospital deciding to let a human outside the hospital into a patient-connected device.

Why this access is unusual

Objections and honest limits

“The vendor logs their own sessions.” They log their access to their product, produced by the party whose access is in question. It is the weakest available form of the evidence and the hospital holds none of it.

“Biomed cannot gate every service call.” They should not try. Gate configuration changes and software updates — the subset that alters the device — rather than diagnostic sessions.

Gating device service access

1. Separate diagnostic access from configuration change. Two different bars.
2. Require a named hospital signature for the second. Biomed, not a ticket number.
3. Bind the device, the change and the window. So the receipt says what was permitted.
4. Keep the receipt outside the vendor's tooling. So the hospital holds its own evidence.

Terms used here

Biomedical engineering

The hospital function responsible for medical device maintenance and vendor coordination.

Remote service session

A manufacturer connecting to a device for diagnosis or maintenance.

Cleared function

The device behaviour covered by its regulatory clearance, which configuration changes can affect.

Frequently asked questions

Will manufacturers agree to this? Several will, because it protects their engineers in a dispute as much as it protects the hospital. The leverage point is contract renewal, and the ask is modest: sign a session-start and session-end statement through a browser.

Does this work on air-gapped or poorly connected devices? Verification is offline against a published key, with no callback required, which is why the design suits environments with unreliable connectivity.

Is this an FDA requirement? No. FDA cybersecurity expectations address manufacturers, primarily at premarket. This is a hospital-side control with no regulatory mandate behind it, which is precisely why it has not been built.

Who should be the approver — IT or clinical engineering? Clinical engineering, in almost every case. They own the device, understand the clinical consequence of the change, and are the party a regulator would expect to have authorised it.

Why is device vendor access different from IT vendor access? The device is a regulated product on a clinical network with a patient connected to it. The consequences can be physical.

Should every service call be gated? No. Gate configuration changes and software updates — the subset that alters the device — not diagnostic sessions.

Why not rely on the vendor's logs? They are the vendor's records about their own access, and the hospital holds none of them.

Sources and further reading

• CISA cybersecurity advisories
• NERC Reliability Standards — CIP
• FDA medical device cybersecurity guidance and postmarket management expectations.
• Healthcare technology management practice literature on vendor service access.
• 45 CFR §164.312 — HIPAA Security Rule technical safeguards