Identity resilience FAQ

Backupta is an Identity Resilience Platform that helps teams see what changed, investigate the impact and recover identity configurations. It combines backup history, version comparison and controlled recovery so teams can respond to unwanted changes with less manual reconstruction. The goal is to restore the access people and applications need, with a clear record of the recovery actions taken.

Explore the Backupta platform.

Backupta supports Okta, Microsoft Entra ID and Active Directory, along with Microsoft Intune configurations that affect device compliance and access. Intune is an endpoint-management service, not an identity provider. Coverage differs by platform: an object, attribute or recovery workflow supported in one environment is not automatically supported in another. Review the configurations and relationships your organization relies on when defining your protection scope.

See coverage for Okta, Entra ID and Intune, and Active Directory.

A backup preserves information you may need to recover. Identity resilience also involves understanding changes, deciding which state to recover, restoring the required relationships and checking that access works as intended. A completed restore job is one step. The business outcome is that employees, customers and applications can resume the operations they depend on, without bringing unwanted access or configuration back with them.

No. Backupta protects supported identity and Intune configurations; it does not become the identity provider or replace your security stack. Your identity provider continues to authenticate users and enforce access decisions. Security monitoring, endpoint protection and incident response remain necessary. Backupta adds configuration history and recovery context to help teams investigate a change and act on it.

Backupta covers more than 70 Okta object and configuration types, including users, groups, applications, policies, workflows, roles and assignments. Teams can recover supported objects or attributes and their supported relationships rather than reconstructing every setting manually. The exact recovery behavior depends on the object and scenario. During evaluation, test the applications, policies and dependencies that matter to your organization, including what requires a separate recovery step.

See Okta recovery coverage.

Backupta supports recovery of Entra ID users, groups, enterprise applications, app registrations, Conditional Access policies and other supported configurations. Recovery scope varies by object and attribute. For example, protecting authentication-method configuration does not mean recovering a user's MFA secrets. Passwords, certificates and full device restoration are not included in the coverage described on this solution page. Review the required objects, relationships and exclusions before relying on a recovery plan.

See Microsoft Entra ID coverage.

Backupta protects supported Intune configuration profiles, compliance policies and assignments, and preserves BitLocker recovery keys. Configuration history helps IAM and endpoint teams investigate an unwanted change and recover the intended settings. This is configuration protection, not a full backup of a device or its files. After restoring a policy, teams still need to check its assignments, device processing and effect on access.

Read about Backupta for Microsoft Intune.

Backupta can recover users, groups, organizational units, computer accounts and Group Policy Objects, including supported memberships, permissions and policy links. Teams can select the affected objects or attributes and review the recovery scope before applying it. Recovering these relationships reduces the work of researching and rebuilding them manually. Coverage should be checked against the directory configuration and recovery scenario you intend to test.

See Active Directory recovery.

Native recovery can be a useful first option. For example, Active Directory Recycle Bin can restore retained attributes and relationships when enabled, and Microsoft Entra Backup and Recovery restores supported configuration changes within its scope. Backupta adds a shared approach to history, investigation and controlled recovery across its supported environments. Evaluate the gaps that matter to you: object coverage, retention, recovery granularity, dependencies and the options available if the original environment is no longer trusted.

Compare the current AD Recycle Bin documentation and Entra Backup and Recovery scope with your requirements.

Yes, for supported objects and attributes. Backupta lets you define a targeted recovery scope so you can address a specific change while preserving unrelated work. Before applying it, review the selected state and any relationships that also need attention. A small restore can still affect access: changing one group membership or policy may influence several applications or users.

Backupta can include supported dependencies in recovery, such as AD group memberships, permissions and GPO links. This helps reduce manual rebuilding, but does not mean every relationship is recovered automatically. Confirm which dependencies are included, which objects must already exist and which steps remain outside the recovery workflow. The final check is whether the intended access works, not just whether the object is present again.

Start with the operations you need to resume. Your recovery point objective (RPO) defines acceptable data loss measured in time; your recovery time objective (RTO) sets the target time to restore a defined service. Check backup frequency and retention against those needs, then measure the full recovery workflow in a test. Include investigation, review, restoration and access validation. A recent backup is not necessarily a trusted one, and fast object recovery is not the same as fast business recovery.

Backupta brings configuration history and available change-event evidence into the investigation workflow. Teams can review differences, timestamps and actor information where the source records it. This helps narrow the search before choosing a recovery action. Attribution depends on the platform and available audit evidence: a configuration comparison shows what differs, but does not by itself prove who made the change or why.

Yes. Backupta lets teams compare supported configuration versions to identify the changes they want to recover. Use that history alongside the incident timeline and available audit evidence to select an appropriate state. Review the proposed scope before applying it, especially if legitimate work happened after the recovery point. An older version is useful evidence, not automatic proof that the configuration is safe.

