Entra ID recovery depends on restoring devices and attributes

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Semperis's blog post: Entra ID recovery must include device identities, Intune configurations, and custom security attributes, not just users and groups.

Why it matters: IAM and identity resilience teams need recovery plans that restore the access signals production depends on, or a tenant can come back online with broken Conditional Access and inconsistent endpoint trust.

Context

Entra ID recovery is not just a directory restore problem. In modern identity programmes, access decisions depend on user accounts, device trust, compliance policy, and user-level attributes that applications read at runtime.

Semperis argues that most disaster recovery planning still over-indexes on users and groups, even though the real access model is wider. That gap matters because a tenant can look restored on paper while the controls that determine whether work can actually continue remain incomplete.

Key questions

Q: What breaks when Entra ID recovery restores users but not device identities?

A: Users may authenticate on paper, but Conditional Access and device-based trust checks can fail because the recovered tenant no longer has the device context it uses to decide whether access is safe. That leaves organisations with accounts present but work still blocked, which is a recovery failure rather than a simple sync issue.

Q: Why do Intune policies matter during identity recovery?

A: Intune policies define the endpoint compliance and configuration posture that many access decisions rely on. If recovery restores directory objects but not policy state, devices may return with incomplete controls, forcing teams to choose between broken access and weakened security. Recovery has to restore the rules, not only the objects.

Q: How do custom security attributes affect access after an Entra ID restore?

A: Custom security attributes often carry the business context that applications use to grant or deny access, such as tenant markers, business-unit tags, or entitlement flags. If those attributes are missing, a user can be restored but still be unusable in practice because the authorisation logic no longer has the data it expects.

Q: What should identity teams include in a tenant recovery plan beyond users and groups?

A: They should include device objects, Intune configuration state, and any custom attributes that applications use in authorisation decisions. That gives the organisation a chance to restore real-world access and posture, not just directory completeness, after an incident or misconfiguration.

Technical breakdown

Why device identities are part of the access plane

Entra ID device objects are non-human identities that represent laptops, desktops, and phones participating in authentication and Conditional Access decisions. When a device is joined to Entra ID, it contributes trust signals that can reduce prompts and support access decisions, especially in managed environments. If those device objects are deleted or corrupted during recovery, the directory may still contain users, but the access plane no longer has the device context it needs to evaluate whether a session should be allowed. That creates a recovery gap between identity data and operational access.

Practical implication: recovery runbooks need to restore device objects alongside users so Conditional Access decisions remain valid.

How Intune configurations shape endpoint recovery

Intune policies define the configuration and compliance posture that many access decisions rely on. They do not just harden endpoints, they also establish the rules that make a device acceptable for work access. In a recovery scenario, losing those policies can leave devices enrolled but effectively unmanaged, which is a different failure mode from losing user accounts. The technical issue is that policy state, not just object state, forms part of the identity control plane. If policy history is missing, the organisation cannot reliably reconstruct the endpoint posture that access rules expect.

Practical implication: restore Intune policy state as part of tenant recovery so posture-based access controls can be enforced again.

Why custom security attributes are recovery dependencies

Custom security attributes are user-level metadata that applications and access logic use to make fine-grained decisions. In multi-tenant and acquisition-heavy environments, they often carry business-unit, tenant, or entitlement markers that are not visible in basic identity restore plans. If those attributes are missing, the user object exists but the authorisation context does not, which can break access in ways that are hard to diagnose. Recovery therefore has to preserve the attribute layer, not just the identity record, because applications depend on that layer to interpret who the user is in business terms.

Practical implication: include custom attribute backup and restore in identity resilience testing, not just object-level recovery.

NHI Mgmt Group analysis

Identity recovery fails when teams treat Entra ID as a user directory rather than an access system. The article shows that users and groups are only the visible part of the control plane. Device objects, Intune state, and custom security attributes all participate in runtime access decisions, so restoring only directory objects creates a false recovery state.

Device trust is now an NHI recovery issue as much as a human identity issue. Entra ID device objects act as non-human identities that influence authentication and Conditional Access. If recovery omits them, the tenant may authenticate people but still lose the machine trust signals that make access usable and secure.

Custom security attributes are the hidden policy substrate of modern identity programmes. They carry the business context applications use to interpret users, especially in complex enterprises. That makes attribute preservation a governance requirement, not a convenience, because losing the attribute layer severs the link between recovered identities and the access logic built on top of them.

Recovery that ignores policy state produces an identity outage after the outage. Intune configurations are not peripheral settings; they are the posture rules that determine whether restored devices remain usable. Practitioners should treat endpoint policy and identity recovery as one resilience problem, because the business impact is the same when access cannot be re-established.

What this signals

Identity recovery is increasingly an access-plane problem, not a backup problem. When Conditional Access depends on device trust and endpoint compliance, recovery has to re-create the trust inputs that made production access work in the first place. Teams that stop at users and groups will continue to see technically successful restores that fail operationally.

Recovery planning now has to follow the same signals the production tenant uses. That means device identity, compliance policy, and user attributes are not edge cases but core dependencies. The practical question is whether the restored tenant can reproduce the same access decisions without forcing policy exceptions.

Custom security attributes deserve the same recovery discipline as directory objects. In many environments, they are the hidden keys that tie identity to business context. If they are not recoverable, the organisation may preserve accounts while losing the authorisation semantics those accounts depend on.

For practitioners

• Map recovery scope to the full access plane Extend Entra ID recovery planning beyond users and groups to include device objects, Intune policy state, and user-level custom attributes that applications depend on for access decisions.
• Test Conditional Access after restore Validate that restored device identities still satisfy Conditional Access rules and do not force emergency policy weakening to bring users back online.
• Preserve custom attribute dependencies Inventory which applications and tenant workflows read user-level custom security attributes, then verify those attributes are included in backup and restore coverage.
• Recover endpoint posture with policy state Treat Intune device configurations as recovery data, not just endpoint management settings, so compliance decisions can be re-established after an incident.

Key takeaways

• The main risk is not losing users and groups, but losing the device and attribute layers that make Entra ID access decisions work.
• Semperis argues that recovery which omits Intune policy and custom attributes can leave organisations with restored accounts but broken operational access.
• Identity resilience testing should prove that restored device trust, endpoint posture, and user attributes can all be reassembled after an incident.

Key terms

• Device Identity: Device identity is the cryptographic proof that a specific machine is the thing being accessed, independent of its IP address or current network. In fleet governance, it allows policy, audit, and revocation to follow the device across locations and transports.
• Intune Device Configuration: Intune device configuration is the policy layer that defines how managed endpoints should behave and whether they are compliant enough for access. During recovery, it must be treated as part of the identity control plane because policy state affects whether restored devices are usable.
• Custom Security Attributes: Custom security attributes are user or application properties used to carry business context into access decisions. They often encode tenant, role, or organisational markers that downstream systems rely on, so losing them can break authorisation even when the account itself is restored.
• Identity Recovery: Identity recovery is the process of restoring identity systems to a trusted state after compromise. It includes containment, forensic validation, removal of persistence, and confirmation that access controls and directory relationships no longer expose the environment.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.