Microsoft Entra Certificate Migration: Move App Registrations Before Expiry

Why Certificates Expire Silently — and the Damage They Cause

Certificate expiry in Azure app registrations is one of the most predictable yet consistently mismanaged failure modes in Microsoft 365 enterprise environments. Unlike a service going down with an error page, an expired certificate produces a generic "401 Unauthorized" or "AADSTS700027: Client assertion contains an invalid signature" error that is often misattributed to a permission change or an Entra policy update. Teams spend hours diagnosing the wrong cause while the production SharePoint integration or SPFx solution sits broken.

The fundamental reason certificates expire silently is that there is no native outage alert in Microsoft Entra ID when a certificate used by a production application passes its expiry date. The application simply fails to authenticate at the next token acquisition attempt, and that failure propagates downstream — a SharePoint site search stops working, a scheduled Power Automate flow starts failing, an SPFx web part shows a spinner that never resolves. Until someone opens a support ticket or notices the failure, the root cause remains invisible.

In our practice, we have seen this happen to SPFx solutions using app-only authentication (the PnP.Auth pattern), to Azure Logic Apps calling SharePoint via a registered application, and to custom web applications using MSAL with a certificate credential. The common thread: the certificate was created during initial deployment, set for a one or two year expiry, and never added to a renewal calendar. This article gives you the full lifecycle management framework to ensure that never happens in your tenant again.

Finding Expiring Certificates Across Your Tenant

The first step in certificate lifecycle management is a complete inventory of all certificates currently uploaded to app registrations in your tenant. The Microsoft Graph API exposes this data through the keyCredentials collection on each application object. Each credential record includes the endDateTime property, the displayName, and the keyId — enough information to build a prioritised renewal list.

Run the following script monthly as part of your governance routine. It queries all app registrations, filters for certificates expiring within 90 days, and exports a prioritised CSV sorted by days-to-expiry. The 90-day window gives you enough lead time to complete the renewal process — which, depending on your organisation's change management process, can take 2–4 weeks from certificate generation to production deployment.

Connect-MgGraph -Scopes "Application.Read.All"

$cutoff = (Get-Date).AddDays(90)
$apps   = Get-MgApplication -All -Property "DisplayName,AppId,KeyCredentials"
$report = [System.Collections.Generic.List[PSObject]]::new()

foreach ($app in $apps) {
    foreach ($key in $app.KeyCredentials) {
        if ($key.EndDateTime -lt $cutoff -and $key.EndDateTime -gt (Get-Date)) {
            $daysLeft = [math]::Round(($key.EndDateTime - (Get-Date)).TotalDays)
            $report.Add([PSCustomObject]@{
                AppName    = $app.DisplayName
                AppId      = $app.AppId
                CertName   = $key.DisplayName
                ExpiresOn  = $key.EndDateTime.ToString('yyyy-MM-dd')
                DaysLeft   = $daysLeft
                KeyId      = $key.KeyId
            })
        }
    }
}

$report | Sort-Object DaysLeft |
    Export-Csv "./expiring-certs.csv" -NoTypeInformation
Write-Host "$($report.Count) certificates expiring within 90 days"

PowerShell Certificate Renewal Automation

Once you have the expiring certificate list, the renewal process involves three steps: generate a new certificate, upload it to the app registration, and update any consuming applications with the new certificate. The upload step is the safest: Microsoft Entra supports multiple active certificates on a single app registration simultaneously. This means you can upload the new certificate before the old one expires, test authentication with the new certificate, and only then remove the old one — a true zero-downtime migration.

Generate a new self-signed certificate using PowerShell's New-SelfSignedCertificate cmdlet for internal apps, or request a certificate from your organisation's internal CA for production workloads. For SPFx solutions using PnP.Auth, the certificate must be exported to a PFX file (with private key) for the solution's app settings, and to a CER file (public key only) for upload to the Entra app registration.

