Infusion Pump Certificates and a Shared Biomed Account
Mercy Regional Hospital has 900 networked infusion pumps using mutual TLS to a vendor management platform. Device certificates are issued by the vendor's CA, have two-year lifetimes, and 540 expire within nine months. Renewal requires a certificate signing request generated on the pump, and many pumps cannot be powered down during active infusions; 15% are in continuous oncology use. The biomedical team of 22 technicians shares one domain account, with the password stored in a spreadsheet, and the vendor's remote support uses the same account. There is no HSM at the hospital; the vendor offers a cloud PKI service with automated enrollment but the hospital's security team has not approved it. An internal audit found no inventory of which pump has which certificate. The CISO wants certificate expiry removed as an outage risk before addressing the shared account.
1. Evaluate the CISO's prioritization: certificate expiry before the shared account. Do you agree?
Read the worked answer
I would not accept the sequencing as stated. Certificate expiry is a certain availability event: 540 pumps in nine months, with renewal requiring an on-device CSR and limited downtime. That deserves a dedicated program and an expiry dashboard now. But the shared biomedical account is an active confidentiality and integrity risk: 22 people share one identity, the password is in a spreadsheet, and the vendor uses it too. It defeats least privilege and audit, and it is the most likely path for lateral movement from a technician workstation to the pump fleet.
The right judgment is to run both tracks in parallel, with the shared account mitigated immediately by MFA, vaulting, and privilege reduction, while the certificate program gets its own schedule. If forced to choose one first, reduce the shared account's blast radius this week and start certificate discovery in parallel; a certificate outage can be planned, but a shared credential compromise cannot.
2. Design a certificate lifecycle that avoids infusion interruptions.
Read the worked answer
Build an inventory first: pump serial, firmware, certificate serial, issuer, expiry, and clinical owner. Use the vendor's automated enrollment if it can be approved with contractual controls; otherwise stand up an internal intermediate CA and use EST/SCEP where supported. Issue shorter-lived certificates, for example 90–180 days, with automated renewal at two-thirds of life so expiry becomes routine rather than a project. For pumps that cannot generate a CSR while infusing, schedule renewal in clinical windows and use a canary group; verify the pump reconnects to the management platform before expanding. Keep the old certificate valid until the new one is confirmed, and have a rollback procedure. Do not put the CA private key on a general-purpose server; use an HSM or the vendor's managed service with clear key-custody terms. Monitor expiry and enrollment failures centrally.
3. What access model should replace the shared biomedical account, including vendor support?
Read the worked answer
Replace the shared account with named accounts for each technician, backed by the hospital directory, MFA, and role-based groups: biomedical technicians get device maintenance rights, not domain-wide rights. Put administrative credentials in a privileged access vault with checkout, approval, and automatic rotation; break-glass accounts are sealed, monitored, and rotated after use. For vendor support, require named vendor engineers, federated identity or guest accounts with MFA, just-in-time elevation, and session recording through a jump host. The vendor should not use a hospital technician's account. Define support hours and an emergency path with approval. Log every pump command to the individual, not to “biomed.” The residual risk is that clinical urgency will push staff back to shared credentials; design the break-glass path to be faster than the spreadsheet, or it will be bypassed.