Quick Takeaways
- An access control entry (ACE) is a single rule inside an Access Control List (ACL) that grants, denies, or audits a specific set of permissions for one user, group, or computer.
- Every ACE carries four pieces of information: a security identifier (SID), an access mask, an ACE type, and inheritance flags.
- Windows evaluates ACEs top to bottom and stops at the first match, which is why deny entries need to sit above allow entries, otherwise they can get skipped entirely.
- ACEs live inside two different lists with two different jobs: the DACL controls who gets access, and the SACL controls what gets logged.
- A NULL DACL doesn’t mean no access. It means the opposite: everyone gets full access, since there are no rules restricting anything.
Access control entry, defined
An access control entry is a single permission rule that applies to one specific security principal, a user, group, computer account, or service identity, and it specifies what that principal is allowed to do, denied from doing, or what conditions must be met before access is granted.
Think of it less as a whole policy and more as one line item within a policy. On its own, a single ACE says something narrow: “This user can read this file,” or “This group is denied write access to this folder.” It’s the smallest unit of authorization a system actually enforces.
How an ACE fits into an ACL
An ACE never exists in isolation. It’s always housed inside an Access Control List (ACL), which is simply an ordered collection of ACEs attached to a specific object, a file, folder, registry key, Active Directory object, or network resource. Microsoft’s own Win32 documentation describes this same structure: adding an ACE means inserting a new rule into the discretionary access control list attached to that object.
If an ACL is a guest list for a secured event, each ACE is one line on that list: this specific guest, this specific level of access, allowed or denied. The ACL is the container. The ACE is the individual rule inside it.
The four components of an ACE
Every access control entry, regardless of platform, is built from the same four pieces, as documented in technical breakdowns of Windows ACL structure:
- Security Identifier (SID). Identifies the specific user, group, or computer the rule applies to.
- Access mask. A bitmask specifying exactly which rights are being granted or denied, such as read, write, execute, or full control.
- ACE type. Defines what kind of rule this is: access-allowed, access-denied, or system-audit.
- Inheritance flags. Determine whether the rule automatically propagates down to child objects, like files inside a folder that has the ACE applied.
Strip away the platform-specific implementation details, and every ACE is answering the same three questions: who does this apply to, what can they do, and does this rule get passed down to anything underneath it.
DACL vs SACL: two lists, two jobs
ACEs don’t all serve the same purpose, and which list they sit in determines that purpose.
| List | What it controls | What its ACEs contain |
| DACL (Discretionary Access Control List) | Who gets access | Allow and deny ACEs |
| SACL (System Access Control List) | What gets logged | Audit ACEs |
The DACL is the one doing the actual access decision-making: when a user tries to open a file, the system checks their access token against the DACL’s ACEs to decide whether to grant or deny the request. The SACL doesn’t grant or deny anything. It records which access attempts should be written to the security event log, which matters for auditing and detecting unauthorized access after the fact, not for making the access decision itself.
Confusing the two is one of the most common misunderstandings people run into with this topic. A missing or misconfigured DACL entry is an access problem. A missing SACL entry is a visibility problem. They fail in completely different ways.
How ACEs are evaluated (order matters)
This is the part that trips up even experienced administrators: ACEs aren’t evaluated all at once. The kernel reads a DACL from top to bottom and stops at the first match, which is exactly why deny ACEs need to be placed above allow ACEs in the list. If a broad “allow” entry sits above a more specific “deny” entry for the same user, the system matches the allow rule first, grants access, and never even reaches the deny rule underneath it. The deny entry isn’t wrong, it’s just never evaluated. This is also why security tooling and best-practice guides consistently recommend placing deny entries first: it’s not a stylistic preference, it’s how the evaluation logic actually works.
One detail that surprises people the first time they encounter it: a NULL DACL, meaning an object has no DACL at all, doesn’t default to blocking access. It means there are no restrictions whatsoever, so every request is granted. An empty DACL, one that exists but contains zero entries, does the opposite and blocks everyone. The difference between “no list” and “an empty list” is small in wording and enormous in practice.
Real-world example
Take a shared folder used by a finance team. A likely DACL for that folder might contain:
- ACE 1: Deny — Contractors group — Write access
- ACE 2: Allow — Finance Managers group — Full control
- ACE 3: Allow — Finance Team group — Read and write
If a contractor who’s also somehow been added to the Finance Team group tries to save a file, the deny entry at the top of the list matches first and blocks the write attempt, regardless of what the Finance Team allow entry further down would have permitted. This is the deny-before-allow principle working exactly as intended.
Common ACE mistakes to avoid
- Placing allow entries before deny entries. The deny rule becomes dead code that never fires.
- Confusing DACL and SACL responsibilities. Assuming an audit entry restricts access, or that a missing DACL entry will show up in logs.
- Forgetting inheritance implications. An ACE applied at a parent folder with inheritance enabled can silently affect every file and subfolder underneath it.
- Leaving overly broad allow entries in place. “Everyone: Full Control” ACEs are a common finding in security audits, usually left over from initial setup and never tightened.
- Assuming an empty ACL and a missing ACL behave the same way. They produce opposite outcomes: one blocks everyone, the other blocks no one.
Frequently asked questions
What’s the difference between an ACE and an ACL?
An ACL is the full ordered list of rules attached to an object. An ACE is one individual rule inside that list. An ACL is made up of one or more ACEs.
Are ACEs specific to Windows?
The DACL/SACL terminology is specific to Windows and Active Directory, but the underlying concept, a rule binding a user or group to a permission, exists in other systems too, including POSIX file permissions and cloud IAM policies, even though the exact structure and vocabulary differ.
What happens if there’s no DACL on an object at all?
A NULL DACL means no restrictions exist, so every request is granted. This is different from an empty DACL, which has zero entries and denies everyone.
Why do deny ACEs need to come before allow ACEs?
Because the system stops evaluating a DACL at the first matching entry. If an allow entry matches first, the deny entry lower in the list never gets checked.
Can one user be affected by multiple ACEs at once?
Yes, especially through group membership. A user might match a deny ACE tied to one group and an allow ACE tied to another. Whichever entry the system encounters first while reading top to bottom is the one that applies.
Understanding how permissions are actually enforced at this level connects directly to broader security fundamentals. If you’re building toward a security-focused role, it’s worth pairing this with what a network security key does at the network layer, and if you’re newer to the field entirely this honest look at whether cybersecurity is hard to learn is a reasonable next stop.