AADSTS5000224: Microsoft deauthenticated the whole tenant. The DR list is not a portal ticket.

Most IT managers who keep a break-glass account and a second Global Admin believe they have covered tenant lockout. That version is built for Conditional Access gone wrong, an MFA provider outage, or a federation break — it does nothing if the security token service has stopped authenticating the tenant.

Here is the failure mode we walk tenants through the Monday after AADSTS5000224 lit up every admin channel, and the list that still works when admin.cloud.microsoft is a brick.

AADSTS5000224 is STS off, not a Conditional Access bug

The string is specific. AADSTS5000224: "The tenant you are trying to access has been deauthenticated and is no longer available." Entra admin, Microsoft 365 admin, and the Azure portal all die with it. OpenID metadata for the tenant can still resolve. That combination is how you know you are not looking at a Conditional Access misfire, a broken MFA registration, or a single account that lost a phone.

Do not map it onto AADSTS5000225. That is the inactivity block, with a published 20-day window to ask Microsoft to reactivate. Different error, different playbook. Community Q&A on 5000224 is full of the same lockout; it is not a Learn how-to, and no Message Center ID was cited in the incident that ran this week. Do not wait for one, and do not invent a root cause while you wait.

What breaks it:

• Read the error code, not the portal symptom — if every admin, including cloud-only Global Admins, hits the deauthenticated string, stop editing Conditional Access.
• Keep 5000224 and 5000225 in separate runbooks — inactivity has a documented reactivation window; tenant deauthentication does not.
• Confirm OpenID metadata still resolves — that is a diagnostic that the directory object exists, not a sign-in path.

You cannot open a support ticket from the dead tenant

The in-tenant support blade lives behind the same STS that just refused you. Phone Microsoft. Use a separate tenant — a trial you already own, or a partner tenant — as a vehicle to open a case, and say the affected tenant shows AADSTS5000224. Ask for Data Protection / Entra escalation. Hand them the tenant ID, the custom domains, and billing proof. None of that can be retrieved from a portal you cannot enter.

A partner with GDAP can sometimes open the case on your behalf. Only if the customer already accepted the relationship. You cannot click Accept on a GDAP invite from a tenant that will not authenticate. Partner Center's model is explicit: the customer grants least-privileged, time-bound access. Grant it while you can still sign in.

What breaks it:

• A phone number and a second tenant you can actually reach support from, written down off this directory.
• GDAP already accepted — not a partner you will "add when something breaks."
• Billing owner plus proof of ownership, ready for identity verification on the call.

The door that stays open: break-glass is for the other lockouts

Microsoft's emergency-access guidance is still the right design for the failures it names: federation down, MFA devices unreachable, the last Global Administrator leaving, Privileged Identity Management with no approvers. Cloud-only .onmicrosoft.com accounts, FIDO2, excluded from blocking Conditional Access, stored offline. Keep them.

They will not sign in if STS is off for the whole tenant. Emergency access accounts authenticate through the same token service. This is the sentence most DR docs get wrong. Break-glass is not a tenant-deauthentication control. The list that still works when the directory will not authenticate is the one you write this week, while you can still sign in: tenant ID, custom domains, billing owner, two-plus Global Admins, emergency-access accounts (for those other lockouts), a partner GDAP already accepted, Microsoft 365 backup that does not live only in this tenant, and the Teams Phone / Azure blast radius if those numbers or subscriptions die with the directory.

A standing review of Message Center and partner access — the operating model a governance retainer is for — does not recover a deauthenticated tenant. It is how you notice you still have no accepted relationship before the portal is a brick.

What "good" looks like: the five-item baseline

If you do nothing else this week, these five moves are the DR list that still works when the portal does not:

1. Tenant ID, custom domains, and billing owner off-tenant — a document Microsoft can verify on a phone call, not a screenshot inside the dead tenant.
2. Two-plus Global Admins, plus emergency-access accounts for CA/MFA/federation lockout — keep break-glass; do not pretend it covers STS-off.
3. Partner GDAP already accepted — least-privileged, time-bound, in place before you need a case opened from the outside.
4. Microsoft 365 backup that does not live only in this tenant — mail, OneDrive, and SharePoint copies you can reach if the directory is a brick.
5. A written blast-radius note — Teams Phone numbers, Azure subscriptions, and anything else that authenticates against this tenant ID.

None of this requires a new SKU. All of it is visible this week in Entra Overview, custom domains, Partner relationships, and your backup last-success. After AADSTS5000224, none of it is.

The uncomfortable question

The question worth asking is not "do we have break-glass?" It is: if every admin hits AADSTS5000224 tomorrow, can we prove the tenant ID and the billing owner from a document that does not live in this directory, reach Microsoft from a tenant that still authenticates, and restore mail without the only copy sitting inside the tenant that just went dark?

If you cannot answer that from Entra Overview, the custom domain list, Partner relationships, and the last successful backup job — while you can still sign in — write it down this week.