An Entra ID (Azure AD) app registration's client secret can be rotated without downtime, but only if you verify the new secret properly before you retire the old one. In live testing, a new secret was accepted inconsistently for anywhere from about 20 seconds to over two minutes. A single successful sign-in is not proof that the secret works everywhere.
This article covers what we saw, and a rotation sequence that accounts for it.
What can go wrong
A client secret is the password of an application. Rotating it means:
- add a new secret to the app registration,
- update everything that uses the secret,
- remove the old secret.
The failure modes are subtle:
- Propagation delay. Entra does not accept a newly created secret everywhere at once. In our tests, a sign-in with the new secret could succeed, then fail with a 401, then succeed again, for up to a couple of minutes.
- Slot limits. In our tests an app registration allowed two client secrets, and expired secrets still counted. If both slots are taken, you cannot add a new one until you remove one, and removal itself is not instant.
- Removal quirks. A "remove" call can report "not found" for a secret that was just added while it is still listed, and an "add" can return a 409 conflict for a few seconds after a removal.
- Slow end-to-end. Because of the above, a careful rotation takes minutes, not seconds. If anything in the chain (a gateway, a UI, a job runner) has a short timeout, it will report failure while the rotation is still succeeding.
Verify properly: three in a row
A single successful token request is a coin flip during propagation. A more reliable check is several consecutive successes, spaced a few seconds apart, with an overall time budget. In our live testing we settled on three consecutive successes three seconds apart and a budget of 240 seconds. Treat those numbers as a starting point to tune against your own tenant, not a rule.
If the check does not pass within the budget, remove the new secret and keep the old one in use. Nothing has changed for your applications.
A safe sequence
- Preflight. Confirm that the identity doing the rotation can read the app, add and remove secrets, and sign in. A useful preflight creates a short-lived marker secret and removes it, which proves write access without leaving anything behind.
- Check the slots. Count the existing secrets, including expired ones, and the one currently in use. If both slots are used, work out which can go. Remember a pending grace window may still be holding the old secret.
- Add the new secret. Retry briefly on a 409, since a removal in the previous step may still be settling.
- Verify with consecutive sign-ins as above.
- Store the new secret where applications read it, and keep the previous one for the grace window.
- Grace window. Azure has no "inactive" state for a client secret, so the old secret stays fully valid until the window ends, then is deleted. Size the window to your slowest consumer.
- Remove the old secret, then confirm by reading back. Do not trust the delete response alone.
- Rollback during the window. Restore the previous secret in the store and delete the new one.
Permissions
Rotation needs the Microsoft Graph application permission to read and write the app registration. The narrowest workable option is Application.ReadWrite.OwnedBy, with the rotating service principal added as an owner of the target app registration. The alternative, Application.ReadWrite.All, is tenant-wide and should be avoided where possible. Admin consent is required. Seeing when a secret was last used additionally needs audit-log read permission and an Entra ID P1 or P2 licence.
Find the secrets nobody owns first
Before automating rotation, list what exists. A read-only scan of app registrations shows every secret and certificate, its expiry, and (with the audit-log permission) when it last signed in. Secrets that have never been used, have no owner, or expire soon are the first candidates to fix or remove.
Mistakes to avoid
| Mistake | Instead |
|---|---|
| Trusting the first successful sign-in | Require several consecutive successes with a time budget |
| Forgetting that expired secrets use a slot | Count them, and remove expired ones as part of rotation |
| Short timeouts in the tooling around rotation | Raise every timeout in the chain together, so a slow but successful rotation is not reported as failed |
| Granting tenant-wide write permission | Use owner-scoped permission where it is enough |
| Deleting the old secret and assuming it worked | Read back to confirm the removal |
How ZenXPAM supports this
ZenXPAM rotates Entra client secrets with preflight checks (including a marker-secret write test), a slot count that includes pending grace windows, consecutive-success verification before cutover, a grace window with rollback, retry on the 409 and 429 responses Entra returns while it frees a slot, read-back confirmation of removal, scheduled rotation, and a read-only inventory of app secrets and certificates. The Azure path has been tested against a live Entra tenant, and the behaviour described here is what that testing found. See non-human identity governance or book a demo.
FAQ
How many client secrets can an app registration have? In our testing, two, and expired secrets counted towards the limit. Check your own tenant, since limits can change.
Why not just verify once? Entra can accept a new secret on one request and reject it on the next for a short period. Consecutive successes smooth that out.
Is there a way to deactivate a secret instead of deleting it? Not for client secrets. The old secret stays valid until it is removed, which is why the grace window ends with deletion.
Should I use certificates or federated credentials instead? Where your workload supports them, they avoid shared secrets entirely and are worth considering. Rotation is for the secrets you cannot yet replace.
