CA/Browser Forum changes are reshaping certificate lifecycle management

At a glance

What this is: This is an analysis of CA/Browser Forum discussions showing that certificate lifecycle automation, validation changes, and post-quantum readiness are becoming governance requirements, not optional improvements.

Why it matters: It matters because IAM, PKI, and NHI teams will need to align certificate operations, validation workflows, and lifecycle controls before current manual processes become a compliance and resilience liability.

By the numbers:

• Only 38% have automated certificate lifecycle management in place.
• Certificate expiry is the leading cause of outages for 45% of organisations.

👉 Read DigiCert’s analysis of CA/Browser Forum changes affecting certificate automation and PKI

Context

Certificate lifecycle management is the operational discipline that keeps digital certificates issued, validated, rotated, and retired on time. In this article, the primary identity security issue is not cryptography in the abstract, but the shift from manual certificate handling toward automatable controls that can survive tighter browser policy and post-quantum change.

For IAM and NHI programmes, certificates are not peripheral artifacts. They are part of the identity plane for workloads, services, and trusted machine-to-machine communication, so changes in validation and issuance policy affect both machine identity governance and broader access assurance.

Key questions

Q: How should security teams prepare for certificate lifecycle automation becoming mandatory?

A: They should inventory every certificate workflow, remove manual renewal dependencies, and test whether issuance, rotation, and revocation can run without human handoffs. The goal is not just faster operations. It is proving that trust continuity can survive policy changes, scale growth, and short-lived certificate models without outages or exception sprawl.

Q: Why do non-automatable DCV methods create governance risk?

A: They create risk because validation depends on processes that are slow, inconsistent, and difficult to scale across modern certificate estates. When browser policies move toward automation and corroboration, legacy methods become harder to defend operationally and harder to audit. That turns issuance into a governance weakness rather than a routine administrative step.

Q: How do organisations know whether certificate readiness is actually improving?

A: They should look for fewer manual exceptions, shorter renewal lead times, clear certificate ownership, and a complete inventory of certificates that includes issuance method and expiry exposure. If teams still rely on spreadsheets, ad hoc approvals, or last-minute renewals, the programme is improving in documentation only, not in control maturity.

Q: Who is accountable when certificate failures disrupt trusted services?

A: Accountability should sit with the service or platform owner, not with a generic infrastructure team after the fact. Certificate failures affect identity assurance, uptime, and trust relationships, so ownership has to be explicit before renewal or validation breaks. That is why certificate governance belongs inside wider identity and operational risk governance.

Technical breakdown

Why certificate lifecycle automation is becoming a baseline control

Browser policy is pushing certificate issuance and renewal toward automatable workflows because manual steps do not scale across large fleets of services and short-lived certificates. When root programs require automation support, the practical change is not just faster renewal. It is a governance shift from exception handling to continuous operational control. That matters because certificate estates are increasingly tied to workload identity, mTLS, and service authentication, where even short delays can create outages or trust failures. The hard problem is no longer whether automation is convenient. It is whether the organisation can prove it can issue and renew trust at machine speed.

Practical implication: audit every certificate workflow for manual handoffs, then remove non-automatable renewal paths before policy changes force a crisis.

How DCV method changes affect public trust and validation workflows

Domain control validation, or DCV, is the process CAs use to verify that the requester controls a domain before issuing a certificate. The article points to the possible retirement of methods that rely on phone, email, fax, SMS, or postal mail because those methods are hard to automate and difficult to corroborate at scale. That change matters because validation is not just a front-end issuance step. It is part of the trust chain that determines whether a certificate should exist at all. If the control cannot be automated, it becomes increasingly incompatible with modern issuance governance and multi-perspective validation models.

Practical implication: inventory all legacy DCV methods in use and plan migration to automatable validation paths before sunset dates land.

What post-quantum readiness means for TLS and code signing

Post-quantum cryptography, or PQC, aims to protect signatures against future cryptographic attack models that could weaken today’s algorithms. The article’s reference to ML-DSA roots for TLS shows that organisations must start treating PQC as a certificate lifecycle planning issue, not a future-only research topic. TLS certificates are typically shorter-lived and operationally more flexible, while code signing keys can persist for much longer and create deeper migration risk. That difference matters because migration timing, trust store compatibility, and issuance policy all have to be coordinated across environments, not handled as a single cryptographic swap.

Practical implication: separate TLS and code-signing migration plans, then map each to a certificate inventory and trust-store change process.

Threat narrative

Attacker objective: The practical objective is to break or weaken trusted certificate-based communication by exploiting operational gaps in issuance, validation, or lifecycle management.

