They should treat them as both, but governance belongs with IAM because the business problem is who or what is trusted to access resources. PKI handles cryptographic issuance and validation, while IAM must own lifecycle state, offboarding, and accountability for the device identity itself.
How device certificates fit both IAM and PKI
Device certificates are not just cryptographic artefacts, and they are not just an endpoint detail. They sit at the intersection of trust establishment and identity governance. PKI is responsible for issuing, chaining, validating, and revoking the certificate, while IAM should own the business decision about which device identity exists, who can register it, what it may access, and when it must be removed.
That split matters because the certificate is only the proofing and authentication mechanism. The identity problem is broader: the device is an actor with lifecycle state, ownership, and privilege boundaries. If teams treat the certificate as a PKI-only concern, they often miss the downstream control questions around enrollment, replacement, suspension, offboarding, and accountability for access to corporate resources.
In practice, the cleanest model is to treat the device certificate as an identity-bearing credential and the device itself as an IAM-managed subject. Device and IoT Identity Guide is useful here because it frames device certificates alongside attestation, secure onboarding, and device trust rather than as a standalone PKI artifact. That is the right mental model for enterprises that need both cryptographic assurance and lifecycle control.
Where PKI ends and endpoint IAM begins
PKI should own certificate issuance policy, trust anchors, key protection, renewal mechanics, revocation, and validation rules. Endpoint IAM should own the identity record, registration workflow, ownership, policy assignment, and the decision to permit or deny access based on the device state. Those responsibilities can be integrated, but they should not be collapsed into one team’s backlog just because both touch the same certificate.
This is especially important when the device certificate is used for mutual TLS, VPN access, wireless access, remote management, or service access from an endpoint. Machine Identity, PKI and Certificate Lifecycle Guide covers the certificate lifecycle side well, while NHI Lifecycle Management Guide helps anchor the broader governance obligations around provisioning, rotation, and offboarding. Together they show why lifecycle control is not optional metadata, it is the control plane.
For organisations with central identity programmes, the practical question is not whether PKI is involved, but which decisions require identity governance. A certificate can be valid cryptographically while the device is no longer owned, no longer managed, or no longer allowed to connect. That is an IAM failure, not a PKI failure.
What good governance looks like for device trust
Device certificates work best when ownership, issuance, and revocation are all traceable to a named control process. Identity Security Programme Guide is a useful pattern for this because it treats identity governance as a programme rather than a narrow technology service. That mindset is important for devices, where onboarding often spans endpoint management, PKI, security operations, and infrastructure teams.
Good governance also means mapping certificate state to business state. If a laptop is reimaged, reassigned, lost, retired, or suspected compromised, the associated device identity should move through a defined lifecycle state and lose access accordingly. Cloud Workload Identity Guide is relevant as a parallel model because it shows how temporary, scoped trust should replace static, unmanaged credentials wherever possible.
For certificate-based device trust, the operational test is simple: can you prove who enrolled the device, who owns it, what trust it has, what it can access, and how quickly that trust is removed when the device leaves service? If not, the organisation is relying on cryptography without lifecycle governance.
Risk and Threat Considerations
Device certificates can create false confidence when teams assume that valid cryptography equals valid trust. Stolen, copied, or long-lived certificates can enable persistence, lateral movement, and unauthorised access long after the device should have been removed from service.
Failure mechanism: Compromise usually occurs when certificate lifecycle controls are weaker than certificate validation controls, for example when offboarding is delayed, renewal is automated without ownership checks, or certificate reuse is allowed across devices.
Impact: An attacker or former device holder may continue to authenticate as a trusted endpoint, which turns device trust into a durable access path and can make containment much harder than the original compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Device certificates govern trusted device access and lifecycle. |
| Recommendation — Tie device certificates to IAM ownership, issuance, revocation, and access decisions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificates require lifecycle control, renewal, and revocation management. |
| IA-9 — Service Identification and Authentication | Device certificates authenticate non-human endpoints to resources. | |
| Recommendation — Manage certificate lifecycle, renewal, and revocation as controlled authenticators. Use certificate-based authentication for devices and enforce mutual trust validation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Device trust must align with access decisions and ownership. |
| A.8.24 — Use of cryptography | Certificates depend on cryptographic issuance, validation, and key handling. | |
| Recommendation — Define access rules so device certificate trust is granted and removed by policy. Apply cryptographic controls for certificate issuance, storage, and validation. | ||
Practitioner Guidance
What to prioritise: Treat device certificate ownership and offboarding as identity governance tasks, not just PKI hygiene. The first control question is whether the organisation can revoke trust quickly when a device is lost, reimaged, reassigned, or retired.
What to verify: Confirm that the identity record for each device links enrollment, certificate issuance, expected use, and revocation authority. If those four items live in different systems with no shared accountability, trust decisions will drift out of sync.
Decision rule: If the certificate is the mechanism that grants access to a protected resource, manage it through both PKI and IAM. If the question is only about cryptographic issuance or validation mechanics, PKI can lead, but lifecycle and access ownership still need identity governance.
Practitioner takeaway: Device certificates are a trust mechanism, but trust without lifecycle ownership is an access-control gap waiting to happen.