Who is accountable for Entra ID recovery and governance when identity changes bypass Infrastructure as Code?

Why This Matters for Security Teams

When identity changes bypass Infrastructure as Code, Entra ID governance stops being a clean deployment problem and becomes an accountability problem. The risk is not just drift. It is missed approvals, untracked privilege escalation, and recovery steps that exist only in tribal knowledge. NIST’s NIST Cybersecurity Framework 2.0 treats identity and access as an operational control area, which is exactly where Entra ID recovery belongs when changes escape the pipeline. NHIMG’s Ultimate Guide to NHIs shows how often identity assets are poorly governed, with only 5.7% of organisations reporting full visibility into service accounts and 97% carrying excessive privileges. That same pattern appears in cloud identity: the break is rarely technical alone, it is ownership confusion. The practical question is who can detect drift, reverse it safely, and prove the restoration did not weaken controls. Identity governance owns the policy, cloud platform owns the implementation path, and security operations should verify and escalate when recovery is needed. In practice, many security teams discover this gap only after a manual change has already altered access or recovery has already become an incident response exercise.

How It Works in Practice

Accountability should be assigned before any recovery is needed, then embedded into the identity operating model. For Entra ID, that means one team owns policy decisions, one team owns the restore process, and both have a shared record of approved break-glass actions. The control objective is simple: if a change bypasses IaC, the organisation must still know who can detect it, who can approve reversal, and who can validate that the tenant returned to a known-good state. A workable model usually includes:

• Drift detection against baseline configuration, using audit logs and configuration review.
• Named owners for privileged roles, conditional access, and directory-wide settings.
• Documented recovery steps for accidental deletion, misconfiguration, and emergency access.
• Formal review of manual changes so they are either codified or removed.
• Escalation paths that separate restore authority from day-to-day admin rights.

This is where NIST SP 800-53 Rev. 5 helps anchor the process, especially around access enforcement, configuration management, and auditability through NIST SP 800-53 Rev 5 Security and Privacy Controls. The operational lesson from NHIMG’s Lifecycle Processes for Managing NHIs is that identity assets need lifecycle ownership, not just initial provisioning. The same logic applies to Entra ID administrative objects, policy artifacts, and privileged assignments. These controls tend to break down when emergency access is granted informally during outages because the restoration path then depends on one person’s memory instead of a repeatable recovery process.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, so organisations must balance fast recovery against control integrity. That tradeoff becomes sharper in large Entra ID environments, mergers, and hybrid identity setups where local admins, legacy scripts, and cloud-native controls all touch the same directory state. Current guidance suggests the following edge cases need explicit ownership:

• Break-glass accounts: security or identity governance should own the guardrails, while platform teams test recovery regularly.
• Temporary exception changes: the business owner may request them, but identity governance should approve expiry and cleanup.
• Hybrid sync issues: cloud recovery and on-premises directory recovery may be different processes with different owners.
• Automation failures: if IaC deployment breaks, the fallback path should not become a permanent manual workflow.

There is no universal standard for naming the accountable team, but best practice is evolving toward a single identity governance owner with delegated execution to platform operations. That is consistent with the broader evidence in NHIMG’s Top 10 NHI Issues, which highlights how missing lifecycle discipline turns access control into a long-term risk. In Entra ID, accountability is strongest when recovery, review, and restoration are assigned to named roles before drift occurs, not after a failed change has already disrupted access.

Related resources from NHI Mgmt Group

• Who is accountable when Infrastructure as Code changes create compliance or security failures?
• Who is accountable when manual identity governance fails to keep up with cloud and SaaS access changes?
• How should security teams prioritise identity governance when cloud, infrastructure, and application access are all changing at once?
• Who should be accountable for access governance when enterprises use a partner to implement identity controls?