Active Directory Hardening Evidence for 2026 Audits

The alert came in at 2:17 AM. A high-privilege account, dormant for six months, had just modified a critical Group Policy Object. At almost the same time, the SOC saw multiple Kerberos pre-authentication failures from a workstation subnet. Five minutes later, a certificate was issued from Active Directory Certificate Services to an account that should never have requested one.

Maria, the CISO of a mid-sized fintech firm, knew what this meant. The organization had not simply detected suspicious activity. It had detected a possible attack on the identity control plane.

The investigation showed a familiar path. A threat actor compromised a legacy application server, found plaintext credentials for an old service account, and discovered that the account still had excessive privileges. The GPO change was stopped before it propagated, but the boardroom discussion the next morning was blunt.

“How did this happen?” the CEO asked. “Can we prove to our regulators and clients that our keys to the kingdom are actually controlled?”

That question defines Active Directory hardening in 2026. For many organizations, on-premises or hybrid Active Directory still supports file access, ERP systems, VPN, backup platforms, Windows servers, privileged administration, legacy applications, Kerberos authentication and Entra ID synchronization. If AD falls, the business does not just lose authentication. It loses control.

Regulators and auditors now understand this. Under NIS2, management bodies must approve cybersecurity risk-management measures and may be held liable for infringements. Under DORA, financial entities must manage ICT risk through documented governance, protection, detection, response and recovery capabilities. Under GDPR, organizations must protect personal data using appropriate technical and organizational measures and must be able to demonstrate accountability. Under ISO/IEC 27001:2022, Active Directory risks must be scoped, assessed, treated, monitored and evidenced.

The answer is not another unmanaged checklist. The answer is a defensible evidence model that connects domain controllers, Kerberos, Group Policy, AD CS, privileged access, logging and recovery to the ISMS, risk register, Statement of Applicability, policy framework and audit trail.

Why Active Directory is still a board-level risk

Most Active Directory compromises are not exotic. They usually combine excessive privilege, stale accounts, weak service account hygiene, over-permissive Group Policy, insecure delegation, poor Kerberos configuration, risky certificate templates, unpatched domain controllers, incomplete monitoring and backups that have never been restored.

The compliance impact is direct. If an attacker obtains domain admin rights, they may access personal data, push malicious GPOs, disable security tools, modify logs, tamper with backups, issue certificates for persistence, move laterally into cloud identity paths and disrupt critical services.

ISO/IEC 27001:2022 makes this a governance issue before it becomes a technical issue. Clauses 4.1 to 4.4 require the organization to define context, interested parties, requirements, scope and ISMS processes. For a hybrid identity environment, scope should explicitly include domain controllers, AD CS, privileged admin workstations, backup systems, identity synchronization servers, managed service providers and cloud identity dependencies.

Clauses 5.1 to 5.3 make leadership accountable for policy, resources, roles and reporting. Cleaning up Domain Admins is not just an infrastructure task. It is a management-backed risk treatment decision.

Clauses 6.1.1 to 6.1.3 require a repeatable risk assessment and risk treatment process, including the Statement of Applicability. That is where Active Directory hardening becomes auditable.

[ZB] Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint captures this in the Risk Management phase, Step 13, Risk Treatment Planning and Statement of Applicability:

The SoA is effectively a bridging document : it links your risk assessment/treatment to the actual controls you have. By completing it, you also double-check if you missed any controls.

For Active Directory, that bridge is critical. A risk such as “compromise of AD privileged accounts leading to ransomware deployment and unauthorized access to personal data” can be mapped to privileged access, secure authentication, configuration management, logging, monitoring, backup, incident response and cryptographic controls. The SoA can then explain why each control is applicable, which regulatory obligations it supports and what evidence proves operation.

The Active Directory evidence stack auditors expect

A hardened AD environment is not audit-ready just because settings exist. Screenshots alone are weak. Policies alone are incomplete. A GPO export without approval history is risky. Strong evidence shows governance, implementation, monitoring and improvement.

The maturity gap is usually not the absence of all controls. It is the absence of ownership, review cadence, exception handling and mapping. An auditor will ask not only whether a privileged group exists, but who owns it, who approved membership, when it was last reviewed, what logs are collected and how exceptions expire.

Privileged access: the first AD control to evidence

The fastest route to Active Directory compromise is excessive privilege. Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, local administrators, delegated OU administrators and certificate authority administrators all require explicit governance.

[P11] User Account and Privilege Management Policy User Account and Privilege Management Policy sets the enterprise expectation:

Account repositories (e.g., Active Directory (AD), Identity and Access Management platforms) must be protected by appropriate controls to prevent unauthorized access or tampering.

