Access Control Entry (ACE) Explained: A Technical Deep Dive for 2026

What is an access control entry? An access control entry (ACE) is a single record inside an access control list (ACL) that grants or denies one trustee — a user, group, or logon session identified by a security identifier (SID) — a specific set of rights on a specific object. Each ACE carries four things: the trustee's SID, an access mask enumerating the rights, a type (allow, deny, or audit), and inheritance flags controlling propagation to child objects. The ACL is the ordered container; the ACE is the atom of authorization inside it.

That one-paragraph definition is easy to find. What is harder to find is a treatment that goes past it — into how the entries are actually structured, why their order changes access decisions, what the two different ACLs in a Windows security descriptor are each for, and why a model this precise still collapses into ungovernable sprawl at enterprise scale. That is what this piece is: a genuine technical deep dive into ACEs, updated for 2026 from our original access control entry deep dive, written for the engineers and analysts who have to reason about effective permissions rather than just click through a Properties dialog.

The ACE model is worth this level of attention because it never went away. NTFS, Active Directory, the Windows registry, services, printers, and file shares all still resolve every access decision through ACEs. NFSv4 imported the model nearly wholesale into Unix filesystems. And cloud IAM — AWS policy statements, Azure role assignments — is best understood as a set of deliberate redesigns of the ACE, keeping the trustee/verdict/rights triple while changing the evaluation semantics. If you govern access anywhere, you are governing ACEs or their descendants.

Anatomy of an ACE: four fields that decide everything

Strip away the tooling and an ACE is a small binary structure with a header and a body. The header declares the ACE type and flags; the body carries the access mask and the trustee SID. Four logical fields do all the work.

The trustee. An ACE never names a user; it stores a SID — the immutable identifier Windows assigns to every security principal. This indirection is why renaming an account never changes its access, and why deleting one leaves permanent debris: the SID stays embedded in every ACE that referenced it, now unresolvable. When a user logs on, Windows builds an access token containing the user's SID plus the SIDs of every group they belong to, directly or transitively. Access checks match ACE SIDs against token SIDs — which means group nesting silently expands who an ACE applies to, a fact that becomes the central scaling problem later in this piece.

The type. Three types matter in practice: ACCESS_ALLOWED_ACE, ACCESS_DENIED_ACE, and SYSTEM_AUDIT_ACE. The first two live in the discretionary ACL and grant or refuse rights; the third lives in the system ACL and generates Security event log entries on matching access attempts. Active Directory adds object-specific variants (ACCESS_ALLOWED_OBJECT_ACE and its deny/audit siblings) that scope the entry to a particular property, property set, or extended right via GUID — this is how AD delegates "reset password but nothing else" at the attribute level. Windows 8 and Server 2012 added callback (conditional) ACE types, which attach a boolean expression over user and device claims — the mechanism underneath Dynamic Access Control.

The access mask. Rights are a 32-bit field. The low 16 bits are object-type-specific rights — for files, things like ReadData, WriteData, AppendData, DeleteChild. Bits 16 through 23 are standard rights common to all securable objects: DELETE, READ_CONTROL (read the security descriptor), WRITE_DAC (modify the DACL), WRITE_OWNER, and SYNCHRONIZE. The top four bits are generic rights — GENERIC_READ, GENERIC_WRITE, GENERIC_EXECUTE, GENERIC_ALL — which the system maps onto bundles of specific rights per object type at check time. Two of the standard rights deserve special respect: WRITE_DAC and WRITE_OWNER are rights about the ACL itself, and granting either is equivalent to granting everything, one step removed. Attack-path tooling in the wild enumerates exactly these edges for a reason.

The inheritance flags. Covered in depth below — they decide whether the entry is a statement about this object, a template for its children, or both.

DACL and SACL: one descriptor, two lists, two jobs

