PKIaaS for Workload Identity Management

Most organizations have a reasonable handle on human identity: the directory is known, the accounts are enumerable, and MFA is either deployed or on a roadmap. Machine identity is a different story. Services authenticate to other services with API keys that were generated three years ago and live in a configuration file. CI/CD jobs present shared credentials that were never designed for the pipeline that now uses them. Containers spin up with service account tokens that outlive the container by months. AI agents make API calls with credentials that nobody audited before the agent was deployed.

The Palo Alto Networks 2026 Identity Security Landscape report (May 14, 2026) found a 109:1 ratio of machine identities to human identities in enterprise environments. Most of those machine identities are not managed with the same rigor as human identities. They are static, long-lived, hard to rotate, and invisible to the security teams responsible for managing identity risk.

Certificate-based workload identity, backed by PKI as a Service, addresses this directly. Short-lived, automatically rotated certificates replace static secrets. Cryptographic identity replaces string-matching. A verifiable chain of trust back to a governed CA replaces the hope that nobody has copied the API key. This post covers how PKIaaS enables workload identity management across services, microservices, containers, CI/CD pipelines, and AI agents, and how machine identity inventory and automation tie it together.

Quick Answer: What Does PKIaaS Do for Workload Identity?

PKIaaS provides the governed CA infrastructure that issues short-lived, automatically rotated certificates to non-human workloads: services, microservices, containers, CI/CD pipeline jobs, and AI agents. These certificates replace static secrets (API keys, passwords, service account tokens) as the mechanism workloads use to prove their identity to each other and to external systems. The certificates are cryptographically verifiable against the PKIaaS root CA, which any relying party can verify without contacting the issuing authority. They expire in hours to days rather than years, so a compromised credential is useless before a threat actor can exploit it meaningfully. And they are issued and rotated automatically by the workload identity infrastructure, not by humans running scripts on a schedule.

Key Takeaways

• Static secrets (API keys, passwords, service account tokens) are the root cause of most workload credential compromises. They are long-lived, shareable, embedded in code and configuration, and provide no cryptographic proof of which specific workload instance is using them. Certificate-based workload identity eliminates these properties: certificates are short-lived, cryptographically bound to the issuing context, automatically rotated, and chain to a verified CA root.
• SPIFFE (Secure Production Identity Framework for Everyone, CNCF) defines the open standard for workload identity. SPIRE is its reference implementation. PKIaaS connects to SPIFFE/SPIRE as the upstream certificate authority, giving SPIFFE-based workload identity an enterprise-governed CA root rather than a cluster-internal self-signed root. This makes workload identity certificates auditable and policy-governed alongside the rest of the organization’s PKI estate.
• CI/CD pipeline jobs are one of the highest-risk workload identity gaps in most organizations. Build jobs need credentials to access source code, container registries, deployment infrastructure, and secrets managers. Those credentials are typically static service account tokens or API keys that outlive the pipelines they were created for. Ephemeral job certificates issued at pipeline start and expired at pipeline end replace these long-lived static credentials with cryptographic identity that cannot be reused outside the pipeline run.
• AI agents require the same workload identity governance as any other software process, with increased urgency due to their autonomous behavior. An AI agent calling external APIs with a stolen static API key is indistinguishable from a legitimate agent call unless the identity mechanism provides cryptographic proof of the agent’s specific identity and current authorization scope. Certificate-based AI agent identity provides that proof.
• Machine identity inventory is the operational foundation of workload identity governance. Without a continuously updated catalog of every certificate, API key, service account, and token in the environment, security teams cannot identify expired credentials, policy violations, or orphaned identities belonging to decommissioned workloads. PKIaaS audit logs and CLM inventory provide the foundation; a CA-agnostic CLM platform extends it to non-PKI machine identities.

The Static Secrets Problem

