I spent ten years at Okta. Six of them owning the identity infrastructure that ran Okta's own global workforce, and the last four as a Tier-3 escalation engineer, which mostly meant getting on a call with a customer whose provisioning had broken in production and figuring out why.
So when I say Okta is genuinely good at what it does, I am not being polite about a partner. I watched the internals for a decade. There are a few things they do better than the industry gives them credit for, and there is one thing that was never theirs to do, and the gap between those two is where I ended up building.
What Okta actually does well
The API surface is the part engineers underrate. Okta exposes a genuinely granular scope model, so an integration can ask for exactly the resources it needs and nothing else. When I built an integration against it I ended up requesting 35 separate scopes, and every one of them maps to a specific resource type rather than a broad "read everything" grant. That is not the norm. A lot of enterprise SaaS still hands you an all-or-nothing API token and calls it security.
The Integration Network review is real, too. It is easy to assume a vendor catalog is a rubber stamp, and I can tell you it is not, because I have been through it twice for two separate integrations. They look at the scopes you request, they ask why you need them, and they push back. As a customer that should matter to you, because every integration in that catalog had someone at Okta actually read the permission list before it reached your admin console.
And Okta Workflows deserves more attention than it gets. It is a legitimately powerful automation platform, and the teams who lean into it end up encoding a lot of institutional knowledge there, which is the thing I want to come back to in a minute.
The part that was never Okta's job
Here is the split, and it is not a criticism.
Okta guarantees the platform. Availability, security of the service, the infrastructure, the compliance posture of what they operate. They are accountable for all of it and they publish against it.
Your configuration inside that platform is yours. Your policies, your groups, your app assignments, your network zones, your authentication rules, your Workflows, your lifecycle automation. Okta will run it faithfully and will not lose it. What Okta will not do is decide that a change you made was a mistake and put it back.
This is exactly how AWS works, and Microsoft, and Salesforce, and Google. The provider secures the platform, the customer owns what they build inside it. Nobody thinks less of AWS for not un-deleting an S3 bucket policy you removed on purpose. It is the standard model and it is the correct one, because the provider genuinely cannot know your intent.
The trouble is that in identity, the blast radius of a configuration change is unusually wide. A group membership rule is not just a setting, it is who can get into what. So the same change that would be an inconvenience in another system becomes an access incident here.
What I kept seeing on those calls
The pattern almost never involved an attacker. Most of the time it was one of these:
An admin tightened a sign-on policy on a Friday and locked out a region that nobody tested against. A lifecycle rule got edited and started deprovisioning people it should not have. Somebody cleaned up apps that looked unused and one of them was load-bearing for a team that only used it at quarter close. A Workflow that had been quietly running for two years got modified by someone who did not know what the original author was solving for.
In every one of those, the same two questions decide how bad the day gets. What exactly changed, and how fast can you get back to how it was before.
The System Log will tell you events happened. It is comprehensive and it is well built. What it will not give you is your configuration as it stood at 9am on Tuesday, so you can compare it against now. Those are different artifacts. One is a record of activity, the other is a state you can return to, and if you have only ever had the first one you tend not to notice the second is missing until you need it.
Where we fit
Butterfly Security sits entirely on the customer side of that line. We do not replace anything Okta does, and we could not, because everything we do depends on Okta's API being as good as it is.
We take point-in-time snapshots of your Okta configuration on a schedule you set, and we keep them for as long as you want them. When something looks wrong you can diff any two snapshots and see exactly what moved, which turns "what changed" from an investigation into a query. And when you want it back, restore runs preview-first, so you see the precise scope of the change before anything is written. Nothing destructive happens without you looking at the plan first.
We cover Okta Workflows properly as well, which matters more than it sounds. Folders, flows, tables and connectors are hand-built automation that often exists nowhere else, and losing a Workflow is closer to losing source code than losing a setting.
We also built it so you can start read-only. Grant only the read scopes, and the product detects the reduced permission set and simply does not offer restore. You can run a real backup against your real tenant and we are technically incapable of changing anything in it. That was a deliberate design choice, and it exists because I remember being on the other side of the table and not wanting to hand write access to a vendor I had known for a week.
If you take one thing from this
Go find out whether you could answer those two questions today. Pick a change in your org, any change, and see how long it takes you to establish what your configuration looked like before it and how you would put it back. If the answer involves scrolling logs and somebody's memory of how it used to be set up, that is worth knowing now rather than during an incident.
Okta will keep the platform running. That part has never been the problem. The part that is yours is worth having a plan for, and that plan should exist before you need it.
Butterfly Security is identity disaster recovery, built on the Okta Integration Network as an API Service Integration. Backup, snapshot diffing and preview-first restore for Okta and Okta Workflows, plus Auth0. You can start with read-only scopes: [butterflysecurity.org](https://butterflysecurity.org)