The customer is accountable for the tenant side of identity continuity. The cloud or IdP vendor may keep the platform running, but the organisation owns backup, recovery testing, and the continuity of its own access configuration.
Who owns identity continuity in a shared responsibility model?
identity continuity is not automatically covered by the provider simply because the provider runs the platform. In practice, the organisation still has to ensure that access paths, recovery assumptions, and configuration state for its own identities can be restored, validated, and operated during disruption.
What continuity really includes for tenant identity
Identity continuity covers more than a live login service. It includes tenant configuration, directory objects, federated trust settings, conditional access, privileged roles, recovery contacts, and the ability to prove that authentication and authorization still work after an outage, a deletion event, or a bad change.
That is why tenant-side continuity sits with the customer, even when an IdP or cloud provider manages uptime for the platform itself. The provider can keep the service available, but it does not own the business decision to preserve your access model, recovery point, or recovery time objectives for identity-related dependencies.
For background on how identity programmes define ownership and operating model boundaries, see the Identity Security Programme Guide. When continuity is part of the question, the relevant issue is not only service availability, but who is accountable for the controls that let the organisation regain control of its identities and access paths.
Where provider responsibility ends and customer accountability begins
shared responsibility model usually split infrastructure reliability from tenant governance. The cloud or identity provider is accountable for the platform, underlying service resilience, and the parts of recovery it explicitly offers. The customer is accountable for how that platform is configured, what is backed up, who can restore it, and whether the organisation can operate if the primary identity plane is impaired.
That distinction matters most for elements like recovery testing, offboarding hygiene, break-glass access, administrator ownership, and restoration of configuration or policy state. If those are absent, the provider can still be “up” while the organisation remains unable to authenticate users, enforce policy, or re-establish trusted access.
The operational side of that ownership is described well in the NHI Lifecycle Management Guide, because continuity fails most often when lifecycle and recovery are treated as separate problems. The same ownership logic also appears in the Top 10 NHI Issues, especially where shared accounts, stale access, and poor offboarding undermine continuity under stress.
How to prove you actually own continuity
The right test is not “does the vendor have uptime?” but “can we restore and operate our identity controls from our own evidence and procedures?” If the answer depends on undocumented vendor intervention, continuity is not owned, it is borrowed.
What to verify: confirm that backups or exports exist for the tenant configuration you would need to rebuild access; confirm that restore procedures have been tested; confirm that privileged recovery paths are separate from everyday admin access; and confirm that you can detect drift after a restore.
What good looks like: the organisation can recover core identity settings, re-establish trusted access, and revalidate critical roles and policies without improvising during an outage.
For teams formalising that operating model, the Identity Security Maturity Model is a useful benchmark for whether continuity is being managed as a repeatable capability rather than an ad hoc recovery task.
Risk and Threat Considerations
Identity continuity failures create a high-impact exposure because they can simultaneously block legitimate access and preserve unsafe access. If tenant configuration is lost, corrupted, or unrecoverable, the organisation may be unable to authenticate users, enforce policy, or recover privileged control when it matters most.
Failure mechanism: the provider keeps the platform available, but the tenant’s own identity state, trust configuration, or recovery path is missing, stale, or untested, so continuity breaks at the customer layer rather than the service layer.
Impact: the organisation can experience prolonged outage, failed recovery, orphaned administrative access, and loss of control over critical systems even though the identity vendor is still operating normally.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CSA Cloud Controls Matrix and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CP-2 — Contingency Plan | Identity continuity depends on tested recovery planning for tenant configuration and access paths. |
| CP-9 — System Backup | Tenant-side identity continuity requires backup or export of configuration needed for recovery. | |
| CP-10 — System Recovery and Reconstitution | The question is about who must restore identity operations after disruption or loss. | |
| Recommendation — Define and test contingency plans for restoring identity state and access services. Back up identity configurations and recovery data needed to rebuild trusted access. Reconstitute identity services from tested recovery procedures and validated configuration state. | ||
| CSA Cloud Controls Matrix | BCR — Business Continuity & Resilience | Shared responsibility for identity continuity is a continuity and resilience question in cloud services. |
| Recommendation — Assign continuity ownership for tenant identity dependencies and test recovery assumptions. | ||
| ISO/IEC 27001:2022 | A.5.30 — ICT readiness for business continuity | Identity continuity is part of business continuity readiness for critical ICT dependencies. |
| Recommendation — Include identity recovery and tenant access restoration in continuity planning. | ||
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan is executed during or after an event | The answer hinges on executing recovery for identity services and tenant access state. |
| GV.OV-01 — Oversight of cybersecurity risk strategy is established and maintained | The accountability question is about who owns identity continuity risk and oversight. | |
| Recommendation — Exercise recovery of identity state and access controls as part of recovery planning. Assign and maintain oversight for tenant identity continuity responsibilities. | ||
Practitioner Guidance
Decision rule: if a change could prevent administrators or users from regaining access after a tenant loss, treat it as a continuity control, not an ordinary configuration task. That includes federation settings, emergency access, recovery ownership, and any setting that must be restored before normal operations can resume.
What to prioritise: document the exact tenant objects, policies, and roles that must be recoverable first, then test the restoration path under an outage assumption rather than a best-case maintenance window.
Practitioner takeaway: in shared responsibility models, the provider owns platform continuity, but the customer owns the continuity of its own identity state, recovery evidence, and ability to operate safely after disruption.
Related resources from NHI Mgmt Group
- Who is accountable for PCI DSS compliance in AWS shared responsibility models?
- Who is accountable for NHI governance in shared responsibility cloud models?
- Who is accountable for restoring tenant state in an identity provider shared responsibility model?
- When does a machine identity become a compliance problem?