Static secrets are credentials that do not change automatically: API keys, database passwords, service account tokens, and shared credentials stored in environment variables, configuration files, or secrets managers. They are the default mechanism for service-to-service authentication in most enterprise environments because they are easy to generate, easy to configure, and they work.

The security properties of static secrets are the inverse of what workload identity requires. They are long-lived: API keys generated for convenience in 2021 are still in production in 2026 in most organizations. They are shareable: a developer who needs to test a service in development copies the production API key from the secrets manager. They are opaque: the API key string itself carries no information about which workload is using it, so the receiving service cannot distinguish a legitimate call from an attacker who obtained a copy. They accumulate: every integration that was ever configured leaves a static credential in the environment, including integrations to services that no longer exist.

The consequences are predictable. Static credentials leaked through code repositories (a common incident vector), exfiltrated from secrets managers, or obtained through insider access provide an attacker with persistent access that is indistinguishable from legitimate workload activity until the credential is discovered and rotated. Rotation itself is painful: changing a widely-used service credential requires coordinating updates across every service that depends on it, which is why rotation is deferred and deferred credentials become permanent.

Certificate-based workload identity solves these problems structurally. A certificate issued to a specific workload instance is short-lived (1 to 24 hours for most workload identity use cases), automatically rotated by the identity infrastructure before expiry, cryptographically bound to the issuing context (so it cannot be meaningfully reused by a different workload), and carries a chain of trust back to the PKIaaS root CA that any relying party can verify. A rotated credential does not require coordination across dependent services because the new certificate has the same identity binding as the old one and is verified by the same CA trust root.

SPIFFE and SPIRE: The Open Standard for Workload Identity

