Okta Backup Storage: Self-Hosted vs Managed

Should you self-host your IAM backups?

Self-hosting IAM backups in your own cloud account or data center places the recovery copy inside the same identity perimeter you are protecting. When the identity provider is compromised, the credentials that reach the backup are compromised with it.

The Four Places IAM Backups Actually Live

Every enterprise running Okta or Microsoft Entra ID ends up choosing one of four storage architectures for its identity data. Most teams choose by default rather than by design, and the default usually follows whatever the tooling made easy.

Models 1 and 2 are easy to rule out once you have needed a restore. The real debate in enterprise procurement is between models 3 and 4, and it usually gets framed as a question about data ownership. It is actually a question about isolation.

Why Self-Hosted Okta Backups Inherit the Blast Radius

Identity is Tier-0 infrastructure. Its failure cascades into every other system, including the console where your backups live.

Work the chain backwards. Your AWS, Azure, or GCP administrative console is almost certainly protected by single sign-on. That single sign-on is provided by Okta or Entra ID. So the storage account holding your identity backup is reachable with credentials issued by the identity provider that backup exists to restore. Compromise the identity provider and you have not just broken production. You have handed the attacker the keys to the recovery copy in the same motion.

This is not theoretical. The October 2023 Okta support system incident and the Midnight Blizzard campaign against Microsoft followed the same three-step sequence: initial foothold, configuration change, persistent privileged access. In the Microsoft case the attacker created a user account specifically to consent to a malicious OAuth application, then used a legacy test app to obtain full_access_as_app permissions. An attacker who can grant themselves application permissions inside your tenant can grant themselves access to anything that tenant federates, and that includes your bucket.

National cyber authorities have been explicit about the fix. The UK’s National Cyber Security Centre, in its principles for ransomware-resistant on-premises backups, puts isolation first and instructs organizations to “make sure a backup solution uses admin accounts and credentials that are separate from those used to administer the rest of your network.” The whole document exists because on-premises backups are reachable from the network that gets compromised. CISA’s #StopRansomware Guide makes the same point more bluntly, advising organizations to keep backups offline “as many ransomware variants attempt to find and subsequently delete or encrypt accessible backups.” Microsoft’s own guidance for protecting backups against ransomware requires out-of-band steps such as a separate security PIN before an online backup can be modified or erased, precisely so a compromised administrator session cannot destroy the recovery point.

Read those three together and a pattern emerges. Every authority says the same thing: the backup must not be reachable using the credentials that were just stolen. A self-hosted identity backup, by construction, usually is.

Identity is now the dominant way in. Sophos’s State of Ransomware 2026, a survey of 2,158 IT and security leaders across 17 countries, found that 79% of ransomware attacks began with an identity-based approach, that 56% succeeded in encrypting data, and that average recovery costs reached $1.7 million.

The economics get worse when the backup goes down with the tenant. Separate Sophos research on compromised backups, based on a survey of 2,974 IT and cybersecurity professionals whose organizations were hit by ransomware, found that attackers attempted to reach backups in 94% of cases and succeeded 57% of the time. Victims whose backups were compromised faced median ransom demands of $2.3 million against $1 million for those whose backups held, and median recovery costs eight times higher, $3 million against $375,000. Backups are not a side objective in a modern intrusion. They are the objective, because destroying them is what converts an outage into a payment.

The Operational Load Self-Hosting Moves onto Your Team

Isolation is the headline risk. The quieter cost is everything self-hosting hands back to you.

Bucket policies. Object lock configuration and retention modes. Versioning. Key management and rotation. Cross-region replication. Lifecycle rules that do not silently expire the recovery point you need. Access logging. Alerting on privileged storage actions. Every one of those is a control you now own, and every one is a place a misconfiguration can quietly disable your recovery without producing a single error. NIST SP 800-209 makes the point directly: as storage architectures have grown more complex, so has “management complexity, which subsequently increases the probability of configuration errors and associated security threats.”