Backupta makes changes to supported identity configurations visible over time. Comparing versions helps teams distinguish an approved update from an unexpected difference and identify what needs further investigation. That context can reduce the time spent searching exports or reconstructing a sequence of changes. Drift is not automatically malicious: the team still needs to assess intent, authorization and impact before deciding whether to keep or reverse it.

Yes. For Okta, Backupta supports comparing configurations and promoting validated changes between environments. This helps teams review what will change before applying it to production. Recovery history also provides context when an update needs to be investigated or reversed. The available testing and promotion workflows differ by platform, so confirm support for the specific environment and change types in your release process.

See the Okta solution.

Choose a recovery destination that fits the incident. For Active Directory, Backupta helps build a new forest in your own Azure environment, outside the affected on-premises infrastructure. For supported cloud identity scenarios, continuity can involve a prepared standby tenant. These are different recovery paths, with different prerequisites. In either case, review what you bring back: fresh infrastructure or a separate tenant does not prove that backed-up accounts, permissions or policies are safe.

See AD recovery after compromise and cloud identity continuity.

Yes. In the Active Directory rebuild workflow, you can prioritize the identity resources and supported dependencies needed for a minimum viable environment (MVE). Start with the access required for defined critical operations, validate it, then expand recovery in stages. The directory is only part of that environment. Applications, devices, network services and operational teams may need additional work before the business process can resume.

Recovery restores a selected configuration or service state. Failover moves operations to a prepared alternative environment. A rebuild creates a new environment from recovery data. They are not interchangeable shortcuts. For example, Backupta's AD new-forest path creates new security identifiers (SIDs) and objectGUIDs, so devices, applications, permissions and credentials require reconnection work. A cloud standby tenant also needs preparation and testing before it can support a continuity plan.

Check the recovered configuration, privileged access, memberships, policies and the dependencies needed for the intended service. Test representative sign-in and application workflows, including access that should remain blocked. After a compromise, coordinate this with incident response and review affected credentials and connected systems. Reconnect in controlled stages with a way to stop if checks fail. A successful directory restore alone does not demonstrate that every application is ready or that the incident is contained.

Backupta supports customer control over backup storage and retention policies. The storage location, access model and available settings should be confirmed for your deployment and identity platforms. During security review, document who can read backups, change retention and perform recovery, as well as how recovery access will work if production identity is unavailable. Match those decisions to your organization's data-handling and recovery requirements.

Ask the Backupta technical team for the storage and access documentation applicable to your deployment. Company assurance documents are available through the Backupta Trust Center.

The required permissions depend on the identity platform and the operations you enable. Capturing configuration and restoring changes are different activities, so request the current permission list for both. Review consent, credential handling and administrative access with the team responsible for that environment. Use the documented permissions for your deployment rather than assuming a role name or scope applies to every supported platform.

Backupta provides configuration history, version comparisons and records of recovery activity that can help explain what changed and how the team responded. Available source-event information can add actor and timing context. Use this alongside provider audit logs, approval records and incident evidence to build a fuller account. Agree which records must be retained and exported for your review process; configuration history alone does not establish every action or its intent.

Backupta's Compliance Center supports evidence collection and reporting for compliance reviews. Teams can use identity configuration and recovery records to assess controls and prepare for audits, alongside their other evidence. This supports the compliance process; it does not make an organization compliant automatically. Confirm the reporting scope for your environment and review Backupta's current company assurance documents separately from the controls your organization must operate.

Visit the Backupta Trust Center.

Start by identifying the platforms, tenants or directories and configurations you need to protect. Confirm the required administrative approvals, permissions and deployment prerequisites, then agree storage, retention and recovery responsibilities. The technical steps differ by platform. Verify that the expected data is captured and complete a representative restore before treating the environment as recovery-ready. Active Directory and standby-environment preparation need their own prerequisite review.

Test an incident your team would actually need to handle: an unwanted policy change, a deleted application or a damaged group membership. Check whether you can identify the change, choose an appropriate recovery state, review dependencies and restore the intended access. Measure the manual steps and the full elapsed time. If major-disruption recovery is in scope, also test recovery access, the alternate environment and the work needed to reconnect critical systems.

Backupta offers integration options for collaboration, ticketing, IT service management and SIEM workflows, as well as webhooks and APIs. The events and delivery methods available for your environment need to be confirmed during evaluation. In particular, distinguish a configuration-change alert from a recovery-status notification: support for one does not establish support for the other. Agree who receives each supported signal, when a ticket is needed and what evidence should accompany it.

Backupta's published pricing approach is based on the users or identities protected. Request a quote using your identity providers, estimated counts and intended recovery scope. Confirm how identities are counted across multiple tenants or platforms and what the quote includes, particularly for Active Directory or a standby environment. The evaluation should establish both the commercial scope and the configurations your team expects to recover.

See Backupta pricing.