Expiring app credentials: the outage nobody plans for

01 / 10

A backup that stopped talking

Consider a fictional 110-person wholesaler that runs its nightly warehouse and accounting data to a cloud archive through a small integration account. Nobody remembers setting it up. It has run every night for three years without a single complaint.

It stopped on a Tuesday. The report that would normally have flagged a failed run was itself sent by the same integration, so the alert never arrived either. Nobody in the building knew anything was wrong until, nine days later, someone tried to restore a file and found nothing newer than the failure date.

The cause, once IT found it, was almost dull. A client secret on an app registration had reached its expiry date. Nobody had renewed it, because nobody knew it existed, and nothing in the building was watching the calendar for it.

02 / 10

What actually expired

Every integration that talks to Microsoft 365 without a human at the keyboard proves its identity the same way a person does: with a credential. A person types a password and, ideally, a second factor. A service uses one of two things registered on its app registration: a client secret, a string value that functions as a password, or a certificate, a public and private key pair.

Both live in the same place: App registrations > (your app) > Certificates & secrets, in the Microsoft Entra admin center. Both carry an expiry date. And both fail the identical way once that date passes: the integration's next sign-in attempt is rejected, with nothing on anyone's screen to say why.

03 / 10

The one hard number Microsoft enforces

There is a real ceiling here, worth knowing precisely rather than guessing. Microsoft's own documentation for registering an application states it plainly: Client secret lifetime is limited to two years (24 months) or less. You can't specify a custom lifetime longer than 24 months.

Microsoft also tells you what to do with that ceiling, and it is shorter than the maximum: Microsoft recommends that you set an expiration value of less than 12 months. Nothing enforces the second number. The portal will let anyone creating a secret pick the full 24 months, and outside a deliberate audit, nobody is likely to ask why they did.

Certificates carry no equivalent platform-wide cap. Microsoft's guidance there is a preference, not a limit: Microsoft recommends that you use a certificate instead of a client secret before moving the application to a production environment, because, in Microsoft's own words, a certificate is the recommended credential type because they're considered more secure than client secrets. A certificate's actual lifetime is set by whoever issued it, or by a tenant policy — covered further down.

04 / 10

Where the expiry date actually lives

The admin center shows it directly. Open Certificates & secrets on the app registration and the expiry date for every secret and certificate is listed beside it. That is the easy path, and it depends entirely on someone opening that specific screen for that specific app.

The programmatic version is the same fact, one layer down. In Microsoft Graph, a client secret is a passwordCredential object and a certificate is a keyCredential object, and both carry an endDateTime property: the date and time at which the password expires represented using ISO 8601 format and is always in UTC time. Anyone building an inventory rather than clicking through app registrations one at a time is querying that field, across every application at once.

05 / 10

The blind spot in your own applications list

Not every credential you depend on is even yours to see. When a third-party vendor's application talks to your tenant — an accounting system's mail connector is a common example — what shows up in your Enterprise applications list is a service principal, not the application object that actually holds the credential.

Microsoft's own architecture documentation draws that line clearly: A Microsoft Entra application is defined by its one and only application object, which resides in the Microsoft Entra tenant where the application was registered — the application's home tenant. A service principal, by contrast, is the local representation... of a global application object in a single tenant; it inherits certain properties from that object, but it is not that object.

Our reading, not something Microsoft states in those words: the practical effect is that your tenant's admin center never hands you the vendor's own secret to inspect or renew, because it was never yours to hold. If that vendor lets their credential lapse, your integration breaks with nothing in your own portal telling you a date was ever coming. The renewal, and the responsibility for tracking it, sits entirely on a side of the relationship you cannot audit from your tenant.

06 / 10

Four ways this authenticates, side by side

The rows below cover every unattended integration you are likely to own. Read the third and fourth columns before the second — that is where the risk actually sits.

07 / 10

What Entra's own recommendation catches

Microsoft has since added an automated version of the reminder nobody else was giving your organisation. The Renew expiring application credentials recommendation, still marked (preview) on Microsoft's own page as of its last update, exists specifically for this failure mode: This recommendation shows up if your tenant has application credentials that will expire soon.

