Identity resilience glossary
Point-in-time recovery
Point-in-time recovery returns data or configuration to a selected earlier state. The available times depend on how the system captures and retains recovery data. Some systems use stored snapshots; others reconstruct a state from a backup and recorded changes. PostgreSQL, for example, can replay archived transaction logs to a chosen recovery target. PostgreSQL point-in-time recovery
In identity systems, the selected state can apply to specific supported objects. It does not have to mean rolling back an entire tenant. Microsoft Entra recovery options
Why it matters
The latest available version may already contain the change that caused an incident. A historical recovery point gives the team another option, but the timestamp alone does not establish that the configuration is safe. Compare the proposed state with incident evidence and the intended access model.
Illustrative identity example
A Microsoft Entra policy change at 14:00 blocks a business application. The team identifies a retained policy version from before the change and reviews it for recovery. With supported selective recovery, valid onboarding changes elsewhere in the directory can remain outside the operation. The team tests the application's access after the policy is recovered.
Common confusion
Point-in-time recovery does not promise restoration to any arbitrary second, preservation of every identifier, or recovery of every dependency. It describes the historical state being selected. Object coverage, recovery scope and available history determine what can actually be restored.