Identity resilience glossary
Identity resilience glossary
Clear explanations of the identity, backup and recovery terms used in resilience planning.
C
- Configuration drift
- Configuration drift is a difference between a system's actual configuration and its intended or approved baseline. In identity environments, this can affect access policies, group assignments, application settings, or other configurations that shape access. The baseline might be an approved configuration record or a definition managed through code. HashiCorp's drift guidance describes the same distinction between actual infrastructure and intended configuration.
D
- Dependency-aware recovery
- Dependency-aware recovery is a descriptive term for recovery that considers the relationships needed for restored objects to work as intended. It includes identifying dependencies, accounting for recovery order where necessary, and validating the resulting connections. The term does not by itself establish a universal standard, certification or fixed set of capabilities.
G
- Granular recovery
- Granular recovery restores a selected part of an environment instead of rolling back the whole environment. The recovery unit might be an individual object, a group of objects, or a particular attribute or relationship where the recovery method supports that level of selection. Microsoft's Entra recovery documentation, for example, distinguishes recovery of all supported objects from selection by object type or object ID. Microsoft recovery scope
I
- Identity backup
- Identity backup is the practice of preserving copies of identity data and configuration so teams have a previous state available for investigation or recovery. Depending on the platform and backup method, that scope can include users, groups, application settings, access policies, and relationships between objects. Coverage must be stated explicitly; the word “backup” does not mean every identity object, attribute, or secret is included.
- Identity provider (IdP)
- An identity provider (IdP) is a service that authenticates a user and provides an application with evidence of that authentication. In a federated sign-in, the application relies on an assertion or token from the IdP instead of verifying the user's authenticator itself. The application is called a relying party. NIST's federation guidance defines these roles and their trust relationship.
- Identity resilience
- Identity resilience is an organization's ability to prepare for identity-related disruption, limit its impact, and restore trusted access and identity operations. It applies to the systems, people, and procedures that support authentication and access. NIST's cyber-resilient systems guidance provides the broader foundation.
P
- 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
R
- Recovery point objective (RPO)
- A recovery point objective, or RPO, is the maximum acceptable data loss measured in time. It defines how far back the organization can tolerate returning when recovering after a disruption. For identity configuration, the potential loss includes changes made after the last usable recovery point. NIST RPO definition, AWS recovery objectives
- Recovery time objective (RTO)
- A recovery time objective, or RTO, is the target maximum time for restoring a defined service after a disruption. It expresses how much downtime the organization is prepared to tolerate for that service. Business needs set the objective; the recovery approach must then be tested against it. NIST RTO definition, Google Cloud disaster recovery planning
T
- Tier 0 identity infrastructure
- Tier 0 identity infrastructure refers to systems, administrative identities, and dependencies that can control the identity foundation on which other access decisions rely. In Microsoft's Active Directory Domain Services tier model, examples include domain controllers and the accounts and supporting systems able to control them. The classification follows effective control, not simply an asset's name or business importance. Microsoft's AD DS tier guidance.