How It Usually Happens

A certificate was created 12 months ago. Nobody set a calendar reminder, and the developer who created it has moved to another team. It expires at midnight UTC. By morning, customers can’t connect to your API, and the on-call engineer is looking at TLS errors with no idea which certificate caused them.

It happens to Microsoft too. An expired certificate took Azure Storage offline worldwide in February 2013, and another took down Microsoft Teams in February 2020. In Keyfactor’s 2025 survey of 450 PKI practitioners, 86% said an expired or mismanaged certificate had caused an outage in the past year.

What Breaks When a Certificate Expires

The blast radius depends on what the certificate was doing.

TLS/SSL certificates on App Services or Application Gateway:

  • Browsers show a full-page security warning. Users can’t proceed without clicking through scary warnings (if they even can).
  • API clients get hard TLS failures. No workaround, no retry.
  • Mobile apps that pin certificates stop working entirely.
  • If the certificate terminates at a load balancer or Application Gateway, every backend behind it goes dark.

App Registration client certificates:

  • The application can’t acquire OAuth tokens.
  • Every downstream API call that depends on those tokens starts failing with 401 Unauthorized.
  • If the App Registration is used by multiple services (common in microservice architectures), the failure cascades across services.

Key Vault certificates used for code signing or encryption:

  • Signing operations fail.
  • Encrypted data can still be decrypted (the key material remains), but new encryption operations using the certificate’s public key may be rejected by consuming applications that validate expiry.

Azure API Management certificates:

  • Backend authentication fails.
  • Client certificate validation fails.
  • Mutual TLS (mTLS) endpoints become unreachable.

What an Expired Certificate Costs

The bill is bigger than the downtime alone.

Direct costs

Downtime duration. Generating a new certificate takes five minutes. Resolving the incident takes hours, because someone has to:

  1. Get paged and acknowledge the alert
  2. Figure out which certificate expired (if monitoring doesn’t tell you)
  3. Trace which applications are affected
  4. Determine who has permission to issue a new certificate
  5. Generate and deploy the replacement
  6. Verify that all consumers have picked up the new certificate
  7. Confirm the incident is resolved

As an illustration, take a checkout API that handles £50,000 of orders a day. Four hours down puts roughly £8,000 of orders at risk, before you count refunds, support time and the customers who don’t come back.

Indirect costs

Customer trust. A TLS error is one of the most visible types of failure. Customers see it before your monitoring does. If they screenshot it and post it on social media, the brand impact is disproportionate to the technical severity.

Engineering time. The on-call engineer dropping everything to firefight a preventable incident. The incident review meeting. The action items. The toil of manually auditing certificates after the fact to find the next one before it expires.

SLA penalties. If you have contractual SLAs (99.9% uptime = maximum 43 minutes of downtime per month), a single certificate expiry incident can blow your monthly budget in one shot.

Compliance findings. Auditors check certificate management practices. An expired-certificate incident creates audit evidence that your controls aren’t working.

Why It Keeps Happening

Certificate expiry isn’t a new problem. So why does it keep catching teams?

Long lifetimes create false safety. A certificate with a 12-month validity feels like a problem for “future you.” By the time it matters, the context is gone.

No single owner. The person who created the certificate may not be the person responsible for renewing it. In many organisations, nobody is explicitly responsible for certificate lifecycle. It’s an implicit expectation that falls through the cracks.

Fragmented tooling. Certificates live in Key Vault, on App Services, in Entra ID App Registrations, in Application Gateway configs, and in API Management. There’s no single place that shows you every certificate and its expiry date across all these locations.

Alert fatigue. Even when alerts exist, they often fire too late (30 days before expiry) or get lost in a noisy monitoring channel. By the time someone pays attention, the window for a calm, planned renewal has closed.

Prevention Strategies

Short-lived certificates

Short lifetimes force you to automate renewal, and a broken renewal process shows up within weeks instead of a year later. Public TLS certificates are going this way regardless: SC-081 cut the maximum lifetime to 200 days in March 2026 and reaches 47 days in 2029. Consider:

  • 90-day certificates for TLS (Let’s Encrypt’s default). This forces you to automate renewal.
  • 180-day certificates for App Registration credentials, which is Microsoft’s recommended maximum.
  • Managed certificates wherever possible (App Service managed certificates auto-renew).

Automated renewal

Azure Key Vault supports auto-renewal for certificates issued by integrated CAs (DigiCert, GlobalSign). For certificates issued by other CAs, use the CertificateNearExpiry Event Grid event to trigger a renewal pipeline.

# Check if a Key Vault certificate has auto-renewal configured
az keyvault certificate show \
  --vault-name my-vault \
  --name my-cert \
  --query "policy.lifetimeActions"

Centralised inventory

You can’t renew what you don’t know about. Build (or use) a system that maintains a live inventory of every certificate across:

  • All Key Vaults in all subscriptions
  • All App Registration credentials in Entra ID
  • All App Service TLS bindings
  • All Application Gateway listeners

Layered alerting

Don’t rely on a single alert. Set up notifications at:

  • 90 days: Informational. Gives the owning team time to plan.
  • 30 days: Warning. Should trigger a renewal task.
  • 7 days: Critical. Escalate if renewal hasn’t happened.
  • Expired: Incident. Page the on-call.

The Difference Between Knowing and Doing

Most teams know they should manage certificates proactively. The gap is between knowing and having the tooling to actually do it across a real environment with dozens of vaults, hundreds of App Registrations, and multiple subscriptions.

CertifyClouds closes that gap. It discovers the certificates across your Azure estate, including the ones your App Services, Application Gateways, API Management, Container Apps and Front Door serve on their custom domains, even if they were never stored in Key Vault. It gives you a single dashboard with expiry timelines, sends configurable alerts at the thresholds that matter to your team, and rotates App Registration secrets and certificates in Pro and Enterprise. Try it free with a 30-day Pro trial.

Further Reading