TL;DR: Entra ID recovery often fails when teams restore users and groups but leave behind device identities, Intune policies, and custom security attributes that drive real access decisions, according to Semperis. Recovery that ignores those layers can preserve directory objects while still breaking Conditional Access, endpoint posture, and business access continuity.
At a glance
What this is: This is an analysis of why Entra ID recovery must extend beyond users and groups to include device identities, Intune configuration, and user custom security attributes.
Why it matters: IAM and identity resilience teams need to recover the signals that actually govern access, or they risk restoring accounts without restoring the control plane that makes those accounts usable.
👉 Read Semperis' analysis of Entra ID recovery beyond users and groups
Context
Entra ID recovery is not just about bringing back directory objects. Access decisions in modern tenants depend on device trust, Intune compliance, and user attributes, so a partial restore can leave the identity system technically online but operationally unusable.
That gap matters for hybrid identity programmes because recovery is part of governance, not just backup. If device objects, endpoint policy, or custom attributes are missing after an incident, Conditional Access and application authorisation can fail even when users and groups are present.
Key questions
Q: How should teams recover Entra ID without breaking Conditional Access?
A: Teams should restore the identity signals that Conditional Access actually depends on, not only users and groups. That means device objects, Intune policy state, and any user attributes used in authorisation decisions. Recovery testing should prove that a restored tenant still supports normal access, compliant endpoints, and application decisions before the incident is considered contained.
Q: What breaks when only users and groups are restored in Entra ID?
A: Access can break even though directory objects appear restored. Device trust, endpoint compliance, and attribute-driven application authorisation may remain missing or inconsistent, which means users are present but cannot safely access the systems they need. The result is a tenant that looks recovered while the control plane is still incomplete.
Q: Why do custom security attributes matter in identity recovery?
A: Custom security attributes often carry the business rules that applications use to make access decisions. If those attributes are not restored, accounts may authenticate successfully but still fail authorisation because the downstream system no longer sees the right context. In practice, attribute recovery is part of access continuity, not optional metadata preservation.
Q: Who should own recovery for Entra ID device identities and Intune policies?
A: Identity, endpoint, and platform teams should share ownership, because these controls span authentication, compliance, and access governance. If one team owns only the directory and another owns only the device estate, the restore process can reassemble parts of the environment without restoring the full access model. Joint testing is the only reliable answer.
Technical breakdown
Why device identities are part of Entra ID recovery
Entra ID device objects are not simple inventory records. They participate in authentication and Conditional Access decisions by signalling whether a device is trusted and compliant enough to permit access. In practice, that makes a laptop or phone identity part of the access fabric, not just an endpoint asset. When device objects are deleted, corrupted, or out of sync after an incident, users may lose access even though their directory accounts remain valid. Recovery therefore has to restore the device identity layer alongside user objects so the trust decision can be reconstituted instead of bypassed.
Practical implication: include device object backup and restore in recovery design, not just user and group recovery.
How Intune configuration recovery preserves endpoint trust
Intune configuration policies define the security posture that Conditional Access and compliance checks rely on. These policies are often distributed across multiple object types and API-managed settings, which makes them vulnerable to partial loss, misconfiguration, or mass deletion during an incident. Restoring Intune only at the profile level is not enough if the relationships between policy, compliance, and enforcement are broken. Recovery has to rebuild the policy logic that shapes device behaviour, because endpoint trust is a dependency of identity access rather than a separate admin domain.
Practical implication: back up the policy set, not just the directory, so endpoint compliance and access controls can be restored coherently.
Why custom security attributes are a hidden access dependency
Custom security attributes often carry the fine-grained context that applications use to decide what a user can see or do. Examples include business-unit tags, tenant markers, and access flags that sit outside standard group membership. In multi-tenant or acquisition-heavy environments, these attributes can be more important than the user object itself because they encode organisational logic that applications read at runtime. If they are lost, restored accounts may look valid but still fail authorisation checks. That is why attribute recovery belongs in identity resilience planning, not as a low-priority metadata issue.
Practical implication: identify which attributes drive authorisation and test whether they are recoverable with the same rigor as accounts.
NHI Mgmt Group analysis
Identity recovery that stops at users and groups is structurally incomplete. Entra ID access now depends on multiple signals, including device identity, endpoint posture, and custom attributes. When recovery only restores the directory core, the organisation regains objects but loses the conditions that make those objects usable. The implication is that recovery must be designed around access dependencies, not directory completeness.
Device identity is an NHI recovery problem, not just an endpoint problem. Entra ID device objects behave as non-human identities that participate in authentication and Conditional Access. If they are not recovered with precision, users can be blocked from critical services or forced into weaker trust paths. Practitioners should treat device objects as governed identity assets with their own lifecycle and recoverability requirements.
Custom security attributes create hidden coupling between identity governance and application behaviour. Attributes that appear administrative often carry the decision logic for access in downstream systems. That means a restore can succeed operationally while still failing functionally because the application no longer recognises the user in the same way. The key lesson is that identity resilience has to map the full authorisation dependency chain.
Recovery readiness should be measured by restored access fidelity, not object count. A tenant can look healthy on paper while endpoint compliance, conditional access behaviour, and application entitlements remain broken. That exposes a governance blind spot because many backup programmes still validate object recovery rather than business access restoration. Practitioners should judge recovery by whether the production access model can be reassembled.
Identity resilience in Entra ID is becoming a control-plane discipline. The article shows that backup is no longer enough when identity, device posture, and policy are interdependent. That shifts recovery into the same governance conversation as Conditional Access, lifecycle management, and privileged access. Teams that still separate backup from identity governance will continue to miss the real failure mode.
From our research:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- For a broader identity resilience lens, see NHI Lifecycle Management Guide for the provisioning, rotation, and offboarding controls that keep restore paths governable.
What this signals
Identity recovery is now inseparable from identity governance. As Entra ID takes on more of the access decision burden, the restore problem becomes a control problem. Teams should expect recovery runbooks to expand beyond backup mechanics into Conditional Access, endpoint posture, and authorisation fidelity, with Ultimate Guide to NHIs providing the broader identity context.
Device identity deserves NHI-style treatment in resilience planning. If device objects are part of the access path, then they need the same lifecycle thinking that security teams already apply to service accounts and tokens. The practical signal is simple: if a restore cannot re-establish the trust relationship, the identity has not באמת been recovered. See Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the governance pattern behind that thinking.
Access restoration should be validated as a production control, not a backup metric. The 2026 Infrastructure Identity Survey found that 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, which is a reminder that identity sprawl makes recovery harder, not easier, according to the 2026 Infrastructure Identity Survey. That same structural weakness appears when recovery ignores the non-user signals that enforce access.
For practitioners
- Map access dependencies before defining restore scope. Document which Entra ID device objects, Intune policies, and custom attributes directly influence Conditional Access and application authorisation. Use that map to decide what must be restored together and what can be safely deferred.
- Test recovery against access outcomes, not just object restoration. Run tabletop and technical recovery tests that verify users can sign in, endpoints remain compliant, and downstream applications still read the expected attributes after restore.
- Treat device identities as governed identity assets. Include Entra ID device objects in lifecycle, backup, and restore processes so trust signals survive incidents instead of forcing weaker access exceptions.
- Inventory custom attributes that drive authorisation. Identify user-level attributes that applications consume for tenant separation, business-unit access, or policy routing, then confirm they are part of the recovery design.
Key takeaways
- Entra ID recovery fails when teams restore directory objects but not the signals that drive access decisions.
- Device identities, Intune policy state, and custom attributes are part of the identity control plane, so they belong in recovery scope.
- Recovery testing should prove restored access fidelity, not just successful object restoration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Access decisions depend on restored device and attribute state. |
| NIST Zero Trust (SP 800-207) | AC-4 | Conditional Access and device trust are zero trust enforcement points. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Device identities and attributes behave like governed non-human identity assets. |
Restore identity signals that support access decisions before declaring the tenant recovered.
Key terms
- Device Identity: A device identity is the Entra ID object that represents a laptop, desktop, or mobile endpoint in access decisions. It helps prove the device is trusted and compliant, so it functions as part of the authentication and authorisation path, not just as hardware inventory.
- Conditional Access: Conditional Access is the policy layer that decides whether an access request should succeed based on identity, device, and risk signals. In recovery scenarios, it depends on more than user accounts because the policy needs the same trusted signals that existed before the incident.
- 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 Resilience: Identity resilience is the ability to restore not just accounts, but the access conditions that make identity usable after disruption. It covers backup, restore, policy state, and trust signals across users, devices, and attributes so the business can keep operating after an incident.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by Semperis: Identity building blocks you don’t want to lose in Entra ID recovery. Read the original.
Published by the NHIMG editorial team on 2026-02-24.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org