How to find expiring app secrets and certificates in Entra ID: queries, owners and safe renewal

An expired client secret or SAML signing certificate is one of the most common causes of an avoidable Entra ID outage, and the credential is usually found only after the integration has already failed. Credentials sit in three places that most reports do not join together: app registrations, service principals (enterprise applications) and SAML signing certificates. This guide gives read-only queries that find every expiring or expired credential across all three, a way to attach owners, a safe renewal sequence that avoids breaking the workload, and the policies that stop the problem recurring. It is written for Entra administrators, identity engineers and NHI programme owners who need a repeatable job, not a one-off export.

Key takeaways

• Look in three places, not one. Microsoft's sample script reads app registrations only; service principals carry their own passwordCredentials and keyCredentials, and SAML signing certificates live on the enterprise application.
• The built-in recommendation covers 30 days. "Renew expiring application credentials" (applicationCredentialExpiry, preview) flags app registration credentials expiring within 30 days; a scheduled query gives you a longer runway.
• Every finding needs an owner. Credentials on apps with no owner are both the most likely to expire unnoticed and the hardest to renew safely.
• Renew by overlap, never by replacement. Add the new credential, move the workload, confirm the new key ID in sign-in logs, then remove the old one.
• Expiry hygiene is also exposure hygiene. Long-lived secrets are what attackers steal; app management policies can cap lifetimes or block new secrets entirely.

When you need this

• Before it breaks: a monthly or weekly job that finds credentials expiring in the next 30, 60 or 90 days.
• After an outage: an integration failed with an authentication error and you need to know which other credentials are close behind.
• Audit or programme baseline: evidence of credential lifetime and ownership for the NHI inventory. See the NHI Inventory Reconciliation guide.
• Incident response: a supplier or tenant compromise means you must find and rotate every secret on a set of apps, whatever the expiry date.

Before you start

Where each credential lives determines which query finds it:

Step-by-step

Steps 1 to 5 are read-only. Step 6 changes the tenant but is additive and reversible. Step 7 is destructive.

1. Check the built-in recommendation. In the Microsoft Entra admin center go to Entra ID > Overview > Recommendations and open Renew expiring application credentials. Impacted resources lists app registrations with a credential expiring within 30 days. Through Graph the recommendation ID is applicationCredentialExpiry, on the beta recommendations API. Treat it as a cross-check, not the inventory.
2. Export app registration credentials.

   Connect-MgGraph -Scopes "Application.Read.All"
   $now = (Get-Date).ToUniversalTime()
   $days = 90
   $rows = foreach ($app in Get-MgApplication -All -Property Id,AppId,DisplayName,PasswordCredentials,KeyCredentials) {
     foreach ($c in $app.PasswordCredentials) {
       [pscustomobject]@{Object='Application'; Name=$app.DisplayName; AppId=$app.AppId; ObjectId=$app.Id;
         Type='Secret'; KeyId=$c.KeyId; Label=$c.DisplayName; End=$c.EndDateTime; DaysLeft=[math]::Floor(($c.EndDateTime - $now).TotalDays)} }
     foreach ($c in $app.KeyCredentials) {
       [pscustomobject]@{Object='Application'; Name=$app.DisplayName; AppId=$app.AppId; ObjectId=$app.Id;
         Type='Certificate'; KeyId=$c.KeyId; Label=$c.DisplayName; End=$c.EndDateTime; DaysLeft=[math]::Floor(($c.EndDateTime - $now).TotalDays)} }
   }
   $rows | Where-Object DaysLeft -le $days | Export-Csv app_creds_expiring.csv -NoTypeInformation

   Negative DaysLeft values are already expired; keep them, because an expired secret still in place is clutter that hides the live one. Using TotalDays avoids the truncation in whole-day arithmetic, where a secret expiring in 12 hours shows as 0.
3. Export service principal credentials. Repeat the loop with Get-MgServicePrincipal -All -Property Id,AppId,DisplayName,ServicePrincipalType,AppOwnerOrganizationId,PreferredSingleSignOnMode,PasswordCredentials,KeyCredentials, setting Object to ServicePrincipal. Rows where PreferredSingleSignOnMode is saml are SAML signing certificates. AppOwnerOrganizationId tells you whether the app is registered in your tenant or a third party's.
4. Attach owners. For each distinct app, call Get-MgApplicationOwner -ApplicationId $id (or Get-MgServicePrincipalOwner for enterprise apps) once per object, not once per credential. Record "no owner" explicitly: Microsoft's own sample labels these <<No Owner>>.
5. Check whether the credential is used. For apps in scope, the appCredentialSignInActivities report (beta) returns per-credential keyId, expiry and last sign-in. A credential with no sign-ins is a candidate for removal rather than renewal. The method is covered in How to find and remove stale service principals in Entra ID.
6. Renew with overlap (additive). Add a new certificate or secret to the same object: portal Certificates & secrets, or Graph addPassword. The secretText value is returned only in that response and cannot be retrieved later, so write it straight to the vault the workload reads from. For SAML apps, select New Certificate on the SAML Signing Certificate page with an expiry overlapping the current one, upload it to the service provider, then choose Make certificate active.
7. Remove the old credential (destructive). Once sign-in logs show the new keyId in use, remove the old one through Certificates & secrets or Graph removePassword. Removal is immediate: any workload still using it fails.

