How do organisations govern certificates and device identities alongside IAM?

Why This Matters for Security Teams

Certificates and device identities are not just technical artifacts. They are machine trust signals that determine what can authenticate, what can connect, and what can be revoked when risk changes. When organisations treat them as infrastructure byproducts, ownership becomes unclear, expiry is missed, and revocation is slow. That creates the same governance failure seen in broader non-human identity programs, where machine access drifts away from human oversight and auditability.

The operational problem is that certificates and device identities often span IAM, endpoint management, PKI, cloud platforms, and application teams. Without a single governance model, issuance and renewal happen on different schedules, under different controls, and with different approvals. The result is a fragmented identity estate that is difficult to inventory and even harder to defend. NHIMG’s research on machine identity management shows how common that gap is, including a 57% lack of complete inventory and a 61% reliance on spreadsheets or manual tracking in some environments, which aligns with the broader maturity gap described in the 2024 Non-Human Identity Security Report.

Security teams that already manage human IAM through joiner, mover, and leaver workflows should extend the same governance discipline to machine trust. In practice, many teams only discover certificate sprawl or stale device identities after an outage, an audit finding, or a failed incident response.

How It Works in Practice

The right model is to govern certificates and device identities as first-class identity objects with explicit lifecycle ownership. That means defining who requests them, who approves them, who issues them, how long they remain valid, and what conditions trigger renewal or revocation. The point is not to copy human IAM exactly, but to connect machine identity controls to the same change-management and access-governance processes that already exist for users.

In practice, this usually includes a few core steps. First, maintain an authoritative inventory of devices, workloads, certificates, and their owners. Second, link issuance to verified enrollment events such as device registration, workload deployment, or approved build pipelines. Third, automate renewal with short validity periods where the environment can support it, because long-lived certificates increase exposure when secrets or keys are stolen. Fourth, revoke quickly when a device is retired, compromised, reassigned, or out of policy.

• Map certificate issuance to joiner, mover, and leaver events for devices and workloads.
• Assign a business and technical owner to each certificate class and device identity type.
• Use policy-driven renewal windows instead of ad hoc manual reissue.
• Log issuance, renewal, and revocation as auditable identity events.

This is consistent with the NIST Cybersecurity Framework 2.0, which emphasizes governance, asset visibility, and controlled identity lifecycle management. It also aligns with NHIMG guidance in the Lifecycle Processes for Managing NHIs section, which frames lifecycle ownership as the foundation for machine trust. These controls tend to break down when certificates are issued by multiple teams with no shared inventory because revocation authority becomes fragmented and stale trust persists.

Common Variations and Edge Cases

Tighter certificate governance often increases operational overhead, requiring organisations to balance stronger trust control against deployment speed and device scale. That tradeoff is especially visible in environments with mobile devices, industrial systems, or third-party managed endpoints, where certificate rotation cannot always happen on a simple fixed schedule.

Best practice is evolving for edge and offline environments. Some organisations extend certificate lifetimes slightly when devices cannot reach the issuer reliably, while others use shorter-lived certificates paired with resilient enrollment or bootstrap trust. There is no universal standard for this yet, so the practical test is whether the exception is documented, approved, and monitored. The same caution applies to IoT fleets and shared devices, where a single physical asset may represent many logical identities over time.

Another common edge case is device identity overlap with endpoint management tools. That can create the false assumption that MDM or EDR ownership equals identity governance. It does not. Identity teams still need visibility into what is issued, when it expires, and who can revoke it. NHIMG’s Regulatory and Audit Perspectives section is useful here because auditability is often the forcing function for getting ownership right. In certificate-heavy estates, outages and audit gaps usually surface together, not separately.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities alongside human accounts?
• How should teams govern non-human identities alongside CAASM and EASM?
• How should organisations govern non-human identities alongside human IAM?
• How should organisations govern non-human identities alongside workforce IAM?