SPIFFE (Secure Production Identity Framework for Everyone) is an open standard for workload identity maintained by the Cloud Native Computing Foundation (CNCF). It defines two things: the SPIFFE ID (a URI-format workload identity in the form spiffe://trust-domain/workload-path) and the SVID (SPIFFE Verifiable Identity Document, an X.509 certificate encoding the SPIFFE ID in the Subject Alternative Name URI field).

SPIRE (the SPIFFE Runtime Environment) is the reference implementation of SPIFFE. In a Kubernetes environment, SPIRE consists of a server (control plane component) and agents (DaemonSet pods running on each node). The SPIRE agent attests each workload based on its execution context (Kubernetes namespace, service account, pod labels, node identity) and delivers an SVID to the workload through the SPIFFE Workload API (a Unix domain socket mounted into the pod). Applications that implement the SPIFFE Workload API receive their identity certificate automatically without any application-level certificate management code.

By default, SPIRE uses a self-signed root CA internal to the SPIRE server. This means SVIDs are verifiable only within the SPIRE trust domain and are invisible to the organization’s enterprise PKI. Connecting SPIRE to PKIaaS as the upstream CA changes this: the SPIRE server requests an intermediate CA certificate from the PKIaaS issuing CA, uses it to sign SVIDs, and all SVIDs become verifiable against the organization’s PKIaaS root. The PKIaaS audit log records the intermediate CA issuance; the CLM layer can inventory SPIFFE-issued certificates alongside other enterprise certificates. For more on the SPIRE-PKIaaS integration patterns, see our PKIaaS Architecture Guide for Kubernetes.

Service and Microservice Identity

In a microservices architecture, dozens to hundreds of services make API calls to each other. Without workload identity, these service-to-service calls are authenticated with shared secrets, service account tokens, or network-location trust (the assumption that if a request comes from the right IP range, it must be from the right service). All three of these approaches fail under adversarial conditions: secrets are stolen, tokens are copied, network location is spoofed.

Mutual TLS (mTLS) with PKIaaS-issued service identity certificates replaces all three approaches with cryptographic verification. Each service has a certificate with its service identity in the Subject Alternative Name (either a DNS SAN for service mesh deployments or a SPIFFE ID URI SAN for SPIFFE-compliant environments). When Service A calls Service B, both services verify each other’s certificates against the PKIaaS root CA before the connection proceeds. Neither service trusts the other based on network location; both require cryptographic proof of identity on every connection.

The service identity certificate is issued to the service’s deployment, not to an individual instance. When a service scales horizontally (adding more pods or instances), each new instance receives the same service certificate (from the deployment’s cert-manager Certificate resource or SPIFFE registration entry) without any manual provisioning. When a service is decommissioned, its certificate expires naturally within the short validity window and the certificate registration entry is removed from the SPIRE server or the cert-manager Certificate resource is deleted. The service identity lifecycle is managed by the infrastructure, not by humans.

For service mesh deployments (Istio, Linkerd), mTLS between all services in the mesh is enforced automatically by sidecar proxies, with each proxy holding a short-lived service identity certificate (typically 24-hour validity) issued by the mesh intermediate CA backed by PKIaaS. No application code change is required to enable mTLS in a service mesh; the proxy handles the certificate presentation and verification transparently.

API Identity: Replacing API Keys with Client Certificates

API keys are the dominant mechanism for authenticating workloads to APIs because they are simple: generate a string, put it in the header, done. They are also the dominant source of workload credential leaks for the same reason: the simplicity that makes them easy to use makes them easy to misuse.

TLS client certificate authentication for APIs replaces API keys with certificate-based identity. The API gateway or service endpoint requires the calling workload to present a TLS client certificate as part of the connection. The certificate identifies the calling workload (its service name, team, or deployment environment in the Subject or SAN), is signed by the PKIaaS CA (so the API can verify it against the CA trust root without maintaining a list of valid API keys), and is short-lived (so a leaked certificate is useless before the next rotation).

Client certificate authentication for APIs is supported natively by all major API gateways (AWS API Gateway with mutual TLS, Azure API Management with client certificate policies, Kong Gateway, Nginx, Envoy) and requires no changes to the API’s business logic. The gateway handles certificate verification; the API receives the verified client identity in a request header or context variable. Authorization decisions (which services are allowed to call which API endpoints) are made based on the verified certificate identity rather than the presence of a valid API key string.

For organizations migrating from API key authentication to client certificate authentication, the transition can be staged: new integrations use client certificates from the start; existing integrations migrate on a schedule, with API keys deprecated per integration as they are replaced. The PKIaaS CA issues client certificates to authorized service identities through the ACME endpoint or REST API, and the CLM layer tracks which integrations have migrated and which are still using API keys.

Container Identity: Short-Lived Certificates for Ephemeral Workloads

Containers are ephemeral by design: a pod may live for seconds to hours before being replaced. Static credentials injected into container environment variables at deployment create a specific problem: the credential outlives the container. A container that ran for 4 hours and was replaced leaves behind an API key that remains valid for the next 2 years unless someone explicitly revokes it. Multiply this by hundreds of containers cycling daily and the credential sprawl becomes unmanageable.

Short-lived certificates issued to containers through cert-manager or SPIFFE/SPIRE match the credential lifecycle to the container lifecycle. A container receives a 4-hour certificate when it starts; the certificate expires around the time the container is likely to be replaced anyway. If the container is long-running, cert-manager or the SPIRE agent rotates the certificate before expiry automatically. When the container is terminated, the certificate expires within its short validity window and the private key is gone with the container’s ephemeral filesystem. There is nothing to revoke and nothing to rotate manually.

For Kubernetes deployments, cert-manager Certificate resources automatically provision and rotate TLS credentials for containers, storing them as Kubernetes Secrets that containers mount as volumes or environment variables. The private key is generated by cert-manager on behalf of the container, the CSR is submitted to the PKIaaS ACME endpoint, and the signed certificate is delivered to the container through the standard Kubernetes secret mechanism. The container never stores a long-lived static credential; its identity credential is managed entirely by the Kubernetes control plane and the PKIaaS CA.

CI/CD Pipeline Job Identity

CI/CD pipeline jobs are one of the highest-risk workload identity gaps in most organizations. A build job needs to authenticate to source code repositories, container registries, deployment infrastructure (Kubernetes clusters, cloud provider APIs), secrets managers, code signing services, and test environments. The typical approach is a service account with a static token or API key provisioned once and used by every subsequent pipeline run.

OIDC-Based Pipeline Identity

Modern CI/CD platforms (GitHub Actions, GitLab CI, CircleCI) support OIDC (OpenID Connect) token issuance for pipeline jobs. Each job receives a short-lived OIDC token signed by the CI platform’s OIDC provider that asserts the job’s identity (repository, branch, workflow, environment). This OIDC token can be exchanged for a PKIaaS ACME External Account Binding credential, enabling the pipeline job to request a short-lived client certificate from the PKIaaS ACME endpoint. The certificate is valid only for the duration of the pipeline run (typically 1 to 4 hours) and is destroyed when the job completes.

The result is a pipeline identity model where each job has a certificate that proves which repository and workflow it belongs to, which can be used to authenticate to deployment targets (Kubernetes API server client certificate auth, cloud provider APIs configured to accept PKIaaS-issued client certs), and which is automatically invalidated when the job ends. No static service account token is involved. No credential is shared across pipeline runs. An attacker who obtains the job’s certificate during the run finds it expired before they can use it in a separate context.

Code Signing in CI/CD Pipelines

CI/CD pipelines that produce software artifacts (container images, binaries, packages, scripts) should sign each artifact with a code signing certificate issued by the organization’s PKIaaS CA. The signed artifact carries a cryptographic attestation that it was produced by a specific, verified build pipeline rather than by an unknown or compromised process.

For pipeline code signing, the signing certificate is issued at pipeline start through the PKIaaS API (authenticated using the OIDC token from the CI platform), used to sign the artifact during the build, and expired at pipeline end. The private key exists only within the pipeline job’s execution context and is never stored in the pipeline secrets store. Deployment systems that verify artifact signatures (Kubernetes admission webhooks with image signature verification, OS-level application control policies) verify the signature against the PKIaaS CA trust root, confirming the artifact’s provenance without maintaining a list of valid signing keys.

AI Agent Identity: The Newest Workload Identity Challenge

AI agents are software processes that act autonomously: they receive a goal, execute a sequence of tool calls (API requests, database queries, code execution, file operations), and produce an output without human intervention at each step. From a security perspective, an AI agent is a workload, and workloads need identity.

The challenge is that AI agents are being deployed at a pace that outstrips the identity governance that typical enterprise software goes through. An AI agent configured with broad API access and a long-lived API key for authentication is an autonomous process with persistent, verifiable access to organizational resources and no cryptographic constraint on what it can do with that access. If the agent is compromised, misconfigured, or manipulated into making unauthorized calls, the static API key provides no mechanism to distinguish legitimate agent behavior from malicious or erroneous behavior.

Certificate-based AI agent identity provides the governance layer that static secrets cannot. Each AI agent deployment receives a certificate issued by the PKIaaS CA that encodes the agent’s identity: its name, deployment environment, version, and authorized scope (expressed as SANs or custom OID extensions in the certificate). When the agent makes an API call, it presents this certificate; the API can verify the agent’s identity and check whether it is within its authorized scope based on the certificate’s content, not on the presence of a valid API key.

Short-lived agent certificates (4 to 24 hours) provide an automatic authorization boundary: an AI agent that is running in an authorized context receives its certificate; when the agent’s session ends or its authorization window expires, the certificate expires and the agent cannot make further calls without a new certificate issued to a new authorized session. This provides the security property that static API keys cannot: agent access is bounded by the certificate’s validity period, not by the persistence of the credential.

The audit trail is also materially better. Every certificate issuance to an AI agent is logged in the PKIaaS audit log with the agent’s identity, the issuing CA, the validity period, and the requester credentials used to obtain it. Every API call the agent makes with that certificate leaves a log entry that references the specific certificate serial number. Correlating the PKIaaS audit log with API gateway access logs produces a complete record of which agent made which API calls during which authorization window, without requiring the agent to log its own actions.

Machine Identity Inventory: The Operational Foundation

Workload identity governance requires knowing what machine identities exist. A 109:1 machine-to-human ratio means an organization with 5,000 employees has approximately 545,000 machine identities in its environment, most of which are not tracked in any authoritative inventory. Some are certificates issued by the PKIaaS CA and tracked in the CLM inventory. Some are certificates issued by other CAs (cloud provider CAs, third-party PKI, legacy internal CAs) that are not visible to the PKIaaS inventory. Most are non-certificate identities: API keys, service account tokens, SSH keys, OAuth client secrets, and HMAC keys that exist in configuration files, secrets managers, and pipeline variables across the environment.

A machine identity inventory for workload identity governance needs to cover all categories. For the certificate portion, a CLM platform connected to the PKIaaS CA and to other certificate sources (other CA APIs, Kubernetes Secret scans, network certificate discovery) provides the certificate inventory layer. For the non-certificate portion, secrets management platforms (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) provide API access to audit the non-certificate machine identities. Combining both provides a view of the full machine identity estate that can be analyzed for policy violations, credential age, unused identities, and migration opportunities (moving from static secrets to certificates).

The machine identity inventory has two governance functions. The first is risk visibility: which workload credentials are approaching expiry, which are long past their expected rotation schedule, which have excessive privilege scopes, and which belong to workloads that no longer exist in the current deployment. The second is migration tracking: which workloads are still using static secrets and are candidates for migration to certificate-based identity, and which have already migrated.

Encryption Consulting’s CertSecure Manager provides the certificate inventory layer with connectors for the PKIaaS CA, cloud CA services, Kubernetes Secrets, and HashiCorp Vault PKI, enabling unified certificate visibility across the machine identity estate. For the broader machine identity picture including non-certificate identities, Encryption Consulting’s CBOM Secure provides cryptographic discovery and inventory that covers certificates, keys, tokens, and cryptographic algorithm usage across the full environment.

Automation: Making Workload Identity Operational at Scale

The value of certificate-based workload identity depends entirely on the automation that issues and rotates certificates without human intervention. A workload identity program that requires a human to request, approve, and deliver a new certificate every time a container starts, a pipeline job runs, or an AI agent session begins does not scale to the machine-to-human ratios of modern environments.

The automation stack for workload identity builds in layers. At the issuance layer, PKIaaS provides the ACME endpoint (for cert-manager and direct ACME clients), the REST API (for infrastructure automation tools and CI/CD integration), and the SPIFFE upstream CA plugin (for SPIRE-based workload identity). At the delivery layer, cert-manager stores certificates as Kubernetes Secrets and rotates them before expiry; SPIRE delivers SVIDs directly to workloads through the Workload API socket; pipeline OIDC exchange delivers short-lived certs to CI/CD jobs. At the governance layer, CLM platforms provide continuous inventory, expiry monitoring, and policy enforcement across all issued certificates.

The policy enforcement layer is critical and often missing in workload identity programs built from individual tools rather than a governed framework. A service that can request any certificate for any subject from the PKIaaS ACME endpoint without constraints is not a governed workload identity program; it is automated certificate issuance with no policy enforcement. PKIaaS certificate profiles, combined with cert-manager CertificateRequestPolicy (the cert-manager policy approver), Kubernetes RBAC on CertificateRequest resources, and SPIRE registration entry constraints, provide the policy enforcement layer that restricts each workload to the identity it is authorized for.

Migrating from Static Secrets to Certificate-Based Workload Identity

The migration from static secrets to certificate-based workload identity is a multi-year program for most organizations, not a single cutover. The practical migration sequence is:

Step 1: Inventory. Run machine identity discovery to enumerate all static secrets, API keys, service account tokens, and certificates currently in use. Prioritize by credential age (oldest first), privilege level (highest-privilege first), and exposure risk (credentials stored in code repositories or broadly accessible configuration first). This inventory is the basis for the migration plan and the baseline for measuring progress.

Step 2: Deploy the identity infrastructure. Stand up the PKIaaS CA hierarchy with ACME endpoint support. Deploy cert-manager in Kubernetes clusters with the PKIaaS ClusterIssuer. Optionally deploy SPIRE with the PKIaaS upstream CA. Configure the CLM layer to inventory PKIaaS-issued certificates alongside existing credentials.

Step 3: Migrate new workloads first. Establish a policy that all new service deployments, pipeline configurations, and agent deployments use certificate-based identity from day one. This prevents the static secrets inventory from growing while the migration of existing workloads proceeds.

Step 4: Migrate existing workloads in priority order. Work through the priority list from Step 1. For each workload, configure the identity infrastructure to issue a certificate (cert-manager Certificate resource, SPIRE registration entry, or CI/CD OIDC exchange), update the workload’s authentication configuration to use the certificate, verify the workload is authenticating correctly with the certificate, then remove the static secret from the secrets manager or configuration. Track migration progress in the CLM inventory.

Step 5: Enforce and monitor. Once a workload has migrated, configure the API gateway or receiving service to reject static secret authentication from that workload. Monitor the CLM inventory for certificate expiry events, policy violations, and new workloads that registered with static secrets rather than certificates. Treat policy violations as incidents, not acceptable exceptions.

How Encryption Consulting Can Help

• PKI as a Service: Encryption Consulting’s PKIaaS offering provides the governed CA infrastructure for workload identity at scale: ACME+EAB for cert-manager and CI/CD OIDC exchange, REST API for infrastructure automation and AI agent identity provisioning, SPIFFE upstream CA plugin for SPIRE integration, and certificate profiles with policy constraints that restrict each workload to its authorized identity. Contact us at Encryption Consulting to discuss your workload identity program.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the CLM layer for workload identity governance: unified certificate inventory across PKIaaS, Kubernetes Secrets, Vault PKI, and network-discovered certificates; expiry monitoring with configurable alerting; policy enforcement with continuous compliance checking; and SIEM integration that feeds certificate lifecycle events into the security monitoring stack.
• CBOM Secure: Encryption Consulting’s CBOM Secure extends machine identity inventory beyond certificates to cover all cryptographic assets: API keys, service account tokens, SSH keys, symmetric keys, and cryptographic algorithm usage across the full environment. This provides the complete machine identity picture that workload identity governance requires, not just the certificate layer.
• PKI Services: For organizations designing a workload identity program from scratch, Encryption Consulting’s PKI Services provide architecture advisory covering SPIFFE/SPIRE integration design, cert-manager ClusterIssuer configuration, CI/CD OIDC exchange setup, AI agent identity governance model design, and machine identity inventory strategy.
• PQC Advisory Services: Workload identity certificates that are being designed today will need to migrate to ML-DSA (FIPS 204) or hybrid algorithms within the NIST IR 8547 window (RSA/ECC deprecation approximately 2030). Encryption Consulting’s PQC Advisory Services integrate PQC migration planning into workload identity architecture design so the migration path is built in, not retrofitted.

Conclusion

Workload identity is the identity problem that most organizations have not fully solved. Human identity management is mature; machine identity management is not. The 109:1 machine-to-human identity ratio means the unmanaged identity surface is orders of magnitude larger than the managed one, and it is growing with every new microservice deployment, every new CI/CD pipeline, and every new AI agent that gets configured with a static API key for convenience.

Certificate-based workload identity backed by PKIaaS addresses this structurally. Short-lived, automatically rotated certificates replace long-lived static secrets. Cryptographic verification replaces string-matching. A governed CA hierarchy with audit logging replaces the hope that nobody has copied the credential. The automation stack (cert-manager, SPIFFE/SPIRE, CI/CD OIDC exchange) handles issuance and rotation without human intervention. The CLM layer provides continuous inventory, policy enforcement, and monitoring.

The AI agent dimension adds urgency. Autonomous software processes making API calls at machine speed with static credentials that were never designed for autonomous agents is an identity risk category that is growing faster than most organizations’ identity governance programs can currently address. Certificate-based AI agent identity is technically straightforward to implement and provides the audit trail and authorization boundary that static API keys cannot.

If your organization is building a workload identity program or assessing the current machine identity landscape, reach out to Encryption Consulting. We help security architects design and implement workload identity programs that cover services, containers, CI/CD pipelines, and AI agents under a unified governed PKI framework.

This post is reviewed on a six-month cadence and when SPIFFE/SPIRE, cert-manager, or major CI/CD platforms publish significant changes to their workload identity models, or when AI agent identity standards (OIDF, CNCF) mature to the point of materially changing implementation guidance.

Frequently Asked Questions

What is workload identity and why does it matter?

Workload identity is the cryptographic identity of a non-human entity: a service, microservice, container, CI/CD job, or AI agent. Without it, workloads authenticate with static secrets (API keys, passwords, service account tokens) that are long-lived, shareable, prone to leaking, and provide no cryptographic proof of which specific workload is using them. Certificate-based workload identity replaces static secrets with short-lived, automatically rotated, cryptographically verifiable credentials.

How does PKIaaS differ from using built-in cloud provider identity for workloads?

Cloud provider workload identity mechanisms (AWS IAM roles, Azure Managed Identity, GCP Service Accounts) work well for authenticating workloads to the cloud provider’s own services, but do not provide cross-cloud or workload-to-workload authentication across environments. PKIaaS-issued workload certificates provide portable identity that works across AWS, Azure, GCP, on-premises, and Kubernetes without depending on any single cloud provider’s identity plane.

What is SPIFFE and how does it relate to PKIaaS workload identity?

SPIFFE (Secure Production Identity Framework for Everyone) is a CNCF open standard defining the SPIFFE ID (spiffe://trust-domain/path URI format) and SVID (X.509 certificate encoding workload identity). SPIRE is the reference implementation. PKIaaS connects as the SPIRE upstream CA, giving SPIFFE-based workload identity a PKIaaS-rooted chain of trust that is enterprise-governed, auditable, and visible to the CLM inventory alongside other enterprise certificates.

What is the difference between static secrets and certificate-based workload identity?

Static secrets are long-lived, shareable, carry no cryptographic proof of which workload is using them, and require coordinated rotation across dependent services. Certificate-based workload identity is short-lived (1-24 hours), cryptographically bound to the issuing context, automatically rotated, and chains to a verified CA root that any relying party can verify without contacting the issuing authority.

How are AI agents different from other workloads for identity purposes?

AI agents are autonomous: they make API calls and access resources without human instruction at each step. A compromised or misconfigured AI agent identity can cause damage faster and at greater scale than a human using a stolen credential. Short-lived agent certificates (4-24 hours) bound to the agent’s authorized scope provide a cryptographic authorization boundary that static API keys cannot, and produce an auditable trail that correlates every API call to the specific certificate-identified agent session.

What is machine identity inventory and why is it needed?

Machine identity inventory is a continuously updated catalog of every non-human identity (certificate, API key, service account, SSH key, token) in the environment. With a 109:1 machine-to-human identity ratio (Palo Alto Networks, May 2026), organizations have approximately 109 machine identities for every human user. Without inventory, security teams cannot identify expired credentials, policy violations, or orphaned identities belonging to decommissioned workloads. PKIaaS audit logs and CLM inventory provide the foundation; CBOM Secure extends it to non-certificate machine identities.