From section “Governance Requirements”, policy clause 5.6.

[P11S] User Account and Privilege Management Policy - SME User Account and Privilege Management Policy - SME gives a practical approval rule:

Elevated or administrative privileges require additional approval by the General Manager or IT Lead and must be documented, time-bound, and subject to periodic review.

From section “Policy Implementation Requirements”, policy clause 6.2.2.

In [ZC] Zenith Controls: The Cross-Compliance Guide Zenith Controls, ISO/IEC 27002:2022 control 8.2, Privileged access rights, is mapped as a preventive control supporting confidentiality, integrity and availability. The guide connects 8.2 to identity management, access rights, information access restriction, secure authentication, remote working, logging and monitoring. It also maps the control to GDPR Articles 5(1)(f), 25 and 32, NIS2 Article 21 risk management expectations and DORA ICT risk governance for financial entities.

Zenith Blueprint, Controls in Action phase, Step 19, explains the operational expectation:

A.8.2 – Privileged access rights: “The allocation and use of privileged access rights should be restricted and managed.”

Control Admin Accounts super user rights to only those who absolutely need them and manage them carefully. For example, have a separate admin account (not use admin rights for daily work), approve and track who gets domain admin or root privileges regularly. Also, use stronger controls for those accounts (like MFA, logging of their actions).

For AD, an auditor should be able to pick one privileged user and trace the complete story: request, approval, business justification, technical assignment, monitoring, review, removal and exception handling.

A practical privileged access evidence pack should include:

1. Export of privileged AD groups, including nested groups.
2. Named business owner for each privileged group.
3. Evidence of quarterly access review.
4. Separate admin accounts for privileged tasks.
5. No daily-use email or browsing from privileged accounts.
6. MFA or phishing-resistant authentication for privileged access paths where applicable.
7. Privileged workstation or secure admin jump host model.
8. Logging of group membership changes and privileged operations.
9. Break-glass account inventory with compensating controls.
10. Risk acceptance for exceptions, with expiry dates.

This is how Maria closed the immediate service account finding. The account was documented as a high-risk item, the User Account and Privilege Management Policy - SME was used to challenge standing privilege, the application owner identified the minimum required access, Domain Admin membership was removed, and the change was documented through change management. The SoA entry for ISO/IEC 27002:2022 control 8.2 was updated to show risk reduction and mapping to GDPR Article 32 and NIS2 Article 21.

Kerberos and authentication information

Kerberos enables scalable authentication across Windows environments, but weak configuration or poor service account hygiene can enable Kerberoasting, ticket abuse, replay attacks and long-term persistence. Evidence should cover authentication information across its lifecycle: passwords, keys, tickets, service account secrets, certificates, reset processes and MFA factors.

In Zenith Controls, ISO/IEC 27002:2022 control 5.17, Authentication information, is mapped as a preventive control supporting confidentiality, integrity and availability. It connects to identity management, secure authentication, roles and responsibilities, acceptable use, and compliance with policies and standards. The cross-mapping connects it to GDPR risk-appropriate protection against unauthorized access, NIS2 Article 21(2)(j) on MFA or continuous authentication where appropriate, and DORA requirements for robust authentication mechanisms within ICT risk management.

GDPR Article 5(1)(f) requires personal data to be protected against unauthorized or unlawful processing and accidental loss, destruction or damage. Article 5(2) adds accountability. If AD credentials grant access to HR records, customer files or mailboxes, Kerberos and authentication controls become GDPR evidence.

NIS2 Article 21 requires appropriate and proportionate technical, operational and organizational measures, including risk analysis, incident handling, business continuity, supply chain security, secure maintenance, effectiveness assessment, cyber hygiene, cryptography, HR security, access control, asset management and MFA or continuous authentication where appropriate.

For DORA-covered financial entities, authentication dependencies must be considered inside the ICT risk management framework. If AD authenticates staff into payment, trading, insurance, customer or risk systems, Kerberos evidence supports operational resilience.

Group Policy governance and configuration management

Group Policy is one of the most powerful security mechanisms in Active Directory. It can enforce firewalls, local administrator restrictions, audit policy, endpoint protection settings, script execution rules and secure baselines across thousands of systems. It can also weaken those same controls if misused.

In Zenith Controls, ISO/IEC 27002:2022 control 8.9, Configuration management, is mapped as a preventive control for secure configuration. It connects to vulnerability management, change management, asset inventory, endpoint devices, privileged access, secure authentication, logging and monitoring. The guide links configuration management to GDPR Articles 5(1)(f), 25 and 32, NIS2 Article 21 secure configuration and risk management expectations, and DORA ICT system reliability, security and resilience.

