Who is accountable for identity continuity in shared responsibility models?

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.

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?