How do organisations decide whether CBA should be used for users, devices, or workloads?

Why This Matters for Security Teams

CBA is often discussed as if the same certificate policy can be applied uniformly, but the governance question changes by actor type. A person can be managed through joiner-mover-leaver processes, a device can be enrolled and revoked, and a workload must be governed as a runtime service with ownership, rotation, and context-aware trust. The operational failure is not certificate issuance itself, but misclassifying who or what the certificate is binding.

This distinction matters because machine identities already outnumber human identities in many environments, and lifecycle failure is common. NHI Management Group notes that 69% of organisations now have more machine identities than human ones in its Ultimate Guide to NHIs, while SailPoint reports that certificate expiry is the leading cause of outages for 45% of organisations in its Critical Gaps in Machine Identity Management report. That combination makes CBA a governance decision, not just a technical one.

Practitioners usually get into trouble when they apply the same control model to users, devices, and workloads without checking whether the identity can actually be owned, monitored, and revoked end to end. In practice, many security teams encounter certificate failure only after a service outage or access incident has already occurred, rather than through intentional lifecycle control.

How It Works in Practice

The practical way to decide is to start with the actor’s lifecycle and control surface. For users, CBA should support strong authentication into an identity process already governed by HR and PAM. For devices, the certificate should be tied to a managed endpoint or hardware root of trust, with enrollment, revocation, and posture checks. For workloads, the certificate is usually a workload identity primitive that proves what the service is, not who logged in.

That workload case is where many programmes diverge. Current guidance suggests using short-lived, automatically rotated credentials where possible, because static certificates create hidden standing trust. The SPIFFE workload identity specification is widely used as a reference point for cryptographic workload identity, and NHIMG’s Guide to SPIFFE and SPIRE explains why ephemeral trust is better suited to services that scale, redeploy, and communicate dynamically.

• Users: align certificate issuance to joiner-mover-leaver controls, MFA, and access reviews.
• Devices: bind certificates to managed inventory, posture, and revocation workflows.
• Workloads: issue short-lived credentials per service or task, with automated renewal and revocation.
• All actors: define ownership, TTL, and recovery paths before rollout.

For workloads, best practice is evolving toward workload identity, policy-as-code, and runtime authorization rather than one-time certificate issuance. That means certificate trust is evaluated alongside service identity, environment, and request context, not just on a static subject field. These controls tend to break down when workloads are ephemeral across Kubernetes, serverless, and CI/CD environments because ownership and revocation become fragmented across too many systems.

Common Variations and Edge Cases

Tighter certificate governance often increases operational overhead, requiring organisations to balance stronger trust boundaries against renewal complexity and ownership gaps. That tradeoff is most visible when a single certificate authority policy is expected to serve users, devices, and workloads at once.

There is no universal standard for this yet, especially for agentic systems and highly dynamic workloads. For human users, CBA may be appropriate for high-assurance access, but it should not replace identity proofing, lifecycle review, or PAM. For devices, CBA is strongest when the device is managed end to end and revocation can actually be enforced. For workloads, certificate-based trust should usually be paired with workload identity controls and frequent rotation, because long-lived secrets create a different risk profile than human credentials.

In practice, the key edge case is shared infrastructure. A platform team may own the certificate authority, while application teams own the workload, and a security team owns policy. If those responsibilities are not explicit, revocation, renewal, and incident response slow down. That is also where standards guidance helps: the Ultimate Guide to NHIs — Standards is useful for mapping certificate controls to broader NHI governance, while vendor-neutral identity guidance should be used to keep the model auditable and consistent.

For autonomous software, the challenge is greater still because the identity may be acting on behalf of a goal rather than a fixed user session. In those cases, certificate decisions should be tied to runtime authorization and service accountability, not to the assumption that one certificate equals one stable actor.

Related resources from NHI Mgmt Group

• How should organisations govern external users in SaaS environments?
• How can organisations know whether Linux IoT security controls are actually working?
• How should teams decide whether to use IAM, IGA, or both?
• How do organisations know whether a replacement will preserve governance quality?