IdP Configuration Backup and Restore: Entra ID and Okta

Most organisations back up their file servers nightly but cannot say what their Conditional Access policies or Okta sign-on rules looked like last Tuesday. When an administrator, a faulty script or an attacker changes identity provider configuration, every application behind it changes with it, and neither Microsoft Entra ID nor Okta keeps a long history you can roll back to. This guide covers what each platform can recover natively, what it cannot, and how to build a versioned configuration backup with Microsoft Entra Backup and Recovery, the Microsoft Entra Exporter, Microsoft Graph and the Okta Terraform provider. It is written for identity engineers and resilience owners who need a tested restore path, not just an export job.

Key takeaways

Native recovery windows are short. Entra soft delete keeps users, groups, applications and service principals for 30 days, and Entra Backup and Recovery keeps seven days of daily backups; a deleted Okta user cannot be restored at all.
Configuration and objects need different backups. Policies, named locations, authentication method settings and app configuration change in place, so you need a known-good copy outside the tenant to compare against and reapply.
Exports are not restores. The Entra Exporter only exports; Okta Terraform can reapply, but only for object types you have imported and manage consistently through it.
Secrets never come back. Client secrets, certificates and key credentials are outside Entra Backup and Recovery scope, so any restore of an application is followed by a credential reissue.
The backup pipeline is itself a privileged identity. A read-everything Graph app or Okta service app with manage scopes is a high-value non-human identity: least privilege, key storage and monitoring apply.

What each platform can recover natively

Platform feature	What it covers	Window	Gap you must close
Entra soft delete (recycle bin)	Users, Microsoft 365 Groups, cloud security groups, application registrations, service principals, administrative units; Microsoft's recovery guidance also lists Conditional Access policies and named locations as keeping all properties when soft deleted	30 days, then hard deleted	All other object types are hard deleted immediately and must be re-created
Microsoft Entra Backup and Recovery	Supported properties of users, groups, applications, service principals; all properties of Conditional Access and named location policies; authentication methods policy; parts of the authorization policy; admin-consented OAuth2 grants and app role assignments with their service principal	Daily backups, seven days retained	Workforce tenants with Entra ID P1 or P2 only; no credentials, no group ownership, manager or sponsor links, no dynamic group rules, no user-consented grants
Tenant configuration management (TCM) snapshots	A subset of Entra resources and properties, plus other workloads such as Intune and Exchange Online	Snapshots stored seven days	Download for external retention; keep separate from Graph exports, as Microsoft advises
Okta user deactivation	Deactivated users keep group memberships; reactivation may need app reassignment	Until deleted	Deletion "can't be undone"; app assignments are removed on deactivation
Okta configuration	No native configuration snapshot appears in the Okta documentation reviewed for this guide	None	Terraform state and configuration, or API exports, are the backup

Entra Backup and Recovery backups cannot be turned off, deleted or modified by any user or application, including the highest admin roles, which makes them a useful tamper-resistant layer against a compromised Global Administrator. Recovery applies to supported properties only and does not roll back whole objects. The wider Entra and Active Directory recovery sequence, including forest recovery and hybrid ordering, is in the Identity Recovery Guide.

What to back up and why

Configuration	Entra ID source	Okta source	Impact if lost or changed
Access policies	Conditional Access policies and named locations (Graph conditionalAccessPolicy API)	Global session, authentication and app sign-on policies and rules; network zones	Access opened to everyone, or administrators locked out
Authentication methods	Authentication methods policy	Authenticators and enrolment policies	Weaker methods allowed, or users unable to sign in
Federation and trust	Domain federation settings, cross-tenant access settings	Identity providers (inbound federation)	Forged or unintended inbound access (ATT&CK T1484.002 Trust Modification)
Applications	App registrations, service principals, permissions and consent grants	App integrations, assignments, OAuth and SAML settings	Single sign-on broken across dependent apps
Roles and delegation	Custom role definitions, PIM settings, administrative units	Custom admin roles and resource sets	Privilege wider or narrower than intended
Groups that drive access	Security groups, dynamic membership rules	Groups and group rules	Mass loss or gain of app access
Tenant-wide settings	External identities, self-service password reset, user settings	Org general settings (imported as singletons)	Behaviour changes for every user

