By Yair Knijn · October 28, 2025

The certificate sat in Key Vault and quietly expired. Nobody had wired the alert.

The cloud platform lead stood up Key Vault, set RBAC tight, imported the wildcard, and ticked "certificates" off the platform checklist. The mental model was simple: it lives in the vault, the vault is managed, so the certificate is managed. Eleven months later the Application Gateway started serving an expired cert, and the on-call heard about it from a customer instead of from an alert.

That gap is the whole post. A vault gives you custody and access control. What it does not give you, on its own, is a renewal path, a near-expiry signal that reaches a human, or any guarantee that whatever consumes the cert picks up the new one. Storage is not lifecycle.

What Key Vault does, and what it pointedly will not do, for renewal

Key Vault stores the cert and serves it over the data plane. Whether it renews depends entirely on how the certificate object was created. A cert imported as a PFX, or one created with a self-signed or unknown issuer, has no renewal engine behind it. The vault holds it, versions it, and serves it right up to the notAfter date, then keeps serving the expired one. Nothing re-issues it. The "managed" feeling is real for the secret material and absent for the lifecycle.

Auto-rotation limits and the integrated-CA caveat

Auto-renewal only kicks in when the certificate's issuance policy names an integrated CA. In practice that means DigiCert or GlobalSign wired in as an issuer; the vault then re-issues against that account ahead of expiry on the policy's schedule. Two failure modes bite here. Any cert outside that integration, whether imported, self-signed, or from a CA you never wired up, is yours to rotate by hand. And even with integration, renewal breaks quietly if the issuer credential goes stale. Microsoft's own docs are blunt: if your DigiCert API key or GlobalSign account password expires, renewals fail until you update the issuer credentials. So you can have auto-rotation configured, a valid policy, and still walk into an outage because a credential one layer down lapsed and nothing alerted on the failure.

Wiring near-expiry events to people and to automation

Key Vault emits lifecycle events through Event Grid, including a near-expiry event and a renewal-result event, but only if you create the subscription. Out of the box that signal goes nowhere. Wire it deliberately:

• Subscribe to Microsoft.KeyVault.CertificateNearExpiry and route it somewhere a human actually reads, not a dashboard nobody opens.
• Subscribe to the renewal-result event and alert specifically on the failure outcome, because a failed auto-renewal is the case that ends in an outage.
• Set the policy's notification window wide enough to act on, in weeks not days, so a stuck renewal still leaves runway.
• Back the events with an independent scan of notAfter across the vault, so a missing or misrouted subscription can't hide an expiring cert.

Closing the loop: who consumes the cert, and do they pick up the new one

This is the part platform leads forget. When Key Vault renews a cert it produces a new version; it does not push that version anywhere. App Service references refresh on their own cadence. Application Gateway and Front Door each have their own sync timing. A VM or container that pulled the PFX at boot holds the old bytes until something restarts it. The renewal can succeed in the vault while the edge keeps serving the expired cert for hours. Map every consumer of every cert, confirm how each one re-reads, and alert on the served-cert expiry at the endpoint, not only on the vault object.

Automate Certificates treats the vault as one node in the chain, not the finish line. For each Environment we inventory every cert, its issuer and renewal path, the near-expiry and failed-renewal signals, and the consumers that must pick up the new version, then alert when any link goes quiet. See how the lifecycle coverage closes the loop a vault leaves open.