Prioritising what you find

Verify it worked

• Sign-in logs: Microsoft's remediation guidance is to confirm in Entra sign-in logs (service principal sign-ins) that the Key ID of the new credential matches the one you added.
• Re-run the export: the renewed app should show a new keyId with the expected end date, and the old keyId should be gone after step 7.
• Recommendation: the app should move off the Impacted resources list on the next refresh.
• SAML apps: sign in to the application after making the new certificate active, as Microsoft's rollover steps require.

Rollback and common errors

• Workload fails after removal: you cannot restore a removed secret. Add a new one, update the workload and remove nothing further until it signs in.
• Lost secret value: secretText is not retrievable after creation. Add another secret; remove the orphan.
• SAML outage after activation: make the previous certificate active again from the SAML Signing Certificate page while it is still valid. Microsoft warns that if an expired certificate and a valid inactive one both exist, Entra uses the valid one, which can cause an outage if the app does not have it yet.
• Owner query returns an application, not a user: service principals can own apps. Trace that owner's own owner before relying on it.
• Change blocked by policy: an app management policy (for example passwordAddition or passwordLifetime) rejects the new secret. Use a certificate or a shorter lifetime, or request an exemption.

Hardening afterwards

• Cap credential lifetimes: app management policies (Entra ID > Enterprise apps > Application policies, or Graph defaultAppManagementPolicy) support passwordLifetime and asymmetricKeyLifetime, and passwordAddition can block new client secrets. Start with "All applications with exclusions" and an exclusion list for apps you cannot change yet.
• Replace secrets where possible: certificates, managed identities and workload identity federation remove the static secret. See the Azure Entra Client Secrets Security Guide and the Workload Identity Federation Guide.
• Notification addresses for SAML apps: Entra emails up to five addresses 60, 30 and 7 days before a SAML certificate expires, from [email protected]. Use a monitored distribution list, not the person who set the app up.
• Schedule the export: run the query weekly from an automation identity with Application.Read.All only, and send results to owners and the ticketing system.
• Alert on new credentials: an unexpected new secret on an existing app is a persistence technique (ATT&CK T1098.001 Additional Cloud Credentials). Monitor the audit log for credential additions. See the Entra ID Sign-In and Audit Log Detection Guide.

Common failure patterns

• App registrations only: the report misses credentials added to service principals and every SAML signing certificate.
• Renewing by replacing: deleting the old secret before the workload has the new one turns a planned renewal into an outage.
• Two-year secrets as the default: long lifetimes make expiry rare and painful, and give a stolen secret a long useful life.
• Expiry-only thinking: when a supplier holding your app secrets is breached, the expiry date is irrelevant. In the Commvault Metallic breach, customers were told to rotate the Microsoft 365 app credentials Commvault used and revalidate permissions; that is only fast if the inventory already exists.
• Notifications to departed staff: SAML expiry emails go to the admin who created the app, who left last year.

Detection and measurement

• Credentials expiring in the next 30 days with no renewal ticket (target zero).
• Outages caused by expired Entra credentials per quarter.
• Percentage of apps with at least one owner who is an active user.
• Median client secret lifetime, and share of apps using secrets versus certificates or federation.
• Expired credentials still present on objects.

Framework mapping

Practitioner checklist

• Export passwordCredentials and keyCredentials from all app registrations and all service principals.
• Identify SAML signing certificates through PreferredSingleSignOnMode and include them in the same report.
• Attach an owner to every finding and record "no owner" explicitly.
• Check credential sign-in activity before renewing; remove unused credentials instead.
• Renew with overlap, confirm the new keyId in sign-in logs, then remove the old credential.
• Write new secret values straight to the consuming vault.
• Set SAML notification addresses to a monitored distribution list.
• Apply app management policies to cap secret and certificate lifetimes.
• Schedule the export weekly and alert on new credentials added to existing apps.

Standards and references

• Microsoft Learn: Export apps with expiring secrets and certificates
• Microsoft Learn: Renew expiring application credentials recommendation
• Microsoft Graph: passwordCredential resource type
• Microsoft Graph: keyCredential resource type
• Microsoft Learn: Manage certificates for federated single sign-on
• Microsoft Learn: Configure app management policies

Related NHI Mgmt Group resources: Azure Entra Client Secrets Security Guide · How to find and remove stale service principals in Entra ID · Secrets Rotation Runbook Template · Machine Identity, PKI and Certificate Lifecycle Guide