Every securable object in Windows carries a security descriptor with up to four parts: an owner SID, a primary group SID (a POSIX-compatibility vestige), and two ACLs. The two lists share the same ACE machinery but do fundamentally different jobs, and conflating them is the most common conceptual error in this domain.

The DACL is the gate; the SACL is the camera. Hardening one while ignoring the other gives you either unwatched access or well-documented mistakes.

The discretionary ACL (DACL) is what people mean when they say "the permissions." It holds allow and deny ACEs, and it is what the kernel's access check evaluates when a process opens a handle. "Discretionary" is a precise term of art: the owner of the object controls this list at their discretion — which places NTFS firmly in the discretionary access control family, in contrast to mandatory models where a central policy overrides owner intent. Our comparison of mandatory versus discretionary access control covers why that distinction shapes everything downstream, including who can quietly re-share what they were given.

Two DACL edge cases are worth committing to memory because they are opposites that look similar. A NULL DACL — no list at all — means no protection: Windows grants everyone full access. An empty DACL — a list with zero entries — means no grants: everyone is denied, because access must be affirmatively allowed by some ACE. The owner retains implicit READ_CONTROL and WRITE_DAC regardless, which is the designed escape hatch for repairing over-restricted objects. Legacy applications that create objects with NULL DACLs remain a live audit finding in 2026.

The system ACL (SACL) holds audit ACEs. It never grants or denies anything; a matching audit ACE causes the access attempt — success, failure, or both, per the ACE's flags — to be written to the Security event log (object-access events such as 4656 and 4663). Reading or writing the SACL requires SeSecurityPrivilege, and audit ACEs are inert unless object-access auditing is enabled in audit policy — a two-key arrangement that surprises teams who set audit ACEs and then wonder why no events arrive. The asymmetry between the lists is strategic: DACL hygiene limits what can happen, SACL coverage determines what you can prove happened. Compliance frameworks that speak of access enforcement and audit events as separate control families — NIST SP 800-53's AC and AU families being the canonical example — are describing exactly this split.

Evaluation order: why deny does not always win

The single most misunderstood fact about ACEs is that Windows does not evaluate them as an unordered rule set. The access check walks the DACL top to bottom, first-match-wins per requested right, and stops early. Order is semantics.

The algorithm, precisely: the requesting process presents a token full of SIDs and a desired-access mask. The system walks the DACL in order. Each allow ACE whose SID appears in the token contributes its mask bits to the accumulated grant. If a deny ACE whose SID appears in the token covers any requested right not yet granted, the check fails immediately. The walk ends successfully the moment the accumulated grants cover the full requested mask — ACEs below that point are never read. If the list ends with requested rights still ungranted, the result is implicit deny: absence of an allow is itself a refusal.

Predictability comes from canonical order, the convention every well-behaved tool enforces when writing a DACL: explicit ACEs before inherited ACEs; within the explicit group, deny before allow; inherited ACEs ordered nearest parent first, each generation's denies before its allows. Given canonical order, three rules of thumb hold: explicit deny beats explicit allow; explicit allow beats inherited deny — the case that startles people, and the reason a direct grant on a file can punch through a folder-level deny; and closer ancestors beat more distant ones.

The corollary is sharp: a non-canonical ACL — written out of order by a defective script, a raw Win32 call, or a bad migration tool — is not invalid. The kernel evaluates it exactly as ordered, while the permissions UI displays and edits it assuming canonical logic. The result is an object whose real behavior contradicts what every GUI shows. When effective-permission behavior seems haunted, dumping the raw ACE order is the first diagnostic, not the last.

Inheritance: CI, OI, IO, NP, and the flow of entries downhill

Nobody sets ACEs file by file; the model scales by letting container ACEs propagate. Four flags on each ACE steer that flow.

