Accountability sits with the identity, security, and platform teams that own directory risk, privileged access, and detection coverage. They need a shared control model for authentication, authorization, and activity monitoring. That includes service account governance, policy enforcement, and evidence trails that support audit requirements and incident response.
Why This Matters for Security Teams
Post-authentication access in active directory is not a single-owner problem. Once a user, service account, or workstation is authenticated, the real risk shifts to what that identity can do next, including lateral movement, privilege escalation, and persistence. Accountability therefore sits across identity operations, security engineering, and platform administration, with clear ownership for policy, monitoring, and remediation. The control gap is especially visible where service accounts are over-permissioned or rarely reviewed, which is why the Ultimate Guide to NHIs remains a useful baseline for teams formalising governance.
This is also where traditional perimeter thinking breaks down. Active Directory may authenticate the subject, but it does not by itself govern every action after login or token issuance. NIST’s SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for access enforcement, auditability, and continuous monitoring rather than relying on sign-in alone. In practice, many security teams discover post-authentication abuse only after a privileged session has already been used to move laterally or alter directory objects.
How It Works in Practice
Accountability in Active Directory works best when it is split into three linked responsibilities. Identity teams own account lifecycle, group membership, tiering, and service account governance. Security teams own detection logic, alert triage, and evidence retention. Platform teams own domain controller configuration, authentication policy, and enforcement of privilege boundaries. That division is important because post-authentication risk is not just about who signed in, but what the directory allows next.
Operationally, teams should treat post-authentication access as a control chain rather than a single control. A practical model includes:
- Least privilege for users, admins, and service accounts, with regular entitlement review.
- Privileged Access Management for elevated sessions so admin rights are not always on.
- Conditional or context-aware restrictions for sensitive actions, especially where tiering is in place.
- Monitoring of directory changes, Kerberos activity, group modification, and unusual service account behaviour.
- Clear evidence trails for who approved access, who used it, and what changed.
The OWASP Non-Human Identity Top 10 is useful here because many AD environments still treat service accounts as background utilities rather than governed identities. NHIMG’s 52 NHI Breaches Analysis shows how weak credential control and poor visibility repeatedly become incident drivers. The practical lesson is simple: post-authentication access must be owned, logged, and reviewed like any other high-risk control surface. These controls tend to break down in heavily nested group structures because effective privilege becomes difficult to calculate quickly and accurately.
Common Variations and Edge Cases
Tighter post-authentication control often increases administrative overhead, so organisations have to balance stronger containment against operational speed. That tradeoff is most obvious in environments with legacy applications, entrenched service accounts, and complex group nesting, where changing one permission can break multiple dependent systems. Current guidance suggests prioritising the highest-risk paths first rather than attempting a full-directory redesign in one step.
There is no universal standard for this yet, but good practice is evolving toward separate accountability for authentication, authorisation, and monitoring. In flat AD estates, one platform team may carry most of the load; in larger enterprises, responsibility is often shared across identity engineering, SecOps, and infrastructure operations. The key is that ownership must be explicit, measurable, and tied to action, not assumed by default.
For organisations seeking a governance anchor, the Ultimate Guide to NHIs standards section helps frame lifecycle and visibility expectations, while ISO’s ISO/IEC 27001:2022 Information Security Management supports the broader need for defined responsibility and evidence. In practice, the hardest edge case is not a missing policy but an access path that no one can clearly attribute to a single owner.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Defines governance for non-human and service account access after authentication. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access permissions and enforcement across authenticated identities. |
| NIST SP 800-53 Rev 5 | AC-2 | Covers account management, including review and removal of unnecessary access. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust limits what authenticated users can do after access is granted. |
Assign explicit owners for every service account and review post-authentication permissions regularly.
Related resources from NHI Mgmt Group
- Who is accountable for controlling Active Directory sprawl and access creep?
- Who is accountable when non-employee access is not governed properly in regulated environments?
- Who is accountable for governing third-party, non-employee, and machine access in public sector cloud environments?
- Who is accountable when directory synchronisation does not match the organisation's access model?
