Tenant lockout is the state in which an organisation loses the ability to manage its own identity environment because administrative access has been removed, disabled, or made unusable. In Entra ID, lockout can follow mass account disablement, broken access policies, or the loss of all recovery-capable administrators.
Expanded Definition
Tenant lockout occurs when an organisation can no longer manage its own identity tenant because the administrative path is gone, broken, or unreachable. In modern cloud identity platforms, that usually means the tenant still exists, but the people and processes needed to recover, restore, or override access do not.
In NHI security, tenant lockout is especially dangerous because the failure often starts with identity controls. A mass disablement, a broken conditional access rule, a deleted break-glass account, or an over-restrictive policy can all remove the very access needed to fix the environment. NIST’s NIST Cybersecurity Framework 2.0 emphasises recoverability and resilience, which is the right lens for this problem even when the term itself is not formalised in the standard.
Usage in the industry is still evolving: some teams use tenant lockout to describe a temporary admin outage, while others reserve it for full loss of control requiring vendor intervention. The most common misapplication is treating it as a simple login failure, which occurs when organisations ignore recovery-role design and assume one administrator or one policy path will always remain available.
Examples and Use Cases
Implementing tenant lockout prevention rigorously often introduces administrative friction, requiring organisations to balance tight access controls against the operational need for guaranteed recovery access.
- A cloud security team disables legacy administrator accounts during hardening and discovers that no remaining account can change the tenant’s emergency settings.
- An identity engineer deploys a conditional access policy that blocks all privileged sign-ins, including the recovery account needed to reverse the change.
- A service desk removes a long-unused global administrator account without confirming that another recovery-capable identity exists.
- An organisation uses the lessons in Ultimate Guide to NHIs to map administrative dependencies for service accounts and break-glass identities before making tenant-wide policy changes.
- A resilience review follows the access model guidance in NIST Cybersecurity Framework 2.0 to test whether a tenant can still be repaired after a high-impact policy error.
Because tenant lockout often involves both human and non-human administrators, recovery testing should include API-based controls, privileged workflows, and emergency access paths rather than only interactive sign-in scenarios.
Why It Matters in NHI Security
Tenant lockout is not just an IT inconvenience. It can freeze revocation, delay incident response, block key rotation, and prevent the removal of compromised non-human identities. That makes it a governance issue as much as an operational one, because a tenant that cannot be administered cannot be secured.
NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotation. When those gaps combine with over-permissive admin design, the result can be a recovery failure that is discovered only during a crisis. The Ultimate Guide to NHIs also notes that 97% of NHIs carry excessive privileges, which increases the blast radius when administrative mistakes are made.
Practitioners should treat tenant lockout as a testable failure mode: preserve break-glass access, separate policy administration from emergency recovery, and verify that NHI controls do not eliminate the ability to restore control. Organisations typically encounter the seriousness of tenant lockout only after an access policy error or account purge, at which point recovery becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Admin lockout stems from identity mismanagement and weak recovery design. |
| NIST CSF 2.0 | PR.AC | Access control and recovery resilience are central to preventing tenant lockout. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification without eliminating recovery capability. |
Preserve emergency admin paths and test tenant recovery before enforcing tenant-wide changes.
Related resources from NHI Mgmt Group
- Why does tenant ownership matter for NHI governance?
- How should regulated teams decide between shared SaaS and tenant-owned identity platforms?
- What is the difference between tenant ownership and data residency in identity governance?
- What is the difference between user error and tenant misconfiguration in collaboration security?
