UAC, integrity levels, and the secure desktop

Security already previewed the key fact this chapter explains fully: being a member of Administrators does not mean your ordinary processes run with full administrative rights. UAC (User Account Control) and MIC (Mandatory Integrity Control) are the two mechanisms that make that separation real.

Two tokens for one admin logon

When an administrator signs in, Windows doesn't hand out one token — for most interactive logons, it creates two:

• A filtered (standard) token — the same user and group SIDs, but with administrative group SIDs (like Administrators) marked deny-only or disabled, and elevated privileges removed. This is the token ordinary processes — a browser, a text editor, Explorer itself — run with by default.
• The full (elevated) token — the unfiltered one, with administrative rights intact, used only when a process is deliberately launched "as administrator."

This split means the everyday act of using the machine happens with meaningfully reduced privilege, even while logged on as an admin — precisely the point. A compromised or buggy ordinary application inherits the filtered token's limited rights, not full administrative control, purely because of which token it happened to be launched with.

What actually happens during a UAC prompt

When a process needs elevated rights, Windows doesn't quietly upgrade its existing token — a running process's token is fixed for its lifetime. Instead, a new process is launched using the full, elevated token, after the user consents (or, for a standard user without admin credentials available, after an administrator explicitly authenticates). That consent UI runs on the secure desktop — the same mechanism Window stations & desktops covers — specifically so an ordinary process on the normal desktop can't spoof, automate, or observe the prompt.

Mandatory Integrity Control: a second, orthogonal axis

MIC adds a completely separate restriction on top of ordinary DACL-based access control: every token carries an integrity level (Low, Medium, High, System, in increasing order of trust), and every securable object can carry an integrity label in its SACL. The rule MIC enforces is simple and absolute: a process cannot write to an object with a higher integrity level than its own token, regardless of what the object's DACL says.

This is genuinely a separate check from the DACL evaluation in Security descriptors & ACLs — a DACL might permissively allow "Everyone: Write" on some system object, and MIC would still block a Low-integrity process (a sandboxed browser tab renderer, for instance) from writing to it, because DACL and integrity are two independent gates a request has to pass, not one.

A worked example: why a browser renderer can't write to your Documents folder DACL notwithstanding

A browser's rendering process, handling untrusted web content, commonly runs at Low integrity specifically so that even a serious exploit in the renderer inherits severely restricted write access — MIC blocks it from writing to Medium-or-higher-integrity locations (which is most of the ordinary filesystem, including a user's own Documents folder) regardless of the folder's actual DACL, which in isolation would happily allow the signed-in user to write there. This is a deliberate defense-in-depth layer: DACLs answer "is this identity generally allowed here," while integrity answers "is this specific, possibly-compromised process trusted enough to write here right now."

A common mistake

Thinking of UAC as "just a popup" undersells what's actually happening structurally: a whole second token, a genuinely separate process, and a hard security boundary (the secure desktop) enforcing that the consent decision itself can't be tampered with by anything running at ordinary integrity. The prompt is the visible tip of a real privilege-separation mechanism, not a standalone annoyance layered on top of an otherwise unchanged security model.

Where this connects

• Privileges (Se*) covers the specific elevated capabilities present in a full token but absent from a filtered one.
• AppContainers & capabilities builds a stricter, newer isolation model on top of the same integrity-level machinery introduced here.