Skip to main content
All posts
Recovery LayerOktaIdentity SecurityDisaster Recovery

Your identity provider can restore nothing. And they know it.

Every layer of your stack has point-in-time recovery except the one that gates access to all of it. Customers have asked identity vendors for config backup and restore for years and gotten silence. And AI will not close the gap, because recovery is a state problem, not an intelligence problem.

Mick Johnson
Founder, Butterfly Security
3 min read

Your database has point-in-time recovery. Your laptops have Time Machine. Your code has git. Your Google Docs have version history going back years.

Your Okta org, the thing that gates access to all of it, has none of that.

One bad policy push and there is no undo button. No rollback. No "restore to yesterday at 4pm." Just you, a support ticket, and a screenshot folder you hope somebody kept.

This is not news to them

Customers have been raising this for years. Go read the community forums. Config backup, restore, rollback. Asked for, upvoted, escalated through account teams. The response? Silence, or a workaround doc that amounts to "export some CSVs and good luck."

No roadmap acknowledgment. No "we hear you." Not even a public "no." The vendors that positioned themselves as the front door to your entire business have watched customers ask for a spare key and just not answered.

That is not a prioritization decision. That is a gap they are hoping you will not notice until the day you need it.

They could not guard their own front door

Let us be honest about the track record here. Okta was breached through a subprocessor in 2022. Then in 2023, attackers walked through their support case management system, and Okta eventually acknowledged that data on every customer support system user was taken.

None of that is a reason to leave the platform. Breaches happen to serious companies. It is a reason to stop assuming the platform's own resilience story covers you. If the vendor could not protect its own org, what exactly is the plan when something goes wrong in yours?

AI is not going to close the gap

AI makes identity admin faster. That includes the mistakes. An overly broad auth rule that used to take an admin twenty minutes to fat-finger now ships in seconds. With confidence, at scale, in your production login path.

Recovery is not an intelligence problem. It is a state problem. You cannot prompt your way back to a configuration that no longer exists. If there is no known-good snapshot, the smartest model on earth will just help you rebuild from memory, faster.

Speed of change without speed of recovery is not productivity. It is a countdown.

We wrote about this dynamic in more depth in AI in admin work does not remove human risk. The short version: AI-assisted admins are the future, but only when every fast change is paired with a fast way to undo it.

What to do while the vendors stay quiet

You do not need your identity provider's permission to have a recovery story.

  1. Keep a recoverable state before every meaningful change. Back up your identity configuration on a predictable cadence, not just before scary changes.
  2. Diff before you commit. See exactly what a restore or a change will touch before it hits production.
  3. Rehearse recovery every quarter. Recovery that has not been tested is a story, not a plan.

This is the gap Butterfly Security exists to fill: point-in-time backup, restore with dry-run preview, and diff across Okta, Okta Workflows, Auth0, Microsoft Entra ID, and Google Workspace.

If your entire company logs in through one config that nobody can restore, and your vendor will not even acknowledge the ask, that is not their problem. It is yours. Today.

Want to see what a real recovery plan looks like for your org? Book 30 minutes here: calendly.com/mick-butterflysecurity/30min