End-of-Life Pumps with TLS 1.0 and a Certificate-Pinning Client
A hospital has 300 infusion pumps with embedded web servers used by a vendor's maintenance laptop. A scan finds that the pumps offer only TLS 1.0/1.1 with RSA-1024 and SHA-1 certificates, and a shared local admin password. The vendor is end-of-life and offers no firmware update; replacement is budgeted over 18 months. The pumps share a flat VLAN with nurse station PCs. Clinicians say losing remote maintenance access would force manual checks, adding 30 minutes per shift, and the vendor's contract requires connectivity. One proposal is to switch off the web servers immediately; another is to place the devices behind a TLS-terminating reverse proxy with modern ciphers and certificate-based client authentication. The proxy would speak TLS 1.0/1.1 to the pumps and hold a credential mapping. The maintenance laptop's client software pins each pump's self-signed certificate.
1. Assess the risk of the current state and rank the two proposals, including the pinning constraint.
Read the worked answer
The current state is high likelihood times high severity. SHA-1 certificates with RSA-1024 give roughly 80-bit security, and chosen-prefix collisions against SHA-1 are practical enough that a forged certificate is a realistic attack for a motivated adversary, not a theoretical one. TLS 1.0 and 1.1 are formally deprecated and lack modern cipher suites and handshake protections. A shared admin password means no accountability and no way to revoke one user. The flat VLAN with nurse station PCs turns a pump compromise into lateral movement toward clinical systems, and the asset is safety-critical, so the severity is patient harm, not data loss.
Switching off the web servers is the safest from a pure security view but creates an immediate clinical and contractual problem, and an availability failure in an infusion fleet is itself a safety event. It should not be done unilaterally by the engineering team.
The proxy is attractive but blocked on one detail: the maintenance client pins each pump's self-signed certificate, so a terminating proxy presenting its own certificate will be rejected. Making it work would require exporting pump private keys or modifying the vendor client, both worse than the original problem. The proxy may still be usable for the browser-based admin interface if that path is not pinned, but it cannot be assumed.
2. Design the compensating-control architecture and state the residual risk and who must accept it.
Read the worked answer
Segment first. Move the pumps to a dedicated VLAN with no route to nurse stations, allow only the specific flows the maintenance workflow needs, and place a firewall or internal segmentation control between the pump segment and clinical networks. Require remote maintenance to enter through a jump host with per-user authentication and session recording, restricted to maintenance windows, instead of letting the vendor laptop reach pumps directly. Enforce 802.1X on the switch ports so an unregistered laptop cannot join.
Replace the shared password with unique per-device credentials held in a privileged access vault, rotated on a schedule and checked out per session, so every action is attributable. Disable unused services on the pumps, mine logs into the SIEM, and alert on unexpected connections, configuration changes and failed logins. Block pump egress to the internet entirely. Put the EOL status in the risk register with an explicit replacement date and a quarterly review.
Residual risk is unavoidable: the pumps still speak broken TLS and still hold a weak key, so an attacker inside the segment or with physical port access can intercept or impersonate. That risk cannot be engineered away before replacement; it must be formally accepted in writing by an accountable owner, typically the CIO with the chief medical officer, with the clinical and vendor stakeholders informed. It is not a decision for the engineer to make silently.
3. How would you handle the clinician, vendor and documentation side of this decision?
Read the worked answer
Communicate in clinical terms, not cryptographic ones. Tell clinicians what changes for them, when, and what the fallback is if the maintenance link is unavailable, and give them a named contact. Do not describe the devices as "unsafe" without context, because that invites unilateral disconnection and panic.
The vendor contract requires connectivity, but a contract term does not override patient safety, and it also does not authorise bypassing controls. Put the requirement in writing to the vendor: what compensating controls are being applied, what access window is permitted, and what the vendor must provide to remove them. Ask formally whether a supported client or firmware exists at any price. Escalate through procurement and legal if the answer is no.
Document the decision as an engineering record: the scan evidence, the risk analysis, the options considered and rejected (including why immediate shutdown and the terminating proxy were not chosen), the controls implemented, the residual risk and the named acceptor, the replacement schedule, and the review date. Record the pinning problem explicitly so the next engineer does not rediscover it after buying a proxy.
If pressure appears to suppress the finding or to skip the replacement plan, the professional obligation is to escalate in writing rather than comply quietly; public safety outranks internal convenience.