What should organisations do when certificates are used for both users and machines?

Why This Matters for Security Teams

Certificates only behave safely when the organisation knows whether they are representing a person or a workload. That distinction drives recovery, renewal, revocation, and accountability. Human certificates are tied to joiner-mover-leaver processes and help-desk recovery. Machine certificates must be bound to assets, service accounts, or workloads and revoked automatically when infrastructure changes. Treating both under one policy usually creates ambiguous ownership and delayed response when something breaks. The problem is not academic: the Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which makes certificate governance harder to sustain at scale. NIST’s Cybersecurity Framework 2.0 reinforces the need for clear asset, identity, and recovery practices, but current guidance still leaves implementation details to the organisation. In practice, many security teams discover this gap only after a service outage or an access dispute has already exposed it.

How It Works in Practice

The practical answer is to split certificate governance into two lifecycle tracks and make each track explicit in policy. Human certificates should follow identity proofing, user support, break-glass recovery, and deprovisioning aligned to HR events. Machine certificates should follow workload registration, asset binding, automated issuance, short-lived renewal, and deterministic revocation when a host, container, pipeline, or service is retired.

For machine identities, the certificate is only part of the control. The stronger pattern is workload identity plus policy-enforced access at request time, not just a long-lived certificate sitting on disk. That is why modern guidance increasingly points to cryptographic workload identity, short TTLs, and runtime authorization rather than manual certificate handling. Where possible, organisations should pair certificate services with inventory, ownership, and automated rotation so that every certificate maps to a known system and a known business purpose. The Critical Gaps in Machine Identity Management report found that 66% of respondents said machine identity management requires significantly more manual intervention than human identity management, which is exactly why one blended process tends to fail.

• Use separate issuance paths for users and workloads.
• Bind machine certificates to asset inventory, cluster identity, or service ownership.
• Automate renewal well before expiry and revoke on decommission, redeploy, or compromise.
• Keep human recovery workflows distinct from workload rollback or redeployment workflows.
• Log certificate issuance, renewal, and revocation with different approval and audit signals.

Where this breaks down is in ephemeral environments with unmanaged containers, ad hoc scripts, or shadow infrastructure because ownership and revocation signals are missing or stale.

Common Variations and Edge Cases

Tighter separation of certificate policies often increases operational overhead, so organisations have to balance governance clarity against implementation complexity. The most common edge case is a hybrid platform where the same platform team supports both employee authentication and service-to-service authentication. Current guidance suggests keeping one certificate authority service if needed, but not one policy model, one renewal cadence, or one revocation path for both use cases.

Another common exception is emergency access. Human certificates may need recovery procedures that preserve continuity, while machine certificates should usually fail closed and be reissued from a trusted source. Best practice is evolving here, but there is no universal standard that says a single certificate lifecycle should govern both. The operational goal is to make it obvious who or what the certificate represents at every step, and to avoid any workflow that lets a workload inherit the softer recovery rules designed for a person. For broader NHI lifecycle context, the Schneider Electric credentials breach and the Sisense breach both underscore how quickly credential misuse becomes a business incident when ownership and revocation are unclear.

Related resources from NHI Mgmt Group

• When should organisations require CA-signed certificates for SAML?
• What should organisations do when users work around MFA or other access controls?
• How should security teams choose between self-signed and CA-signed SAML certificates?
• Why do SAML certificates not need the same trust model as HTTPS certificates?