Entra ID AADSTS7000222: Rotating Expired App Client Secrets Safely

#Current method: finding out when sign-in breaks

Many teams learn that an app registration credential has expired when users or services fail to sign in. The error AADSTS7000222 is associated with an expired client secret or key on the application. The usual response is a rushed fix: someone with access creates a new secret, pastes it into the application and hopes the outage ends.

This works but carries delay and risk. Nobody owns the expiry date, the secret value is shown only once at creation, and the person rotating may not know every system that holds the old value. Evidence of which credential was in use is weak. Confirm the error meaning and credential behaviour in the Microsoft Entra documentation, as details can change by version.

#Improved workflow: inventory, overlap, verify, retire

The improved method treats credential expiry as a scheduled operational event rather than an incident. It has four stages, each with a reason.

1. Inventory. List every app registration with its secrets and certificates and their end dates. This turns an unknown into a sorted list and shows the credentials already expired.
2. Assign owners. Each application needs a named owner and a record of where the credential is stored and consumed. Without this, rotation stalls on discovery.
3. Overlap. Add the new credential while the old one remains valid. Entra ID allows more than one credential on an app registration, so the consuming application can switch without a hard cutover. The trade-off is a short period where two valid credentials exist, which widens exposure slightly.
4. Retire. Once sign-ins succeed with the new credential, remove the old one so it cannot be reused.

Where an application has already expired, there is no overlap to offer; the same steps apply but the outage is live, so prioritise those first.

#Implementation

Prerequisites: a non-production tenant or test registration to rehearse in, an account with rights to manage the target app registrations (for example the application owner or an appropriate administrator role), and read access to sign-in logs. Confirm exact role requirements in the vendor documentation.

#

Stage 1: build the inventory

Use the Entra admin centre app registrations view, or a read-only Microsoft Graph query, to list each application’s credentials and end dates. Export the result and sort by end date. Expected evidence: a list showing expired items, items expiring within your chosen window, and items with no owner recorded. Stop if you cannot read credentials for a large share of applications; that is a permissions gap to resolve before continuing.

#

Stage 2: confirm the failure is the credential

For an affected application, check the sign-in logs for the failing service principal sign-in and the error code. Expected evidence: AADSTS7000222 against the application. If a different code appears, such as a consent or redirect problem, the credential is not the cause. See AADSTS65001 on missing consent and AADSTS50011 on redirect URI mismatch for those paths.

#

Stage 3: add the new credential

Add a new client secret or, preferably where the application supports it, a certificate, with a defined and reasonably short lifetime. Copy the secret value at creation into your approved secret store; it cannot be retrieved later. Do not paste it into tickets or chat. Expected evidence: two credentials listed on the registration, one old and one new. Stop if the value is not stored securely.

#

Stage 4: deploy and test

Update the consuming application or vault reference to the new value, then trigger a sign-in. Expected evidence: a successful service principal sign-in in the logs using the application. Stop and roll back to the old credential if it is still valid and the new one fails.

#

Stage 5: retire the old credential

After a defined observation period with no sign-ins depending on the old credential, remove it from the registration. Record the date and owner.

#

Stage 6: alert before the next expiry

Schedule a recurring report from your inventory query and notify owners well ahead of each end date. Pick a notice period that matches how long your change process takes to deploy a new secret. Prefer certificates or workload identity options where the platform supports them, since they reduce manual secret handling; confirm applicability in the documentation.

#Guardrails

• Rehearse in an isolated tenant or test registration before touching production.
• Apply least privilege: owners manage their own registrations rather than broad administrators doing everything.
• Never record secret values in tickets, logs or source control.
• Change one application at a time and keep the old credential until the new one is proven.
• Do not delete any credential unless you have confirmed it is no longer used.

Residual risk: the sign-in logs show which application authenticates but may not show which credential, so removal of an old secret relies on an observation period and owner confirmation rather than proof. Treat this as an assumption to confirm for your tenant.

#Validation

1. The inventory shows no expired credentials on in-scope registrations.
2. Each rotated application records a successful sign-in after the change.
3. No AADSTS7000222 events appear for rotated applications during the observation period.
4. Each registration has a named owner and a documented secret location.
5. The expiry report runs on schedule and reaches owners.

#Common mistakes

• Replacing instead of adding. Removing the old secret first creates an outage; add first, remove later.
• Copying the secret ID. The secret ID differs from the value; using the ID causes a different authentication failure.
• Updating only one environment. The same registration may feed several deployments, each holding a copy.
• Setting very long lifetimes. This hides the problem until an owner has left.
• Ignoring certificates. They expire too and need the same inventory.

#Recovery

If a rotation breaks sign-in: the symptom is new failures after deployment. A likely cause is a wrong value, a stale cache, or a missed consumer. Check the sign-in log error code. If the old credential is still valid, point the application back to it, confirm sign-ins recover, then investigate. If the old credential was already removed, add another new secret, deploy it, and verify. Afterwards, confirm failures stop and record the cause. Escalate to the identity owner if multiple applications fail at once or if the error code is not credential-related. Also consider whether a conditional accessThe KBY LexiconConditional AccessConditional Access evaluates identity, device and network signals at sign-in to grant, block or challenge access; safe use requires report-only validation and a tested rollback path. Read Full Context policy, such as one stuck in report-only mode, is affecting your assumptions about sign-in behaviour.