# Step 1: Generate new certificate (valid 2 years)
$cert = New-SelfSignedCertificate `
    -Subject "CN=MyApp-Production-2026" `
    -CertStoreLocation "Cert:\CurrentUser\My" `
    -KeyExportPolicy Exportable `
    -KeySpec Signature `
    -KeyLength 2048 `
    -HashAlgorithm SHA256 `
    -NotAfter (Get-Date).AddYears(2)

# Step 2: Export public key (CER) for Entra upload
Export-Certificate -Cert $cert `
    -FilePath "./MyApp-Production-2026.cer" | Out-Null

# Step 3: Export private key (PFX) for application use
$pwd = ConvertTo-SecureString -String "StrongPw@2026!" -Force -AsPlainText
Export-PfxCertificate -Cert $cert `
    -FilePath "./MyApp-Production-2026.pfx" `
    -Password $pwd | Out-Null

# Step 4: Upload public key to Entra app registration
Connect-MgGraph -Scopes "Application.ReadWrite.All"
$appId   = "<your-application-object-id>"
$cerPath = "./MyApp-Production-2026.cer"
$cerBytes = [System.IO.File]::ReadAllBytes($cerPath)
$x509 = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($cerBytes)

$keyCredential = @{
    Type        = "AsymmetricX509Cert"
    Usage       = "Verify"
    DisplayName = "MyApp-Production-2026"
    Key         = $cerBytes
    StartDateTime = $x509.NotBefore.ToUniversalTime().ToString("o")
    EndDateTime   = $x509.NotAfter.ToUniversalTime().ToString("o")
}

