Preventing Expiry

A credential that expires is the most predictable incident there is. Unlike a disk failure or a bad release, it comes with a date printed on it. When one catches a team out, the date was not the problem: nobody owned it, nobody was reminded, or the reminder went to someone who had left. Prevention is therefore not a clever technology. It is a small, boring system: a list of every expiry, an owner for each, warnings that reach a real person, and a rehearsed renewal. This chapter builds that system out of what Entra offers and what your own product can add.

Why These Incidents Recur

Who Can Prevent What

Your reach depends on the arrangement (Chapter 2). Prevention you control completely is different from prevention you can only request.

What Entra Tells You (and Whom)

The Expiry Register

The register is a list, one row per credential per client, that your team owns. It is deliberately a plain spreadsheet or ticketing-system view. Its value is that someone looks at it on a schedule.

Where the data comes from

• Your own tenant: the Application credential activity report, or Microsoft Graph. The passwordCredential object has displayName, startDateTime, endDateTime (always UTC), keyId and a hint (first three characters). The secret text itself is returned only once, when created; there is no way to retrieve it later.
• A client's tenant: you rarely have the access to run reports, so the data arrives by request: the administrator reads dates to you on a screen share (Chapter 5), or exports the Application credential activity list. Add it to the register the same day.
• Your product: if it stores the credential, it should also store (and show) the expiry date and last-success time, so the register can be checked against what is in use.

When to Renew: Lead Times

Entra's own signals suggest the rhythm: 60, 30 and 7 days for SAML emails; a 30-day window for the credential recommendation. A practical schedule for your register, scaled to how hard the client is to coordinate:

Choosing Lifetimes and Credential Types

• Client secrets have a maximum lifetime of 24 months; Microsoft recommends under 12. Longer isn't available, so "set it and forget it" doesn't exist for secrets.
• SAML signing certificates default to three years and can be set to any date up to three years ahead; the date can't be edited after saving.
• Certificates over secrets. Microsoft recommends certificates for production. A certificate doesn't remove expiry, but a CA-issued certificate kept in a vault such as Azure Key Vault is easier to renew in a controlled way than a pasted string.
• No stored secret at all, where possible. Microsoft's guidance for migrating away from secrets points to managed identities (for workloads running in Azure) and federated identity credentials (for supported external workloads). These apply to your workloads, and only where the platform supports them; they are not something a client can switch on for a product that does not support them.
• The client's policy may decide for you. Application management policies can limit the maximum lifetime of passwords and certificates, or block adding secrets (Chapter 4). Ask during onboarding what their limits are, and design for the shortest.
• Don't confuse short with safe. Short lifetimes shrink the damage of a leak but multiply the number of renewals. If you shorten lifetimes, the register and the runbook must be solid first.

Making Rotation Boring in Your Product

This is the part you control completely, and it is where most recurring pain is removed. Ask your engineering team for these, in rough priority order:

1. Accept two credentials at once. Support an old and a new secret or certificate in parallel, so the sequence create, install, prove, remove never involves downtime or a precisely timed swap.
2. For SAML, read the federation metadata URL regularly (Microsoft recommends at least every 24 hours), add newly published signing certificates as secondary, and promote them when Entra activates them. Then the client's rollover needs no action from you.
3. Show the expiry. The connection settings page should display which credential is in use, its expiry date if it can be known, and the date of the last successful sign-in.
4. Warn early and loudly. Product-side warnings at 60, 30 and 7 days to the client's named contacts, and an alert to your own support team.
5. Make "validate the connection" informative. Distinguish "credential expired" (7000222), "credential invalid" (7000215), "consent missing" and "blocked by Conditional Access" with plain-language messages, instead of a generic failure. Chapters 6 to 8 give you the mapping.
6. Never log or display the secret once stored; record only a short hint, such as the first three characters (the same approach as Graph's hint).

Catching Failures Early

If prevention fails, you want the first failure, not the thousandth. Two layers:

• In your product: alert your support team on the first failed token request or provisioning cycle for any client, with the error code attached.
• In the client's tenant: an administrator with at least Security Administrator can send the Entra logs to a Log Analytics workspace through Entra ID > Monitoring & health > Diagnostic settings and build alerts on failed sign-ins for the integration's application. This is a client-side project with its own cost and decision-making, so offer it; don't assume it. Chapter 7's retention figures (7 days Free, 30 days P1 and P2) are the reason many clients benefit.

Client-Facing Prevention

Onboarding checklist (ask once, record the answers)

• Named owner for the integration, and a shared mailbox rather than one person.
• Notification recipients set on the SAML certificate (up to five; use a distribution list).
• Their application management policy limits, if any.
• Which licence they hold (P1/P2), because it decides log retention and which reports exist.
• How a renewal is requested and approved on their side, and the usual lead time.
• Whether they allow us a read role such as Reports Reader for diagnosis.

A renewal reminder you can send at 90 days

Hands-On Exercises

All three use fictional organisations and values. Never put real secrets, tokens or tenant details into practice notes.