Its detection window is narrow, and worth knowing exactly. A credential triggers it only if it's on an application registration AND is expiring within the next 30 days. Thirty days, against a secret that can legally run for up to twenty-four months. A companion recommendation, Renew expiring service principal credentials, also in preview, uses the same 30-day window for credentials living on the service principal rather than the application object.

Both explain their value in the same plain terms: Renewing an application's credentials prior to their expiry date is crucial for maintaining uninterrupted operations and minimizing the risk of any downtime resulting from outdated credentials. True — and still dependent on a human noticing before that window closes. Microsoft's recommendations overview describes a preview feature that emails new recommendations to a set of roles — Application Administrator for these two — and carries its own caveat: If no one is actively assigned to the role, no emails are sent.

08 / 10

The tenant-wide off switch, and a contradiction worth naming

For an administrator who would rather not depend on any one person reading a recommendation on the right day, Microsoft offers a blunter instrument: an app management policy. Its passwordLifetime restriction can enforce a max lifetime range for a password secret, and its passwordAddition restriction can block the addition of new passwords... on applications altogether — forcing every new integration onto certificates or federation instead.

Two of Microsoft's own pages disagree on how you get there, and it is worth naming rather than picking a side. Microsoft's configuration reference lists these restrictions as configurable through app management policy APIs ... and the Microsoft Entra admin center. Microsoft's tutorial on the same feature states flatly: Application management policies can only be updated using Microsoft Graph PowerShell or Microsoft Graph API. We could not resolve which is current from the documentation alone; try the admin center first and fall back to Graph PowerShell if the option is not there.

The two pages differ on roles too. The tutorial's prerequisite reads At least the Cloud Application Administrator or Application Administrator role. The configuration reference asks for more: The Security Administrator role, AND the Cloud App Administrator or Application Administrator role. OR, just the Global Administrator role. Plan for the stricter of the two. Neither page we read states a separate license requirement for the feature itself.

09 / 10

The credentials that never need renewing

Two Microsoft options remove the clock entirely, for the workloads that qualify. Workload identity federation lets an app registration trust tokens from an external identity provider — GitHub Actions, Kubernetes and Azure Pipelines are among the named scenarios — without needing to manage secrets (in supported scenarios), which in Microsoft's words eliminates the risk of leaking secrets or having certificates expire. Nothing expires because nothing was issued; the trust is a claims match, not a stored value.

Managed identities go further, for anything already running on Azure compute. Microsoft's own description is direct: Applications can use managed identities to obtain Microsoft Entra tokens without having to manage any credentials. And from the same page's list of benefits: You don't need to manage credentials. Credentials aren't even accessible to you. Neither option fits a fictional wholesaler's on-premises backup job, which is exactly why this failure mode is still common: it belongs to the workloads that cannot move to Azure compute, or simply have not yet.

10 / 10

Where to start

Before anything else, get a complete list of the app registrations your organisation actually owns, and the expiry date on every secret and certificate attached to them. App registrations > All applications in the Entra admin center, then Certificates & secrets on each one, will get a handful of integrations covered this afternoon. For more than a handful, pull the passwordCredentials and keyCredentials collections through Graph and sort by endDateTime. Either way, the list should exist somewhere other than the memory of whoever set the integration up.

Disclosure: this is a category we sell into. Avalon CloudSec keeps an inventory of enterprise applications and OAuth grants in a customer's Microsoft 365 tenant, including the credential expiry metadata described above, and its findings pipeline auto-resolves an expiry finding once the underlying credential is renewed or removed. It is read-only by architecture — every Microsoft Graph permission it holds is a read permission — so it can show an expiry date; it cannot renew a secret or install a certificate for you, and it has no visibility at all into a vendor's credential sitting in the vendor's own home tenant. To see what that inventory looks like against your own tenant, email support@awservices.org.

Microsoft, Microsoft 365, Azure, Entra, Intune and Defender are trademarks of the Microsoft group of companies. Avalon CloudSec is an independent service and is not endorsed by Microsoft.