Identity Is a Shared Responsibility (And Most Teams Don't Realize It)

The assumption that gets teams in trouble

When you move to Okta, Entra ID, or Auth0, you're trusting a vendor with the most critical layer of your infrastructure: identity. Who can log in. What they can access. How they're authenticated. The policies that govern it all.

These platforms are world-class at keeping their infrastructure running. Multi-region failover, redundant databases, 99.99% uptime SLAs. If an Okta data center goes down, your tenant stays up. If Azure has a regional outage, Entra ID fails over.

But here's what most teams miss: that uptime guarantee protects the platform, not your configurations.

If an admin deletes a critical group rule, your IdP won't restore it. If a policy change locks out half your company, there's no undo button. If a compromised account wipes your conditional access policies, support can't roll them back.

Your identity provider is responsible for the infrastructure. You're responsible for everything you've built on top of it.

The shared responsibility model

If you've worked with AWS, Azure, or GCP, you're familiar with the shared responsibility model for cloud infrastructure. The provider secures the physical data centers, the hypervisors, and the network. You secure your workloads, your data, and your configurations.

The same model applies to identity -- it's just that nobody talks about it.

What your IdP is responsible for:

• Platform availability and uptime
• Database replication and infrastructure redundancy
• Security of the underlying platform
• API availability and performance

What you're responsible for:

• Your tenant configurations (policies, rules, settings)
• Your user and group structures
• Your application assignments and integrations
• Your authentication and authorization policies
• Backup and disaster recovery for all of the above

This isn't a criticism of these platforms. It's how SaaS works. Salesforce doesn't back up your custom objects. GitHub doesn't restore your deleted repositories after 30 days. And your identity provider doesn't maintain a version history of your policy configurations.

Why identity configurations are uniquely risky

Most SaaS misconfigurations cause localized problems. A bad Salesforce workflow affects one business process. A misconfigured CI/CD pipeline breaks one deployment.

Identity misconfigurations cascade. A single change can:

• Lock out your entire company. A conditional access policy change in Entra ID or an authentication policy update in Okta can block every user from every application simultaneously.
• Break SSO for all applications. Identity is the front door. If the front door breaks, nothing behind it works.
• Create security gaps that go undetected. A deleted MFA policy or a loosened network zone doesn't cause an outage -- it just quietly exposes your organization.
• Cost thousands per minute. When nobody can log in, the entire company stops. Engineering, sales, support, operations -- all blocked.

The blast radius of an identity misconfiguration is the entire organization. That's why backup and recovery for identity deserves the same rigor as your production databases.

What a real disaster recovery plan looks like

Most organizations have disaster recovery plans for their databases, their application infrastructure, and their code repositories. Very few have one for identity.

A real identity DR plan should include:

1. Automated, scheduled backups

Manual exports don't work. They're inconsistent, incomplete, and nobody remembers to do them. You need automated snapshots of your entire identity configuration on a schedule -- daily at minimum.

2. Complete coverage

It's not enough to back up users and groups. You need policies, authentication settings, application assignments, network zones, group rules, authorization server configurations, and every other resource type that defines how your identity layer works. For Okta alone, that's 60+ resource types.

3. Point-in-time restore

When something breaks, you need to get back to a known-good state fast. That means being able to pick a specific backup and restore specific resources -- not an all-or-nothing recovery.

4. Dry-run previews

Restoring identity configurations blindly is almost as dangerous as the original incident. You need to see exactly what a restore will change before you execute it.

5. Cross-provider coverage

Most organizations don't use a single identity provider. You might have Okta for workforce identity, Auth0 for customer identity, and Entra ID for Microsoft 365. Your backup strategy needs to cover all of them.

The gap in the market

Cloud infrastructure has mature backup tooling. AWS Backup, Azure Site Recovery, Veeam, Commvault -- the options are extensive. Database backup is a solved problem. Code repositories have built-in version history.

But identity? Until recently, there was nothing. No automated backup. No point-in-time restore. No way to recover from a misconfiguration other than manually rebuilding from memory or documentation that's probably out of date.

This is the gap Butterfly Security was built to fill. We provide automated backup and disaster recovery across Okta, Entra ID, Auth0, Ping Identity, and other identity providers -- capturing every configuration, every policy, every resource type.

Because your identity layer is too important to be the one thing in your infrastructure without a backup plan.

Start with the question

If you take nothing else from this post, ask your team one question: "If someone accidentally deleted our conditional access policies right now, how would we recover?"

If the answer involves "rebuild from memory" or "open a support ticket and hope," you have a gap in your disaster recovery strategy. And that gap is sitting at the most critical layer of your infrastructure.