CONTAINER_INHERIT (CI) — child containers (subfolders, registry subkeys) inherit the ACE. OBJECT_INHERIT (OI) — child leaf objects (files) inherit it. INHERIT_ONLY (IO) — the ACE is purely a template for children and is skipped during access checks on the object it sits on; an inherit-only entry on a folder grants nothing on that folder itself, the classic misreading. NO_PROPAGATE_INHERIT (NP) — direct children receive the ACE, but its inheritance flags are cleared on arrival, so it stops after one generation. A fifth flag, INHERITED, is stamped onto every ACE that arrived by propagation rather than direct assignment — it is what icacls renders as (I), and it is how the system distinguishes explicit from inherited entries during canonical ordering.

Propagation is policy. CI, OI, IO, and NP decide where an entry travels — and an inherit-only entry grants nothing where it sits.

Two operational facts complete the picture. First, NTFS inheritance is applied at write time, not evaluated dynamically: when you change a folder's DACL, the system walks the subtree rewriting child descriptors. On a subtree with millions of objects that walk takes real time, and interrupting it leaves the tree half-converged — a genuine source of "permissions are different halfway down" tickets. Second, any object can set SE_DACL_PROTECTED — the "disable inheritance" checkbox — which blocks inherited ACEs entirely. Protected subtrees are where inheritance-based reasoning quietly stops being valid, and every large estate accumulates them.

Reading an ACE in the wild

Theory to practice. Here is a folder DACL as PowerShell presents it:

PS C:\> (Get-Acl -Path 'D:\Finance\Reports').Access

FileSystemRights  : Write
AccessControlType : Deny
IdentityReference : CONTOSO\Contractors
IsInherited       : False
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

FileSystemRights  : ReadAndExecute, Synchronize
AccessControlType : Allow
IdentityReference : CONTOSO\Finance-ReadOnly
IsInherited       : False
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

FileSystemRights  : FullControl
AccessControlType : Allow
IdentityReference : BUILTIN\Administrators
IsInherited       : True
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

Three ACEs, and every field maps to the anatomy above. The first is an explicit deny: members of Contractors cannot write here or anywhere below (CI + OI), even if some nested group membership would otherwise allow it — explicit deny is evaluated first. The second is an explicit allow granting the read/execute bundle; Synchronize rides along because file handles need it, and its absence from the deny ACE is deliberate — denying Synchronize would block far more than writing. The third is inherited (IsInherited : True) from a parent, so it is evaluated after both explicit entries. The same list through icacls D:\Finance\Reports compresses each ACE to a grammar worth learning to sight-read: CONTOSO\Contractors:(OI)(CI)(DENY)(W) and BUILTIN\Administrators:(I)(OI)(CI)(F) — flags in parentheses, then the rights bundle. One level lower still is SDDL, where the inherited admin ACE becomes the string (A;OICIID;FA;;;BA) — rarely hand-written, frequently hand-debugged.

Beyond Windows: POSIX, NFSv4, and the cloud descendants

The ACE concept is portable; the semantics are not, and the differences are exactly where cross-platform permission bugs live.

POSIX ACLs (the draft 1003.1e model implemented by Linux getfacl/setfacl) are the minimalist cousin: named-user and named-group entries carrying only rwx bits, with no deny entries at all — refusal is expressed only by omission — and a mask entry that silently caps the effective rights of every named entry and the owning group. NFSv4 ACLs went the other way and imported the Windows model nearly intact: ordered allow and deny ACEs, fine-grained rights, inheritance flags, and special principals OWNER@, GROUP@, EVERYONE@. Mainframe RACF, meanwhile, reached similar ends by a different architecture — centralized profiles rather than per-object entry lists — covered in our RACF user access control guide.

