A machine identity that uses a client certificate, private key, and often a password-protected PFX archive to authenticate to a service. If any part of that bundle is exposed, the workload can be impersonated until the certificate is revoked or replaced.
Expanded Definition
Certificate-based workload identity is a machine identity pattern in which a service, container, or automated job proves who it is by presenting a client certificate paired with a private key. In some deployments, that credential bundle is packaged as a PFX archive, which makes the private key easier to distribute but also raises the impact of exposure because the bundle can be reused for impersonation until revocation or replacement occurs.
In NHI security, the term is narrower than general certificate authentication. It usually refers to workload-to-service authentication, not user sign-in or device enrollment. The security value comes from binding identity to cryptographic material, but the operational burden comes from issuance, rotation, revocation, and storage hygiene. Industry usage is still evolving, and definitions vary across vendors when certificates are combined with SPIFFE, service mesh, or platform-native secrets workflows. The SPIFFE workload identity specification is the clearest external reference point for certificate-backed workload identity semantics.
The most common misapplication is treating a certificate bundle as a durable application credential, which occurs when teams embed the private key in code, image layers, or shared storage instead of managing it as a rotating identity artifact.
Examples and Use Cases
Implementing certificate-based workload identity rigorously often introduces lifecycle overhead, requiring organisations to balance strong cryptographic assurance against renewal, distribution, and revocation complexity.
- A Kubernetes workload authenticates to an internal API with a short-lived client certificate issued by an internal trust anchor, reducing reliance on static API keys.
- A CI/CD runner uses a certificate and private key to reach a deployment service, with rotation aligned to job duration rather than a human password cycle.
- A service mesh enforces mutual TLS between microservices, where certificate identity is used to authorise east-west traffic and limit lateral movement.
- A legacy Windows service still depends on a password-protected PFX archive, which may be acceptable for compatibility but demands tighter key custody and faster replacement on compromise.
- NHI teams compare certificate inventory and expiry risk against the patterns described in the Ultimate Guide to NHIs — What are Non-Human Identities and map workload authentication behavior to the SPIFFE workload identity specification.
- Security teams use certificate issuance logs to detect unowned workload identities, especially where certificates exist outside a central secrets manager or platform identity plane.
Why It Matters in NHI Security
Certificate-based workload identity is attractive because it gives machines a verifiable cryptographic identity, but it also concentrates risk into a small set of assets that attackers actively target. If the certificate, private key, or PFX archive is exposed, an attacker can impersonate the workload, access downstream services, and blend into expected automation. That makes inventory, ownership, and revocation just as important as encryption strength.
The scale problem is now material. In The Critical Gaps in Machine Identity Management report, SailPoint found that 69% of organisations now have more machine identities than human ones, while only 38% have automated certificate lifecycle management in place. NHIMG also notes that 71% of NHIs are not rotated within recommended time frames, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in the Ultimate Guide to NHIs. Those figures point to a familiar failure mode: certificates are issued faster than teams can track, rotate, and retire them.
Organisations typically encounter certificate-based workload identity as an urgent problem only after an outage, a leaked bundle, or an abuse investigation, at which point revocation and replacement become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Addresses weak lifecycle and exposure risks for workload identities and their credentials. |
| OWASP Agentic AI Top 10 | Agentic systems often rely on certificate-based machine identities for tool access and service calls. | |
| NIST SP 800-63 | AAL2 | Credential assurance concepts help calibrate strength and replay resistance for machine authentication. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust requires continuous verification of workload identity before granting service access. |
| NIST CSF 2.0 | PR.AC-1 | Identity and credential management controls cover machine identities and certificate trust material. |
Treat certificate-backed execution paths as privileged agent credentials and restrict their downstream access.
Related resources from NHI Mgmt Group
- What breaks when certificate-based controls do not include workload identity?
- What is the difference between workload identity and secret-based access?
- When should organisations move from vault-based secrets to workload identity?
- How should security teams replace secret zero with attestation-based workload identity?