Do not try to back up every user object as configuration. Okta explicitly advises against importing users into Terraform because user objects, with memberships and assignments, are large. Users belong to your HR or directory source of truth; groups, policies and apps belong to configuration backup.

Building the Entra ID backup

Turn on the native layer (read-only to review): confirm the tenant is licensed for Entra ID P1 or P2 and open Entra Backup and Recovery. Assign Microsoft Entra Backup Reader to the people who review backups and Microsoft Entra Backup Administrator through PIM to the small team that runs recoveries.
Create the export identity: a dedicated identity for the Entra Exporter with read scopes only, such as Directory.Read.All, Policy.Read.All, Application.Read.All and RoleManagement.Read.All. Microsoft notes delegated authentication in a pipeline needs a dedicated agent with pre-configured authentication.
Export nightly: Install-Module EntraExporter, Connect-EntraExporter, then Export-Entra -Path 'C:\EntraBackup\'. The default Config type covers Conditional Access, named locations, authentication methods, roles and many settings. Add -Type "Applications","ServicePrincipals" or use -All for wider coverage. PowerShell 7 is recommended and long Windows paths must be enabled.
Commit to version control: push the JSON to a repository in a separate security boundary with restricted write access and branch protection. Each night's diff becomes your change history.
Keep TCM snapshots separate: if you also download TCM snapshots, store them in a different path. Microsoft advises not combining them with Graph exports because TCM covers only a supported subset.
Document what exports miss: anything not exposed in Microsoft Graph is not exported. Record those settings manually as part of the change process.

Building the Okta backup

Create the Terraform service app: in the Admin Console create an API Services app integration, use public key and private key client authentication, and keep the PKCS#1 private key in a secrets manager. Okta recommends OAuth over API tokens because API tokens inherit the creating admin's permissions and are valid for 30 days, renewing each time they are used.
Grant least privilege: assign a custom admin role for production rather than Super Administrator, and grant only the Okta API scopes Terraform needs (for example okta.groups.read for a read-only export, okta.groups.manage for restore). Granting scopes needs a Super Administrator.
Import existing configuration (read-only against Okta): with Terraform 1.8.5 or later, add import blocks for policies, rules, network zones, groups, group rules and app integrations, then run terraform plan -generate-config-out=generated_resources.tf. Policy rule and network IDs must come from the REST API, not the Admin Console URL. Org-wide singletons use the ID singleton. Okta feature settings cannot be imported.
Converge to zero drift: run terraform plan until it reports no changes. Only then is the configuration a faithful backup.
Protect state: Okta recommends remote state, versioned and encrypted. Treat state as sensitive, because it holds the full current configuration.
Pick one owner per object type: Okta recommends managing each object type through Terraform or the Admin Console, not both. Mixed management means the next apply silently reverts an emergency console fix.

Restoring: a tested sequence

Restores change live access for every user, so the first steps are read-only and the destructive ones are marked.

Secure admin access first: confirm a break-glass account works and is excluded from the policies you may change. See the Break-Glass Account Guide.
Establish what changed (read-only): in Entra, run a difference report in Backup and Recovery and read the audit log entries, which show old and new values. In Okta, run terraform plan against the last known-good commit; the plan is the difference report.
Decide the restore path: soft-deleted object within 30 days: restore from the recycle bin or the Graph deletedItems restore API. Changed supported property within seven days: Entra Backup and Recovery job. Older change or unsupported property: reapply from the exported JSON. Okta: terraform apply of the known-good commit.
Restore dependencies before policies: groups and service principals that a Conditional Access policy or Okta rule targets must exist first. Restoring a policy without its exclusion group can lock out administrators.
Apply in a narrow scope first: recover selected object IDs rather than the whole tenant, or apply one Terraform resource with -target. Destructive: each apply overwrites live configuration and takes effect immediately.
Reissue credentials: re-created applications have no secrets or certificates; issue new ones and update the consuming workloads. A deleted Okta user must be re-created and re-enrolled.
Verify: re-run the difference report or plan until clean, test sign-in for a sample of users and apps, and record the incident.

Roll back a bad restore the same way: the previous night's export or commit is itself a restore point. That is why the backup must be taken before the change window, not after it.

Choosing an approach

