The problem
Legacy medical devices commonly expose a physical service port — RS-232, USB, or a proprietary connector — that vendor field engineers use for diagnostics, configuration, and firmware updates. The port is typically protected by:
Hardcoded service-mode password
Documented in service manuals that frequently leak online; identical across deployment sites.
No per-user authentication
Once anyone has the password, all actions are attributed to "service mode" — no individual accountability.
No audit logging on the device
Configuration changes, firmware updates, and parameter modifications leave no trace.
Cannot be retrofitted with MFA
Vendor firmware is locked by FDA clearance; modifying it requires re-submission, a multi-year process.
Patterns A (upstream PAM) and B (network gating) protect the network management interface but do nothing for the physical service port. Pattern C closes that gap.
How Pattern C works
A small inline hardware element sits between the technician's laptop and the device's service port. Every byte of every session passes through it.
Technician laptop
Pattern C MFA Shim
Medical device
The shim also reaches a central SIEM over a side channel for session forwarding, heartbeats, and tamper alerts. Full architecture →
Session flow — click "Run" to step through
Technician plugs in laptop
Service tooling opens the serial connection. The shim intercepts; no traffic passes through until step 4 succeeds.
Shim presents authentication prompt
"Authenticate as: <technician_id> <totp_code>". Tamper detector confirms the case is sealed; if not, session is refused before prompt.
Technician submits TOTP code
Generated by their authenticator app from the shared secret issued at enrollment. Try the live demo below.
TOTP gate validates
Checks the code against ±1 time-window tolerance, marks the period used (replay protection), tracks failed attempts (lockout). If valid: emit session_start event; passthrough enabled.
Bidirectional session
Every byte recorded with direction (IN/OUT), timestamp, and technician ID. Recorded to local non-volatile storage and forwarded to SIEM when reachable.
Session ends
Technician disconnects, or shim force-closes on tamper event or emergency stop. Footer event emitted with terminal reason and byte counts.
Live TOTP demo
Generates a real TOTP code (RFC 6238, SHA-1, 6 digits, 30-second period) from a demo secret. Enter the current code into the field below to test the gate logic. This is the same algorithm prototype/totp_gate.py implements.
STRIDE-HC threats addressed
T — Tampering
Firmware injection via service port now requires TOTP authentication. Every byte recorded for forensic analysis.
R — Repudiation
Per-user attribution restored via TOTP binding. Session recording provides post-hoc proof of who did what.
E — Elevation of Privilege
Documented service-port password is operationally useless without a valid TOTP. Lockout prevents brute force.
I — Information Disclosure (partial)
Insider PHI capture via service-port export is deterred by session recording. Vendor still sees PHI in the clear when authorized; not a confidentiality control.
See stride-hc-templates/examples/infusion-pump.md for the worked threat model that prescribes this control.
Documentation
README.md
Overview, why Pattern C exists, where this fits in the wider repo.
DESIGN.md
Design rationale and security properties.
ARCHITECTURE.md
System architecture, components, data flow.
FDA-CONSIDERATIONS.md ⚠️
Regulatory analysis. Read before any clinical deployment.
prototype/README.md
How to run the Python reference implementation. 37 tests, all passing.
hardware/README.md
Notes on porting to Raspberry Pi / ESP32 / custom hardware.
CJR example
Worked Control Justification Record for deploying Pattern C against a leaked service PIN.
Source on GitHub
Browse the Python code, tests, and configuration template.