Why do connected medical devices need PKI instead of shared credentials?

Why This Matters for Security Teams

Connected medical devices are not just endpoints; they are autonomous trust participants that can authenticate to hospital systems, telemetry platforms, update services, and sometimes clinical workflows. In that environment, shared credentials create a single compromise path across the fleet, while PKI lets each device present a unique, verifiable identity with scoped trust and revocation. That matters because device identity failures often become patient safety issues, not just IT incidents. Guidance from the OWASP Non-Human Identity Top 10 maps the risk clearly: secrets shared across machines are difficult to govern and easy to abuse.

NHI Management Group research shows how quickly secret exposure becomes operationally dangerous. In the Ultimate Guide to NHIs, static secrets are contrasted with dynamic credentials because rotation and containment are materially harder at scale. This is especially relevant in clinical environments where devices are deployed for years, vendor access is fragmented, and downtime windows are narrow. The result is a common mismatch: security teams assume a shared password is simpler to manage, then discover it is also simpler to steal, reuse, and fail to retire. In practice, many security teams encounter the real weakness only after a fleet-wide credential leak or a delayed device replacement cycle has already expanded the blast radius.

How It Works in Practice

PKI changes the trust model from “who knows the secret” to “what device can prove its identity.” Each medical device receives a unique certificate during manufacture, onboarding, or initial provisioning, and backend services validate that certificate against an approved trust chain before allowing access. When implemented well, the certificate is bound to the device, issued under a controlled policy, and retired when the device is decommissioned or replaced. That creates a revocation path that shared credentials do not provide.

For connected medical fleets, the practical controls usually include:

• Unique device certificates rather than shared passwords or shared API keys.
• Shorter certificate lifetimes where operations can support it, so compromise windows stay limited.
• Automated renewal and revocation workflows tied to asset inventory and lifecycle management.
• Backend verification of certificate chain, device posture, and endpoint role before accepting traffic.
• Segregation of issuance authority so a compromised vendor process does not automatically compromise the entire fleet.

This approach aligns with the broader NHI guidance in the Secret Sprawl Challenge, where shared credentials are shown to multiply risk across systems that are difficult to inventory and rotate cleanly. It also fits the identity direction in NIST SP 800-63 Digital Identity Guidelines, which reinforce that identity assurance depends on strong proofing and lifecycle management, not reusable secrets alone. For medical environments, the key operational question is not whether certificates are more secure in theory, but whether issuance, renewal, and revocation are automated enough to survive real device lifecycles. These controls tend to break down when legacy devices cannot support certificate renewal or when vendors hard-code trust anchors that cannot be rotated without firmware changes.

Common Variations and Edge Cases

Tighter PKI controls often increase operational overhead, requiring organisations to balance stronger device assurance against firmware constraints, clinical uptime, and vendor support limits. That tradeoff is real in healthcare, where some devices ship with limited crypto support or long maintenance cycles.

Best practice is evolving, but current guidance suggests avoiding a false choice between “full PKI everywhere” and “shared secrets forever.” In some environments, certificate-based mTLS may be practical for modern devices while older equipment is isolated behind gateways that translate legacy protocols into a safer trust boundary. In others, certificate enrollment may need to be staged during manufacturing or managed through a dedicated device identity service. The important point is that shared credentials should be treated as a temporary compatibility measure, not a security strategy.

There is also a lifecycle edge case: if certificates are issued but revocation is not enforced by the receiving system, the control degrades quickly. That is why issuer policy, CRL or OCSP checking, asset decommissioning, and vendor accountability must be designed together. For broader NHI governance and incident patterns, NHIMG’s 2024 Non-Human Identity Security Report found that only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, which reflects the maturity gap behind many device identity programs. The same report also shows how widespread insecure secret handling remains, which is why PKI is often the safer default for connected medical devices.

Related resources from NHI Mgmt Group

• Why do IoT devices need certificates instead of shared secrets?
• How should security teams reduce credential sharing on shared devices?
• How should healthcare organisations secure shared mobile devices without slowing clinicians down?
• How can organizations secure their MCP server credentials?