PKI For Devices

Expanded Definition

PKI for devices is the use of certificate-based trust to prove that a machine, appliance, or embedded endpoint is genuine before it is allowed to communicate. In NHI security, this matters because a device identity is not just a login method, it is the basis for authentication, authorization, and revocation across backend services. NIST’s NIST Cybersecurity Framework 2.0 frames this kind of trust as part of identity and access governance, while device PKI operationalizes it with certificates, private keys, and lifecycle controls.

Definitions vary across vendors on where PKI ends and device identity governance begins. Some tools treat certificate issuance as the primary control, while NHI programs treat the certificate as only one element of a broader identity lifecycle that includes provisioning, rotation, revocation, inventory, and offboarding. In medical and clinical environments, that distinction is critical because a device may remain physically present while its software state, network location, or vendor relationship changes. PKI gives security teams a way to bind trust to the device itself instead of to a shared secret that can be copied or reused.

The most common misapplication is treating PKI as a one-time enrollment step, which occurs when certificates are issued but renewal, revocation, and key protection are not operationally maintained.

Examples and Use Cases

Implementing device PKI rigorously often introduces certificate lifecycle overhead, requiring organisations to weigh stronger machine trust against operational complexity and renewal discipline.

• Medical infusion pumps present a client certificate to authenticate to a medication management platform, replacing shared credentials that could be extracted and reused.
• Imaging systems use certificates to establish mutual TLS with analytics services, so backend access depends on a validated device identity instead of a network location alone.
• Connected monitors are issued unique certificates during onboarding, then revoked when the asset is retired, stolen, or returned by a third party.
• Clinical gateways rotate device certificates on a schedule aligned to the organisation’s key-management policy, reducing the impact of long-lived trust artifacts.
• Device certificate issuance is tied to an inventory record so security teams can correlate trust decisions with asset ownership and maintenance status, a pattern discussed in the Ultimate Guide to NHIs and reflected in certificate-driven trust models referenced by the NIST Cybersecurity Framework 2.0.

For broader NHI programs, device PKI usually sits alongside secret detection, access reviews, and offboarding controls described in the Ultimate Guide to NHIs.

Why It Matters in NHI Security

PKI for devices is important because medical and operational technology often outlives the assumptions made during deployment. If trust is based on shared secrets or static network placement, compromise becomes difficult to detect and even harder to contain. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 71% of NHIs are not rotated within recommended time frames, which helps explain why device identities need explicit lifecycle governance rather than ad hoc administration. The same research also reports that only 5.7% of organisations have full visibility into their service accounts, a warning sign for environments where devices are expected to authenticate continuously without human supervision.

PKI becomes especially relevant when a device changes ownership, firmware, vendor support status, or clinical role. At that point, the organization must be able to revoke trust quickly and prove that the old identity can no longer connect. Without that capability, certificate-backed systems can still drift into weak practice if expired certificates, orphaned keys, or unmanaged renewal paths accumulate. The broader NHI lesson is that strong identity is only as strong as its revocation and inventory discipline.

Organisations typically encounter the consequences only after a device is lost, compromised, or decommissioned without cleanup, at which point PKI for devices becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should teams secure SaaS administration systems that can affect identities and devices?
• What is the difference between PKI hygiene and machine identity governance?
• When should organisations modernise PKI instead of keeping legacy processes?
• How should security teams handle legacy network devices in NHI governance?