TL;DR: Manual certificate renewal inside Azure Key Vault breaks down as certificate lifespans shrink toward 47 days, according to AppViewX, because native tooling lacks the discovery, multi-CA support, and policy orchestration enterprise estates need. Certificate governance now depends on lifecycle automation, not storage alone.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on AppViewX's blog post: Azure Key Vault cannot handle enterprise certificate lifecycle demands on its own as certificate validity shortens and estates span multiple clouds.
Why it matters: IAM, PKI, and platform teams need to govern certificates as a lifecycle problem across discovery, issuance, renewal, and policy, not as a vault-only storage problem.
By the numbers:
- Automation can reduce certificate management time by 73-82% according to AppViewX.
- Certificate lifespans are moving from 200 days to 47 days by March 2029 according to AppViewX.
Context
Certificate management fails when visibility stops at the vault. In an enterprise estate, certificates sit across app gateways, Kubernetes clusters, load balancers, edge services, and hybrid endpoints, so a vault-centric view leaves blind spots in issuance, renewal, ownership, and expiry control.
The governance problem is not storage but orchestration. A certificate may be protected in one system and still be unmanaged in another, which is why static and dynamic secrets thinking matters here: the control question is how lifecycle state is tracked, not where the object is parked.
Key questions
Q: How do I manage Azure Key Vault certificates at enterprise scale?
A: Manage Azure Key Vault certificates at enterprise scale by centralising issuance, storage, rotation and revocation in a certificate lifecycle platform, with role-based access control, managed identities for application access, and policy enforcement for expiry, key usage and approval workflows. Use separate vaults or subscriptions by environment, enable logging for certificate operations, and track ownership, renewal, and dependency mapping for every certificate.
Q: Why do short-lived certificates increase governance risk?
A: Short-lived certificates increase governance risk because they compress the time available for manual review, approval, and replacement. If renewal processes depend on people, the chance of delay, outage, or inconsistent trust state rises quickly. Short lifetimes only improve security when ownership and automation are already mature.
Q: What is the difference between certificate management and certificate lifecycle management?
A: Certificate management is often treated as tracking issuance and expiry, while certificate lifecycle management includes ownership, policy, renewal, revocation, and offboarding. That broader lifecycle view is the only one that scales when certificates behave like machine identities. Practitioners should govern the full lifecycle, not just the expiry date.
Q: How should teams govern certificate lifecycle management in multi-cloud environments?
A: Teams should govern CLM as part of the broader machine identity stack, not as a standalone certificate tool. That means tying issuance, renewal, revocation, and discovery to secrets management, key protection, and audit evidence so identity state remains consistent across cloud platforms and workloads.
Technical breakdown
Why vault-native renewal stops at enterprise scale
Azure Key Vault can store certificates and automate some renewals, but its native model is bounded by its own scope and CA partnerships. That works for smaller estates or tightly Azure-centric deployments, yet it leaves gaps when certificates are issued by multiple public and private CAs or consumed outside Key Vault by adjacent services. The technical problem is fragmented lifecycle authority: issuance, renewal, deployment, and validation are not governed as one closed loop. Once certificate state is distributed across services, storage alone cannot prevent expiry or inconsistent renewal behaviour. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Practical implication: Treat Key Vault as one component in a broader certificate lifecycle model, not as the system of record for every certificate decision.
How CA-agnostic certificate automation works
CA-agnostic automation means the lifecycle platform speaks to multiple certificate authorities and multiple enrollment protocols without forcing a single vendor path. In practice, that includes automated CSR generation, CA submission, issuance retrieval, deployment to endpoints, and post-deployment validation through protocols such as ACME, EST, SCEP, CMP, and native Windows auto-enrollment. The important architectural shift is that renewal becomes policy-driven orchestration rather than a per-CA manual workflow. That matters when the certificate estate spans public and private trust anchors and the enterprise cannot accept renewal logic that changes by issuer. See the ACME and Automated Certificate Management Guide.
Practical implication: Standardise renewal workflows on protocol support and CA neutrality before certificate volume or expiry windows compress further.
Why certificate governance needs policy enforcement, not just automation
Automation without governance can accelerate the wrong outcome just as efficiently as the right one. Certificate policy needs to define approved CAs, key sizes, algorithms, ownership, and approval boundaries so that self-service does not become uncontrolled issuance. In an enterprise setting, RBAC is part of that model because different teams need different authority over request, approval, and oversight. Governance also has to produce audit-ready evidence without manual consolidation, because compliance reporting is otherwise detached from the actual certificate lifecycle. This is where lifecycle control and entitlement control meet.
Practical implication: Embed certificate policy, ownership, and audit evidence into the automation design instead of bolting them on after deployment.
Threat narrative
Attacker objective: Cause trust failure, outage, or unmanaged exposure by exploiting certificate lifecycle blind spots rather than attacking the vault itself.
- Entry occurs through undiscovered or shadow certificates that sit outside the vault-centric inventory, so expiry risk begins before any renewal workflow can see them.
- Escalation follows when manual renewal paths or CA lock-in leave certificates to age out across app services, gateways, or hybrid endpoints without a coordinated response.
- Impact is service interruption, failed trust chains, or unmanaged exposure from expired or orphaned certificates that were never governed as a complete estate.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Certificate lifecycle, not certificate storage, is the real control boundary. Azure Key Vault can hold certificates, but the operational problem is everywhere those certificates are used, renewed, and validated. Once the estate spans App Service, AKS, gateways, and hybrid endpoints, governance has to track object state across systems rather than assume a vault is sufficient. That changes certificate management from a repository question into an identity and lifecycle discipline.
Shorter certificate validity turns manual renewal into a structural failure mode. When lifespans compress toward 47 days, the issue is not workload pressure alone. It becomes a predictable governance break because renewal windows shrink below the tolerance of spreadsheet tracking, ticket handoffs, and one-off issuer processes. The result is not just more work, but more opportunities for orphaned or expired certificates to persist unnoticed.
CA lock-in creates hidden governance debt. When auto-renewal only works with select issuers, the enterprise inherits different renewal paths for different certificates, which means the same policy cannot be applied uniformly. That fragmentation makes certificate ownership harder to prove and audit harder to trust. The implication is that lifecycle governance must be designed for issuer diversity, not built around one partner pathway.
Smart discovery is the prerequisite control for certificate governance. You cannot govern what you do not inventory, and certificate estates routinely exceed the count teams expect. Discovery has to surface certificates across the whole environment, assign ownership, and map expiry timelines before any policy can be enforced consistently. Without that baseline, automation simply accelerates a partial view.
Multi-cloud certificate governance is a posture problem, not a tooling preference. Enterprises that run Azure alongside AWS, GCP, and on-premises cannot rely on cloud-local certificate tooling to give them a complete posture. The operating model has to unify issuance, renewal, policy, and reporting across environments or accept blind spots by design. That is why certificate management now belongs in broader governance planning, not only in platform administration.
From our research library:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- Read next: Secrets Management Buyer's Guide
What this signals
Certificate governance will keep moving from point-product administration to estate-level orchestration. As renewal windows shorten, teams that rely on vault-local workflows will keep finding that the control they need is visibility across the full certificate population, not another isolated management screen. The practical shift is toward a single lifecycle view that can span issuance, renewal, deployment, and audit evidence.
Visibility debt becomes the dominant risk when certificates sit outside the primary vault. AppViewX's analysis points to a pattern that many programmes already recognise: the hardest failures are the ones outside the normal admin path, where expired or orphaned certificates never enter a routine review. That means governance teams need inventory completeness as a security objective, not a reporting nice-to-have.
For practitioners
- Build a complete certificate inventory Discover certificates across Key Vault, App Service, AKS, Front Door, gateways, and hybrid endpoints before setting renewal policy. See the Secrets Management Buyer's Guide.
- Replace issuer-specific renewal workflows Abstract renewal away from partner-only paths so public and private CAs can follow the same policy-driven process.
- Define certificate ownership and approval rules Assign named owners, approved CA lists, algorithm baselines, and approval boundaries to each certificate class.
- Tie compliance evidence to lifecycle events Generate audit-ready reports from issuance, renewal, deployment, and validation events instead of manual export and reconciliation.
Key takeaways
- Azure Key Vault can store certificates, but enterprise control depends on lifecycle orchestration across every environment where those certificates are consumed.
- Shorter validity periods make manual renewal unsustainable and expose gaps in discovery, ownership, and policy enforcement.
- Practitioners should treat discovery, CA flexibility, and governance as the core design requirements for certificate automation.
Related NHI Mgmt Group resources: Ultimate Guide to NHIs: Static vs Dynamic Secrets · Secrets Management Buyer's Guide · Machine Identity, PKI and Certificate Lifecycle Guide · ACME and Automated Certificate Management Guide
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Short certificate validity and renewal pressure make long-lived certificate handling a core risk here. |
| NHI-01 — Improper Offboarding | Expired and orphaned certificates are effectively offboarded poorly from the estate, which this article highlights. | |
| Recommendation — Track certificate lifetimes against NHI-07 and remove any renewal path that depends on manual timing. Map orphaned certificates to NHI-01 and close offboarding gaps in renewal and retirement workflows. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate renewal and lifecycle handling align directly to authenticator management controls. |
| Recommendation — Apply IA-5 to enforce certificate rotation, renewal, and revocation across the estate. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Certificate governance here depends on who can request, approve, and deploy certificates. |
| Recommendation — Use PR.AA-05 to govern certificate request and approval entitlements with least privilege. | ||
| CIS Controls v8 | CIS-5 — Account Management | Certificate ownership and administrative access need lifecycle control similar to account governance. |
| Recommendation — Extend CIS-5 account governance discipline to certificate owners, approvers, and automation roles. | ||
Key terms
- Azure Key Vault: Azure Key Vault is a secret management service for storing credentials, API keys, certificates, and other sensitive material. It centralizes access to secrets and works best when paired with managed identities, so applications can retrieve what they need at runtime without hard-coding sensitive values in source files or configuration.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- ACME: ACME is a protocol used to automate certificate issuance and renewal between a client and a certificate authority. For practitioners, it reduces manual renewal work, but it also introduces a dependency on correct client configuration, credential handling, and monitoring of the automation path.
- SCEP: Simple Certificate Enrollment Protocol is a standard used to automate digital certificate enrollment for devices at scale. It relies on a certificate authority, a SCEP server, device agents, and shared secrets so devices can request, receive, and renew certificates with less manual handling.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org