Access control around Active Directory still breaks at the point of access

At a glance

What this is: This is an interview about Active Directory access control, and its key finding is that security still needs to be applied at the point of access, with real-time visibility and contextual controls.

Why it matters: It matters because the same access governance gaps that affect human identity in AD also shape how teams secure service accounts, workloads, and agentic systems as identity expands beyond the directory.

👉 Read IS Decisions's interview on Active Directory access control and Zero Trust

Context

Active Directory remains the control plane for many enterprise identity programmes, but the article argues that directory presence alone does not equal access security. The real problem is that organisations often know who has an identity, yet still cannot see or shape what happens when that identity actually uses access in a session.

That gap matters for IAM, PAM, and lifecycle governance because visibility, context, and enforceable session control are what keep directory access from becoming implicit trust. As identity programmes stretch across humans, workloads, and AI-driven systems, the point-of-access problem becomes more, not less, important.

Key questions

Q: How should security teams control privileged access in Active Directory environments?

A: They should control privileged access at the session level, not only through account provisioning or login events. The key is to observe and constrain what happens after access is granted, using contextual signals and real-time visibility. That approach reduces the chance that a valid identity can perform unsafe actions without detection.

Q: Why do contextual access controls matter more than static rules in Windows environments?

A: Static rules often fail in Windows environments because users work across changing devices, locations, and session types. Contextual controls let teams narrow access based on current conditions, which reduces over-permissioning without forcing every exception into manual approval. That is the practical difference between policy that exists and policy that actually functions.

Q: What do organisations get wrong about identity security in Active Directory?

A: They often treat identity presence as if it were equivalent to access safety. In practice, the risk emerges at the point of use, when access is exercised in a session that may not match the conditions under which the identity was originally authorised. Governance has to reach that moment or it remains incomplete.

Q: Who is accountable for identity security when access data is moved outside the network?

A: The organisation remains accountable for the access risk, even if a cloud provider or external system processes the data. Moving identity telemetry outside the network changes the exposure model, so security, compliance, and architecture teams need to approve that choice as a governance decision, not just a technical convenience.

Technical breakdown

Why Active Directory visibility fails at session level

Active Directory can authenticate and authorise identities, but that is not the same as observing what happens during a live session. Session-level control is where risk accumulates, because a valid identity can still perform unsafe actions if device, location, time, or session context are ignored. The article's core technical point is that security layers need to operate where access is exercised, not just where it is granted. Real-time session visibility is therefore not a monitoring extra. It is the difference between policy on paper and control in practice.

Practical implication: instrument session visibility and control at the access layer, not only at directory or sign-in events.

Why context-based access control beats static rules in Windows environments

Context-based access control uses signals such as device, location, time, and session type to decide whether access should be allowed or restricted. In Windows and AD environments, static rules are often too coarse because they either grant too much or block too much. The article argues for a simpler model that adapts to situation without turning administration into a project. That matters because access control fails when it cannot reflect how work is actually done across remote, hybrid, and mobile conditions.

Practical implication: use contextual signals to narrow access decisions without adding brittle exceptions or heavy administrative overhead.

Why on-premises identity controls still matter for sensitive data

The article makes a clear sovereignty and exposure argument: pushing identity data into the cloud can expand the attack surface. On-premises controls are therefore not a legacy preference by default. For organisations that cannot or do not want to externalise sensitive identity information, keeping enforcement close to Active Directory can reduce data movement and preserve tighter operational control. The technical issue is not cloud versus on-premises in the abstract. It is whether the access control plane stays close enough to the identity source to limit exposure and preserve trust boundaries.

Practical implication: evaluate where identity telemetry and enforcement reside, and avoid exporting sensitive access data without a clear security need.

NHI Mgmt Group analysis

Point-of-access control is the missing layer in many identity programmes: Directory-centric security tells you who exists, but not whether access is being used safely in the moment. That gap becomes more serious as work shifts across devices, locations, and sessions that cannot be managed with static directory rules alone. IAM teams should treat the access session as the real control boundary, not the account record.

Complexity is often the enemy of adoption in access governance: The article's emphasis on simplicity reflects a basic operating truth, not a product slogan. If controls are too complex for admins and users to apply consistently, they become shelfware and the risk remains unchanged. Practitioners should judge access tooling by whether it can actually be used in production at scale.

