The Windows Security Model: ACLs, Integrity Levels, and UAC

Windows access control is frequently reduced to “administrator vs. standard user,” but the real model layers several independent mechanisms: discretionary ACLs (who is explicitly granted access), mandatory integrity levels (a coarser, non-discretionary ceiling on write access), and UAC (which determines which of a user’s two possible tokens a given process actually runs with). Together they form a defense considerably deeper than a single yes/no permission check.

ACLs and security descriptors

Every securable object — a file, a registry key, a process, a service — carries a security descriptor, containing an owner SID and a DACL (Discretionary Access Control List): an ordered list of Access Control Entries, each granting or denying specific rights to a specific SID.

Get-Acl C:\Data\report.docx | Format-List
icacls C:\Data\report.docx

Evaluation stops at the first matching entry, which is why explicit deny entries are evaluated before allow entries regardless of list order — a design ensuring an explicit deny can never be silently overridden by a broader allow rule appearing later.

icacls C:\Data\report.docx /deny Guests:F

Integrity levels: a mandatory ceiling above ACLs

Since Windows Vista, every process and every securable object also carries an integrity level — Untrusted, Low, Medium (the default for a standard user process), High (elevated/administrator processes), and System. The rule is simple and non-negotiable regardless of what the DACL says: a process cannot write to an object of higher integrity than its own, full stop.

icacls "C:\Users\Public\Downloads" /setintegritylevel Low

This is exactly why a sandboxed browser tab (running at Low integrity) can’t write to your Documents folder even though your user account’s own DACL permissions would normally allow it — the mandatory integrity check happens as an independent gate before the discretionary ACL is even consulted.

When a member of the Administrators group logs in, Windows generates two access tokens: a full-privilege administrator token, and a filtered token with administrative group memberships marked deny-only and high-risk privileges removed. Under UAC, every process the user starts normally gets the filtered token by default — “administrator” and “running with administrator rights” are deliberately not the same thing.

whoami /groups | findstr /i "Deny"

Elevation: swapping in the full token

Clicking “Yes” on a UAC prompt (or Run as Administrator) creates a new process using the full-privilege token instead of the filtered one — it doesn’t retroactively elevate anything already running. This is why a running application can’t silently gain administrator rights mid-execution; the swap only happens at process creation, through a fresh consent prompt each time (unless the executable is specifically manifested to auto-elevate and the user’s UAC level permits it).

Start-Process cmd -Verb RunAs

UAC levels: how much friction the prompt applies

The four UAC slider settings determine when the prompt appears and whether the desktop dims (a secure desktop switch, preventing another process from spoofing the click) — from “always notify, always secure desktop” down to “never notify” (which effectively disables the elevation prompt’s protective value, though the underlying token-splitting mechanism itself still exists).

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name ConsentPromptBehaviorAdmin

Windows Defender: the runtime layer above all of this

Windows Defender (Microsoft Defender Antivirus) operates at a different layer entirely from ACLs/integrity/UAC — it’s a behavioral and signature-based scanning engine, not an access-control mechanism, hooking into the filesystem filter driver stack to inspect files on access and processes on launch:

Get-MpComputerStatus
Get-MpThreatDetection
Start-MpScan -ScanType QuickScan

Its Controlled Folder Access feature is worth calling out specifically because it layers a behavioral allow-list (which specific, named applications may write to protected folders like Documents) on top of the ACL/integrity model already described — a fourth, independent check, not a replacement for the others.

Set-MpPreference -EnableControlledFolderAccess Enabled
Add-MpPreference -ControlledFolderAccessAllowedApplications "C:\Apps\myeditor.exe"

Why layering matters

No single one of these mechanisms is sufficient alone: ACLs alone can’t stop a fully-authorized user’s compromised low-privilege process from overwriting sensitive files (integrity levels close that gap); integrity levels alone say nothing about which specific users or groups should have access in the first place (ACLs still do that job); and neither says anything about a legitimate, correctly-permissioned process turning out to be malware (Defender’s behavioral layer is what catches that). Diagnosing a Windows “access denied” that doesn’t make sense from the ACL alone almost always means checking one of these other two layers next, rather than assuming the permissions must be misconfigured.