Certificate authorities are becoming workload identity control points

At a glance

What this is: This is a beginner’s guide to certificate authorities, with the key finding that CA trust now depends on ongoing validation, lifecycle control, and operational governance.

Why it matters: It matters because certificates increasingly protect machine identities, APIs, and connected systems, so IAM, NHI, and PAM teams need to treat CA governance as part of access control.

👉 Read DigiCert's guide to certificate authorities and certificate trust

Context

A certificate authority is the trust anchor behind certificates used by websites, applications, devices, and services. In identity terms, the real issue is not encryption alone, but whether the thing presenting a certificate can be reliably verified and continuously trusted.

That matters because certificate governance now reaches beyond web traffic into machine identity and workload identity. As certificate lifecycles shorten, organisations need to manage issuance, renewal, revocation, and inventory as an identity programme problem, not just a PKI task.

Key questions

Q: How should security teams govern certificate authorities in a machine identity programme?

A: Treat certificate authorities as part of the identity control plane, not as a one-time procurement choice. Teams should map certificates to owners, automate renewal where possible, monitor expiry and revocation, and review how trust stores could affect service continuity. That approach turns certificate governance into a managed lifecycle process rather than an occasional PKI task.

Q: Why do certificates create operational risk even when encryption is in place?

A: Encryption protects data in transit, but it does not guarantee that the endpoint is trusted, owned, or still valid. Certificates can expire, be misissued, or become distrusted by browsers and operating systems. The operational risk is not the absence of encryption. It is the failure of identity assurance and lifecycle control around the certificate.

Q: What breaks when certificate inventory is incomplete?

A: Incomplete inventory breaks ownership, renewal planning, and revocation response. Hidden certificates can expire without warning, remain deployed after service changes, or become impossible to audit during incidents. In practice, incomplete visibility turns certificate management into a discovery problem that teams only notice when users see failures or browser warnings.

Q: Who is accountable when a certificate is distrusted or revoked?

A: Accountability should sit with the service owner, the identity or PKI team, and the platform operator jointly, because trust failures cut across all three. The practical question is whether the organisation has documented ownership, renewal authority, and a tested fallback path before a trust-store change affects production.

Technical breakdown

How certificate authorities establish identity assurance

A certificate authority verifies a requester before issuing a digital certificate, then binds that identity to a public key inside a trusted certificate chain. Validation depth matters: domain validation confirms control of a domain, while organisation and extended validation add stronger identity checks. The browser or application does not trust the site because of encryption alone. It trusts the certificate because the CA has vouched for the identity or resource in a way the relying party recognises.

Practical implication: teams should align certificate validation level with the sensitivity of the service, not treat all certificates as equal.

Why certificate lifecycle management is now an identity control

Certificates have finite validity, and trust is only useful while the certificate remains current, correctly deployed, and visible to the owning team. In modern environments, certificates are attached to cloud services, APIs, software supply chains, and connected devices, which makes inventory and renewal a governance issue. Expiry, hidden certificates, and manual renewals create service disruption and weaken assurance long before an attacker is involved.

Practical implication: map certificates to owners, automate renewal where possible, and track expiry as an operational risk indicator.

Trust stores, audits, and revocation define the boundary of CA trust

A CA is not trusted forever. Browser vendors and operating systems maintain trust stores, and those trust decisions can change when a CA fails audits or experiences security problems. That means certificate trust is partly external to the enterprise. Organisations using certificates must understand that their operational continuity depends on both their own governance and the trust decisions of ecosystem providers.

Practical implication: include CA reputation, audit history, and revocation readiness in vendor and architecture review.

Threat narrative

Attacker objective: The objective is to exploit or undermine trust in certificate-based identity so that users or systems cannot safely distinguish legitimate services from unsafe ones.

1. Entry occurs when users, browsers, or services accept a certificate as proof of identity and begin trusting the connection.
2. Escalation occurs when expired, misissued, or distrusted certificates break that trust relationship and force traffic, services, or users into failure states.
3. Impact is loss of secure connectivity, service interruption, or exposure of data and transactions that should have remained protected in transit.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Certificate authorities have become workload identity control points, not just web security infrastructure. Certificates now secure services, APIs, devices, and software supply chains, which means the CA decision affects machine identity assurance as much as browser trust. That shift pushes certificate governance into the core of identity architecture rather than leaving it in infrastructure operations. The practitioner conclusion is that CA oversight belongs in identity governance, not in a separate technical silo.

Certificate lifecycle is the real governance problem, and expiry is only the visible symptom. The article’s emphasis on shortening lifecycles reflects a broader operational truth: the moment you cannot inventory, renew, and revoke at scale, trust becomes brittle. This is a classic NHI governance pattern, where unmanaged certificates behave like stranded credentials. Practitioners should treat lifecycle visibility as the control plane, not an administrative afterthought.