#Measurable outcome

Establish a baseline before changing anything: count the credentials already expired, the number expiring within your notice window, and the number of credential-related sign-in failures over a recent period you choose. Success is zero expired credentials on in-scope registrations, no unplanned credential-expiry incidents, and every credential having an owner. Review the report monthly and treat any credential reaching the notice window without a rotation under way as a process failure to discuss. No percentage improvement is claimed here; measure your own tenant.

#Checklist: credential expiry rotation

• Inventory exported and sorted by end date.
• Owner and storage location recorded for each credential.
• Expired credentials prioritised.
• New credential added alongside the old one.
• Value stored only in the approved secret store.
• Sign-in success verified after deployment.
• Old credential removed after the observation period.
• Expiry alert scheduled and tested.
• Next decision: move high-risk applications to certificates or workload identity where supported, after confirming in vendor documentation.

#Prerequisites and permissions in detail

Before the first rotation, confirm three things in writing: who may add or remove credentials on each registration, who may read the secret store, and who may approve a production change. Keep these separate where practice allows, so the person who creates a secret is not the only person able to approve its use.

#

Read-only inventory access

An inventory account needs only read access to application registrations. If you use Microsoft Graph PowerShell, request a read scope and nothing broader:

1Connect-MgGraph -Scopes "Application.Read.All"
2Get-MgApplication -All | ForEach-Object {
3  $app = $_
4  $app.PasswordCredentials | ForEach-Object {
5    [pscustomobject]@{
6      App = $app.DisplayName
7      AppId = $app.AppId
8      Type = 'Secret'
9      End = $_.EndDateTime
10    }
11  }
12} | Sort-Object End | Export-Csv credential-inventory.csv -NoTypeInformation

Repeat for KeyCredentials to capture certificates. Check the scope name and cmdlet availability against your installed module version. Expected evidence: a CSV whose row count matches the number of registrations that hold credentials, with no blank end dates.

#Implementation detail for the overlap window

#

Choosing the overlap length

Set the overlap to at least one full cycle of the slowest consumer, such as a nightly batch job or a weekly scheduled task. A consumer that runs monthly needs a longer window than a web application that reads its secret on start-up. Record the chosen length in the change record.

#

Handling cached values

Many hosts read a secret only at process start. After updating the vault entry, restart or recycle the consumer and note the time. Where a vault reference is used, confirm the reference resolves to the new version rather than assuming it does. Expected evidence: a sign-in entry timestamped after the restart.

#

Labelling secrets

Give each new secret a description that identifies the owner and creation date, for example the team name plus a date. This lets a reviewer tell old from new when two entries sit side by side, and it narrows the observation period decision.

#Monitoring and expected evidence

Query the sign-in logs for the application over the observation period and keep the output with the change record. A Log Analytics example, if sign-in logs are exported to a workspace:

1AADServicePrincipalSignInLogs
2| where AppId == "<application-id>"
3| where TimeGenerated > ago(7d)
4| summarize Attempts=count() by ResultType, bin(TimeGenerated, 1h)

Confirm the table and column names in your workspace before relying on this. Healthy evidence is a result type of success at the usual cadence and no failures after the restart. Alert on any rise in failed service principal sign-ins for rotated applications during the window, and on a credential reaching its notice date with no open change.

#Realistic failure symptoms after rotation

• Failures begin at the next scheduled run, not at deployment. A batch job or timer still holds the old value. Find the job and update its reference.
• One environment works while another fails. A second deployment holds its own copy. Compare vault versions across environments.
• Authentication fails immediately with a different error. The secret ID was pasted instead of the value, or whitespace was added during copying. Re-enter from the store, not from memory or chat.
• Failures appear only after the old secret is removed. An undiscovered consumer was still using it. Re-add a new secret, then trace the consumer through its owner.

#Change-control records

Each rotation should leave one record containing:

• application name, application ID and named owner;
• credential type, creation date, end date and the description used;
• storage location and the vault version identifier, never the value;
• approver, implementer and the time of deployment and restart;
• log query output showing post-change success;
• planned and actual removal date of the old credential;
• rollback decision and who took it, if any.

#Escalation thresholds

Set thresholds before the work starts, so nobody negotiates them during an outage.

• Owner level: a credential reaches the notice date with no change raised. Owner is contacted and the item stays on the report.
• Team lead: a rotated application still fails after one rollback attempt, or the owner cannot be reached within an agreed working period.
• Identity owner: two or more applications fail together, the error is not credential-related, or a secret value may have been exposed.
• Security incident process: any secret value found in a ticket, chat, log or repository. Treat that credential as compromised, rotate it at once and remove the exposed copy.

#Safe rollback actions

1. Stop further changes and record the time of the first failure.
2. If the old credential is still valid, revert the vault reference or configuration to it and restart the consumer.
3. Confirm a successful sign-in in the logs before declaring recovery.
4. Leave the new credential in place but unused, so the next attempt does not need another creation step. Remove it only if it is suspected to be exposed.
5. If the old credential has gone, create a fresh secret, store it, deploy it and verify. Do not try to recover the removed value.
6. Schedule a review within the agreed period and attach the findings to the original record.