Rotate signing keys by introducing a new key, allowing tokens and metadata to be refreshed, and then retiring the old key after dependent applications trust the replacement. Confirm that applications, APIs, and any validation logic can accept the new key before decommissioning the old one. The main risk is breaking token validation if rotation happens without coordination or overlap.
How signing key rotation works in Microsoft identity platform
Rotating a signing key is not just a key change, it is a trust transition. In the Microsoft identity platform, the new key has to be published early enough for metadata and validation caches to pick it up before the old key is retired. That overlap window is what lets token issuers and token validators stay in sync.
The practical sequence is to introduce the replacement key, wait for dependent systems to observe it, and only then remove the old key from active use. For a deeper key-lifecycle reference, see Cryptographic Key Management Guide, which covers signing keys, key lifecycle, and rotation after compromise.
In the Microsoft ecosystem, that coordination matters because applications, APIs, and intermediate caches may continue to trust previously published signing material until they refresh. If the retirement happens too soon, token verification can fail even though the platform itself is healthy. The key point is to manage overlap as part of the change, not as an afterthought.
What to verify before retiring the old key
Before you decommission the old key, confirm that every consuming system can accept the replacement through normal metadata refresh. That includes relying parties, API gateways, token validation middleware, and any custom logic that pins or filters keys rather than following the published key set. A good way to think about the change is as an interoperability test, not just a key administration task.
Use the published key-set flow, avoid hard-coded assumptions about a specific key identifier, and verify that cache lifetimes are shorter than the overlap window. If you want the broader identity lifecycle angle, NHI Lifecycle Management Guide covers provisioning, rotation, and offboarding patterns that apply to long-lived trust material as well.
When validation fails during rotation, the cause is often stale metadata, a delayed refresh cycle, or an application that has been written to trust a single signing key for too long. The correct response is usually to extend the overlap, confirm discovery of the new key, and then retry retirement only after the trust chain is demonstrably updated.
How to reduce outage risk during key rotation
The safest rotations are staged changes with monitoring, not one-step swaps. Introduce the new key, observe token issuance and validation success, and only retire the old key once you have evidence that dependent services have seen the replacement. This matters most where multiple apps, APIs, or environments validate the same tokens but refresh metadata on different schedules.
That same coordination problem shows up in real incidents involving signing material. The Microsoft Storm-0558 key breach 2023 illustrates why a never-retired signing key can have consequences well beyond a single system boundary, while Static vs Dynamic Secrets explains why shorter-lived trust material is easier to govern than long-lived keys.
When signing keys are rotated cleanly, the old key becomes a temporary compatibility bridge. When they are rotated carelessly, the same bridge becomes an outage source because validators and issuers no longer agree on which key should be trusted.
Risk and Threat Considerations
The main operational risk is breaking token validation if the new key is not trusted everywhere before the old one is withdrawn. The security risk is the opposite mistake, leaving old signing material active for too long, which extends the blast radius if a key is exposed or misused.
Failure mechanism: A validator continues to depend on cached or hard-coded trust state while the issuer has already moved to the replacement key, or an old key remains valid long enough to be abused after compromise.
Impact: Authentication failures, service disruption, failed token acceptance, or continued token forgery risk if stale signing material is not retired on time.
Risk and Threat Considerations
The main operational risk is breaking token validation if the new key is not trusted everywhere before the old one is withdrawn. The security risk is the opposite mistake, leaving old signing material active for too long, which extends the blast radius if a key is exposed or misused.
Failure mechanism: A validator continues to depend on cached or hard-coded trust state while the issuer has already moved to the replacement key, or an old key remains valid long enough to be abused after compromise.
Impact: Authentication failures, service disruption, failed token acceptance, or continued token forgery risk if stale signing material is not retired on time.
Practitioner Guidance
What to verify: Confirm that every token-consuming application is actually using metadata refresh and not a pinned key list, local cache, or custom validation shortcut. Those are the places where rotation usually fails in production.
Decision rule: If you cannot prove that dependent systems have seen the new key, keep the old one in overlap and delay retirement. If the old key is suspected to be exposed, treat the issue as both a rotation and compromise-response exercise, not a routine maintenance task.
Practitioner takeaway: Successful signing-key rotation is defined by trust convergence, not by the moment the new key is created, so the change is complete only when every validator has caught up.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-57, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | 4.2 — Key Lifecycle Management | Signing key rotation is a key lifecycle problem involving overlap and retirement. |
| Recommendation — Apply key lifecycle policy to stage replacement, overlap trust, and retire old signing keys safely. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Signing keys are authenticator material whose rotation affects validation and trust. |
| Recommendation — Manage signing-key lifecycle and rotation with controlled issuance, replacement, and retirement. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Signing keys are long-lived trust material whose stale use increases exposure and rotation risk. |
| NHI-01 — Improper Offboarding | Retiring old signing keys is the decommissioning side of trusted credential offboarding. | |
| Recommendation — Reduce long-lived signing-key exposure by shortening lifetime and rotating with overlap. Retire obsolete signing keys after dependent systems have fully switched trust. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Signing keys are sensitive cryptographic material that must be protected during rotation. |
| Recommendation — Protect signing keys throughout rotation and retirement to prevent disclosure or misuse. | ||
Practitioner Guidance
What to verify: Confirm that every token-consuming application is actually using metadata refresh and not a pinned key list, local cache, or custom validation shortcut. Those are the places where rotation usually fails in production.
Decision rule: If you cannot prove that dependent systems have seen the new key, keep the old one in overlap and delay retirement. If the old key is suspected to be exposed, treat the issue as both a rotation and compromise-response exercise, not a routine maintenance task.
Practitioner takeaway: Successful signing-key rotation is defined by trust convergence, not by the moment the new key is created, so the change is complete only when every validator has caught up.