Trust stores externalise part of the risk boundary, which makes certificate trust a shared-control problem. Browser vendors and operating systems can distrust a CA even when an enterprise has done nothing wrong internally. That creates a governance dependency on ecosystem trust decisions, audit outcomes, and revocation readiness. The practitioner conclusion is that certificate strategy must account for third-party trust volatility, not assume perpetual validity.

CA validation levels are a practical proxy for assurance, but they are not a substitute for ownership. DV, OV, and EV differ in verification depth, yet none of them solves the harder identity question of who owns the certificate after issuance. Without explicit ownership, a valid certificate can still become an unmanaged access artifact. The practitioner conclusion is to pair issuance policy with lifecycle accountability.

Identity security teams should treat certificate trust as part of the same control family as secrets and workload identity governance. The common failure mode is fragmented ownership across PKI, platform, and application teams. Once certificates are embedded in cloud services and device fleets, the control problem becomes one of inventory, renewal, revocation, and auditability. The practitioner conclusion is to align CA governance with broader NHI and lifecycle controls.

From our research:

• 53% of organisations have experienced a security incident directly related to machine identity management failures, according to The Critical Gaps in Machine Identity Management report.
• Certificate expiry is the leading cause of outages for 45% of organisations, according to SailPoint research published in The Critical Gaps in Machine Identity Management report.
• For a broader lifecycle view, read NHI Lifecycle Management Guide for the governance controls that keep certificates visible, owned, and renewable.

What this signals

Certificate lifecycle debt: once certificates are distributed across cloud services, APIs, and connected devices, hidden ownership becomes the fastest route to outage and audit failure. The practical signal for readers is that certificate governance now needs the same inventory discipline as NHI programmes, not just periodic PKI maintenance.

With 61% of organisations still relying on spreadsheets or manual tracking for machine identity management, according to The Critical Gaps in Machine Identity Management report, certificate visibility is a structural control issue rather than an operations preference. Teams should expect renewal automation, owner mapping, and trust-store dependency checks to become baseline expectations.

The next governance step is to connect certificate assurance to broader identity architecture. If workload identity, secrets, and certificate lifecycle live in separate ownership models, trust will fail at the seams. Readers should prepare to align CA governance with Zero Trust and machine identity controls rather than treating it as a standalone PKI concern.

For practitioners

• Map every certificate to an owner and service Build a certificate inventory that ties each certificate to a business service, technical owner, and renewal path. Include hidden certificates in cloud, API, and device environments, then review ownership on a recurring schedule.
• Automate renewal before expiry becomes outage risk Prioritise automatic renewal for high-volume and customer-facing certificates, then add alerts for certificates that cannot be automated. Track renewal failures as operational incidents rather than routine admin tasks.
• Align validation level to transaction sensitivity Use stronger validation for services that handle sensitive data or high-trust interactions, and do not rely on domain validation alone for critical business-facing services. Match assurance to the identity risk of the workload.
• Review trust-store dependency in continuity planning Identify where service availability depends on public trust stores and external CA decisions, then test what happens if a certificate chain is distrusted or revoked. Add fallback paths for customer-facing services and email.

Key takeaways

• Certificate authorities are identity trust brokers, not just infrastructure utilities, because they verify and bind the identities that certificates represent.
• The scale of machine identity management failure is already material, with 53% of organisations reporting an incident tied to those failures and 45% citing certificate expiry as the main outage cause.
• Practitioners should move certificate governance into identity lifecycle management, where ownership, visibility, renewal, and revocation are controlled as a single programme.

Key terms

• Certificate authority: A certificate authority is the trusted issuer that validates an identity or domain and binds it to a digital certificate. In practice, the CA sits at the centre of certificate-based trust for websites, services, devices, and software, so its decisions affect both connectivity and identity assurance.
• Certificate lifecycle management: Certificate lifecycle management is the process of tracking, issuing, renewing, replacing, and revoking certificates across an environment. For identity teams, it is a control discipline that prevents expired, hidden, or orphaned certificates from turning into outages or trust failures.
• Trust store: A trust store is the set of certificate authorities and roots that browsers, operating systems, or applications accept as trustworthy. It defines the external boundary of certificate trust, which means enterprise assurance can be undermined when a trusted root is distrusted by the ecosystem.
• Domain validation: Domain validation is the lightest certificate verification level, confirming control of a domain rather than deeper organisational identity. It is useful for basic encryption, but it provides less assurance than OV or EV when the business needs stronger proof of who is behind the certificate.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: What's a certificate authority? A beginner's guide to CAs. Read the original.