Then there is the part teams discover during an incident. A pile of JSON in a bucket is a copy of your data, not a recovery. Restoring an identity tenant means replaying objects in dependency order, reattaching group memberships, rebuilding app assignments and policy bindings, and preserving the relationships between all of them. Get the order wrong and you create orphaned users with no access or, worse, users with access they should not have. Identity data is a graph, and graphs do not restore alphabetically.

Testing is the third burden. Owning the storage means owning the proof that the storage works. Manual restore drills are expensive to run, which is why they tend to get scheduled annually and then deferred. Our position is that you should test your identity backups continuously rather than annually. An untested backup is a hypothesis.

Okta Backup Storage Models Compared

Acsense Backup and Recovery: Protect, Recover, Prove

A copy you cannot restore is not a recovery plan. Acsense treats identity data as Tier-0 infrastructure and builds the storage architecture around one requirement: the backup has to survive the compromise of the thing it is backing up.

Protect: Immutable Backup Storage Outside Your Tenant

Continuous Data Protection captures Okta and Entra ID state in near real time, including Okta Workflows and Entra ID automations, and writes it to secured, immutable, air-gapped Managed Storage. That storage sits outside your identity provider, outside your cloud account, and behind an authentication plane your tenant does not federate. An attacker holding super administrator rights in your Okta tenant holds no path to it. This is what the 3-2-1 backup rule applied to identity data is supposed to deliver, and what a bucket in your own account cannot.

Recover: Full Tenant Rollback With Relationships Intact

Recovery spans the whole range, from one deleted user to the entire tenant. Undo from Recycle Bin restores individual objects instantly. Time Machine and the change log let you navigate tenant state across time and see who changed what, when, and from what state. Single Object Recovery, Bulk Recovery, and Full Tenant Rollback return the environment to any prior known-good point with object relationships, group memberships, and app assignments preserved. Point-in-time recovery is the difference between owning data and owning a way back, which is why immutability alone is only half the control.

Prove: Recovery Readiness You Can Show an Auditor

Continuous Resilience Validation runs automated, ongoing tests of recovery readiness and produces auditable proof of RTO and RPO without waiting for an incident. Recoverability Health scores whether your backups are complete and restorable, surfacing recovery risk before it matters. Configuration drift is detected in ≤10 minutes across both identity providers. Self-hosting can give you a copy. It cannot give you evidence that the copy restores.

One Baseline Across Okta and Entra ID

Most enterprises run both. Acsense covers Okta and Microsoft Entra ID under a single platform, a single recovery runbook, and a single compliance baseline, so protection does not fragment across two tools with two different storage models and two different sets of assumptions.

When Data Residency Is a Real Requirement

The strongest argument for self-hosting is not security. It is sovereignty. Regulated entities in the EU, financial institutions under national supervision, and public sector buyers frequently have binding requirements about where identity data physically rests and who can be compelled to produce it. Those requirements are legitimate and should not be waved away.

But residency and self-hosting are different things, and conflating them costs you the isolation you actually need. A managed backup can be regionalized, encrypted with customer-controlled keys, and contractually bound to a jurisdiction while still living outside your tenant. You get the residency guarantee and the separate authentication plane at the same time. Self-hosting gives you the first and takes away the second.

The genuine exception is a fully air-gapped classified environment with no outbound connectivity at all. If that describes you, the trade-off is real and the operational burden is the price of the mission. For everyone else, “we want to own our data” is usually a procurement instinct rather than a control requirement, and it is worth asking which specific obligation it satisfies. The shared responsibility model already makes recoverability your obligation. Where the bytes sit does not change who is accountable when they cannot be restored.

Okta Backup Storage Readiness Checklist

Illustrative Scenario: The Backup Behind the Breach

