Who is accountable for restoring tenant state in an identity provider shared responsibility model?

The identity provider is responsible for keeping its own service available, but the customer is accountable for tenant configuration integrity, policy state, user data, application assignments, workflows, and recoverability. In practice, that means the organisation must own backup, rollback, validation, and evidence gathering. If tenant recovery is not assigned to a specific internal team, it often fails as a cross-functional gap.

Why This Matters for Security Teams

Tenant state is not a platform availability issue alone. In a shared responsibility model, the identity provider may restore service, but the customer still owns the configuration and data that define how identity works inside the tenant: policies, app assignments, workflows, groups, conditional access, and recoverability. That split becomes critical after misconfiguration, deletion, compromise, or a failed change window, because the provider cannot know which state is business-critical for a specific tenant.

This is why recovery planning has to include backup scope, restore authority, validation criteria, and evidence capture. The operational risk is not theoretical: NHIMG notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is a reminder that identity state is often less observable than teams assume. NIST control guidance on backup and recovery is a useful baseline, but it still has to be translated into tenant-specific runbooks.

In practice, many security teams discover that no one owns tenant recovery until a policy rollback or identity outage has already exposed the gap.

How It Works in Practice

Operational accountability should be assigned to the team that can actually reconstruct tenant state, not just the team that administers day-to-day identity changes. That usually means security identity operations, IAM engineering, or a platform resilience function, with clear handoffs to application owners for validation. The provider’s role is to preserve service availability and platform durability; the customer’s role is to protect the tenant’s logical state.

A workable recovery model usually includes three layers:

• Configuration backup for conditional access, RBAC, app registrations, federation settings, and policy objects.
• State validation after restore, including permission checks, SSO testing, and workflow verification.
• Evidence gathering for incident response, audit, and change control, so the restore can be proven and replayed.

For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls is the right external anchor because it formalises backup, contingency, and access control expectations at a level security teams can operationalise. NHIMG’s Ultimate Guide to NHIs is also relevant because tenant recovery often depends on the same hidden identity assets that make NHI governance difficult in the first place. If tenant state includes tokens, service principals, or automation accounts, restore procedures must cover those identities as well as human-admin settings.

The practical test is simple: can the organisation recreate tenant access and policy intent from documented artefacts without waiting on the provider’s support queue? These controls tend to break down in heavily custom tenants that depend on undocumented admin changes, because the restore target is not a clean backup image but a moving set of identity objects and application dependencies.

Common Variations and Edge Cases

Tighter recovery control often increases administrative overhead, requiring organisations to balance resilience against change velocity. That tradeoff is especially visible in multi-tenant estates, mergers, and delegated administration models, where different business units expect local autonomy but still share a central identity platform.

There is no universal standard for tenant-state ownership in every cloud identity product yet, so guidance should be written at the service boundary rather than assumed from marketing language. Some vendors back up platform metadata, but not tenant-specific configuration history or business workflows. In those cases, relying on the provider for a full restore is a category error.

Edge cases include:

• Federated identity, where the identity provider may be healthy but trust relationships are broken at the customer side.
• Privileged access platforms, where recovery must include role mappings and approval paths, not just account objects.
• Automation-heavy tenants, where service accounts and APIs may need separate restore and rotation steps after a rollback.

For teams that need a breach-oriented recovery lens, the 52 NHI Breaches Analysis is a useful reminder that restore failures often cascade from identity and secret sprawl. The strongest practice is to assign a named internal owner for tenant state, define the restore evidence required, and test the process before an outage forces the decision.

Related resources from NHI Mgmt Group

• Who is accountable for identity assurance in a shared governance model?
• Who is accountable when an identity provider stays available but a tenant configuration is weakened or lost?
• Who is accountable when identity and device management are consolidated into a shared cloud model?
• What is the difference between code scanning and runtime identity monitoring?