1. Entry begins when organisations continue relying on manual validation and renewal processes that cannot keep pace with browser policy changes or certificate volume.
2. Escalation occurs when certificate lifecycle exceptions accumulate, leaving workload and public trust controls exposed to delayed issuance, renewal failures, or inconsistent validation.
3. Impact emerges as services lose trusted identity continuity, creating outages, failed mTLS handshakes, or delayed readiness for post-quantum requirements.

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 lifecycle governance is shifting from a housekeeping function to an identity control plane. When browser policy starts requiring automation support, certificate handling stops being a back-office renewal task and becomes a live control surface for trust continuity. That affects workload identity, mTLS, and enterprise certificate operations at the same time. Practitioners should treat automation readiness as governance maturity, not an engineering convenience.

Manual validation methods are becoming a structural liability, not just an inconvenience. Phone, email, fax, SMS, and postal-mail DCV methods depend on human-paced processes that do not align with modern issuance scale or corroboration models. Once a CA ecosystem starts sunsetting those methods, the organisation’s issue is not whether a legacy process still works in principle. The issue is whether it can still function as part of a defensible trust chain.

Post-quantum migration will expose the difference between certificate inventories and certificate governance. Many organisations can list certificates but cannot consistently manage lifecycle timing, ownership, and renewal dependencies across TLS and code signing. That gap matters more as PQC planning introduces overlapping trust models and longer transition periods. The practitioner conclusion is simple: inventory alone will not carry a migration.

Standing trust assumptions collapse when certificate lifetimes, issuance policy, and validation modes all change at once. Certificate governance was designed for a world where validation paths, trust roots, and renewal patterns were relatively stable. That assumption fails when the ecosystem shifts toward mandatory automation and cryptographic transition because the trust chain itself becomes a moving target. The implication is that organisations must rethink how they define operational readiness for identity-backed infrastructure.

Machine identity governance and browser-driven certificate policy are converging. Certificates now sit inside the same control conversation as service accounts, workload identities, and secrets because they all establish non-human trust. The organisations that separate PKI from NHI governance will miss the lifecycle dependency that creates outages and exposure. Practitioners should unify certificate controls with the broader identity governance model.

From our research:

• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs , What are Non-Human Identities.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a broader governance baseline, see NIST Cybersecurity Framework 2.0 for how identify, protect, detect, respond, and recover functions support trust continuity.

What this signals

Certificate governance is converging with NHI lifecycle governance. As certificate automation becomes mandatory in more places, teams that still treat PKI as separate from workload identity will carry hidden operational risk. The organisations that feel this first will be the ones with large service estates, mixed issuance channels, and weak ownership records.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the same operational pattern shows up across identity domains: trust artifacts drift into unmanaged places, then become hard to rotate or retire. That is why lifecycle visibility matters as much for certificates as it does for API keys and tokens.

The practical signal for IAM and platform teams is that certificate policy, workload identity, and secret management now belong in one control conversation. If renewal automation, validation changes, and ownership mapping are not aligned, every browser policy shift becomes a reliability event.

For practitioners

• Map every certificate workflow end to end Document issuance, renewal, validation, revocation, and exception handling across public TLS, internal PKI, and code signing so you can see where humans still intervene.
• Eliminate non-automatable validation paths Identify domains or certificate classes that still depend on phone, email, fax, SMS, or postal mail validation and migrate them to automatable methods before policy deadlines.
• Separate TLS and code-signing readiness plans Treat short-lived TLS certificates and long-lived signing keys as different migration tracks with different trust-store, tooling, and rollback requirements.
• Tie certificate ownership to service accountability Assign a named owner to each certificate family, then make renewal, validation, and retirement part of the same operational accountability chain.

Key takeaways

• The article shows that certificate policy is moving into the same governance category as identity lifecycle management, because automation and validation rules now shape whether trust can be maintained at scale.
• The evidence points to a coming mismatch between legacy certificate operations and modern browser expectations, which will expose manual workflows, weak ownership, and poor renewal discipline.
• Practitioners should respond by unifying PKI, workload identity, and certificate lifecycle controls so policy changes do not become service outages or migration blockers.

Key terms

• Certificate Lifecycle Management: Certificate lifecycle management is the process of issuing, validating, renewing, revoking, and retiring certificates in a controlled way. In modern environments, it is a governance discipline as much as an operational one because it directly affects service continuity, trust assurance, and compliance across human and machine identity systems.
• Domain Control Validation: Domain control validation is the process a certificate authority uses to verify that a requester controls a domain before a certificate is issued. It matters because weak or manual validation methods can break at scale, resist automation, and create a gap between issuance policy and operational reality.
• Post-Quantum Cryptography: Post-quantum cryptography is a set of cryptographic methods designed to resist future attacks from quantum computers. For identity teams, the practical issue is migration timing, trust compatibility, and lifecycle planning for certificates and signing systems that may need to coexist with older algorithms for years.
• Machine Identity: A machine identity is the credentialed identity used by software, workloads, services, and devices to authenticate and communicate. Certificates are one of the most common forms of machine identity, so changes in certificate policy directly affect how non-human systems prove trust.

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: Insights from the CA/Browser Forum’s Warsaw Discussions. Read the original.