Cloud IAM is the ACE redesigned with hindsight. An AWS IAM policy statement — Effect, Principal, Action, Resource, Condition — is a trustee/verdict/rights/scope tuple; the deliberate break is evaluation: AWS is order-independent, and an explicit deny anywhere overrides every allow, eliminating the entire class of ordering bugs at the cost of Windows' explicit-allow-over-inherited-deny expressiveness. Azure RBAC role assignments (principal + role definition + scope) are additive allow entries — deny assignments exist but are rare and mostly platform-managed. Conditional ACEs, for their part, were an early step toward attribute-based control, a thread that runs forward into modern RBAC and ABAC models. And where resource ACLs stop, delegated authorization protocols pick up, solving the same who-may-do-what problem one layer up the stack with scoped tokens instead of per-object entries.

Where the ACE model breaks at enterprise scale

Nothing above is broken engineering. ACEs fail at scale for a different reason: the model is perfectly precise per object and has no aggregate view whatsoever.

Per-object precision, zero aggregate view. Nested groups, token bloat, and orphaned SIDs are the tax — governance is the collector.

Group sprawl and nesting. Because ACEs match any SID in the token, and tokens include transitive group memberships, "who can read this folder?" requires expanding every group in every ACE recursively. Estates routinely carry nesting five and more levels deep, with circular memberships and groups whose original purpose nobody can state. Effective access becomes uncomputable by inspection — you need tooling, and the tooling's output goes stale immediately.

Token bloat. The same nesting inflates the token itself. Kerberos tickets carry the SID list in the PAC, and users accumulated into enough groups — over-entitled long-tenure staff being the canonical case — hit the MaxTokenSize ceiling and simply fail to authenticate against some services. Access debt eventually presents as an availability incident, which is a strange and instructive failure mode.

Orphaned SIDs. Deleting a principal cleans up nothing: every ACE referencing the SID persists, now rendering as raw S-1-5-21-… strings. They clutter reviews, destroy audit legibility, and in cross-domain migrations involving SID history can occasionally still resolve to someone.

Drift and divergence. Half-converged inheritance walks, protected subtrees, share-level versus NTFS-level permission mismatches, and years of one-off grants leave the actual ACEs describing a policy no one ever chose. The per-object truth is exact; the estate-level truth is unknowable without continuous reconciliation. This is precisely the gap least-privilege programs exist to close — and why they fail when run as one-time cleanups rather than standing processes.

What Avatier ships toward this pattern

The honest framing: no IGA product replaces ACEs, and vendors who imply otherwise are selling abstraction as substitution. The entries stay on the resources. What a governance layer does is own the intent those entries are supposed to express, and continuously reconcile the two. That is where Avatier's platform sits. Access requests route through workflow with approval and full audit trail, so a new ACE (in practice, a group membership that ACEs already reference) exists because a recorded decision created it. Access certification puts the expanded, human-readable form of current entitlements in front of owners on a cycle, catching the drift that per-object inspection never surfaces. Lifecycle automation — the join/move/leave integration covered in our access governance and user lifecycle management piece — removes memberships at role change and termination, which is the only durable fix for both token bloat and orphaned-SID accumulation, because it deletes the entitlement while the principal still resolves. The compliance posture behind the platform is published at the Avatier Trust Center: SOC 2 Type II audited with zero exceptions noted, ISO/IEC 27001:2022 certified, PCI DSS v4.0.1 compliant, CSA STAR Level 1 attestation, NIST 800-53 Rev. 5 aligned, and a CISA Secure-by-Design Pledge signatory.

What ACE hygiene does not solve

Close with the limits, because they are real. Perfectly canonical, fully governed ACEs still authorize identities, and most 2026 identity compromise arrives through the front door — phished credentials, MFA fatigue, token theft. A pristine DACL grants the attacker exactly what it granted the user they became. ACE hygiene also says nothing about what happens after access: exfiltration by an authorized reader is invisible to the DACL and only faintly visible to the SACL. And no amount of entry-level precision answers the governance question of whether a grant should exist — that judgment lives in role design, certification, and policy, one layer up. The ACE is the enforcement atom, and this piece has argued it deserves to be understood at full resolution. Just do not mistake the atom for the physics: enforcement executes decisions, and the decisions are where access risk is actually won or lost.