[P05S] Change Management Policy - SME Change Management Policy - SME states:

If a change involves sensitive data, system access rights, or external integrations, a security impact review is required. The designated security or compliance contact must assess whether the change introduces additional risks and recommend additional safeguards.

From section “Risk Treatment and Exceptions”, policy clause 7.5.1.

[P05] Change Management Policy Change Management Policy requires:

All change requests, reviews, approvals, and supporting evidence must be recorded in the centralized Change Management System.

From section “Policy Implementation Requirements”, policy clause 6.1.1.

A GPO evidence package should answer four questions:

1. Who owns each security-relevant GPO?
2. Which baseline does it enforce?
3. Who approved changes to it?
4. How is unauthorized drift detected?

Zenith Blueprint, Controls in Action phase, Step 19, gives the baseline approach:

Begin by establishing configuration checklists for all major system types, Windows servers, Linux hosts, network devices, databases, and cloud services. These baselines should reflect both industry best practices (such as CIS Benchmarks) and your internal risk posture.

For AD, that means GPOs should enforce documented baselines, not undocumented preferences. Evidence should include monthly GPO exports, mapping to baseline requirements, change tickets for modifications, delegated permission reviews, GPO backup records and alerts for changes to high-impact GPOs.

AD CS and PKI: the forgotten attack path

Active Directory Certificate Services often escapes compliance reviews because it quietly works in the background. Attackers value it for the same reason. Misconfigured certificate templates, excessive enrollment permissions, weak issuance controls or dangerous Extended Key Usage settings can enable privilege escalation, impersonation and persistence.

AD CS belongs in cryptographic controls, identity management, privileged access and change management. It is not enough to say, “we have PKI.” The organization must know which CAs exist, which certificates can be issued, who can request them, which templates enable client authentication, who administers the CA and whether issuance is monitored.

[P18S] Cryptographic Controls Policy - SME Cryptographic Controls Policy - SME states:

The IT Support Provider must maintain an up-to-date inventory of cryptographic tools and certificates in use

From section “Governance Requirements”, policy clause 5.1.2.

[P18] Cryptographic Controls Policy Cryptographic Controls Policy explicitly includes:

Public Key Infrastructure (PKI)

From section “Policy Implementation Requirements”, policy clause 6.4.

NIS2 Article 21 includes cryptography and encryption policies and procedures. GDPR Article 32 requires security of processing, including confidentiality, integrity, availability and resilience. DORA requires ICT assets supporting financial processes to be protected and recoverable. AD CS can support all of these, or undermine all of them.

Domain controller logging, backup and recovery

Domain controllers are not ordinary servers. They are authentication systems, directory replicas, policy distribution points and recovery-critical assets. If ransomware compromises AD, recovery depends on clean domain controller backups, system state restore, preserved logs, known-good GPOs, AD CS backups, protected private keys and documented recovery procedures.

[P22S] Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME defines authentication log expectations:

Authentication logs: Successful and failed login attempts, session duration, MFA usage

From section “Governance Requirements”, policy clause 5.4.2.

[P22] Logging and Monitoring Policy Logging and Monitoring Policy requires:

All covered systems must generate logs capturing:

From section “Policy Implementation Requirements”, policy clause 6.1.1.

In an AD-dependent environment, covered systems should include domain controllers, AD CS servers, privileged access systems, admin workstations, identity synchronization servers and backup consoles.

Zenith Blueprint, Controls in Action phase, Step 19, is explicit:

Ensure all critical systems (servers, domain controllers, firewalls) are forwarding logs to your SIEM or log collector. Validate that log retention aligns with your logging policy (e.g., 90 days live, 1 year archive). Pick a recent incident or event and demonstrate how you traced it using your logs.

It also highlights clock synchronization, which maps to ISO/IEC 27002:2022 control 8.17, Clock synchronization. Without reliable time, log correlation during an incident becomes fragile.

[P15S] Backup and Restore Policy - SME Backup and Restore Policy - SME sets a minimum evidence expectation:

Restore tests are conducted at least quarterly, and the results are documented to verify recoverability

From section “Governance Requirements”, policy clause 5.3.3.

Relevant ISO/IEC 27002:2022 controls include 8.13 Information backup, 8.15 Logging, 8.16 Monitoring activities, 8.17 Clock synchronization, 5.24 Information security incident management planning and preparation, 5.29 Information security during disruption and 5.30 ICT readiness for business continuity.

A practical recovery evidence pack should include:

