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.
What belongs in a tenant recovery plan after users and groups?
Directory recovery fails when teams stop at human accounts. A usable tenant recovery plan has to restore the objects and settings that applications, devices, and management planes depend on, so access decisions and security posture come back in a controlled way instead of by manual exception.
Why device objects, policy state, and custom attributes matter
Users and groups tell you who should exist, but not what the tenant can actually trust. Device objects often drive conditional access, compliance checks, and enrollment status. Intune configuration state can determine whether managed endpoints are compliant enough to regain access. Custom attributes matter when applications use them for authorization or routing decisions, because losing them can silently change who can do what.
A recovery plan should therefore inventory the objects and tenant data that influence real-world access decisions, not just the directory entries that are easiest to export. That includes dependencies such as device registrations, policy assignments, app-specific extension data, and any attribute values that downstream systems use to decide whether an identity is allowed through.
What recovery teams need to be able to restore cleanly
The practical question is not “can we recreate the tenant?”, but “can we recreate the operating state that enforces trust?” A tenant can look complete while still being functionally broken if managed devices no longer evaluate correctly, policy objects are missing, or application logic cannot read the attributes it expects. The recovery runbook should define which objects are authoritative, which settings are rehydrated from backup or export, and which values must be validated before access is reopened.
- Restore device objects and confirm they are associated to the right management and compliance state.
- Restore Intune and similar policy configuration so enrollment, compliance, and conditional access behave as expected.
- Restore application-used custom attributes and extension data before re-enabling business workflows that depend on them.
- Verify that policy inheritance, assignment scope, and exceptions match the pre-incident intent, not just the object count.
For broader tenant recovery patterns, the NHI Lifecycle Management Guide is useful because lifecycle completeness is the same recovery problem seen from an identity-operations angle.
Risk and Threat Considerations
Tenant recovery becomes risky when teams restore only directory presence and assume that access control will self-correct. Missing device state, stale policy links, or lost application attributes can create silent over-authorization, failed access, or unmanaged exceptions that persist long after the incident is declared closed.
Failure mechanism: If recovery omits the non-user objects that drive access decisions, applications may fall back to defaults, users may regain access without the intended posture checks, or critical workflows may fail because required attributes are absent.
Impact: The organisation can end up with either excessive access or unnecessary outage, and both outcomes undermine confidence in the recovery process. In the worst case, a “recovered” tenant is operationally live but security-incomplete.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CP-10 — System Recovery and Reconstitution | Tenant recovery must restore systems, objects, and settings to a trusted state. |
| IA-9 — Service Identification and Authentication | Device objects and managed identities affect how non-user entities are authenticated. | |
| Recommendation — Document and test reconstitution steps for directory, policy, and dependent app state. Restore and validate non-user authentication dependencies before reopening access. | ||
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan Execution | This question is about what a recovery plan must include to resume secure operations. |
| Recommendation — Include dependent policy and device-state restoration in the recovery plan. | ||
| ISO/IEC 27001:2022 | A.5.30 — ICT readiness for business continuity | Tenant recovery is an operational continuity exercise for identity-dependent services. |
| Recommendation — Define and test recovery of identity-dependent configuration in continuity plans. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Recovery must preserve identity data, access decisions, and dependent configuration. |
| Recommendation — Restore identity and access dependencies, not just directory records. | ||
Practitioner Guidance
What to verify: Test recovery against real access paths, not just admin console visibility. A good drill proves that a restored device can satisfy policy, a restored app can read the attributes it expects, and a restored user can only access what the current controls permit.
What changes at scale: The bigger the tenant, the more dangerous partial recovery becomes. At scale, one missed attribute schema or one broken device-policy relationship can affect entire populations, so recovery evidence should include object counts, policy assignment checks, and sample end-to-end access tests.
Practitioner takeaway: Treat tenant recovery as restoration of decision-making state, not directory inventory. If an object influences authentication, compliance, or authorization after the incident, it belongs in the plan.
Related resources from NHI Mgmt Group
- How should teams build an Okta disaster recovery plan for critical identity flows?
- What breaks when identity teams rely on logs instead of rollback for tenant recovery?
- How should security teams extend identity controls beyond human users to reduce credential misuse risk?
- How should security teams build recovery for identity tenant configuration before an incident happens?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org