Update-MgApplication -ApplicationId $appId `
    -KeyCredentials @($keyCredential)
Write-Host "New certificate uploaded successfully"

Azure Key Vault Certificate Rotation

For organisations managing more than a handful of app registrations, manual certificate renewal quickly becomes unsustainable. Azure Key Vault with automatic certificate rotation is the enterprise-grade solution. Key Vault can generate, store, and auto-rotate certificates according to a lifecycle policy you define — for example, auto-renew 30 days before expiry. Your application fetches the current certificate from Key Vault at startup rather than reading it from a file system or configuration value, which means certificate rotation becomes transparent to the application.

The integration pattern for Entra app registrations with Key Vault involves a Key Vault-generated certificate whose public key is synchronised to the Entra app registration via an Azure Function or a Logic App triggered by the Key Vault "CertificateNearExpiry" event. The flow is: Key Vault auto-renews the certificate, emits an event, the Function is triggered, reads the new public certificate from Key Vault, and uploads it to the Entra app registration using the Graph API. The private key never leaves Key Vault.

# Create certificate with auto-rotation 30 days before expiry
az keyvault certificate create \
  --vault-name "myorg-keyvault" \
  --name "MyApp-Cert" \
  --policy '{"issuerParameters":{"name":"Self"},"keyProperties":{"exportable":true,"keySize":2048,"keyType":"RSA"},"lifetimeActions":[{"action":{"actionType":"AutoRenew"},"trigger":{"daysBeforeExpiry":30}}],"secretProperties":{"contentType":"application/x-pkcs12"},"x509CertificateProperties":{"subject":"CN=MyApp-Production","validityInMonths":24}}'

# Grant the Azure Function managed identity access to read certs
az keyvault set-policy \
  --name "myorg-keyvault" \
  --object-id "<function-managed-identity-object-id>" \
  --certificate-permissions get list \
  --secret-permissions get

Configuring Entra Certificate Expiry Alerts

Until your Key Vault rotation pipeline is fully operational, configure manual expiry alerts using two complementary mechanisms. The first is the Microsoft Entra Recommendations feature, available under Entra admin center > Overview > Recommendations. The "Renew expiring application credentials" recommendation surfaces app registrations with credentials expiring within 30 days. This is useful for spot-checking but is not a reliable alerting mechanism because it requires manual navigation.

The second and more reliable mechanism is an Azure Monitor alert rule based on the Entra sign-in log. Create a Log Analytics workspace connected to your Entra diagnostic settings, ingest the "ServicePrincipalSignInLogs" table, and create an alert rule that fires when sign-in failures matching error code "700027" or "700016" appear more than N times in a one-hour window. Route the alert to a Teams channel via an Action Group. This alert fires when certificate authentication actually fails — which is your last-resort backstop if the proactive renewal script missed an expiring certificate.

ServicePrincipalSignInLogs
| where TimeGenerated > ago(1h)
| where ResultType in ("700027", "700016", "AADSTS700027")
| summarize
    FailureCount = count(),
    AppIds = make_set(AppId),
    ErrorMessages = make_set(ResultDescription)
    by bin(TimeGenerated, 5m)
| where FailureCount > 3
| project TimeGenerated, FailureCount, AppIds, ErrorMessages

Zero-Downtime Certificate Swap for Production Apps

The zero-downtime swap relies on Entra's support for multiple simultaneous active credentials on a single app registration. The process has five steps, none of which require a maintenance window or application restart if implemented correctly.

Step 1 — Upload new certificate: Use the Graph API or the Entra admin UI to add the new certificate to the app registration's keyCredentials collection while keeping the existing certificate. Both certificates are now valid for authentication. Verify the upload by checking the app registration's "Certificates & secrets" blade.

Step 2 — Update consuming applications in staging: Update the application configuration (app settings, Key Vault reference, or configuration file) to reference the new certificate's thumbprint. Deploy to staging and verify that the application authenticates successfully using the new certificate. Check the Entra sign-in logs for the service principal to confirm successful authentication attempts with the new credential.

Step 3 — Production deployment: Deploy the updated configuration to production. At this point both the old and new certificates are active in Entra — the application now uses the new one, but the old certificate is still trusted and any cached tokens issued using it remain valid until they expire naturally.

Step 4 — Monitor for 48 hours: Watch the Entra sign-in logs and application-level error rates for 48 hours. This window covers any edge cases — long-lived cached tokens, scheduled jobs that run infrequently, secondary applications that also use the same app registration.

Step 5 — Remove old certificate: After the monitoring window, use the Graph API to remove the old certificate's keyCredential entry from the app registration. The app registration now carries only the new certificate, completing the zero-downtime migration.

Certificate Expiry Impact on SPFx Solutions

SPFx solutions using app-only authentication (PnP.Auth or a custom MSAL configuration) are among the most vulnerable to certificate expiry because they often run as background jobs or scheduled flows where failures are not immediately visible to end users. A SharePoint Framework web part that authenticates on behalf of the signed-in user via delegated permissions is not affected by app registration certificate expiry — only app-only (daemon) authentication patterns are impacted.

The most common SPFx pattern vulnerable to this issue is an Azure Function (or Azure Automation runbook) that connects to SharePoint Online using a registered app's certificate to perform background operations — content indexing, user profile updates, list synchronisation. When the certificate expires, the Function silently fails, and the SharePoint data it was supposed to update stops being refreshed. Adding Application Insights telemetry to these functions with a specific event for authentication failures turns the silent breakage into an observable alert.

Certificate Governance Checklist

Embed certificate governance into your existing Microsoft 365 change management process using this checklist. Apply it at application creation, at the 90-day mark before each expiry, and at quarterly governance reviews.

• At creation: Register the certificate expiry date in a SharePoint governance list with the application name, app ID, owner email, and environment (dev/staging/prod). Set a Power Automate reminder flow to notify the owner at 90, 60, and 30 days before expiry.
• At 90 days: Generate the replacement certificate. Upload it to the Entra app registration. Store the new PFX in Azure Key Vault with appropriate access policies.
• At 60 days: Deploy the updated certificate reference to staging. Run integration tests. Verify Entra sign-in logs show successful authentication with the new certificate thumbprint.
• At 30 days: Deploy to production. Run the 48-hour monitoring window. Remove the old certificate from Entra. Update the governance SharePoint list with the new expiry date.
• Quarterly: Run the full tenant certificate inventory script. Reconcile against the governance SharePoint list. Identify any certificates not in the list (shadow IT) and add them or remove them if no longer needed.