1. Domain controller inventory and FSMO role ownership.
2. Backup scope, frequency and immutability evidence.
3. System state backup validation.
4. Quarterly restore test results.
5. GPO backup and restore procedure.
6. AD CS backup and private key protection evidence.
7. Break-glass authentication procedure.
8. Clock synchronization configuration.
9. Incident playbook for AD compromise.
10. Lessons learned from tabletop or technical recovery exercises.

NIS2 Article 23 also matters. Significant incidents may require early warning within 24 hours of awareness, incident notification within 72 hours and a final report no later than one month after the incident notification. If AD outage disrupts essential or important services, recovery evidence and incident timelines become regulatory evidence.

Cross-compliance map for Active Directory hardening

Active Directory hardening is a clear example of one control set supporting many obligations.

For NIS2, this is no longer theoretical. National measures apply to many medium and large essential or important entities in Annex I and Annex II sectors, and also to certain entities regardless of size, including trust service providers, TLD registries, DNS service providers and selected critical services.

For DORA, the timeline is also real. DORA applies from 17 January 2025 and directly covers many financial entities. If an outsourced MSP manages AD, DORA third-party ICT risk requirements become relevant, including contract registers, due diligence, audit rights, incident assistance, security expectations and exit strategies under Articles 28 and 30.

For GDPR, the bridge is accountability. If AD controls access to personal data, privileged access reviews, authentication evidence, logging, configuration baselines, certificate controls and recovery tests help demonstrate appropriate technical and organizational measures.

Build an AD hardening evidence pack in one sprint

A practical two-week sprint can turn fragmented AD hardening into an audit-ready evidence pack.

Day 1 to 2: Scope AD inside the ISMS. Use ISO/IEC 27001:2022 clauses 4.1 to 4.4 to confirm whether AD, Entra Connect, domain controllers, AD CS, privileged admin workstations, backup systems and managed service providers are inside scope. Record interested parties, including regulators, customers, auditors, data subjects, business owners and IT operations.

Day 3 to 4: Add AD risks to the risk register. Include domain controller compromise, excessive privileged access, Kerberos abuse, GPO tampering, AD CS misconfiguration, identity synchronization compromise, backup failure and insufficient logging. Assign owners, likelihood, impact and treatment decisions.

Day 5 to 6: Update the SoA. Following Zenith Blueprint Step 13, mark controls such as privileged access rights, authentication information, configuration management, logging, monitoring, information backup, incident management, cryptographic controls and change management as applicable. Add notes linking them to GDPR Article 32, NIS2 Article 21 and DORA ICT risk management where relevant.

Day 7 to 9: Collect technical evidence. Export privileged groups, Kerberos settings, GPO inventory, domain controller baselines, CA templates, certificate issuance logs, backup job status and SIEM ingestion status. Add owner, date, reviewer, finding and remediation status.

Day 10 to 11: Run a control review workshop. IT, security, compliance and business owners review exceptions. Why does this service account need an SPN? Why can this group edit GPOs? Why can this template issue client authentication certificates? Why is this domain controller missing log forwarding?

Day 12 to 14: Package the audit narrative. Create an AD Hardening Evidence Pack with executive summary, scope, risks, SoA mapping, control evidence, open findings, remediation plan and testing schedule.

The result is a defensible story: we know the risk, we selected controls, we implemented them, we monitor them, we test recovery, and management has visibility.

Common Active Directory audit findings and closure actions

The closure pattern is consistent: policy requirement, technical implementation, evidence capture, review cadence, exception handling and management reporting.

Turn Active Directory hardening into audit-ready evidence

Active Directory hardening in 2026 is not a one-time cleanup. It is a living control system that must be governed, evidenced and improved. Domain controllers, Kerberos, Group Policy, AD CS, privileged access, logging and recovery all sit at the intersection of security operations and regulatory accountability.

Clarysec helps CISOs, IT leaders and compliance teams build that bridge. Use Zenith Blueprint to map AD risks into the ISMS, risk register and Statement of Applicability. Use Zenith Controls to cross-reference ISO/IEC 27002:2022 controls against GDPR, NIS2, DORA, NIST CSF 2.0 and audit expectations. Use Clarysec policy templates, including User Account and Privilege Management Policy, Change Management Policy, Cryptographic Controls Policy, Logging and Monitoring Policy and Backup and Restore Policy - SME, to turn technical hardening into repeatable evidence.

If your next audit, regulator request or customer assurance questionnaire asks how Active Directory is controlled, do not answer with screenshots alone. Build the evidence pack, connect it to risk, and show that management can rely on the identity control plane.

Start with one sprint: privileged access, GPO governance, AD CS review, domain controller logging and restore testing. Clarysec can help you structure it, evidence it and defend it.