Expiring app secrets: the outage nobody sees coming

Somewhere in your tenant there is an app registration with a client secret that expires in the next 90 days. When it does, something stops working: the backup job, the ticketing integration, the SSO for a line-of-business app, the script that provisions new hires. Nobody gets an email. The app doesn't degrade gracefully — it returns AADSTS7000215: Invalid client secret provided to a service account, once, and then keeps returning it until a human notices that the nightly export hasn't landed for four days. This is the most predictable outage in Microsoft 365, and almost nobody has it on a calendar.

Two credential types, two places to look

An app registration in Entra ID can hold two kinds of credential, and the Graph API exposes them as two separate collections on /applications:

• passwordCredentials — client secrets. A string, created in the portal with a maximum lifetime of 24 months (the API allows longer, which is how tenants end up with secrets nobody remembers creating). Each entry has a displayName, startDateTime and endDateTime.
• keyCredentials — certificates. Same shape, longer lifetimes, and usually attached to the integrations that matter most, which makes them the ones that break loudest.

Then there is the second place: /servicePrincipals. Every app registration has a service principal in your tenant, but not every service principal has an app registration you own — third-party SaaS apps and Microsoft first-party apps appear there too, some with their own credentials. Auditing only /applications gives you the apps your team created. Auditing only the portal blade gives you whichever one you happen to be looking at.

The four failure modes

The fourth row deserves a second look, because it isn't an availability problem — it's the same category as orphaned Azure resources: something that was provisioned, stopped being used, and was never removed. An app registration with an expired secret and Mail.ReadWrite application permission is dormant, not harmless. Someone can add a new secret to it in thirty seconds and inherit consent that was granted in 2022.

Getting ahead of it in four steps

Why the portal won't tell you

The Entra portal shows credentials per app registration, one blade at a time. There is no tenant-wide "expiring in the next 90 days" view, no alert, and no export that spans applications and service principals together. Doing it by hand means a Get-MgApplication -All loop that flattens PasswordCredentials and KeyCredentials, a second pass over service principals, and a date filter — a script that works fine the first time and then quietly stops being run. Across multiple tenants, multiply by the number of tenants and add the delegated-access dance for each one.

GraphPaaS collects expiring app secrets as part of the governance domain it already syncs per tenant, alongside admin roles and Conditional Access policies, so "what expires in the next 90 days, across every tenant" is a filter rather than a scripting afternoon. It sits next to the same identity hygiene questions as MFA registration gaps — because an app credential is an identity too, and it's the one nobody offboards.