Who is accountable when Zerologon exploitation is discovered in a production domain?

Why This Matters for Security Teams

Zerologon is not just a vulnerability in a domain controller, it is a test of whether identity operations, patching, and monitoring are treated as a single accountability chain. Once exploitation is confirmed, blame assignment matters less than proving who owned remediation, who verified log coverage, and who could have detected abnormal domain admin changes sooner. NHI Management Group’s 52 NHI Breaches Analysis and NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce the same operational reality: identity compromise is rarely contained to one team’s queue.

In practice, organisations usually discover that domain controller ownership, patch governance, and SOC visibility were split across separate workflows, which makes incident ownership unclear at the exact moment decisive action is needed. The question becomes who had authority to patch, who had authority to validate abuse, and who had authority to declare the domain trustworthy again.

How It Works in Practice

Accountability for discovered Zerologon exploitation should follow control ownership, not just incident response convenience. The domain controller team is accountable for patch deployment, configuration hardening, and verifying that the affected systems are no longer exploitable. Security operations is accountable for monitoring, triage, and evidence collection, including checking for suspicious changes such as event 4742 and related domain admin activity. Identity or infrastructure leadership is accountable for ensuring the remediation plan is executed and that business risk is communicated clearly.

That division aligns with the broader NHI lifecycle discipline described in the NHI Lifecycle Management Guide, where ownership must exist across creation, use, rotation, and retirement of identities and the systems that issue or validate them. In a production domain, the practical sequence is usually:

• confirm exploitability and scope on all domain controllers;
• patch or isolate affected controllers immediately;
• review logs for privileged account resets, replication abuse, and unexpected credential changes;
• validate that backups, trust relationships, and recovery paths are not themselves compromised;
• document who approved remediation and who signed off on return to service.

The reason this matters is that directory compromise often becomes a platform compromise. Attack paths can chain from one weak control to many systems, which is why NHIMG’s Top 10 NHI Issues highlights ownership gaps and stale credentials as recurring failure points. These controls tend to break down when domain administration is outsourced or federated across teams because no single group can see both patch status and privilege misuse end to end.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance speed of remediation against formal change control and forensic preservation. That tradeoff becomes sharper in large enterprises, where regional IT teams may own patching but central security owns detection, and neither can complete the response alone.

There is no universal standard for this yet, but current guidance suggests the accountable party should be the team with operational control over the domain controller estate, while the responsible parties include SOC analysts, incident responders, and identity engineers. If exploitation occurred because patching was delayed, the infrastructure owner is accountable. If it was missed because alerting failed or logs were absent, security monitoring ownership becomes part of the accountability review. If recovery required emergency domain rebuilds, leadership must also evaluate whether the environment had the resilience described in the Ultimate Guide to NHIs.

Edge cases include third-party managed domain controllers, hybrid identity environments, and recovery from suspected domain-wide compromise. In those cases, accountability should be contractually defined before an incident, because post-breach ambiguity usually leads to delayed containment and incomplete evidence handling.

Related resources from NHI Mgmt Group

• Who is accountable for closing backdoors and validating Active Directory before restoring production access?
• Who is accountable when AI-assisted exploitation reaches production before remediation?
• Who should be accountable for securing disconnected applications when access is managed through custom API automation?
• Who is accountable when a supported version reaches end of life and teams have not upgraded?