Identity data locality is a security decision, not just an architecture preference: Moving identity telemetry outside the environment changes who can observe, retain, and potentially misuse that data. For regulated or sovereignty-sensitive organisations, the control plane location is part of the threat model. The implication is that architecture choices must be assessed as governance choices, not only deployment choices.

Active Directory still anchors the human identity estate, but the governance model now has to stretch beyond humans: The same control principles of visibility, context, and least privilege apply when identities are service accounts, workload identities, or AI-driven actors. The lesson is not to abandon AD, but to stop treating directory presence as the endpoint of governance.

Access control at the point of use is a named governance gap, not a feature preference: Security programmes built around authentication events and periodic review assume the risky act happens elsewhere. That assumption fails when the actual exposure is created during the session. Practitioners should redesign controls around the moment access is exercised, because that is where the loss actually occurs.

From our research:

• 57% of organisations lack a complete inventory of their machine identities, according to The Critical Gaps in Machine Identity Management report.
• The same research found that 69% of organisations now have more machine identities than human ones, which means visibility gaps in access governance now affect a larger estate than many teams realise.
• For teams building a broader identity control strategy, NHI Lifecycle Management Guide is the next step for understanding provisioning, rotation, and offboarding across machine identities.

What this signals

Point-of-access governance is becoming the default identity control problem. As identity estates expand beyond humans, teams cannot rely on directory membership or periodic access review alone. The practical shift is toward controls that can evaluate context, session state, and enforcement location at the moment access is used.

The Ultimate Guide to NHIs , Key Challenges and Risks is relevant here because the same visibility and sprawl issues that affect machine identities also show up when human IAM tools are stretched to cover more identities than they were designed to handle. The programme signal is clear: if you cannot see the session, you do not really govern the access.

Identity data locality is becoming a governance decision. Organisations that move access telemetry outside their trust boundary need to account for the additional exposure surface, retention risk, and compliance burden. For teams under regulatory pressure, the architecture choice now has audit consequences, not just infrastructure consequences.

For practitioners

• Map control to the session, not just the identity record Identify which privileged actions are only visible after login and place monitoring or enforcement at the session layer rather than relying on sign-in logs alone.
• Reduce access decision complexity Review whether your access rules depend on too many exceptions, manual approvals, or admin judgement calls, then simplify the policy set so it can be used consistently.
• Treat identity data location as part of the threat model Assess whether sensitive identity telemetry should remain on-premises or be exported, and document the security justification for any external processing.
• Apply contextual signals to Windows access Use device, location, time, and session type as factors for access decisions so that permissions reflect current risk instead of static entitlement alone.

Key takeaways

• Active Directory remains foundational, but directory presence alone does not secure access in the session where risk actually happens.
• Visibility, context, and simplicity are the recurring controls that separate usable access governance from shelfware.
• The main implication for practitioners is to move identity control closer to the point of use and to treat data locality as part of the security design.

Key terms

• Point-of-access control: Point-of-access control is the practice of enforcing security where an identity actually uses access, not just where it authenticates. It focuses on the live session, because that is where misuse, privilege abuse, and contextual risk become visible and actionable.
• Contextual access control: Contextual access control adjusts permission decisions using signals such as device, location, time, and session type. It is more precise than static rules because it reflects current conditions, but it only works when those signals are reliable and operationally enforced.
• Identity data locality: Identity data locality describes where identity telemetry, logs, and enforcement data are stored and processed. It matters because moving that data changes exposure, trust boundaries, and compliance obligations, especially in organisations that need tighter control over sensitive access information.

What's in the full article

IS Decisions's full interview covers the operational detail this post intentionally leaves for the source:

• How the product integrates directly with Active Directory for Windows access control.
• Why the team prefers on-premises deployment for organisations that do not want identity data pushed outside their network.
• What the new UserLock 13.0 interface changes in practice for administrators.
• How the vendor frames simplicity, deployment speed, and pricing for IT teams working in regulated environments.

👉 The full IS Decisions interview covers the company’s access control philosophy, deployment approach, and view of AD security gaps.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.