Situation	Recommended approach	Trade-off
Small Entra tenant, few admins	Native Backup and Recovery plus nightly Entra Exporter to a private repository	Restores beyond seven days are manual reapplication
Large Entra tenant with change control	Policy-as-code for Conditional Access through Graph, Exporter for everything else, TCM snapshots for multi-workload coverage	Engineering effort; pipeline identity needs careful scoping
Okta org managed in the console	Terraform import with generated config as a read-only backup, applied only in recovery	Drift grows unless plan runs nightly and differences are reviewed
Okta org managed fully as code	Terraform as source of truth, console changes prohibited for managed types	Emergency changes must also go through the pipeline
Third-party SaaS backup product	Evaluate coverage per object type against the tables above	Another privileged integration to govern; see the SaaS Backup Buyer's Guide

Detection and measurement

Entra audit log: watch Add, Update and Delete activities on Conditional Access policies and named locations, authentication methods policy updates, role definition changes, cross-tenant access settings and "Set federation settings on domain". Microsoft notes "Delete group" does not reveal group type, so pair it with your export. The Sensitive operations report workbook flags credential and federation changes. See the Entra ID Sign-In and Audit Log Detection Guide.
Okta System Log: alert on policy.lifecycle.update, policy.rule.update and policy.rule.deactivate, system.idp.lifecycle.create and system.api_token.create, and any change made by an actor other than the Terraform service app for Terraform-managed types. See the Okta System Log Detection Guide.
Nightly drift: a non-empty Git diff or Terraform plan with no matching change ticket is an alert, not just a report.

Metrics:

Days since the last successful export and last successful restore test, per IdP.
Percentage of critical configuration types (from the table above) covered by a backup.
Unticketed configuration changes found by drift detection per month.
Time to restore a deleted Conditional Access policy or Okta sign-on rule in the last test.
Number of identities holding restore rights (Backup Administrator, Terraform manage scopes).

Common failure patterns

Exporting without ever restoring: the JSON exists, but nobody has turned it back into a working policy, and the first attempt is during an incident.
Backup stored in the same blast radius: the repository is writable by the same admin accounts that could be compromised, so an attacker edits history as well as the tenant.
Over-privileged pipeline identity: the export app holds write scopes or Super Administrator because it was easier, creating a standing path to change every policy. Okta API tokens inherit the creator's rights and renew on use, which makes them a poor choice here.
Restoring the policy before its groups: a Conditional Access policy comes back referencing a deleted exclusion group and blocks the admins doing the restore.
Mixed console and Terraform management in Okta: an emergency console fix is reverted by the next scheduled apply.
Forgetting credentials: applications are restored but their secrets are not, and integrations fail hours later.

Where identity fits

The export identity and the restore identity are among the most privileged non-human identities in the estate: one can read every policy, the other can rewrite them. Use separate identities for export (read-only) and restore (write, held in PIM or activated only in recovery), store Okta private keys and Entra certificates in a secrets manager, and review both in access reviews. The isolation principles match those in the Backup Identity Isolation Guide, and Okta service app review is covered in How to audit Okta API tokens and service apps.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	CP-9 System Backup; CP-10 System Recovery and Reconstitution	Configuration exports and tested restore sequence
NIST SP 800-53 Rev 5	CM-2 Baseline Configuration; CM-3 Configuration Change Control; CM-6 Configuration Settings	Known-good state in version control, drift detection
NIST CSF 2.0	PR.DS-11; PR.PS-01; RC.RP-03; RC.RP-05	Backups tested, configuration managed, integrity verified before and after restore
MITRE ATT&CK v20	T1484 Domain or Tenant Policy Modification; T1484.002 Trust Modification; T1531 Account Access Removal	Malicious policy or federation changes and lockout that the backup must undo

Practitioner checklist

Confirm Entra Backup and Recovery is available and assign Backup Reader and Backup Administrator (through PIM) deliberately.
Run the Entra Exporter nightly with a read-only identity into a protected, versioned repository.
Import Okta policies, rules, zones, groups, group rules and apps into Terraform and converge the plan to zero changes.
Authenticate Terraform with an OAuth service app, private key in a secrets manager, custom admin role and minimal scopes.
Store Terraform state remotely, encrypted and versioned.
Document configuration that exports cannot capture.
Test a restore of one Conditional Access policy and one Okta sign-on rule each quarter, including dependent groups.
Alert on unticketed drift and on configuration changes made outside the pipeline.
Include credential reissue in every application restore runbook.

IdP configuration backup and restore for Entra ID and Okta: export, version and recover tenant settings