Credentials and Expiry

"It expired" is the most common explanation for an integration that suddenly stops. But Entra has several different things that can expire, on very different timescales, and they are fixed in very different ways. A token that lasts an hour and a client secret that lasts two years are not the same kind of thing. This chapter sorts them out, with the lifetimes Microsoft documents, so you can say exactly what expired and who has to act.

What Can Expire

The sources are Microsoft Learn pages on access tokens, refresh tokens, authorization code flow, adding app credentials and managing federation certificates. Check them before quoting a number to a client; Microsoft does change defaults.

Client Secrets

A client secret is described by Microsoft as sometimes called an "application password": a string your system sends to prove who it is. It is created in the application's registration, under App registrations > (your app) > Certificates & secrets > Client secrets > New client secret, by choosing a description and an expiry (or a custom lifetime).

• Lifetime: limited to two years (24 months) or less. A custom lifetime longer than 24 months can't be set. Microsoft recommends under 12 months.
• The value is shown only once. Microsoft says the secret Value is never displayed again after you leave the creation page. If nobody copied it, it cannot be recovered; a new secret has to be created.
• Microsoft discourages them in production. The documentation says client secrets are less secure than certificates or federated credentials, and recommends a certificate before moving to production.

Certificates on an App Registration

A certificate is the credential Microsoft recommends. Per the documentation, a public certificate is uploaded under Certificates & secrets > Certificates > Upload certificate, accepted as .cer, .pem or .crt, and the certificate's thumbprint is what the client application uses to refer to it. Your system holds the matching private key and signs a short assertion with it for each token request (Chapter 3). Two points for support:

• The certificate has its own validity dates. When they lapse, token requests fail in the same way an expired secret does.
• Whoever manages the private key manages the risk. For production Microsoft recommends a certificate from a well-known certificate authority, managed through a service like Azure Key Vault. See the HTTPS/TLS Fundamentals course for how certificates work in general.

SAML Signing Certificates

When SAML single sign-on is set up on an enterprise application, Entra generates a self-signed signing certificate that is, by default, valid for three years. This is the certificate your system uses to check every assertion (Chapter 3). A few rules from Microsoft's certificate tutorial matter in practice:

• The expiry date can't be edited after saving. To get a different date you create a new certificate (the portal offers any date between today and three years away), save it, give it to the application, then make it active. New certificates start as Inactive; Make certificate active promotes it and demotes the old one.
• Entra emails before expiry: 60, 30 and 7 days before the SAML certificate expires. By default the only recipient is the administrator who added the application; up to five addresses can be listed, and a distribution list is suggested if more people need it. The sender is azure-noreply@microsoft.com, which is worth allow-listing. If the addresses were set through Graph or PowerShell, Microsoft advises opening the SAML page in the portal to confirm notifications are registered.
• Renewal without downtime: create the new certificate with a date that overlaps the old one, give it to the application, then activate it. If the application accepts only one certificate at a time, choose a short maintenance window.
• Role needed: Privileged Role Administrator, Cloud Application Administrator or Application Administrator.

Tokens and Refresh Tokens

Access tokens expire after roughly an hour and the software quietly gets another, so a token expiring is not by itself a fault. Refresh tokens are different, because their end does surface to people. Microsoft documents their default lifetime as 90 days (24 hours for single-page apps and email one-time-passcode flows), and says they can be revoked by the service at any time before then. Your application is expected to handle revocation by sending the user to an interactive sign-in again.

Revocations that Microsoft lists include:

• the user revokes their own refresh tokens, or an administrator revokes all of a user's tokens (everything is revoked);
• an administrator resets the user's password in the Microsoft Entra admin center or the Microsoft 365 admin center (revokes tokens issued to confidential clients as well as most others);
• a password change by the user or a self-service reset, which revokes some kinds of token but, per Microsoft's table, leaves a confidential client's token alive; and
• a password simply expiring, which doesn't revoke tokens.

For support, this explains a particular pattern: an integration that acts for one user in the background (for example, reading their calendar) works for weeks and then stops after that person's password is reset by an administrator or their tokens are revoked. That is not an expired credential and renewing a secret will not fix it; the user has to authorise the integration again.

Rules That Shape These Lifetimes

A tenant can restrict how applications are configured, using app management policies, which Microsoft describes as controls over how app owners and administrators configure applications and service principals. They are found at Entra ID > Enterprise apps > Application policies and configured by a Security Administrator together with an Application or Cloud Application Administrator (or by a Global Administrator). Among the restrictions Microsoft lists:

So "the client can't create a new secret" is not necessarily a permissions issue: a tenant policy may be forbidding it. Ask the administrator whether application policies are in force before assuming anything else.

Finding Out What Expires, and When

Chapter 5 walks through the portal in detail, but the places to look follow directly from this chapter:

That recommendation, per Microsoft, appears when an application registration has a credential expiring within the next 30 days. The roles that can view it include Reports Reader, Security Reader and Global Reader. Microsoft's documented fix is the sequence you will use in Chapter 8: add a new credential, update the service to use it, check in the sign-in logs that the new credential is the one being used, then remove the old one. Microsoft's own sample of that recommendation lists a required licence of Microsoft Entra Workload ID, so confirm what the client has before telling them it will be there.

Symptoms: Which Kind of Expiry Is It?

Hands-On Exercises

All three use fictional data. "Today" in the exercises is 1 October 2026.