Picture a mid-sized US healthcare provider running Okta for workforce identity, with a HIPAA contingency plan on file under 45 CFR §164.308(a)(7). Identity backups are written by a bring-your-own-storage tool into an S3 bucket in the organization’s own AWS account. The AWS console is protected by Okta single sign-on, because standardizing on one identity provider was the right call everywhere else.

An attacker phishes an IAM administrator, defeats the push factor through fatigue, and reaches super administrator in the Okta tenant. Within the hour they have assumed the federated AWS administrator role, disabled object lock on the backup bucket, and deleted the prior versions. Only then do they start deleting groups and app assignments in Okta.

How Acsense Closes the Recoverability Gap

The recoverability gap is the structural space between what identity providers guarantee and what enterprises actually need. Providers guarantee their own service uptime. They do not guarantee that you can restore your tenant after a privileged account is turned against you. Closing that gap is the customer’s job under every shared responsibility model in the market.

Self-hosting feels like closing it. On paper you own the copy, you control the region, and nobody else touches your data. In practice you have moved the recovery copy inside the perimeter you are defending, taken on a dozen storage controls your team now has to get right permanently, and kept a restore path that has never been tested end to end.

Storage location is not a preference. It is a control.

Acsense is built the other way around. Identity data is captured continuously, written to immutable air-gapped storage that your identity provider cannot reach, restored with relationships intact in minutes rather than days, and validated on an ongoing basis so recovery readiness is a number you can show rather than an assumption you are carrying. That is what IAM Resilience means in practice, across Okta and Microsoft Entra ID, under one platform.

Frequently Asked Questions

Should IAM backups be stored on-premises?

Generally no. On-premises backups are reachable from the network and directory that an attacker compromises, which is why the NCSC’s principles for ransomware-resistant on-premises backups lead with isolation and separate administrative credentials. For identity data specifically the problem is sharper, because the identity provider you are backing up is usually what authorizes access to the backup infrastructure itself.

What is wrong with backing up Okta to our own S3 bucket?

The bucket is fine. The access path is the problem. If your AWS console authenticates through Okta, then anyone who reaches super administrator in Okta can assume a federated AWS role, disable object lock, and delete recovery points before touching production. Bring your own storage puts the recovery copy inside the same blast radius as the system it is meant to recover.

Is a Git repository a valid IAM backup target?

Only for part of the picture. Git and Terraform capture declared configuration, not live tenant state. Users, group memberships, factor enrollments, app assignments, and workflow definitions largely live outside state files. Repositories are also an attack target: Okta disclosed in December 2022 that its own GitHub repositories were accessed, and GitGuardian counted 28.65 million new hardcoded secrets pushed to public GitHub during 2025, a 34% year-over-year rise.

Does Okta or Entra ID already keep a copy of our data?

Not in a way that constitutes a backup. Soft-delete windows and log retention are operational features with fixed horizons, not recovery points. Neither provider offers full tenant rollback to an arbitrary prior state, and neither accepts responsibility for restoring configuration that a privileged account inside your tenant deliberately changed or deleted.

How is Acsense storage isolated from our tenant?

Acsense writes backups to secured, immutable, air-gapped Managed Storage that sits outside your identity provider and outside your cloud account, behind an authentication plane your tenant does not federate. Compromising Okta or Entra ID does not produce a credential that reaches it. Immutability and air-gapping are enforced by design rather than configured by your team.

Does self-hosting give us better data ownership and residency?

It gives you physical custody, which is not the same as the control most residency obligations require. Managed backups can be regionalized, encrypted with customer-controlled keys, and contractually bound to a jurisdiction while still living outside your tenant. That satisfies residency and preserves isolation. Self-hosting satisfies residency and gives isolation away.

How do we prove our IAM backups actually restore?

By testing them continuously rather than annually. Acsense Continuous Resilience Validation runs automated, ongoing recovery readiness tests and produces auditable proof of RTO and RPO without waiting for an incident, and Recoverability Health scores whether backups are complete and restorable. Manual restore drills scheduled once a year cannot answer the question on the day an auditor or an incident asks it.