Notifications
Clear all
Topic starter
06/06/2026 2:14 am
TL;DR: Entra ID recovery has split into two distinct needs: fast restoration after accidental deletion or misconfiguration, and security-centric recovery after malicious changes or logins, according to Semperis. The governance gap is that identity teams must preserve both service continuity and security posture, not just restore objects.
NHIMG editorial — based on content published by Semperis: Evolving Entra ID protection and recovery
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when Entra ID recovery only restores deleted objects?
A: Object-only restore can leave the tenant functionally present but security-inconsistent.
Q: Why do identity recovery and security recovery need different runbooks?
A: They solve different problems.
Q: How do teams know whether Entra ID backup is actually protecting them?
A: A useful test is whether the team can recover a tenant to a known-good security posture after a malicious change, not just after deletion.
Practitioner guidance
- Separate accidental restore from security restore Define one runbook for deleted users, groups, and licenses, and a different runbook for policy drift, privilege tampering, and malicious configuration changes.
- Prioritise recovery of the control plane Restore Conditional Access, privileged role settings, device management policy, and application dependencies before rebuilding lower-value directory objects.
- Test restore order under compromise assumptions Validate which objects must come back first to preserve authorisation, then confirm that the sequence does not reintroduce the weakness the attacker changed.
What's in the full article
Semperis's full article covers the operational detail this post intentionally leaves for the source:
- A side-by-side comparison of DRET and Microsoft Entra Backup and Recovery for different recovery scenarios
- Specific examples of which Entra ID objects require scenario-driven restore versus straightforward backup restore
- Operational guidance on preserving Conditional Access, PIM, and Intune-related security posture during recovery
- The vendor's rationale for choosing different tools based on accidental deletion versus intrusion-driven change
👉 Read Semperis's analysis of Entra ID recovery for accidents and intrusions →
Entra ID recovery and resilience: are your controls keeping up?
Explore further
06/06/2026 3:48 am
Security posture, not object restore, is the real identity recovery problem: Entra ID recovery fails when teams treat directory restoration as the end state. A deleted group can be recreated, but a compromised Conditional Access policy or privilege setting can persist as a live security defect. The lesson is that the unit of recovery is the identity control plane, not just the object.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- That same research shows 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: Who is accountable when malicious identity changes are restored too slowly?
A: Accountability sits with the identity and resilience owners jointly, because delayed recovery affects both service continuity and access control integrity. Frameworks such as the NIST Cybersecurity Framework 2.0 and zero trust governance expect recovery to support both operational restoration and containment.
👉 Read our full editorial: Entra ID resilience now spans accidents and malicious logins
