Parag Mali - tag: administrator-protection

The Integrity-Level Stack: MIC, UIPI, and Twenty Years of UAC's Quiet Plumbing

noreply@paragmali.com (Parag Mali) — Sun, 31 May 2026 00:00:00 GMT

**UAC has never been the consent prompt.** Two Vista-era primitives, Mandatory Integrity Control (MIC) and User Interface Privilege Isolation (UIPI), add an integrity axis to the access check and a windowing-layer analog that blocks cross-IL message injection. The split-token model gives every administrator a Medium-IL filtered token at logon and holds the full admin token dormant. The yellow dialog is the smallest part of the system. Its architect, Mark Russinovich, publicly disclaimed it as "not a security boundary" in February 2007, and twenty years of bypass research has been the empirical confirmation. In November 2024, Microsoft finally moved the boundary line with Administrator Protection. The MIC + UIPI plumbing outlived UAC itself: it is still the substrate of every browser sandbox, every AppContainer, and the Adminless successor in 2026.

1. Two whoami Outputs, Sixty Seconds Apart

Open an unelevated PowerShell on a Windows 11 administrator account. Run whoami /groups /priv. Click "Yes" on the yellow prompt. Open an elevated PowerShell on the same account. Run the same command. The two outputs are different lists of SIDs. Sixty seconds have passed. The consent prompt did not move a single bit of OS state on its own. The operating system did, because of a stack of primitives that ship with every Windows install and that almost no Windows user has ever heard the names of. This article is a tour of that stack, and of what twenty years of bypass research has taught us about it.

Place the two outputs side by side. The user is the same. The session is the same. The clock has barely moved. Read them carefully.

PS C:\Users\admin> whoami /groups /priv | findstr /i "Mandatory Administrators SeDebug"
BUILTIN\Administrators                Group used for deny only
Mandatory Label\Medium Mandatory Level Label
(SeDebugPrivilege not present)

PS C:\Users\admin> whoami /groups /priv | findstr /i "Mandatory Administrators SeDebug"
BUILTIN\Administrators                Enabled by default, Enabled group, Group owner
Mandatory Label\High Mandatory Level   Label
SeDebugPrivilege                       Disabled

Four facts fall out of those two outputs, and each one of them is a foothold for the rest of this article.

The first fact is that the administrator group SID is present in both tokens. It is not added by the elevation. In the filtered token it carries the flag SE_GROUP_USE_FOR_DENY_ONLY, which means the access-check algorithm consults it only when matching a deny ACE and otherwise pretends it is absent [@uac-how-it-works]. In the elevated token, the same SID is fully enabled. The dialog did not add a SID; it changed which token Windows uses.

The second fact is the integrity level. In the filtered token, the mandatory label reads Mandatory Label\Medium Mandatory Level. In the elevated token, the same label reads Mandatory Label\High Mandatory Level. That label corresponds to a well-known SID under the S-1-16-X family (S-1-16-8192 for Medium and S-1-16-12288 for High) [@well-known-sids]. The integrity level is not a regular group SID. It is a separate field on the token, and as we will see in §4, it drives a separate access-check evaluator that runs before the discretionary access check [@mic-doc].

The third fact is the privilege set. The filtered token holds a small set of user-mode privileges (SeChangeNotifyPrivilege, SeShutdownPrivilege, a handful of others). The elevated token holds the full administrator privilege set, including the named ones the security press writes about: SeDebugPrivilege, SeTakeOwnershipPrivilege, SeLoadDriverPrivilege, SeBackupPrivilege, SeAssignPrimaryTokenPrivilege, and twenty or so others, depending on the Windows build [@russinovich-tnm-2007].

The fourth fact is the most subtle, and the one this whole article exists to make rigorous. The yellow dialog did not create the elevated token. The OS created it at logon, almost half an hour before the prompt ever rendered, and held it dormant in the LSA. The prompt asked the user a single question: may I, the operating system, use the token I already have? It did not ask: may I, the operating system, mint a more privileged token now? That distinction is the difference between how every Windows user talks about UAC and how UAC actually works.

Note: The yellow dialog moves no bits. It asks permission to use authority that was already constructed at logon and held dormant. The integrity primitives, MIC and UIPI, do the bounding work whether or not a prompt ever renders.

The four primitives we are about to tour are the substrate beneath everything in those two whoami outputs. Mandatory Integrity Control (MIC) is the access-check evaluator that decided your Medium-IL PowerShell could not write into %SystemRoot%\System32 before any DACL was consulted. User Interface Privilege Isolation (UIPI) is the windowing-layer analog that prevented your Medium-IL Edge tab from injecting WM_SETTEXT into the High-IL elevated PowerShell next to it. The split-token model is the LSA policy that decided your interactive shell should hold the Medium-IL token instead of the High-IL one. The Application Information service (Appinfo) is the SYSTEM-trusted broker that mediated the token swap when you clicked "Yes."

This article walks every one of those layers, then ends at the empirical proof: twenty years of "UAC bypasses," and Microsoft's own quiet acknowledgement, from week one, that the dialog was never the security boundary [@russinovich-blog-2007]. Why did Microsoft build this stack in the first place? What was wrong with how Windows XP did it?

2. The XP Problem and the Vista Bet

On the overwhelming majority of consumer Windows XP installs in 2003, every process the user launched ran as Administrator, because the first interactive account XP provisioned at setup was an Administrator and the typical user never created a separate Limited User account [@margosis-archive]. Every browser tab. Every embedded Word macro. Every drive-by download. The operational vulnerability surface was the entire OS, because authority on Windows is carried in the access token, and the access token of those XP-era user processes held the full administrator SID set.

Sysinternals co-founder Mark Russinovich, then a Microsoft engineer following the 2006 Winternals acquisition, framed the problem precisely in the June 2007 issue of TechNet Magazine: "Most users of Windows XP run with full administrative rights all the time, allowing all software they run, including malware, to have unrestricted access to the system" [@russinovich-tnm-2007]. The sentence reads like a confession, and it was. The OS shipped with a sound access-control model and an operational policy that defeated it from the first reboot.

Two distinct threat models drove the architectural response Vista shipped four years later.

Threat model one: the runaway admin

The first threat model was the runaway admin. Default-admin consumer installs meant malware silently inherited admin authority because the user was the admin. A drive-by exploit in Internet Explorer ran as the user, the user was an admin, and the malware was an admin. There was no point in the OS where a least-privilege boundary could intervene, because the token never carried a least-privilege bound to begin with. The DACLs were correct; the policy that filled the tokens was the failure.

Threat model two: the shatter-attack class

The second threat model was the shatter-attack class. In August 2002, security researcher Chris Paget published a paper titled "Exploiting design flaws in the Win32 API for privilege escalation" on the Bugtraq mailing list, immediately mirrored on Help Net Security [@helpnet-paget]. The paper coined the term shatter attack and demonstrated that on Windows NT, 2000, and XP, any process running on a user's interactive desktop could send a WM_TIMER message carrying a callback function pointer to any other process's message loop on the same desktop. The receiving process would invoke the callback in its own address space, at its own privilege level [@shatter-wiki].

The shatter-attack term is sometimes attributed to Brett Moore alone. Paget's August 2002 Bugtraq paper actually coined the term; Moore's Black Hat USA 2004 talk Shoot The Messenger: Win32 Shatter Attacks productised the technique class and brought it to a wider conference audience. Both attributions are correct for different artifacts.

This was an architectural defect. The receiving process did not authenticate the message origin. It could not, because the Win32 messaging system was designed in the late 1980s under the assumption that all windows on a desktop belonged to one trust principal. By 2002, that assumption had been false for a decade: services ran on the user's interactive desktop with LocalSystem authority, and the user's browser could send them messages.

Microsoft's December 2002 patch (security bulletin MS02-071) fixed individual services that exposed the most exploitable callbacks. It did not fix the architectural class, because the class was a property of the Win32 messaging design, not of any one service [@shatter-wiki].

The popular history of the shatter-attack class collapses two separate authorship events into one. Chris Paget's August 2002 Bugtraq paper coined the term and produced the original demonstration tool (which Paget called "Shatter") [@helpnet-paget]. Brett Moore's Black Hat USA 2004 talk *Shoot The Messenger: Win32 Shatter Attacks*, eighteen months later, productised the technique into a conference-grade reference talk and contributed additional disclosure work at Security-Assessment.com.

Both attributions are accurate for different artifacts: Paget for the term and the August 2002 paper, Moore for the Black Hat 2004 productisation. The Wikipedia Shatter attack article preserves both authorships verbatim [@shatter-wiki]. The reason the disambiguation matters: any historical account of Vista's UIPI design decision must attribute the threat-model framing correctly, because Microsoft cited Paget's 2002 paper, not Moore's 2004 talk, in the internal architectural discussions Russinovich later summarised [@russinovich-blog-2007].

The Vista bet, stated as four design decisions

Between 2005 and 2006, Microsoft made four decisions about how Vista would respond. The first was to split the administrator's authority by default: an admin user would not hold a single admin token at logon, but a filtered token plus a dormant linked one. The second was to mediate the recombination through an OS-controlled UI surface, so the user could see and consent to the moment authority crossed an integrity boundary. The third was to add a second access-check axis (integrity) that the DACL could not override. The fourth was to add a windowing-layer analog to close the cross-IL variant of the shatter-attack class.

All four shipped together. Vista RTM'd on November 8, 2006 to OEMs and businesses, and Microsoft launched it to consumers on January 30, 2007 [@vista-press-release]. The press release called it "the most significant product launch in Microsoft Corp.'s history."

The architectural canon was published five months later, in the June 2007 issue of TechNet Magazine under the title Security: Inside Windows Vista User Account Control [@russinovich-tnm-2007]. The author was Russinovich, and the article became the single most-cited primary on UAC in the Windows-security literature. Five months earlier, however, in a TechNet Blogs post about PsExec, the same author had quietly written something the entire later debate would rest on, and almost no one read it for what it actually said [@russinovich-blog-2007]. We will return to that post in §7. First, the harder question: why couldn't NT's existing access-control model handle any of this on its own?

3. Why the DACL and the Privilege Were Not Enough

Windows NT had the access-control model from day one. It had Security Identifiers (SIDs), access tokens, discretionary access control lists (DACLs), privileges, and an access-check algorithm with a name (SeAccessCheck) that the kernel exposed and documented [@access-control][@windows-internals]. The model was correct in theory and broken in practice. To see why, watch what happens when an XP administrator opens a malicious Word document.

The user double-clicks the document. Word starts. Word loads the document's embedded macro. The macro calls URLDownloadToFile and writes evil.exe into %TEMP%. Then it calls CreateProcess on evil.exe. The new process inherits its parent's primary access token, which is the user's interactive token, which carries the administrator group SID, enabled, with the full administrator privilege set. The DACL on HKLM\SYSTEM\CurrentControlSet\Services grants Full Control to BUILTIN\Administrators. The malware writes a new service entry. The malware now persists across reboots, all without a single elevation prompt, because there was no elevation transition to prompt at. The user was already the administrator [@russinovich-tnm-2007].

The first problem is in the D of DACL. Discretionary access control lists are discretionary by definition: the owning principal of an object decides who has access [@dacls-control]. An attacker running as the user can rewrite any DACL the user owns. That is not a bug; it is the meaning of the word discretionary. Mandatory access-control models (Bell-LaPadula 1973 [@blp-wiki], Biba 1977 [@biba-wiki]) exist precisely because discretionary models cannot defend against principals running with the owner's authority.

The second problem is in the privilege model. A Windows access token carries a list of named privileges such as SeDebugPrivilege, SeTakeOwnershipPrivilege, SeLoadDriverPrivilege. Each privilege is a per-token authorisation to bypass some specific DACL check. An admin token holds them all. There is no way in the NT 4.0 / 2000 / XP design to say "this Word process holds the admin's identity but should not be trusted to use SeDebugPrivilege." Privileges are granted to tokens at logon, and the only way to remove them from a downstream process is to construct a restricted token explicitly, by hand, with CreateRestrictedToken [@createrestrictedtoken].

Generation 1: the seven-year failure to make least-privilege voluntary

Between 1999 and 2006, Microsoft and the Windows security community tried five different ways to make least privilege voluntary. None of them worked at consumer scale.

CreateRestrictedToken is a Win32 API, documented since Windows XP and Server 2003, that produces a copy of an existing access token with selected SIDs marked deny-only, selected privileges removed, and an optional list of restricting SIDs added [@createrestrictedtoken]. It is the kernel primitive every later sandbox (Chromium's renderer sandbox, AppContainer, Office Protected View) is built on. It was a primitive, not a policy. A consumer install with default-admin logons could not use it without an opt-in from every application vendor.

runas.exe, shipped in Windows 2000, let a user explicitly launch a process under a different identity. The user was supposed to log in as a standard user and runas an administrator account when needed. In practice, the user logged in as the administrator and forgot the standard account existed.

Software Restriction Policies (SRP), shipped with Windows XP, let a domain admin define hash, path, certificate, or zone rules that the OS enforced at process creation [@srp-2003]. SRP was a policy mechanism on top of the SAFER substrate [@winsafer]. It worked when configured. On consumer Windows it was off by default; on enterprise Windows it was configured by the few who knew it existed.

Aaron Margosis, then a Microsoft consultant, ran a years-long blog campaign called "Non-Admin" arguing that ordinary users should log in as standard users and only elevate when necessary. His tooling included LUA Buglight (which diagnosed which OS calls a misbehaving application made that required admin privilege), MakeMeAdmin (a runas shim), and PrivBar (a status-bar widget that displayed the IL of the current process) [@margosis-archive]. The blog became required reading inside Microsoft and the Windows-admin community.

Margosis's writing documents the daily friction of being a non-admin on XP. A printer-driver installer fails because it writes a per-user setting to `HKLM`. A game launcher fails because it writes save files to `%ProgramFiles%`. A 1998 line-of-business app fails because it stores its INI file under its install directory. Each failure was the application's fault; in aggregate, the application population rendered non-admin operation untenable for the typical user [@margosis-archive].

Margosis's own pattern, openly discussed on the blog, was to give up on per-application diagnosis and log in as Administrator full-time, while documenting the friction professionally so Microsoft could harvest the data for Vista's compatibility shims. The primitives existed (CreateRestrictedToken, SRP, the SAFER substrate). The third-party software base rendered them unusable. That dataset is the reason Vista shipped file and registry virtualisation as a built-in shim [@russinovich-tnm-2007]: the only alternative was for every application vendor to fix their software, and Margosis's blog had documented for half a decade that this was not happening.

The lesson Microsoft took from the 1999-2006 experience was that voluntary least privilege does not scale. You cannot solve the runaway-admin problem with policy and exhortation. You need an architectural primitive that runs by default, bounds authority by integrity rather than by identity, and absorbs the legacy of applications written for unrestricted admin without breaking them. All four primitives of the Vista bet shipped together in November 2006 [@vista-press-release].

What does an integrity primitive look like, and how is it different from "another ACE"?

4. The Twin Primitives: MIC and UIPI

4.1 Mandatory Integrity Control

An access-check evaluator that compares the integrity level of a subject token to the integrity level of a target object before consulting the object's DACL. MIC denials short-circuit the access check; a Low-IL principal cannot write to a Medium-IL object regardless of what the DACL says.

The load-bearing fact about MIC is in a single sentence on the Microsoft Learn reference page, and the entire architectural difference between MIC and "just another ACE" lives in that sentence. MIC "evaluates access before access checks against an object's discretionary access control list (DACL) are evaluated" [@mic-doc].

Pause on that ordering. Before the DACL. Not together with it. Not after it. The integrity-level check is a separate evaluator that runs first, and its denial is final. If the IL check denies access, the DACL is never consulted, no matter what the DACL says. That is what the word mandatory in Mandatory Integrity Control means.

A well-known SID, carried on every Windows access token and every securable object, that orders subjects and objects on a seven-level integrity lattice (Untrusted, Low, Medium, Medium Plus, High, System, Protected Process).

The seven well-known integrity-level SIDs are defined in the Well-known SIDs reference page on Microsoft Learn [@well-known-sids].

Integrity level	RID (S-1-16-X)	Typical use
Untrusted	`S-1-16-0`	Most-restricted sandboxes; rare on consumer Windows
Low	`S-1-16-4096`	IE Protected Mode, AppContainer, Edge / Chrome renderers
Medium	`S-1-16-8192`	Default for interactive user processes
Medium Plus	`S-1-16-8448`	UI-Access processes (`uiAccess=true` manifest, Windows 7+)
High	`S-1-16-12288`	Elevated administrative processes
System	`S-1-16-16384`	Kernel-mode and `LocalSystem` services
Protected Process	`S-1-16-20480`	PPL-protected processes (LSASS with `RunAsPPL`, antimalware)

The Microsoft Learn MIC reference page describes the operational set as four integrity levels (low, medium, high, system) [@mic-doc]. The Well-known SIDs reference page enumerates seven [@well-known-sids]. Both framings are correct: Untrusted is rare on consumer systems, Medium Plus is a UI-Access-only quirk used by accessibility software, and Protected Process overlaps with Protected Process Light signing-level semantics rather than the canonical IL pipeline. The four-vs-seven discrepancy is a documentation artifact, not an inconsistency in the kernel.

The IL lives on a token in the TokenIntegrityLevel field, retrievable through GetTokenInformation and the TOKEN_MANDATORY_LABEL structure [@mic-doc]. The IL lives on an object in the system access control list (SACL) as a SYSTEM_MANDATORY_LABEL_ACE, a special ACE type that carries the object's IL SID and a mandatory-policy mask [@mandatory-label-ace]. Three policy bits are defined in the winnt.h header [@mandatory-label-ace].

SYSTEM_MANDATORY_LABEL_NO_WRITE_UP (0x1) -- default. A subject at lower IL cannot write to this object.
SYSTEM_MANDATORY_LABEL_NO_READ_UP (0x2) -- opt-in. A subject at lower IL cannot read this object.
SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP (0x4) -- opt-in. A subject at lower IL cannot execute this object.

Object authors who do not specify a mandatory label inherit the default, which is NO_WRITE_UP only [@mic-doc]. The opt-in policies are exactly that: opt-in. A High-IL process that wants its files invisible to a Medium-IL process must explicitly request NO_READ_UP on the SACL. By default, MIC bounds writes, not reads, and that is one of the structural shapes Forshaw's 2017 "Reading Your Way Around UAC" series exploited [@forshaw-reading-uac].

The "regardless of DACL" property is the part to read slowly. A Low-IL principal cannot write to a Medium-IL object "even if that object's DACL allows write access to the principal," because the IL check runs first and short-circuits the access decision before the DACL evaluator ever sees the request [@mic-doc]. This is the difference between adding "another ACE" for integrity and adding a separate evaluator that runs first. An integrity ACE in the DACL would have been overridable by the object owner, because DACLs are discretionary. A mandatory-label ACE in the SACL is enforced by SeAccessCheck itself, independently of any other ACE in the DACL.

flowchart TD A["Subject requests access
(SID set, IL, desired access)"] --> B["MIC evaluator
compares subject IL to object IL
against NO_WRITE_UP / NO_READ_UP policy"] B --> C{"IL check allows
requested access?"} C -- "No" --> D["ACCESS_DENIED
(DACL not consulted)"] C -- "Yes" --> E["DACL evaluator
walks ACEs in order
(deny first, then allow)"] E --> F{"DACL grants
requested access?"} F -- "Yes" --> G["ACCESS_GRANTED"] F -- "No" --> H["ACCESS_DENIED"]

The architectural payoff is in the pseudocode of the access-check decision itself. Strip the API noise away and the decision reduces to two evaluators in series. The conceptual ordering is exact.

{` // Pseudocode of the Windows access-check ordering (Vista+). // See Microsoft Learn: Mandatory Integrity Control.

function seAccessCheck(subjectToken, object, desiredAccess) { // Step 1: Mandatory Integrity Control. Runs before the DACL. const subjectIL = subjectToken.integrityLevel; // e.g. Medium = 0x2000 const objectIL = object.mandatoryLabel.integrityLevel; // e.g. High = 0x3000 const policy = object.mandatoryLabel.policy; // bitmask

if (subjectIL < objectIL) { if ((policy & NO_WRITE_UP) && (desiredAccess & WRITE_BITS)) return 'ACCESS_DENIED'; if ((policy & NO_READ_UP) && (desiredAccess & READ_BITS)) return 'ACCESS_DENIED'; if ((policy & NO_EXECUTE_UP) && (desiredAccess & EXECUTE_BITS)) return 'ACCESS_DENIED'; }

// Step 2: only if MIC allowed do we consult the DACL. for (const ace of object.dacl.aces) { if (ace.sid in subjectToken.sids) { if (ace.type === 'DENY' && (ace.mask & desiredAccess)) return 'ACCESS_DENIED'; if (ace.type === 'ALLOW') desiredAccess &= ~ace.mask; if (desiredAccess === 0) return 'ACCESS_GRANTED'; } } return 'ACCESS_DENIED'; // implicit deny if no ACE grants } `}

The naive reading of MIC is "they added another ACE for integrity." The correct reading is that they added a separate axis with its own evaluator that the DACL cannot override. The reader who internalises that ordering can re-derive almost every subsequent design decision Vista made about UAC, AppContainer, IE Protected Mode, and Administrator Protection. A MIC denial is final. The DACL is not consulted. That is what mandatory means.

Key idea: MIC adds a second axis to the access check. The first axis is identity (DACL plus token SIDs); the second is integrity (IL). The two axes are evaluated in order: integrity first, identity second. A failure on the integrity axis short-circuits the entire check, regardless of what the identity axis would have said.

MIC bounds file, registry, and most other securable-object writes across IL boundaries. But the XP-era shatter attacks Paget published in 2002 were not about file writes. They were about cross-desktop message injection in the Win32 windowing layer, and MIC cannot help with that, because window messages do not pass through SeAccessCheck. So Vista shipped a second primitive specifically for the windowing layer.

4.2 User Interface Privilege Isolation

The windowing-layer analog of MIC. UIPI blocks a defined subset of window messages and hook APIs sent from a lower-IL process to a window owned by a higher-IL process on the same desktop, terminating the cross-IL variant of the shatter-attack class.

If MIC is mandatory integrity for objects, UIPI is mandatory integrity for windows. Same idea, different layer of the OS. Same principle: a separate evaluator that runs in the window manager and blocks cross-IL operations regardless of the window's own configuration [@uipi-wiki].

The canonical failed-shatter scenario is short and exact. A Medium-IL malware process calls SendMessage(hwnd, WM_SETTEXT, 0, (LPARAM)"some-attacker-controlled-string") against a window handle (hwnd) belonging to a High-IL elevated PowerShell on the same desktop. On Windows XP, the message would arrive and the elevated PowerShell's edit control would update its text, with no authentication check anywhere in the path. On Vista and every subsequent Windows release, the call returns zero. GetLastError returns ERROR_ACCESS_DENIED. The message is silently dropped by win32k.sys before the receiving process's window procedure ever sees it. The window manager noticed that the sender's IL was lower than the receiver's IL and dropped the message [@uipi-wiki][@russinovich-blog-2007].

The "silently dropped" part matters operationally. Legacy applications written before Vista did not check the return value of SendMessage. When Vista shipped UIPI, those applications kept "working" in the sense that they did not crash. They just stopped being effective at any cross-IL interaction they may have previously relied on. This is the same compatibility shape Microsoft used everywhere in Vista: the new bound was real, but the API surface returned plausible failure codes rather than raising new errors that broke legacy callers.

What UIPI blocks, precisely

UIPI does not block every window message. It blocks a specific dangerous subset, and a complete reading of the article requires reading the list slowly.

Operation	UIPI behaviour from lower IL to higher IL
`SendMessage` / `PostMessage` for `WM_SETTEXT`, edit-control mutators, combo-box mutators	Blocked; returns 0 / `ERROR_ACCESS_DENIED`
Posted messages above `WM_USER` (0x0400)	Blocked
`WM_TIMER` with a callback function pointer	Blocked (the original Paget vector)
`SetWindowsHookEx` against a higher-IL thread or process	Blocked
`AttachThreadInput` to a higher-IL thread	Blocked
`SendInput` targeting a higher-IL window	Blocked
Journal record / journal playback hooks	Blocked
Mouse and most keyboard input from the OS itself	Allowed (the user is the principal)
Most paint messages (`WM_PAINT`, `WM_ERASEBKGND`)	Allowed
Read-only window queries (`GetWindowText`, `EnumWindows`)	Allowed (return empty / minimal data rather than failing)

"UIPI blocks all WM_* messages" is one of the most common misconceptions in Windows-security literature. It does not. It blocks the dangerous subset: the messages and hooks that allow a sender to alter the receiving process's state or execute code in it [@russinovich-blog-2007][@uipi-wiki].

sequenceDiagram participant M as Medium-IL malware participant W as win32k.sys participant P as High-IL PowerShell M->>W: SendMessage(hwnd, WM_SETTEXT, ...) W->>W: Compare sender IL (Medium) to target window IL (High) Note over W: Sender IL lower than target IL, WM_SETTEXT in dangerous subset W-->>M: Returns 0, ERROR_ACCESS_DENIED Note over P: Window procedure never invoked, text unchanged

The Microsoft Learn page that opens "Modifies the User Interface Privilege Isolation (UIPI) message filter for a specified window" is the ChangeWindowMessageFilterEx function reference [@changewindowfilter]. It is the closest thing to a first-party UIPI conceptual page on Microsoft Learn. There is no standalone Microsoft Learn page titled "User Interface Privilege Isolation" at the winmsg path: the Wikipedia UIPI article is the standard secondary anchor for the concept itself [@uipi-wiki], and Russinovich's February 2007 TechNet Blogs post introduces UIPI by name in the original architectural canon [@russinovich-blog-2007].

The opt-in exemption: `ChangeWindowMessageFilterEx`

The UIPI block is per-window and per-message. When a higher-IL window has a legitimate reason to accept a specific message from lower-IL senders (for example, a developer tool that needs to receive WM_COPYDATA from a Medium-IL client), the higher-IL process can call ChangeWindowMessageFilterEx to add the specific message to its window's allow-list [@changewindowfilter].

The action constants are documented as MSGFLT_ALLOW (add the message to the allow-list), MSGFLT_RESET (remove explicit policy and inherit defaults), and MSGFLT_DISALLOW (explicitly block the message even if defaults would allow it) [@changewindowfilter]. The function returns BOOL; failure is non-fatal and the caller is expected to validate the result.

A High-IL window that opts WM_SETTEXT into the cross-IL allowed list inherits the responsibility to validate the contents of every message it then receives. The filter is the gate. It is not the validator. A higher-IL process that takes attacker-controlled text and pastes it into a system shell has bypassed UIPI in the same way a service that takes attacker-controlled input and passes it to system() has bypassed least privilege. The mechanism cannot make the higher-IL process safe; it can only make the higher-IL process aware.

The `uiAccess=true` carve-out

The single largest residual exemption from UIPI is the uiAccess=true manifest flag, designed to support accessibility software (screen readers, on-screen keyboards, remote-control tools) that needs to interact with windows above its own IL [@uia-security]. A process that asserts uiAccess=true in its application manifest gets, at process creation, a token flag (TokenUIAccess) that exempts the process from UIPI's cross-IL blocks for the outbound direction. A Medium-IL UI-Access process can post WM_SETTEXT to a High-IL elevated PowerShell window, because the Medium-IL process is acting on behalf of an accessibility client.

The gating conditions for uiAccess=true are tight, by design. Microsoft Learn enumerates three [@uia-security]. The manifest must assert uiAccess="true" in the requestedExecutionLevel element. The binary must carry a valid Authenticode signature. The binary must reside in a directory writable only by administrators, which in practice means %SystemRoot%\System32, %ProgramFiles%, or a similarly admin-only path. The three conditions together are intended to bound uiAccess to vetted, signed, install-time-protected binaries.

We will return to the uiAccess carve-out in §9, because Forshaw's February 2026 Project Zero retrospective documents that five of nine pre-GA Administrator Protection bypasses operated entirely through this surface [@forshaw-adminprot-feb26]. The Vista-era exemption inherited unchanged into 2026 is, nearly twenty years later, the single largest residual cross-IL attack class in the Windows integrity stack.

What UIPI killed, precisely

UIPI killed the cross-IL variant of the Brett-Moore-2002 shatter-attack class. Same-IL shatter attacks (two Medium-IL processes on the user's Default desktop, both belonging to the same user, both running with the user's authority) are not blocked by UIPI, because UIPI is an IL-based filter. Two same-IL processes can still send each other arbitrary window messages, and this is exactly why every modern browser sandbox layers AppContainer and a restricted-token sandbox on top of MIC [@appcontainer-isolation]: the integrity primitives are correct, but they are integrity primitives, not identity primitives, and same-IL same-desktop processes need a different isolation mechanism.

Together, MIC and UIPI provide an integrity bound on access (objects) and on user-interface manipulation (windows). Both are mandatory, default-on, and constant-overhead. They are the load-bearing primitive pair of the entire integrity-level stack. But how does the OS decide which processes get which IL? When you log in as Administrator and open a PowerShell, why is that PowerShell Medium and not High?

5. The Split-Token Breakthrough

The integrity-level pair (MIC plus UIPI) is the access-control primitive. The split-token model is the policy decision that wires those primitives into the administrator's everyday experience. Without the split-token policy, an administrator's interactive shell would hold a High-IL token at logon and UAC would never need to exist. With it, every administrator on Windows 11 today has two tokens. One is in use. The other is dormant. The yellow dialog is the negotiation that toggles between them.

The Vista policy in which an Administrators-group user logging on receives a Medium-IL filtered token plus a dormant High-IL linked token. The filtered token becomes the primary token of the interactive shell; the linked token is used only after consent or auto-elevation, and only when the Application Information service brokers a process creation with it.

What the LSA does at logon

When EnableLUA=1 in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System (the default since Vista), and an Administrators-group user logs on, the Local Security Authority subsystem (LSASS) constructs three things during logon processing [@uac-how-it-works].

The first is the full token: an access token that contains all of the user's administrator group SIDs (enabled, not deny-only), all of the privileges the user is authorised to hold, and an integrity level of High. This is the token that, on XP, would have been the user's primary token from logon onward.

The second is the filtered token: a copy of the full token with all administrator-equivalent group SIDs marked SE_GROUP_USE_FOR_DENY_ONLY, all privileges except a small user-mode subset removed, and the integrity level reduced to Medium. The administrator group SIDs are not removed; they are marked deny-only so they still match deny ACEs but do not satisfy allow ACEs. The privileges are not zeroed; the powerful ones (SeDebug, SeTakeOwnership, SeLoadDriver, SeAssignPrimaryToken, and others) are dropped from the filtered token entirely.

The third is the linked relationship: the LSA stamps each token with a reference to the other via the TokenLinkedToken information class, so that a holder of the filtered token can, with the right privileges, retrieve a handle to the dormant full token by calling NtQueryInformationToken(filteredToken, TokenLinkedToken, &linkedToken, ...) [@uac-how-it-works].

The filtered token then becomes the primary access token of the user's interactive shell (explorer.exe). Every process the user launches by clicking, by Win+R, by typing in a console, inherits the filtered token as its primary token. The dormant full token sits in the LSA, addressable through TokenLinkedToken. The verbatim Microsoft Learn statement is exact: "When an administrator logs on, two separate access tokens are created for the user: a standard user access token and an administrator access token" [@uac-how-it-works].

flowchart TD A["User authenticates
as a member of Administrators"] --> B["LSA logon processing
(LsaLogonUser)"] B --> C["Full token
(admin SIDs enabled, all privileges, IL = High)"] B --> D["Filtered token
(admin SIDs deny-only, privileges stripped, IL = Medium)"] C -.->|"linked via TokenLinkedToken"| D D --> E["Primary token of explorer.exe
and all interactive child processes"] C --> F["Dormant in LSA, used only by Appinfo after consent or auto-elevation"]

The TokenElevationType API surface

Three values of the TOKEN_ELEVATION_TYPE enumeration describe what state the current process is in [@token-elevation-type].

TokenElevationTypeDefault (1) -- no split-token policy is in effect for this token. This is the legacy case (EnableLUA=0) or the case where the user is not a member of any administrators-equivalent group at all. The single token is the only token, and no linked token exists. On a default consumer or enterprise Windows 11 install with an admin account, this value is rare.
TokenElevationTypeFull (2) -- the current process is running with the unfiltered admin token. Admin Approval Mode is in force; this process either was launched via elevation (and holds the linked full token) or was created in a context where the filtered/full distinction is collapsed (some service contexts).
TokenElevationTypeLimited (3) -- the current process is running with the filtered token, Admin Approval Mode is in force, and a dormant full token exists. This is the typical state of an interactive admin shell on Windows 11.

TokenElevationTypeDefault (value 1) is the legacy or domain-controller case in which EnableLUA=0 and the user has no filtered token at all. On a default consumer Windows install, administrators are always TokenElevationTypeLimited or TokenElevationTypeFull, never Default. The Default case is what reverting EnableLUA to 0 produces, and it is the configuration the FAQ in §11 warns against.

What the consent prompt actually does

The behaviour of the consent prompt now resolves to a single operation, and the operation is not "elevate." When the user invokes "Run as administrator" on a binary, the shell calls ShellExecuteEx with the "runas" verb [@shellexecuteexa]. The Application Information service (the topic of §6.2) receives the request via RPC. Appinfo, running as LocalSystem, retrieves the linked full token of the calling user via TokenLinkedToken. Appinfo shows the consent prompt on the Secure Desktop (§6.1). If the user clicks "Yes," Appinfo creates a new process using the full token as the new process's primary token, by calling CreateProcessAsUser with the privileges Appinfo holds because it is LocalSystem [@russinovich-tnm-2007].

The bits that move are the kernel-level handle for the new process and the assignment of the linked token as that process's primary token. The bits the prompt itself moves are zero. The prompt is the consent surface; the token swap is the primitive.

Key idea: The consent prompt does not create authority. It uses authority that was already constructed at logon and held dormant in the linked token. The same primitive can move bits without the prompt -- that is exactly what auto-elevation does.

sequenceDiagram participant U as User participant E as explorer.exe (Medium IL) participant A as Appinfo (LocalSystem) participant C as consent.exe (Secure Desktop) participant P as New process (High IL) U->>E: Right-click, Run as administrator E->>A: RPC: request elevation of target.exe A->>A: Look up TokenLinkedToken of caller's filtered token A->>C: Show consent prompt U->>C: Click Yes C-->>A: Consent granted A->>P: CreateProcessAsUser(linked full token, target.exe) Note over P: New process runs at High IL, full admin SIDs enabled, full privileges Split-token administrator in UAC just means MS get to annoy you with prompts unnecessarily but serves very little, if not zero security benefit. -- James Forshaw, *Reading Your Way Around UAC (Part 1)*, Tyranid's Lair, May 2017

Forshaw's 2017 critique is the load-bearing observation that frames the rest of the article [@forshaw-reading-uac]. Even with the elegant split-token policy in place, there is a structural problem the design did not solve. The filtered token and the linked token share the same user SID. They write to the same %USERPROFILE%. They consult the same HKCU registry hive. They live in the same logon-session LUID. From an integrity-isolation point of view, the two tokens are bounded against each other; from an identity-isolation point of view, they are the same user.

That shared-identity property is what made the bypass-research industry possible, and what Administrator Protection finally attacks in 2024 (§9). We will return to it. First, let us tour the rest of the stack the consent prompt sits on. If Appinfo is the SYSTEM-trusted broker that does the token swap, where does it live? And what stops malware from spoofing the consent prompt itself?

6. The Full UAC Stack on a Modern Windows Box

The reader now knows the four load-bearing primitives. This section walks every supporting piece that surrounds them on a 2026 Windows install, in the order needed to follow an elevation event end-to-end. There are four pieces: the Secure Desktop the prompt renders on, the Appinfo service that brokers the token swap, the two distinct activation surfaces that trigger an elevation, and the auto-elevation allowlist that shaped fifteen years of bypass research.

6.1 The Secure Desktop, not Session 0

A separate desktop object at the Object-Manager path `\Sessions\\Windows\WindowStations\WinSta0\Winlogon`, within the user's interactive session, on which `consent.exe` runs the UAC prompt. Isolated from the user's `Default` desktop by Object-Manager DACL and the `SwitchDesktop` API.

When you click "Run as administrator" and the screen dims and the prompt appears, the screen dims because you have just been switched to a different desktop. Not a different session, not Session 0, not a different window station. A different desktop within the same window station, accessed through the SwitchDesktop API [@russinovich-tnm-2007].

The Object-Manager path is exact. Inside the user's interactive session (Session 1 if the user is the first interactive logon, higher numbers for subsequent users), there is a window station named WinSta0. Inside WinSta0 there are several desktop objects: Default (where the user's normal interactive processes paint), Winlogon (where consent.exe runs the prompt), and Disconnect and Screen-saver for related uses. The full path of the Secure Desktop is \Sessions\<n>\Windows\WindowStations\WinSta0\Winlogon.

The Winlogon desktop is protected by an Object-Manager DACL that the user's normal interactive processes (running on Default) cannot open for DESKTOP_CREATEWINDOW or DESKTOP_HOOKCONTROL. A Medium-IL malware process on Default cannot draw into the Winlogon desktop, cannot enumerate its windows, and cannot send messages to them. The OS performs the desktop switch in win32k.sys and renders consent.exe's window on the new desktop with a snapshot of the previous desktop as a dimmed background, so the user has visual continuity but consent.exe is the only process accepting input [@russinovich-tnm-2007].

Note: The Secure Desktop is not in Session 0. Session 0 Isolation is a different Vista feature that moved all Windows services off the interactive desktop into a non-interactive session (Session 0), separately from the per-user interactive sessions (Sessions 1, 2, ...). The Secure Desktop is within the user's interactive session: a different desktop object inside the same window station, not a different session. The two features ship together in Vista and are constantly confused, because they are both 2006-era hardening primitives. They are architecturally independent: Session 0 Isolation prevents services from drawing on the user's desktop, and the Secure Desktop prevents the user's processes from drawing on the prompt's desktop. Conflating them mis-describes how either one works. The corpus's Object Manager Namespace article (#46) covers Session 0 Isolation directly; this article treats only the Secure Desktop.

A separate Vista feature, architecturally independent of the Secure Desktop, that moved all Windows services off the interactive desktop and into Session 0. The two features ship together in Vista and are constantly confused, but they live at different layers of the Object Manager hierarchy. flowchart TD A["Session 1
(interactive logon for user 'admin')"] --> B["WinSta0
interactive window station"] A --> C["Service-0x0-3e7$
non-interactive WinSta (services)"] B --> D["Default desktop
explorer.exe, browsers, console windows
(Medium IL processes)"] B --> E["Winlogon desktop
consent.exe renders here
(Secure Desktop)"] B --> F["Disconnect / Screen-saver
desktops"] D -. "blocked by Object-Manager DACL
and SwitchDesktop" .-> E

The Secure Desktop addresses UI spoofing and input injection against the prompt itself. It does not address whether elevation can happen without a Secure Desktop prompt; that is the territory of the auto-elevation allowlist (§6.4) and of the bypass-research class (§7).

6.2 The Application Information service (Appinfo)

The SYSTEM-trusted Windows service (`appinfo.dll`, hosted in `svchost.exe`, runs under `LocalSystem`) that mediates the token swap between filtered and linked tokens at elevation time. Required service: "Run as administrator" fails without it. The modern process-creation entry point is `RAiLaunchAdminProcess`.

Every UAC elevation on Windows goes through one service: Appinfo (display name "Application Information"). Its image is C:\Windows\System32\appinfo.dll, loaded into a shared svchost.exe host process, running as LocalSystem [@russinovich-tnm-2007].

The job is single-purpose: be the SYSTEM-trusted broker that performs the token swap. A Medium-IL caller cannot, by definition, create a process holding a token the caller does not possess. Creating a process under a token with privileges the caller lacks requires two privileges Medium-IL filtered admin tokens do not hold: SeAssignPrimaryTokenPrivilege and SeIncreaseQuotaPrivilege. LocalSystem has both [@russinovich-tnm-2007]. The broker therefore has to run as LocalSystem, and that is what Appinfo is for.

The modern entry point on Appinfo's RPC interface is RAiLaunchAdminProcess, documented verbatim in Forshaw's February 2026 Project Zero post on Administrator Protection [@forshaw-adminprot-feb26]. The Medium-IL caller invokes ShellExecuteEx with "runas"; the shell marshalls the request across to Appinfo; Appinfo retrieves the caller's TokenLinkedToken; if a prompt is needed, Appinfo shows consent.exe on the Secure Desktop; if the user clicks "Yes," Appinfo calls RAiLaunchAdminProcess to create the new process under the linked full token.

Disable Appinfo and "Run as administrator" returns an error. It is the single point of trust in the elevation pipeline, which is exactly why the bypass-research industry pays attention to it: anything that can trick Appinfo into auto-elevating an attacker-influenced binary, without the consent prompt, becomes a fileless UAC bypass (§7.1).

6.3 Two activation surfaces

Note: When you say "elevate a thing," the operating system understands two distinct primitives, not one. ShellExecuteEx "runas" is whole-process elevation: the OS launches a new process and runs the entire process at High IL. The COM Elevation Moniker is per-object elevation: the OS spins up an isolated dllhost.exe that exposes exactly one COM CLSID's methods at High IL while the caller stays at Medium. The bypass-research literature attacks these two surfaces in very different ways. Conflating them mis-describes both the attack surface and the fix surface.

The first activation surface is ShellExecuteEx with the "runas" verb. The OS launches consent.exe, asks the user, and if approved, Appinfo creates a brand-new process under the caller's linked full token. The new process is High-IL for its entire lifetime, with the entire administrator privilege set and all the admin group SIDs enabled. The Windows Explorer "Run as administrator" context menu uses this verb. So does the runas /trustlevel: command. So does any program that calls ShellExecuteEx and sets the lpVerb member of SHELLEXECUTEINFO to the string "runas" [@shellexecuteexa].

A COM activation surface (`Elevation:Administrator!new:{CLSID}`) that asks the OS to instantiate a single COM out-of-process server in a new elevated `dllhost.exe`, exposing only that one CLSID's methods at High IL. Per-object elevation, distinct from `ShellExecuteEx "runas"` whole-process elevation.

The second activation surface is the COM Elevation Moniker. A Medium-IL caller invokes CoGetObject (or CoCreateInstance via a moniker) with the display name "Elevation:Administrator!new:{CLSID}" (or "Elevation:Highest!new:{CLSID}"). This asks the OS to instantiate a single COM out-of-process server in a new elevated dllhost.exe host process, exposing only that one CLSID's methods at High IL. The caller stays at Medium. Only the COM object's host process is elevated, and only for the lifetime of the object [@com-elevation-moniker].

The semantics are deliberately narrow. The COM Elevation Moniker requires the target CLSID to opt in via two registry values under HKCR\CLSID\{CLSID}: Elevation\Enabled = 1 and an LocalizedString value that names the elevation prompt's display string. Not every COM class is moniker-eligible; the registry enables elevation per CLSID.

Property	`ShellExecuteEx "runas"`	COM Elevation Moniker
Granularity	Whole process	One COM object
Lifetime	Entire process lifetime	Object lifetime only
Caller IL after	Caller stays Medium; new process High	Caller stays Medium
New process	Target executable	`dllhost.exe` host
Authority surface	All admin SIDs and privileges, broad	Methods of one CLSID, narrow
Typical use	"Run as administrator" context menu, MSI installers	Programmatic file copy, Wmi management, registry edits
Primary canonical bypass class	DLL-search-order against the new process	Auto-elevated COM behaviour abuse

The distinction matters because most of the canonical UAC bypasses do not touch ShellExecuteEx "runas" at all. Leo Davidson's December 2009 essay attacked the COM Elevation Moniker by invoking the IFileOperation COM class (auto-elevation-eligible, registered under the right CLSID) from a Medium-IL caller, and using its CopyItem method to overwrite a system file at High IL [@davidson-2009][@ifileoperation]. The ICMLuaUtil and IColorDataProxy interfaces follow the same shape: a Medium-IL caller instantiates an auto-elevatable COM class via the moniker, and then calls a method on the High-IL object that performs an attacker-chosen action [@uacme].

Both surfaces share the same backend: Appinfo brokers the token swap, and RAiLaunchAdminProcess (or its COM equivalent) creates the new process. The difference is whether the elevated child is a whole new process (broad authority for a long time) or a COM object's host (narrow authority for a single activation). The bypass-research literature exploits the second class far more than the first, because the second class exposes a narrower, more abusable behavioural surface: the CLSID's methods.

6.4 The auto-elevation allowlist

Vista's prompt fatigue was a usability disaster. Beta reviewers described users clicking through three or four prompts per common task. Windows 7, shipped in October 2009, tried to cut the noise by quietly elevating a curated set of Microsoft-signed binaries with no prompt at all. That single decision shaped the next fifteen years of UAC bypass research, because every "bypass" you have ever read about lives inside the gap between which binary gets elevated and what the binary does after elevation.

The set of Microsoft-signed binaries in trusted system directories on Appinfo's internal allowlist that elevate without a consent prompt. Four gating conditions: `autoElevate=true` manifest element, Microsoft Authenticode signature, trusted directory path, and an internal Appinfo allowlist entry enforced inside `appinfo.dll`.

The manifest element is a single string. Inside the application's side-by-side manifest, under the <trustInfo> / <security> / <requestedPrivileges> element, the binary asserts <autoElevate>true</autoElevate> [@app-manifests]. That assertion was discovered and publicly documented by independent UK developer Leo Davidson in December 2009 [@davidson-2009].

The autoElevate=true manifest assertion is necessary but not sufficient. Appinfo enforces three additional gating conditions before honouring an auto-elevation request [@davidson-2009].

The binary must carry a valid Authenticode signature chained to a Microsoft root certificate.
The binary's path must reside under a trusted system directory, in practice %SystemRoot%\System32 or %SystemRoot%\SysWOW64 (or the localized variants for non-English locales).
The binary's name must appear on an internal allowlist enforced in code in appinfo.dll, not in any user-visible policy file.

The fourth gate (the internal allowlist) is the one that surprises practitioners. A binary can be Microsoft-signed, located in System32, and carry autoElevate=true in its manifest, and Appinfo can still refuse to auto-elevate it, because the binary's name is not on the hard-coded allowlist inside appinfo.dll. There is no public Microsoft-published file enumerating the allowlist; the only way to enumerate it operationally is to scan the manifests of every binary in System32 and cross-check which ones actually auto-elevate.

The community-standard way to enumerate the manifest-asserting subset of the allowlist is to run Sysinternals `sigcheck -m C:\Windows\System32\*.exe` and pipe the output to `findstr /i autoelevate`. That gives you every binary in `System32` whose embedded manifest asserts `autoElevate=true`. On a Windows 11 25H2 install, the list runs to thirty to forty binaries: `mmc.exe`, `eventvwr.exe`, `fodhelper.exe`, `ComputerDefaults.exe`, `sdclt.exe`, `slui.exe`, and others.

The list of names in the manifest is not the same as the set Appinfo actually auto-elevates. UACMe's research README enumerates the operational subset: which manifest-asserting binaries Appinfo actually honours, by Windows build, with the technique class and the catalogued bypass method [@uacme]. The canonical observation is that of the manifest-asserting list, only the operationally-allowlisted subset is exploitable, and the operational subset changes silently across feature updates without any security bulletin because none of the resulting bypasses are classified as security vulnerabilities.

{` // Pseudocode of Appinfo's auto-elevation decision (Win7+). // All four gates must pass for auto-elevation without a consent prompt.

function shouldAutoElevate(binaryPath) { // Gate 1: the application manifest must assert autoElevate=true. const manifest = readEmbeddedManifest(binaryPath); if (manifest?.requestedPrivileges?.autoElevate !== true) return false;

// Gate 2: the binary must carry a valid Microsoft Authenticode signature. const sig = verifyAuthenticodeSignature(binaryPath); if (sig.status !== 'valid' || sig.rootCA !== 'Microsoft') return false;

// Gate 3: the binary must reside under a trusted system directory. const trustedDirs = ['C:\\Windows\\System32\\', 'C:\\Windows\\SysWOW64\\']; if (!trustedDirs.some(d => binaryPath.toLowerCase().startsWith(d.toLowerCase()))) return false;

// Gate 4: the binary name must appear on Appinfo's internal allowlist. // This is the one enforced in code in appinfo.dll, not exposed as policy. if (!APPINFO_INTERNAL_ALLOWLIST.includes(baseName(binaryPath).toLowerCase())) return false;

return true; } `}

Four gating conditions. Three of them constrain which binary gets elevated. None of them constrain what the binary does after elevation. The fourth gap, the behavioural one, is the space the bypass-research industry has occupied for fifteen years. That is §7.

7. Twenty Years of Bypass Research as Empirical Test

In February 2007, eleven days after Vista's consumer launch, Mark Russinovich published a TechNet Blogs post titled PsExec, User Account Control and Security Boundaries. The post walked through a quirk of how PsExec's -l switch interacted with restricted tokens on Windows XP, used the walkthrough to introduce Vista's integrity-level model, and then dropped a single sentence the entire later debate would rest on [@russinovich-blog-2007].

Neither UAC elevations nor Protected Mode IE define new Windows security boundaries... potential avenues of attack, regardless of ease or scope, are not security bugs. -- Mark Russinovich, *PsExec, User Account Control and Security Boundaries*, TechNet Blogs, February 12, 2007

That sentence, in the public record from week one, is the architectural reason every "UAC bypass" published from 2009 onward was classified by Microsoft as a non-vulnerability. The bypass-research literature is the empirical proof of the disclaimer, not a counterargument to it. Three durable bypass classes carry the empirical weight.

7.1 The `ms-settings` / `DelegateExecute` registry-hijack class

The first durable class is the registry-hijack bypass of auto-elevated binaries. Mechanism: an auto-elevated binary (eventvwr.exe, fodhelper.exe, ComputerDefaults.exe, certain sdclt.exe variants) executes a handler for a custom file extension or URL protocol on launch. The relevant handler mapping is in HKCR, but Windows resolves HKCR by first consulting HKCU\Software\Classes and only falling back to HKLM\Software\Classes if no per-user mapping exists. A Medium-IL user can write to HKCU without elevation. So the user writes a HKCU\Software\Classes\<scheme>\shell\open\command key whose default value is an arbitrary command line and whose DelegateExecute value is the empty string. Then the user launches the auto-elevated binary. The binary loads, Appinfo elevates it to High IL, the binary resolves its registered handler, walks HKCU\Software\Classes first, finds the attacker-controlled command line, and executes it. The attacker's command runs at High IL [@enigma-eventvwr][@mitre-t1548002].

The first public canonical demonstration was Matt Nelson's August 15, 2016 post Fileless UAC Bypass Using eventvwr.exe and Registry Hijacking, published on his blog under the handle enigma0x3. Nelson hijacked the mscfile association by writing HKCU\Software\Classes\mscfile\shell\open\command with cmd.exe as the default value, then launched eventvwr.exe. The Event Viewer auto-elevates because of its manifest, resolves the mscfile association to load eventvwr.msc, walks the HKCU mapping first, finds cmd.exe instead of mmc.exe, and launches an attacker-controlled cmd.exe at High IL [@enigma-eventvwr]. The technique required no file on disk except the registry value itself; this is what fileless means in this context.

Nelson productised the class through 2017. The March 14, 2017 Bypassing UAC Using App Paths post generalised to HKCU:\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe, exploited by sdclt.exe [@enigma-apppaths]. The March 17, 2017 'Fileless' UAC Bypass Using sdclt.exe post showed a fileless variant of the same attack using the IsolatedCommand REG_SZ value on HKCU:\Software\Classes\Folder\shell\open\command, with sdclt.exe /KickOffElev as the trigger [@enigma-sdclt]. The same post referenced WikiLeaks's March 2017 Vault7 disclosures, in which the CIA's "Vault7" cache contained operationalised versions of the technique, confirming nation-state adoption of the bypass class [@enigma-sdclt].

The fodhelper variant was published on May 12, 2017 under the title Bypassing UAC Using fodhelper.exe. The canonical URL enigma0x3.net/2017/05/12/bypassing-uac-using-fodhelper-exe/ currently returns HTTP 404; the technique is anchored by UACMe Method 33 and MITRE ATT&CK T1548.002, both of which preserve the date, author, and registry path verbatim [@uacme][@mitre-t1548002].

sequenceDiagram participant U as User (Medium IL) participant R as HKCU registry participant F as fodhelper.exe (auto-elevated) participant A as Appinfo (LocalSystem) participant C as Attacker payload (High IL) U->>R: Write HKCU Software Classes ms-settings shell open command with attacker cmd U->>F: ShellExecute("fodhelper.exe") F->>A: Request elevation (autoElevate gate passes) A->>F: New process at High IL, no consent prompt F->>R: Resolve ms-settings handler via HKCU first R-->>F: Returns attacker command F->>C: Spawn attacker payload at High IL

Microsoft's response to the eventvwr bypass was to ship a fix in the Windows 10 Creators Update (1703) that made eventvwr.exe not consult the registered association the technique exploited. The fix was technique-specific, not class-specific: the ms-settings (fodhelper), App Paths (sdclt), and IsolatedCommand (sdclt) variants remained exploitable through subsequent Windows 10 builds and into Windows 11 [@uacme][@mitre-t1548002]. None of these were patched as security vulnerabilities, because, per Russinovich 2007, UAC is not a security boundary [@russinovich-blog-2007].

7.2 The DLL-search-order class

The second durable class is the DLL-search-order attack against auto-elevated binaries. Mechanism: an auto-elevated binary calls LoadLibrary on a DLL name resolved via the standard Windows search order: the application directory, the system directory, the current directory, the PATH environment variable, and so on. If any path on that search order earlier than the legitimate one is writable by the Medium-IL caller, the caller can plant an attacker DLL at that path. When the auto-elevated binary loads the legitimate name, the search order returns the attacker's DLL first, and the DLL is loaded at the binary's elevated IL [@davidson-2009].

The foundational canonical example is the December 2009 Leo Davidson essay Windows 7 UAC whitelist: Code injection issue (and more). Davidson demonstrated that sysprep.exe (Microsoft-signed, in System32, auto-elevation-allowlisted) loads cryptbase.dll from its working directory before the system directory. By copying sysprep.exe and a malicious cryptbase.dll into a writable directory and launching sysprep.exe from there, an attacker could load the malicious DLL into a High-IL process [@davidson-2009]. The same essay introduced the IFileOperation COM-object technique that founded the second durable class (§7.3), making the December 2009 Davidson essay the single most-cited primary in the entire UAC bypass literature.

Coverage in the trade press confirmed the class's significance immediately. In February 2009, The Register reported on a related Long Zheng / Rafael Rivera disclosure that demonstrated piggybacking on auto-elevation via rundll32.exe [@register-2009], establishing that the auto-elevation surface had been understood as exploitable from the moment Windows 7 shipped.

Microsoft's mitigations against the DLL-search-order class have been incremental. SafeDllSearchMode was made the default in Windows XP SP2 and reshuffled the search order so the application directory came before the current directory. The LOAD_LIBRARY_SEARCH_* flags introduced in Windows Vista let applications opt into stricter search behaviour. Side-by-side manifest pinning and the KnownDLLs mechanism shrink the surface further. All of these are application-author opt-ins; an auto-elevated binary that does not use them remains exploitable, and UACMe's catalogue of 81 methods includes numerous DLL-search-order entries across Windows versions [@uacme].

7.3 The auto-elevated COM-object behaviour-abuse class

The third durable class abuses the behaviour of auto-elevation-eligible COM classes. Mechanism: a COM class registered as auto-elevation-eligible (the IFileOperation / ICMLuaUtil / IColorDataProxy family historically, then the explicit COMAutoApprovalList registry surface introduced in Windows 10 RS1 / build 14393 in August 2016) can be instantiated High-IL by a Medium-IL caller via the COM Elevation Moniker. Once instantiated, the High-IL object exposes methods (file copy, registry write, executable launch) that perform actions at High IL using whatever parameters the caller passes [@davidson-2009][@ifileoperation].

Davidson's IFileOperation proof of concept from December 2009 is the canonical example. A Medium-IL caller instantiates IFileOperation via the COM Elevation Moniker. The resulting dllhost.exe runs at High IL and exposes IFileOperation::CopyItem and related methods. The caller invokes CopyItem("evil.dll", "C:\\Windows\\System32\\"). The High-IL dllhost.exe performs the copy, because the High-IL token has write access to %SystemRoot%\System32. The caller has now planted a DLL in System32 without ever holding a High-IL token itself [@davidson-2009][@ifileoperation].

The COMAutoApprovalList era began in August 2016 with the Windows 10 Anniversary Update (RS1, build 14393). Microsoft added a dedicated registry surface at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UAC\COMAutoApprovalList enumerating which CLSIDs consent.exe would auto-elevate without a prompt. The change was unannounced: there is no Microsoft-published security bulletin naming the introduction. The community anchor is UACMe Method 49, whose fix-note carries the verbatim "Side effect of consent.exe COMAutoApprovalList introduction" against the TpmInit.exe ICreateNewLink technique, dated to RS1 / build 14393 [@uacme]. Method 27 captures the subsequent narrowing in RS3 / 16299, when Microsoft removed the UninstallStringLauncher interface from the list.

Class	Mechanism	Canonical research	Microsoft response
Registry-hijack (DelegateExecute)	Auto-elevated binary resolves user-writable HKCU handler	Nelson, eventvwr Aug 2016; sdclt and fodhelper 2017	Patched individual binaries; class never classified as security vulnerability
DLL-search-order	Auto-elevated binary loads attacker DLL via standard search path	Davidson, December 2009 (sysprep + cryptbase)	`SafeDllSearchMode`, `LOAD_LIBRARY_SEARCH_*`, KnownDLLs; shrunk but not eliminated
Auto-elevated COM behaviour	Medium-IL caller invokes High-IL methods via moniker	Davidson, December 2009 (IFileOperation); COMAutoApprovalList RS1 Aug 2016	Curated allowlist; entries added or removed in feature updates without CVEs

7.4 The doctrine and the aha

The two distinct 2007 sources need precise attribution, because the citation chain is the load-bearing artifact of the entire UAC-as-not-a-boundary argument.

Note: The verbatim "Neither UAC elevations nor Protected Mode IE define new Windows security boundaries" sentence lives in the PsExec, User Account Control and Security Boundaries TechNet Blogs post by Mark Russinovich, dated February 12, 2007 [@russinovich-blog-2007]. The architectural reference that most practitioners cite, Security: Inside Windows Vista User Account Control, was published in the June 2007 issue of TechNet Magazine and is the canonical reference for the integrity model, file/registry virtualisation, and the elevation pipeline [@russinovich-tnm-2007]. The architectural article does not contain the "not a security boundary" sentence; the February blog post does. Conflating the two is a citation error and gives the wrong impression of when Microsoft committed to the boundary classification.

The Microsoft Security Response Center's published servicing criteria define a security boundary as one that "provides a logical separation between the code and data of security domains with different levels of trust" [@msrc-criteria]. The MSRC servicing-criteria page enumerates which Windows boundaries qualify under that definition. Through the Vista-through-Windows-10 era (2007-2024), UAC was explicitly classified as a security feature, not a boundary, in the enumeration table on that page. The enumeration is rendered client-side (in JavaScript) and not visible through static fetches; the canonical confirmation for the classification is the Russinovich February 2007 sentence above, repeated and re-affirmed in Microsoft public statements throughout the period [@russinovich-blog-2007].

Forshaw's January 2026 Project Zero post on Administrator Protection reads the doctrine clearly in retrospect: "due to the way it was designed, it was quickly apparent it didn't represent a hard security boundary, and Microsoft downgraded it to a security feature" [@forshaw-adminprot-jan26]. The "downgraded" framing is exact. UAC was promoted to a security feature, not a security boundary, from the moment it shipped. The reclassification in November 2024 was a re-promotion with new architecture, not a fix to the old architecture.

Note: The twenty-year UAC bypass-research record is empirical confirmation, not counterargument, of the architect's 2007 disclaimer. Microsoft did not fix the bypasses as security vulnerabilities because Russinovich had already said in writing that there was nothing to "fix": the consent prompt was a convenience, not a boundary. The bypass record is the proof that the disclaimer was honest from week one.

For the Windows administrator who has watched the bypass-research industry produce a new fileless bypass every six to twelve months, the reframing is the load-bearing aha of the entire article. The bypasses are not bugs Microsoft has failed to fix. They are the empirical map of the access-control versus information-flow gap that any access-control primitive runs into in a backward-compatible OS. The empirical record from 2009 forward (Davidson, Nelson, hfiref0x, Forshaw) is the cumulative confirmation that the disclaimer was honest.

If MIC, UIPI, and the split-token model are sound primitives, and the bypasses do not violate Microsoft's own classification of them, what are the actual theoretical limits of integrity-level systems? What can MIC and UIPI never do, by design?

8. Theoretical Limits: What MIC and UIPI Cannot Do, by Design

The 2007 disclaimer was not just an admission of weakness. It was an accurate statement of the theoretical limits of any access-control primitive in a backward-compatible operating system. The bypass-research industry of 2009 to 2026 has empirically traced out those limits one technique at a time, and a careful reading of the theory tells us why the trace looks the way it does.

Biba 1977 and the three rules

The integrity model MIC implements comes from Kenneth J. Biba's 1977 MITRE technical report MTR-3153 [@biba-wiki]. Biba's model is the integrity-side mirror of the better-known Bell-LaPadula confidentiality model [@blp-wiki]: where Bell-LaPadula's "no read up" prevents confidentiality leaks, Biba's "no write up" prevents integrity contamination. The Biba model defines three rules.

Simple Integrity Property (no read down): a subject at integrity level $I_s$ cannot read an object at integrity level $I_o < I_s$. A High-IL subject cannot read Low-IL data, because Low-IL data may have been written by an untrusted source and might contaminate the subject's state.
Star Integrity Property (no write up): a subject at integrity level $I_s$ cannot write an object at integrity level $I_o > I_s$. A Low-IL subject cannot write to a High-IL object, because the Low-IL subject's writes would degrade the High-IL object's integrity.
Invocation Property: a subject at integrity level $I_s$ cannot invoke (call, request services from) a subject at integrity level $I_o > I_s$. A Low-IL caller cannot ask a High-IL server to perform an action on the caller's behalf, because the High-IL server would then act on Low-IL inputs.

MIC implements the Star Integrity Property as the default NO_WRITE_UP policy. Every object that does not explicitly request a different policy is protected against lower-IL writes [@mic-doc][@mandatory-label-ace]. That is the one Biba rule MIC actually enforces.

MIC does not implement Biba's Simple Integrity Property at all. There is no NO_READ_DOWN policy in the winnt.h mandatory-label-policy enumeration. The opt-in NO_READ_UP bit MIC exposes points the other way: it stops a lower-IL subject from reading a higher-IL object, which is structurally Bell-LaPadula's Simple Security Property (no read up for confidentiality) repurposed onto an integrity SID rather than a confidentiality label [@blp-wiki][@mandatory-label-ace]. By default, a Low-IL process can read a High-IL file. This is the design choice Forshaw's Reading Your Way Around UAC series turned into a research program in 2017 [@forshaw-reading-uac].

MIC does not implement the Invocation Property either. A Medium-IL process can invoke a High-IL service via the COM Elevation Moniker, via ShellExecuteEx "runas", via any of the auto-elevated binaries, via RPC to Appinfo. The absence of the Invocation Property is exactly what makes UAC operationally usable: a strict reading of Biba would forbid every brokered elevation surface in Windows, and the OS would be unbearable to use. The omission is deliberate, and it is the theoretical reason why every "bypass" of UAC is technically a use of an architectural surface, not a violation of it.

flowchart LR subgraph BIBA ["Biba 1977 -- integrity model"] A["Biba 1977
integrity model"] --> B["Simple Integrity
(no read down)"] A --> C["Star Integrity
(no write up)"] A --> D["Invocation Property
(no invoke up)"] B --> E["MIC: not implemented
(no NO_READ_DOWN policy in winnt.h)"] C --> F["MIC: default NO_WRITE_UP
(on by default)"] D --> G["MIC: not implemented
(COM moniker, runas verb, Appinfo)"] end subgraph BLP ["Bell-LaPadula 1973 -- confidentiality model"] H["Bell-LaPadula 1973
confidentiality model"] --> I["Simple Security
(no read up)"] I --> J["MIC: opt-in NO_READ_UP
(off by default, repurposed onto IL)"] end Strict Biba would forbid every brokered-elevation primitive in Vista. The COM Elevation Moniker, `ShellExecuteEx "runas"`, the entire RPC interface to Appinfo, the `IFileOperation`-class auto-elevated COM objects, the manifest-based elevation request: all of these are explicitly *invocations* by a lower-IL caller of a higher-IL server [@biba-wiki].

Microsoft's architectural decision was that brokered elevation is the operationally usable workaround. A Medium-IL caller cannot invoke a High-IL server directly, but a Medium-IL caller can ask the SYSTEM-trusted Appinfo broker to create a High-IL process whose initial state the broker controls. The broker is the mediation point. The brokered model is structurally weaker than strict Biba, and that weakness is exactly the surface the bypass-research industry has operated in for sixteen years. Every COM-elevation moniker bypass, every auto-elevation registry hijack, every DLL-search-order attack is a refinement of the same observation: brokered elevation lets Medium-IL inputs influence High-IL outputs in ways the broker cannot fully validate.

The access-control versus information-flow gap

The deeper bound is information-flow. Dorothy Denning's May 1976 Communications of the ACM paper A lattice model of secure information flow established the formal framework [@denning-1976]. Denning's result is fundamental: information-flow enforcement is undecidable in the general case, because verifying that a program never leaks information from class $A$ to class $B$ requires deciding properties of arbitrary programs, which reduces to the halting problem.

MIC enforces access control, not information flow. The distinction is essential. Access control answers "can this subject perform this operation on this object?" in O(1) at operation time. Information flow asks "does the final state of this system contain any information derived from data the subject was not authorised to read?" That is undecidable.

What this means for UAC: even when MIC perfectly enforces NO_WRITE_UP, a Low-IL process can still influence a High-IL process via shared state the High-IL process reads. Forshaw's January 2026 lazy DOS device directory hijack [@forshaw-adminprot-jan26] is exactly such an attack: it places attacker-controlled state in a location a High-IL process will later read, without ever writing up directly. MIC cannot prevent this; no access-control primitive can. Closing the gap requires information-flow analysis, which is provably undecidable for arbitrary code.

The five concrete limits

The theoretical bounds map onto five concrete limits any practitioner can observe on a default Windows 11 install.

The first limit is that no-write-up does not imply no-influence-up. A Low-IL process cannot write to High-IL objects directly, but it can place state (registry keys, files, environment variables, named objects) that a High-IL process will subsequently read or be influenced by. Every fileless UAC bypass in §7.1 walks through this gap.

The second limit is that NO_READ_UP is opt-in [@mic-doc]. By default, a Low-IL process can read a High-IL file. This is intentional: accessibility tools, antivirus, and diagnostic utilities depend on cross-IL reads. The cost is that any High-IL data placed at a default-policy location is readable by every Medium-IL or lower process on the system.

The third limit is that UIPI covers only the windowing layer. Sockets, named pipes, COM, RPC, shared memory, MIDL-defined RPC interfaces, and every other inter-process channel that does not go through win32k.sys is out of scope [@uipi-wiki]. UIPI is necessary, but it is not sufficient for cross-IL isolation; the full bound requires MIC on the file system, the registry, and every named object the higher-IL process might consume.

The fourth limit is the same-IL same-desktop attack surface. Two Medium-IL processes on the user's Default desktop are not isolated from each other by either MIC or UIPI. They have the same IL (no MIC bound) and they own windows on the same desktop with the same IL (no UIPI bound). Every modern browser sandbox addresses this separately, by combining MIC (the renderer runs at Low IL or Untrusted IL) with AppContainer (capability-based identity isolation) and restricted tokens (CreateRestrictedToken-style SID denial) [@chromium-sandbox][@appcontainer-isolation]. Where MIC alone is insufficient, the stack layers additional primitives, but those primitives are additions to MIC, not replacements for it.

The fifth limit is the auto-elevated-binary surface. As long as a Medium-IL process can cause a High-IL process to come into existence executing user-controllable inputs (registry handlers, DLL search-order resolution, COM moniker activation, command-line arguments), the bypass-research industry has architectural space to operate. The fix would be to apply the Invocation Property strictly, which would break elevation.

Why MIC has to be a separate evaluator

The Harrison-Ruzzo-Ullman 1976 result is the theoretical reason MIC could not be implemented as discretionary ACEs [@hru-1976]. HRU prove that the safety question (given an initial access matrix, will any future sequence of operations cause subject $s$ to acquire permission $p$ on object $o$?) is undecidable for the general access-matrix model. That undecidability is what makes mandatory policy necessary as a separate evaluator: if integrity were encoded as discretionary ACEs, the safety of an object's integrity label would inherit HRU undecidability through every principal with rights over the ACE.

By making MIC a separate evaluator with non-discretionary semantics, Windows answers the integrity-safety question in O(1) per access check: compare two SIDs, consult three policy bits, decide. The decidability comes from the separation. MIC is bounded because it is structurally simpler.

None of the bypass classes in §7 violate any of these limits. They all operate within them. The registry-hijack class places Low-IL state where a High-IL reader will consume it (limit #1). The DLL-search-order class abuses the auto-elevated-binary surface (limit #5). The COM-behaviour-abuse class operates on the absent Invocation Property. Microsoft's response, repeated for sixteen years, was to acknowledge these as architectural realities of the design rather than as bugs to fix. The bypass-research literature is the empirical map of the access-control versus information-flow gap that no mainstream OS has closed.

Did Microsoft ever try to actually move the boundary? What does it look like when a security feature finally becomes a security boundary?

9. The Adminless Successor and the Open Problems

In November 2024, Microsoft did something it had not done in seventeen years. It moved the security-boundary line. Administrator Protection, announced as a Windows 11 platform feature, became the first generation in the integrity-level lineage that Microsoft classifies as a security boundary [@admin-protection][@msft-devblog-adminprot]. The reclassification is structurally substantial. It is not Microsoft renaming UAC; it is Microsoft adding the architectural primitives a boundary classification requires.

What the split-token model shared, and what Administrator Protection separates

The four shared properties between the filtered token and the linked token were the structural reason UAC could not be a security boundary. They are listed verbatim in Forshaw's May 2017 Reading Your Way Around UAC framing [@forshaw-reading-uac]: same user SID, same %USERPROFILE%, same HKCU hive, same logon-session LUID. Administrator Protection attacks all four.

The per-user separate identity Windows 11 Administrator Protection provisions at first elevation. Has a different SID, `%USERPROFILE%`, `HKCU` hive, and LUID from the calling user, defeating the registry-hijack class of UAC bypasses by structurally separating elevated-process state from the caller's state.

Property	2007 Split-Token (UAC)	2024 Administrator Protection
User SID	Same as caller	Different (per-user System Managed Administrator Account, SMAA)
`%USERPROFILE%`	Same as caller	Different: `C:\Users\ADMIN_<random>\`
`HKCU` registry hive	Same hive as caller	Different hive (per-SMAA)
Logon session LUID	Same session as caller	Fresh logon session per elevation
Authentication	Consent click only	Windows Hello integrated authentication
Classification	Security feature, not boundary	Security boundary

SMAA expands as "System Managed Administrator Account" per the May 19, 2025 Microsoft Windows Developer Blog explainer Enhance your application security with Administrator protection [@msft-devblog-adminprot]. Earlier Microsoft Learn documentation from 2024 used the working name "Adminless" without the SMAA acronym. The corpus's Adminless / Administrator Protection article (#52) covers the SMAA lifecycle and the Insider-Preview timeline in more depth than this article does.

The concrete operational consequence of the SMAA identity change is structural defeat of the entire registry-hijack class. When an attacker writes the canonical fodhelper bypass key to HKCU\Software\Classes\ms-settings\shell\open\command, the attacker writes to the caller's HKCU hive. When fodhelper.exe is then elevated under Administrator Protection, the elevated process runs under the SMAA identity, with the SMAA's own HKCU hive, which does not contain the attacker's key. The auto-elevated binary resolves the ms-settings association via the SMAA's HKCU, falls through to HKLM, and gets the legitimate handler. The attacker's bypass is structurally defeated by the identity change, not by a per-binary fix [@admin-protection][@forshaw-adminprot-jan26].

The 2025 timeline

Administrator Protection's rollout has been incremental. Microsoft released it as an opt-in toggle in early 2024 Insider Preview builds, then shipped a generally-available implementation in optional update KB5067036 on October 28, 2025 [@forshaw-adminprot-jan26]. The Microsoft Learn Administrator protection page acknowledges a temporary revert on December 1, 2025 "while an application compatibility issue is dealt with" [@admin-protection][@forshaw-adminprot-jan26]. The expected re-enablement is in 2026.

Forshaw's January 26, 2026 Project Zero post Bypassing Windows Administrator Protection documents the application-compatibility revert with verbatim precision. He notes that "the issue is unlikely to be related to anything described in this blog post," meaning that the December 2025 revert was a third-party application compatibility regression rather than a security issue with the feature itself [@forshaw-adminprot-jan26]. The revert is operational, not architectural.

The 2026 retrospective: nine bypasses, five via UI Access

Forshaw's January and February 2026 Project Zero pair is the canonical modern retrospective on Administrator Protection's architectural maturity. The January post documents nine separate Administrator Protection bypasses Forshaw reported to Microsoft during the Insider Preview cycle, all of which were fixed before general availability [@forshaw-adminprot-jan26]. The post details one in depth (the lazy DOS device directory hijack) and summarises the rest.

If the weaknesses in UAC can be mitigated then it can be made a secure boundary. -- James Forshaw, *Bypassing Windows Administrator Protection*, Project Zero, January 26, 2026

The February 2026 follow-on post, Bypassing Administrator Protection by Abusing UI Access, is the more architecturally significant of the pair. It documents that five of the nine pre-GA Administrator Protection bypasses operated entirely through the uiAccess=true exemption, the long-standing UIPI carve-out for accessibility software inherited unchanged from Vista 2007 [@forshaw-adminprot-feb26].

The reading is structural. Administrator Protection successfully closes the bypass surface that the split-token model's shared identity created (limit #1 through limit #4 in §8). It does not close the bypass surface created by the UI Access carve-out, because UI Access is a deliberate exemption from UIPI. Closing UI Access would break screen readers, on-screen keyboards, remote-control tools, and every accessibility utility that depends on cross-IL window-message access. The exemption is necessary; the residual attack surface is the cost of accessibility.

The three gating conditions for uiAccess=true (manifest assertion, valid Authenticode signature, admin-only install location) are documented in the Security Considerations for Assistive Technologies Microsoft Learn page [@uia-security]. Forshaw's February 2026 post enumerates them verbatim and describes the RAiLaunchAdminProcess Appinfo RPC entry point the UI-Access bypasses operate through [@forshaw-adminprot-feb26]. The trade press picked up the story immediately: The Register covered Forshaw's January 2026 post under the headline "Google researcher sits on UAC bypass for ages, only for it to become valid with new security feature" on January 28, 2026 [@register-2026].

The downstream legacy

MIC and UIPI outlived UAC. The integrity-SID primitive is the connective tissue of every later sandbox model on Windows.

flowchart TD A["Integrity-SID primitive
(MIC + UIPI, Vista 2006/2007)"] --> B["AppContainer
(Windows 8, 2012)"] A --> C["IE Protected Mode
(IE7, Vista 2006)"] A --> D["Edge / Chrome / Firefox sandbox tiers
(2008-present)"] A --> E["Protected Process Light
(Windows 8.1, 2013)"] A --> F["Administrator Protection / SMAA
(Windows 11, 2024)"] A --> G["RunAsPPL for LSASS
(Windows 8.1, 2013)"] A --> H["Office Protected View
(Office 2010+)"]

AppContainer (Windows 8, 2012) layers package SIDs above the integrity SID and rides the same SeAccessCheck infrastructure [@appcontainer-isolation]. IE Protected Mode (Windows Vista IE7, 2006) was the first non-UAC consumer of Low IL, running browser-rendered content as a Low-IL process before the user's Medium-IL interactive shell. Modern browser sandbox tiers (Chrome, Edge, Firefox content processes) use Low-IL or Untrusted-IL sandbox processes, layered with AppContainer and restricted tokens [@chromium-sandbox]. Protected Process Light (Windows 8.1, 2013) is a signature-based generalisation of the integrity-SID concept that PPL-protects LSASS against OpenProcess by lower-IL callers. Administrator Protection itself uses the integrity-SID primitive: SMAA processes run at High IL while the calling Medium-IL admin shell stays Medium [@admin-protection].

The twenty-year experiment was a success. The integrity-level stack did exactly what it was designed to do: bound integrity, not authority. The consent prompt was honestly never the security boundary. Microsoft's November 2024 reclassification finally promotes a feature to a boundary by adding the architectural support the boundary classification requires (separate identity, separate profile, separate hive, separate LUID, Windows Hello-mediated transition). The bypass-research literature is the empirical proof that the 2007 disclaimer was honest, and the proof that the architecture worked exactly as architected.

Key idea: MIC and UIPI outlived UAC. The integrity-SID primitive is the connective tissue of AppContainer, every modern browser sandbox, Protected Mode, Protected Process Light, and the Administrator Protection successor. The yellow dialog is the smallest, most replaceable piece of the system.

On December 1, 2025, Microsoft temporarily reverted Administrator Protection in KB5067036 pending an application-compatibility fix [@admin-protection][@forshaw-adminprot-jan26]. Forshaw's exact framing matters: "the issue is unlikely to be related to anything described in this blog post." The revert was *not* a security regression; it was a third-party application-compatibility issue, with re-enablement expected in 2026. As of May 2026, Administrator Protection can be enabled manually on Windows 11 24H2 and later but is not the default on consumer or enterprise SKUs pending re-enablement [@admin-protection].

10. Inspecting the Stack on a Real Box

Every primitive in this article is observable on the Windows install you are reading on. Here are the five commands and the two tools that will let you walk the stack yourself.

Inspecting integrity levels

whoami /groups | findstr Mandatory prints the mandatory label of the current process token. From an unelevated PowerShell on an administrator account, it will read Mandatory Label\Medium Mandatory Level. From an elevated PowerShell, it will read Mandatory Label\High Mandatory Level. From a renderer-process command inside a Chromium-based browser, it would read Mandatory Label\Low Mandatory Level or Untrusted Mandatory Level, depending on the sandbox tier.

whoami /all is the longer view. It prints every group SID, every privilege, and the full mandatory label.Process Explorer (and System Informer) will show you the same data graphically, but whoami is the canonical first-party command for getting at the same kernel information from the shell. Run it twice -- once from an unelevated PowerShell, once from an elevated PowerShell on the same admin account -- and diff the outputs to see what the elevation actually changed. That is the empirical re-creation of §1's hook.

Sysinternals' Process Explorer has an Integrity column you can add via View / Select Columns / Process Image. Once enabled, it shows the IL of every running process at a glance. System Informer (the open-source Process Explorer successor) supports the same column plus richer SACL inspection. The accesschk -e -l <object> Sysinternals command prints the mandatory label of a file, registry key, or other securable object: accesschk -e -l C:\Windows\System32\drivers\ reveals the System-IL label that protects the driver directory.

The PowerShell-native equivalent of `whoami /all` that programs can consume is:

[System.Security.Principal.WindowsIdentity]::GetCurrent() |
  Select-Object -ExpandProperty Groups |
  ForEach-Object { $_.Translate([System.Security.Principal.NTAccount]) }

This produces the same SID-to-account-name resolution whoami /groups does, and is useful inside automation that needs to test deny-only group membership programmatically.

Inspecting UIPI

UIPI is harder to observe directly because the OS does not log dropped messages. The practical demonstration is to run Spy++ (the Visual Studio windowing inspector) from a Medium-IL process and attempt to subclass a window owned by an elevated High-IL process. The subclass call silently fails. SendMessage returns 0 with GetLastError reading ERROR_ACCESS_DENIED. The ChangeWindowMessageFilterEx documentation page is the Microsoft Learn entry point for understanding the per-window, per-message exemption surface [@changewindowfilter].

Enumerating the auto-elevation list

sigcheck -m C:\Windows\System32\*.exe | findstr /i autoelevate walks every executable in System32 and prints the manifest of each. The findstr filter narrows to lines containing autoElevate, surfacing the binaries that assert the manifest flag. On a Windows 11 25H2 install, the resulting list runs to thirty to forty binaries. Remember that the manifest-asserting list is not the same as Appinfo's internal operational allowlist; the operational subset is what UACMe enumerates [@uacme].

Watching Appinfo in action

Procmon (Sysinternals Process Monitor) filtered on consent.exe shows every elevation event: the registry reads against the manifest, the SACL reads on the binary, the token-information queries against the caller's filtered token. The Windows Event Viewer's Applications and Services Logs / Microsoft / Windows / User Account Control channel logs elevation events at the OS level. The combination of Procmon (mechanism) and the Event Viewer (audit trail) is the standard observability surface for elevation operations.

A safe lab for the bypass classes

UACMe is the community catalogue of 81 documented UAC bypass methods, each with author, technique, target binary, and Windows-version applicability annotations [@uacme]. For inspection of the integrity-level state of running processes from an analyst's workstation, James Forshaw's sandbox-attacksurface-analysis-tools repository (the NtObjectManager, TokenViewer, and NtCoreLib PowerShell modules) is the standard research toolchain [@forshaw-tools]. The UACMe reference implementations (akagi32.exe, akagi64.exe) are flagged by Microsoft Defender as HackTool:Win32/Welevate, the detection name Davidson noted as early as 2009 [@davidson-2009]. This is research tooling, not endpoint operations: run UACMe only on a snapshot VM with Defender exclusions documented, and treat the output as an empirical confirmation of the bypass-research record rather than as an offensive primitive.

Note: The minimum five commands a reader can run on their own Windows box to verify everything in this article: 1. whoami /all (run twice: once unelevated, once elevated; diff the outputs) 2. whoami /groups | findstr Mandatory (inspect the IL of the current token) 3. sigcheck -m C:\Windows\System32\eventvwr.exe (read the autoElevate manifest) 4. tasklist /v /fi "imagename eq svchost.exe" | findstr Appinfo (confirm the Appinfo service host) 5. Process Explorer with the Integrity column enabled, sorted by IL (the entire stack at a glance) The whole tour takes ten minutes. By the end you will have seen the split-token model, the integrity-level lattice, the auto-elevation allowlist, the Appinfo broker, and the Medium-vs-High distribution of your interactive desktop, with your own eyes.

11. Five Misconceptions That Will Not Die

Five UAC misconceptions come up so often in practitioner discussions that any complete treatment owes the reader explicit corrections. Two practical questions round out the FAQ.

No, and Microsoft's own documentation has said so since February 2007. The canonical "Neither UAC elevations nor Protected Mode IE define new Windows security boundaries" sentence appears in the *PsExec, User Account Control and Security Boundaries* TechNet Blogs post by Mark Russinovich, dated February 12, 2007 -- see §7.4 for the full quote and the citation-chain disambiguation against the *Inside Windows Vista User Account Control* TechNet Magazine architectural article [@russinovich-blog-2007][@russinovich-tnm-2007]. The boundary line was finally moved in November 2024 with Administrator Protection, which Microsoft does classify as a security boundary [@admin-protection][@forshaw-adminprot-jan26]. The original split-token UAC was never a boundary, by design, and the bypass-research record from 2009 to 2024 is the empirical confirmation that the disclaimer was honest. No. The Secure Desktop is on the `Winlogon` desktop within `WinSta0`, *within* the user's interactive session (Session 1, 2, ...) -- §6.1 walks the full Object-Manager hierarchy and contrasts it with the separate Vista Session 0 Isolation feature that moved Windows services into a non-interactive Session 0 [@russinovich-tnm-2007]. The two features ship together in Vista and are constantly confused, but they live at different layers of the Object Manager hierarchy and address different threats. No. The manifest entry is necessary but not sufficient. Appinfo enforces three additional gates: the binary must carry a valid Microsoft Authenticode signature, the binary must reside under a trusted system directory (`%SystemRoot%\System32` or `%SystemRoot%\SysWOW64`), and the binary's name must appear on an internal allowlist enforced in code in `appinfo.dll`, not in any user-visible policy file [@davidson-2009][@app-manifests]. Copying `autoElevate=true` into your own binary's manifest does nothing on its own. The community-standard enumeration technique is `sigcheck -m C:\Windows\System32\*.exe | findstr /i autoelevate`, but that enumerates the manifest-asserting set, not the operational allowlist. No -- UIPI blocks a specific dangerous subset (window-state mutators, hooks, input injection, journal record / playback); mouse messages, most paint messages, and read-only window queries pass. The complete row-by-row enumeration of blocked vs allowed vs degraded-but-passes message classes is in the §4.2 table. The "blocks all `WM_*`" misconception is one of the most common errors in Windows-security literature [@uipi-wiki][@russinovich-blog-2007]. No. `ShellExecuteEx` with the `"runas"` verb is whole-process elevation: Appinfo creates a new process under the caller's linked full token, and the new process runs at High IL for its entire lifetime [@shellexecuteexa]. The COM Elevation Moniker is per-object elevation: a Medium-IL caller instantiates a single COM object in a new elevated `dllhost.exe` exposing only that one CLSID's methods at High IL [@com-elevation-moniker]. The caller stays Medium; only the COM object's host process is elevated. The bypass-research literature attacks the second surface far more than the first, because per-object elevation exposes a narrower, more abusable *behavioural* surface (the methods of one CLSID), while whole-process elevation requires a path-class bypass like DLL-search-order to weaponise. Partially. The registry-hijack class (the eventvwr / fodhelper / sdclt / ComputerDefaults family from 2016-2017) is structurally defeated by the SMAA identity change: the attacker writes to the caller's HKCU hive, but the elevated process runs under the SMAA's different HKCU hive and never consults the attacker's key [@admin-protection]. The DLL-search-order class is partially mitigated by the SMAA's different `%USERPROFILE%` and different working directory. The UI Access class is *not* mitigated: it is the long-standing carve-out for accessibility software, inherited unchanged from Vista 2007, and Forshaw's February 2026 Project Zero post documents that this carve-out carried five of nine pre-GA Administrator Protection bypasses [@forshaw-adminprot-feb26]. UACMe remains the canonical operational catalogue for the bypass classes that survive Administrator Protection. No. Setting `EnableLUA=0` in `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System` reverts the OS to the pre-Vista posture: no split-token model, every admin-account process running High-IL by default, every interactive shell holding the full admin SID set and the complete privilege list. The integrity-level *primitive* (MIC) remains in the kernel; the *policy* that makes it operationally useful (the default-Medium-IL filtered token for interactive admins) is disabled. Browser sandbox tiers still function, because they construct restricted Low-IL tokens explicitly. The admin's daily shell does not benefit, and a malware drop in any process under the admin's interactive session immediately holds High IL [@uac-how-it-works]. This is structurally the XP situation. Leaving `EnableLUA=1` (the default) is correct on every modern Windows install.

12. The Plumbing Outlived the Yellow Dialog

Return to the two whoami outputs from §1. The user is the same. The session is the same. The clock has barely moved. Read them again, and now read what each line means.

The administrator group SID was present in both tokens, marked deny-only on the filtered token and enabled on the elevated token. The integrity level changed from Medium (S-1-16-8192) to High (S-1-16-12288). The privilege set expanded from the small user-mode subset to the full administrator set. The bits that moved were the kernel-level token-assignment bits in the new process Appinfo created via CreateProcessAsUser, using the dormant linked token that LSA had constructed thirty minutes earlier at logon. The yellow dialog was the consent surface on top of a token-swap primitive that existed before the dialog rendered and that can move bits without the dialog (via auto-elevation).

Four primitives carried the work. Mandatory Integrity Control added an axis to the access check that runs before the DACL and short-circuits on a Low-to-High write attempt, regardless of what the DACL says. User Interface Privilege Isolation closed the cross-IL variant of the shatter-attack class that Paget published in 2002, by dropping the dangerous subset of window messages and hook calls from lower-IL senders to higher-IL receivers. The split-token model gave every administrator a Medium-IL filtered token at logon and held the full token dormant. The Appinfo SYSTEM-trusted broker mediated the token swap when consent or auto-elevation called for it.

The bypass-research industry of 2009 to 2024 was the empirical confirmation of the architect's 2007 disclaimer. Davidson's December 2009 essay opened the auto-elevation surface; Nelson's 2016-2017 series productised the registry-hijack class; hfiref0x's UACMe catalogued 81 methods and counting; Forshaw's 2017 Reading Your Way Around UAC series named the read-side surface; the cumulative record was a sixteen-year demonstration that UAC was not a security boundary, exactly as Russinovich had publicly stated in February 2007. Microsoft never classified any of these as security vulnerabilities, because the architectural commitment from week one had been that they would not be [@russinovich-blog-2007][@msrc-criteria].

The November 2024 Administrator Protection reclassification is the line finally moving. The split-token model's four shared properties between filtered and linked tokens (same SID, same %USERPROFILE%, same HKCU, same LUID) are replaced by an SMAA identity that differs on all four dimensions, plus Windows Hello-mediated authentication for every elevation [@admin-protection][@msft-devblog-adminprot]. The registry-hijack class is structurally defeated; the residual surface is the UI Access carve-out inherited unchanged from Vista 2007, which Forshaw's February 2026 Project Zero post documents as the source of five of nine pre-GA bypasses [@forshaw-adminprot-feb26].

The yellow dialog is the only piece of UAC most users will ever see. It is also the one piece the OS could replace tomorrow without changing what UAC is. MIC and UIPI outlived UAC. AppContainer, every modern browser sandbox, IE Protected Mode, Office Protected View, Protected Process Light, and Administrator Protection itself all ride on the integrity-SID and WinSta0 primitives that shipped on January 30, 2007 [@vista-press-release][@appcontainer-isolation][@chromium-sandbox]. The quiet plumbing did the work.

Next time you click "Yes" on the consent prompt, the bits that move are the same bits that move when Edge spawns a renderer at Low IL, when Defender protects LSASS as PPL, and when a SMAA process shadows your administrator identity on a Windows 11 25H2 install with Administrator Protection enabled. The dialog is the smallest part of the system. Twenty years of empirical research proved the architect right: UAC was never the boundary. The integrity-level stack was, and is [@russinovich-blog-2007][@admin-protection].

<StudyGuide slug="integrity-level-stack-mic-uipi-uac" keyTerms={[ { term: "Mandatory Integrity Control (MIC)", definition: "An access-check evaluator that compares the integrity level of a subject token to the integrity level of a target object before consulting the object's DACL. Denials short-circuit the access check; integrity beats identity." }, { term: "Integrity Level (IL)", definition: "A well-known SID under S-1-16-X carried on every token and securable object. Seven values: Untrusted, Low, Medium, Medium Plus, High, System, Protected Process." }, { term: "User Interface Privilege Isolation (UIPI)", definition: "The windowing-layer analog of MIC. Blocks dangerous window messages, hooks, and input injection from lower-IL processes targeting higher-IL windows on the same desktop." }, { term: "Split-token model", definition: "Admin Approval Mode: an administrator's logon produces a Medium-IL filtered token plus a dormant High-IL linked token. The filtered token runs the interactive shell." }, { term: "Secure Desktop", definition: "A separate desktop object (Winlogon) within WinSta0 in the user's interactive session, on which consent.exe renders the UAC prompt. Not Session 0." }, { term: "Application Information service (Appinfo)", definition: "The SYSTEM-trusted Windows service that mediates the filtered-to-linked token swap at elevation time. Exposes RAiLaunchAdminProcess." }, { term: "Auto-elevation allowlist", definition: "The internal Appinfo allowlist of Microsoft-signed binaries in trusted directories whose manifests assert autoElevate=true. Four gates: manifest, signature, path, allowlist entry." }, { term: "COM Elevation Moniker", definition: "Per-object elevation via Elevation:Administrator!new:{CLSID}. Spins up a single CLSID in an isolated High-IL dllhost.exe while the caller stays Medium." }, { term: "System Managed Administrator Account (SMAA)", definition: "The per-user separate identity Administrator Protection provisions at first elevation. Different SID, profile, HKCU, LUID from the calling user." }, { term: "Biba Star Integrity Property", definition: "No write up: a subject at integrity level Is cannot write an object at integrity level Io > Is. MIC implements this as the default NO_WRITE_UP policy." } ]} questions={[ { q: "Why is MIC a separate evaluator rather than another ACE in the DACL?", a: "Because DACLs are discretionary by definition; an object owner can rewrite the DACL. MIC's mandatory semantics require an evaluator that runs before the DACL and cannot be overridden by it. The HRU 1976 undecidability of the access-matrix safety question is the formal reason mandatory policy cannot be encoded as discretionary ACEs and remain decidable." }, { q: "Why doesn't the consent prompt elevate?", a: "Because the elevated token was constructed at logon by LSA, not at consent time by the prompt. The prompt asks the user whether the OS may use the already-existing linked full token to launch a new process. The token swap is performed by Appinfo, not by consent.exe; the prompt is the consent surface on top of a token-swap primitive." }, { q: "Why does UIPI block WM_SETTEXT but not WM_PAINT?", a: "Because WM_SETTEXT mutates the receiving window's state (the message replaces the window's text), and an attacker who can mutate a higher-IL window's state has gained influence over the higher-IL process. WM_PAINT only asks the window to redraw itself; it carries no attacker-controlled mutation, so allowing it from lower-IL senders is safe." }, { q: "Which Biba rules does MIC actually implement?", a: "Just one. MIC implements the Star Integrity Property (NO_WRITE_UP) as the default policy on every object that does not specify otherwise. MIC does not implement Biba's Simple Integrity Property (no read down) at all -- there is no NO_READ_DOWN policy in winnt.h. The opt-in NO_READ_UP bit MIC exposes is structurally a Bell-LaPadula simple-security analog applied to integrity SIDs, not a Biba rule. MIC does not implement the Invocation Property either; brokered elevation (COM Elevation Moniker, ShellExecuteEx 'runas', Appinfo) is the operationally usable workaround." }, { q: "What changed in November 2024 that turned UAC's elevation transition into a security boundary?", a: "Administrator Protection replaced the split-token model's four shared properties (same SID, same %USERPROFILE%, same HKCU, same LUID) with a System Managed Administrator Account that differs on all four dimensions, and required Windows Hello integrated authentication for every elevation. The structural identity separation defeats the entire registry-hijack bypass class. The residual surface is the UI Access carve-out inherited unchanged from Vista 2007." } ]} />

Windows Security Boundaries: The Document That Decides What Gets a CVE

noreply@paragmali.com (Parag Mali) — Sun, 24 May 2026 00:00:00 GMT

**Microsoft maintains a single public document that decides which Windows vulnerability reports receive a CVE, a Patch Tuesday bulletin, and a bounty payout, and which receive "by design."** The *Security Servicing Criteria for Windows* enumerates nine security **boundaries** (network, process, kernel, session, user, AppContainer, virtual machine, Virtual Trust Level, and as of 2025, the Administrator Protection elevation path) and seven security **features** (UAC, Microsoft Defender, HVCI, Driver Signing, Protected Process Light, admin-to-kernel privilege escalation, same-user post-authentication). A two-question triage rule generates every MSRC disposition, including every "by design -- UAC is not a security boundary" reply you have ever read. Reading the doctrine is the difference between filing a useful MSRC report and getting back one polite sentence.

1. A UAC Bypass Walks Into MSRC

Three weeks of reverse engineering. A clean video of consent.exe being skipped via a registry-hijack technique. A report filed through msrc.microsoft.com/report. Two business days later, the Microsoft Security Response Center replies in one sentence: "Thank you for the report. UAC is not a security boundary; please refer to the Microsoft Security Servicing Criteria for Windows. This issue is by design."

That sentence has been Microsoft's consistent position since June 2007 [@russinovich-vista-uac-wayback]. It is the operational anchor of every Windows vulnerability disposition made in the last nineteen years, and it routes through a single public document most researchers have never read.

The document is called the Microsoft Security Servicing Criteria for Windows [@msrc-criteria]. Twenty-eight paragraphs and two enumerated tables live on a single MSRC web page. Those paragraphs decide which Windows findings get a CVE number, which get a Patch Tuesday bulletin, which get a bounty payout, and which get a polite "by design" reply that closes the ticket without a fix. Every other operational artifact in Microsoft's security response -- the bounty schedule, the monthly bulletin calendar, the per-finding severity ratings -- is downstream of this one taxonomy.

Note: The "by design" reply is not boilerplate. Every MSRC triage engineer who issues it is applying a specific clause of a specific document. The reply means: we read your finding, mapped it against our published classification, and the primitive you attacked is on our security-feature list rather than our security-boundary list. We may still harden the feature in a future build, but we are not going to assign a CVE or ship a Patch Tuesday bulletin for it. The classification is published. The disposition follows from the classification.

The researcher's first reaction is the natural one. Three weeks of work. A working bypass. A Microsoft binary skipped. And the reply is one sentence?

It is right, and the rest of this article is the explanation of why. We will walk the document's history from a single June 2007 TechNet article through the November 2024 Administrator Protection announcement, decode the two-question triage rule that generates every MSRC disposition, take each of the nine boundaries and each of the seven features in turn, and finish with a checklist for filing a report that does not come back "by design."

To understand why the reply was operationally correct, not a cop-out, we have to walk the document's history back to its origin: a single article published in TechNet Magazine in June 2007, by an author Microsoft had named a Technical Fellow just five months before.

2. The Pre-Doctrine Era

For the first fourteen years of Windows NT, there was no servicing-criteria document. There did not need to be.

Windows NT 3.1 (July 1993) shipped with the architectural pieces every later boundary entry would rest on: the user-mode/kernel-mode privilege split enforced by the CPU's ring transitions, securable kernel objects mediated by the reference monitor's SeAccessCheck primitive, the Security Account Manager (SAM) database with per-user Security Identifiers (SIDs), discretionary access control lists, and access tokens that travelled with every thread [@openlib-custer-nt]. The kernel boundary -- user-mode code MUST NOT execute kernel code without a syscall transition -- and the user boundary -- one user's process MUST NOT read another user's data without permission -- were born here as primitives, two decades before either would be enumerated in a vendor-disclosure document.

But the architecture was not a doctrine. The boundaries sat implicitly inside Helen Custer's Inside Windows NT (Microsoft Press, 1992) and a handful of internal MSDN reference monographs. A researcher reporting a finding in 1998 could not look up "is this a boundary?" anywhere they were authorised to read.

A *security boundary* provides a logical separation between the code and data of security domains with different levels of trust [@msrc-criteria]. The defining requirement is that security policy dictates what can pass through the boundary -- a guarantee, not a hint. A *security feature*, by contrast, raises the difficulty of attack but carries no vendor commitment that the separation will hold. This distinction, articulated by Mark Russinovich in 2007, is the load-bearing taxonomy of the entire MSRC triage process.

Three failures accumulated pressure during the implicit-boundary era.

The Power Users group. Microsoft documented the Power Users group on Windows 2000 and XP as a "less-privileged-than-administrator" middle tier. Microsoft Knowledge Base article KB 825069 eventually conceded that members could obtain administrator rights through multiple privilege paths (the article has since been retired).The Power Users group survived through Windows Server 2003 and was finally dropped from the default Windows Vista install. The lesson stuck: a tier presented as a separation without a policy-enforced guarantee is not a separation at all. The Russinovich convenience-vs-boundary distinction inherits the lesson. A tier presented operationally as a boundary that turned out never to have been one.

The wormable RCE class of 2001-2003. Code Red (July 2001) and the RPC DCOM Blaster worm (August 2003) compromised millions of internet-connected Windows hosts [@caida-code-red], [@cert-vu-568148]. Microsoft shipped MS03-026 with Critical severity for the Blaster RPC interface vulnerability [@ms-bulletin-ms03-026]. Operationally, the events made one thing legible: there was no place in the kernel architecture you could point at and say "this is the network boundary that held." There was a buffer overflow, an unauthenticated RPC call, and a worm.

The 2002 Shatter class. In August 2002, a researcher posting under the handle "Foon" (Chris Paget) disclosed to NTBugtraq that any process on the interactive desktop could drive any other process's windows via Win32 messages [@helpnetsecurity-shatter-2002]. That included SYSTEM-level services with windows on the same desktop, turning every interactive service into a local privilege-escalation surface. Brett Moore generalised the class the following year in Shattering By Example, walking message types like WM_SETTEXT, SB_SETTEXT, and SB_GETTEXTLENGTH and turning a one-off bug into a systematic primitive [@exploit-db-21691]. Microsoft's initial response framed the problem as architectural-by-design rather than as a vulnerability. The community could not predict that response, because the boundary was nowhere written down.

timeline title Pre-doctrine era (NT 3.1 to Vista RTM) 1993 : Windows NT 3.1 ships with SeAccessCheck and per-user SIDs 1995 : Windows NT 3.51 and the SAM database stabilise 1996 : Windows NT 4.0 ships with the Power Users group 2000 : Windows 2000 introduces Active Directory 2001 : Code Red worm compromises IIS hosts at internet scale 2002 : Chris Paget discloses Shatter via NTBugtraq 2002 : Bill Gates Trustworthy Computing memo reorders Microsoft priorities 2003 : Brett Moore generalises Shatter in Shattering By Example 2003 : RPC DCOM Blaster worm and MS03-026 2006 : Russinovich joins Microsoft via Winternals acquisition 2006 : Windows Vista RTM ships with UAC, MIC, UIPI, and Session 0 isolation 2007 : Russinovich promoted to Technical Fellow

The combined pressure forced Bill Gates's January 15, 2002 Trustworthy Computing memo -- "Trustworthy Computing is the highest priority for all the work we are doing" [@wired-twc-memo]. The memo did not itself contain a boundary taxonomy. It reorganised engineering priorities so that one could be written.

By the November 2006 Vista launch, the mechanisms were in the box. Windows Vista shipped with User Account Control, the linked-token split, Mandatory Integrity Control, the User Interface Privilege Isolation (UIPI) shield, and Session 0 isolation [@ms-news-vista-launch]. By June 2007, those mechanisms had names. The document the next two decades of Windows vulnerability disclosure would route through was about to be written -- not by an MSRC document committee, but by a single Technical Fellow Microsoft had promoted to the title five months earlier.

3. Russinovich, June 2007, and the Birth of the Distinction

In the June 2007 issue of TechNet Magazine, Mark Russinovich -- promoted to Technical Fellow that January, after joining Microsoft via the July 2006 Winternals acquisition -- published a single article that would dictate the disposition of every Windows vulnerability filed for the next nineteen years. The article was Inside Windows Vista User Account Control [@russinovich-vista-uac-wayback]. Its load-bearing section, Elevations and Security Boundaries, ran two paragraphs.

It's important to be aware that UAC elevations are conveniences and not security boundaries. A security boundary requires that security policy dictates what can pass through the boundary. User accounts are an example of a security boundary in Windows because one user can't access the data belonging to another user without having that user's permission. -- Mark Russinovich, *Inside Windows Vista User Account Control*, TechNet Magazine, June 2007

The article was first published on TechNet on May 23, 2007 and ran in the June issue of the magazine [@russinovich-vista-uac-announce]. That sentence is the doctrinal origin point. Three architectural ideas appear in it: boundaries exist, they are different from features, and UAC sits on the feature side.

Russinovich then walked the structural reason. The Vista UAC split-token model shares a great deal between the standard-user token and the elevated-administrator token [@russinovich-vista-uac-wayback]: the same SID, the same %USERPROFILE% directory, the same HKEY_CURRENT_USER registry hive, the same logon session, and the same DOS device object directory. Those shared resources are the reason the elevation path cannot be a guaranteed separation. An attacker running at standard integrity on the same desktop can interact with the elevated process's window station, its named objects, and its user-writable files. The convenience is real -- prompting before a privileged operation is a high-friction barrier against accidental elevation. The guarantee is not.

flowchart TD User[Interactive user logs on] User --> Linked[Linked-token logon] Linked --> Standard[Standard-user token] Linked --> Elevated[Elevated administrator token] subgraph Shared[Shared resources between the two tokens] SID[Same user SID] Profile[Same USERPROFILE] HKCU[Same HKCU hive] Session[Same logon session] Desktop[Same interactive desktop] end Standard -.-> Shared Elevated -.-> Shared Shared --> Verdict[No guaranteed separation = feature, not boundary]

The article identifies the real boundaries Windows enforces -- the user boundary (cross-user access requires explicit permission), the kernel boundary (the syscall gate), and the process boundary (one process cannot read another's memory without PROCESS_VM_READ access) -- as the lines policy does enforce. UAC sits among the features that make those boundaries cheaper to defend, not among the boundaries themselves.

The widely-circulated press narrative is that Microsoft *initially* called UAC a security boundary and *retracted* that classification in 2009 after the Zheng and Rivera research. This framing is false. Russinovich's June 2007 article already said verbatim that UAC elevations are "conveniences and not security boundaries." The position was on the record from Vista's first six months, two years before any 2009 Windows 7 beta disclosure. What Microsoft changed in 2009 was *implementation* -- the UAC slider began running at High integrity, UAC-settings changes began prompting -- not the classification. The Russinovich Windows 7 follow-up restated the original position word for word [@ms-learn-russinovich-win7].

The historical record matters because so much downstream doctrine rests on it. In late January 2009, Long Zheng and Rafael Rivera demonstrated a Windows 7 beta UAC auto-elevation flaw via rundll32.exe: Microsoft-signed binaries inside %SystemRoot% auto-elevated when invoked from a process holding the user's administrator token, and rundll32.exe accepted arbitrary DLL paths [@crn-uac-flaw-2009].The original istartedsomething.com post and the Ars Technica contemporary coverage have since been reorganised away by both sites; the CRN contemporary report (cited here) preserves the disclosure timeline, the rundll32.exe mechanism, and the Microsoft response. The historical claim is uncontested. What is contested is the framing of Microsoft's response, which primary sources show was implementation hardening, not a change in classification. Microsoft's initial reply ("by design; UAC is not a security boundary") was operationally consistent with the June 2007 article. The engineering response that followed -- UAC slider promoted to High integrity, UAC-settings changes prompting -- was implementation hardening, not reclassification. The doctrinal position did not move. Russinovich's July 2009 follow-up, Inside Windows 7 User Account Control, restated the convenience-vs-boundary argument with the same architectural reasoning [@ms-learn-russinovich-win7].

Russinovich's June 2007 article gave the community three ideas: boundaries exist; they are different from features; UAC sits on the feature side. The next step was to publish the table. That took roughly five years.

4. The Document Accumulates

Between 2007 and 2026, the boundary table grew by accretion. One new entry per Windows generation. The shape of the doctrine changed three times.

Generation 1 -- scattered prose (2007 to roughly 2010). Russinovich's June 2007 article, plus the July 2009 Inside Windows 7 User Account Control restatement, articulated the convenience-vs-boundary doctrine without a public enumeration. A reader of the two articles could correctly predict the disposition of a UAC bypass, and could correctly predict that user-to-user data access was a CVE-eligible boundary violation. They could not, from those articles alone, predict the disposition of a network-stack RCE, an AppContainer escape, or a guest-to-host virtual-machine break. The doctrine was consistent but it was not yet a document.

Generation 2 -- the enumerated MSRC page (roughly 2010 to 2015). The microsoft.com/en-us/msrc/windows-security-servicing-criteria page appears in something close to its current form. It states the two-question triage rule. It includes the verbatim definition of a security boundary. It enumerates a list of boundaries -- process, kernel, network, session, user, AppContainer, virtual machine, web browser -- and a parallel list of security features. The doctrine moves from a single magazine article to a vendor commitment with a URL [@msrc-criteria].The first-publication date of the page is folk knowledge. Wayback Machine snapshots survive from 2017 onward at the current URL slug. No Microsoft announcement post pins the exact date the page first appeared, so the "roughly 2010" figure is a community estimate rather than a documented birthday.

Generation 3 -- VTL added (2015 to 2017). Windows 10 1507 (RTM July 29, 2015) shipped Virtualization-Based Security, the Secure Kernel, Isolated User Mode (IUM), and the first canonical Trustlet -- LsaIso, the Credential Guard isolated LSA process. The boundary table grew a row whose enforcement primitive is the hypervisor itself: VTL0 (the normal kernel) cannot read or modify VTL1 (the Secure Kernel and IUM) without going through documented hypercalls [@ms-learn-vbs-ci]. The strongest local boundary on the system is now classified, not orphaned.

A *Trustlet* is a process that runs inside Isolated User Mode (IUM) -- the user-mode portion of VTL1 -- protected by the hypervisor from the normal-kernel VTL0 [@ms-learn-vbs-ci]. The canonical example is LsaIso, the Isolated LSA process that holds the credential material Credential Guard protects. Even a kernel-mode attacker in VTL0 cannot read the memory of a Trustlet running in VTL1; the hypervisor's second-level address translation tables do not map VTL1 pages into VTL0. Cross-VTL communication routes through Virtual Secure Mode hypercalls (`HvCallVtlCall` and `HvCallVtlReturn`), which are the only documented channel.

Generation 4 -- stabilised reference (2018 to 2024). No new rows. The boundary list is treated as a stable reference that MSRC, researchers, and the community all cite. Three flagship community projects encode the doctrine in their names and structure during this period: hfiref0x's UACMe (more than 80 catalogued UAC bypasses, none of which receive CVE numbers) [@uacme]; Gabriel Landau's ItsNotASecurityBoundary GitHub repository, whose name is an explicit homage to MSRC's admin-to-kernel policy [@landau-itsnotasb-gh]; and Alon Leviev's Windows Downdate, presented at Black Hat USA 2024 [@leviev-downdate-orig]. The community-side institutional memory now exists outside MSRC, augmented by Matt Miller's BlueHat IL keynotes (notably the 2019 Trends, challenges, and shifts in software vulnerability mitigation talk) that carried the boundary-and-mitigations story to the security-conference audience in parallel with the MSRC page [@miller-bluehat-il-2019].

Generation 5 -- Administrator Protection (2024 to 2026). On November 19, 2024, David Weston announced Administrator Protection at Microsoft Ignite, framing it as part of the Windows Resiliency Initiative [@weston-ignite-2024]. The Microsoft Learn page carries the verbatim doctrinal statement: "Administrator protection introduces a new security boundary with support to fix any reported security bugs" [@ms-learn-admin-protection]. This is the first new boundary entry added to the servicing-criteria table in nearly a decade.

The *System Managed Administrator Account* is the elevation primitive at the heart of Administrator Protection [@ms-learn-admin-protection]. Each interactive user with administrator privileges has a hidden, system-generated, profile-separated SMAA companion account provisioned in the SAM database. Elevations route through Windows Hello consent and run against the SMAA token, which has a *different* SID, a *different* profile directory, and a *different* logon session from the user's standard-user token. The token is destroyed when the elevated process ends. The shared-resources structural reason UAC could not be a boundary no longer applies, because the SMAA token does not share those resources with the user's standard token. timeline title Five generations of the boundary doctrine section Generation 1 - Scattered prose (2007 to 2010) 2007 : Russinovich publishes the convenience-vs-boundary distinction 2009 : Long Zheng and Rafael Rivera force UAC implementation hardening 2009 : Russinovich Windows 7 follow-up restates the doctrine section Generation 2 - Enumerated page (2010 to 2015) 2010 : MSRC servicing-criteria page goes live with two-question rule 2014 : hfiref0x publishes UACMe v1.0 2014 : CVE-2014-4113 Win32k EoP becomes canonical kernel-boundary case section Generation 3 - VTL added (2015 to 2017) 2015 : Windows 10 1507 ships VBS, Secure Kernel, Credential Guard 2016 : Edge AppContainer sandbox cements the browser boundary entry 2017 : EternalBlue and MS17-010 anchor the network-boundary case study section Generation 4 - Stabilised reference (2018 to 2024) 2023 : Landau PPLFault names PPL as not a security boundary 2024 : Landau ItsNotASecurityBoundary homages MSRC policy in repo name 2024 : Leviev Windows Downdate at Black Hat USA 2024 section Generation 5 - Administrator Protection (2024 to 2026) 2024 : Ignite keynote announces Administrator Protection as new boundary 2025 : Developer-blog detail post lands 2025 : October non-security update KB5067036 rolls out and is reverted 2026 : Forshaw publishes nine pre-GA bypasses via Project Zero

The December 1, 2025 rollout revert of the October 2025 non-security update KB5067036 is an application-compatibility decision, not a doctrinal one [@ms-learn-admin-protection]. The Microsoft Learn page now reads that the feature will roll out "at a later date." The boundary classification stands; the rollout schedule slipped.

Five generations later, the boundary table has nine entries. The next section walks the parallel evolution that nobody outside MSRC reads first -- the not-a-boundary table -- because that is the table that decides what does not get a CVE.

5. The Not-a-Boundary Table Also Accumulates

For every boundary Microsoft has added to the servicing-criteria table, there is a primitive that did not make the list. The not-a-boundary table tells a parallel story: primitives that attackers repeatedly tried to make into boundaries, and that Microsoft repeatedly classified as features. Seven entries, each tied to a load-bearing research artifact.

User Account Control (since June 2007). The original not-a-boundary entry; see Section 8.1 for the full treatment.

Driver Signing / Code Integrity / KMCS (since the Vista x64 kernel-mode driver signing requirement). Local administrator can, by design, load drivers; see Section 8.2. The "bring your own vulnerable driver" (BYOVD) catalog and the LOLDrivers project are the institutional memory [@loldrivers].

*BYOVD* is the attack pattern in which a privileged user installs a legitimately-signed driver that happens to contain an exploitable vulnerability, then exploits the driver to obtain arbitrary kernel-mode code execution. Because Driver Signing is on the security-feature side of the doctrine, a BYOVD chain that exploits a signed driver does not, on its own, receive a CVE attributed to Microsoft -- the driver vendor may receive one, but Microsoft does not classify the loadability of the driver as a boundary crossing. The Lazarus Group's use of expired-but-signed drivers and the broader [LOLDrivers catalog](https://www.loldrivers.io/) are the operational embodiment of this classification [@loldrivers].

Microsoft Defender / Antimalware. A heuristic detection layer cannot, by construction, be a boundary. Defender bypasses earn CVEs only when they also cross another boundary (see Section 8.3 for the Tavis Ormandy 2014 to 2017 network-boundary pattern; the flagship CVE-2017-0290 crazy bad MsMpEng RCE is the canonical example [@ms-advisory-4022344]).

HVCI / Memory Integrity. A feature enforced at the VTL boundary, not itself a boundary; see Section 8.4.

Protected Process Light (PPL). Introduced in Windows 8.1 to protect anti-malware services and other specially-signed processes from administrator tampering [@ms-learn-am-ppl]. Gabriel Landau's PPLFault research preserves the verbatim MSRC position that PPL is not a security boundary; see Section 8.5 for the full Landau quotation [@landau-pplfault].

Administrator-to-kernel privilege escalation. Local administrator can, by design, load drivers; see Section 8.6. Gabriel Landau named his False File Immutability research repository ItsNotASecurityBoundary as an explicit homage to MSRC's policy [@landau-itsnotasb-gh]; Alon Leviev's October 2024 Downdate follow-up contains the most recent verbatim Microsoft quotation of this position (see Section 8.6) [@leviev-downdate-update].

Same-user post-authentication. Once a process has executed under a user's session, it inherits that user's trust; per-process isolation within the same user is not a declared boundary. James Forshaw's June 3, 2024 Working your way Around an ACL post is the doctrinal anchor (see Section 8.7 for the verbatim formulation) [@forshaw-tyranid-acl].

Here are the two tables side by side.

The boundary table (nine entries)	What enforces it
Network	NDIS/TCP-IP/SMB/RPC stack; remote callers are the lowest trust tier
Kernel	SYSCALL/SYSRET transition, syscall service table, Driver Verifier, HVCI
Process	`SeAccessCheck` on `PROCESS_VM_READ`, `PROCESS_VM_WRITE`, `NtDuplicateObject`
Session	Session 0 vs Session 1+; per-session `BaseNamedObjects` namespace isolation
User	Per-user SIDs in SAM, file-system DACL inheritance, per-user `HKCU`
AppContainer	LowBox token + capability SID list + DENY-by-default ACLs
Virtual machine (guest-to-host)	Hyper-V root partition, VMBus, synthetic device model
VTL (VTL0 to VTL1)	Hypervisor-enforced SLAT (Intel EPT / AMD NPT); VSL hypercalls as the only cross-VTL channel
Administrator Protection elevation path (2025)	SMAA with separate SID, profile, logon session; Windows Hello consent

The not-a-boundary table (seven entries)	Why it is a feature, not a boundary
UAC	Split token shares SID, profile, session, namespace; no policy guarantee
Driver Signing / Code Integrity / KMCS	Administrators can install drivers by design
Microsoft Defender / Antimalware	Heuristic detection cannot guarantee detection
HVCI / Memory Integrity	A feature enforced at the VTL boundary, not itself a boundary
Protected Process Light (PPL)	Hardened against admin tampering, not policy-guaranteed
Administrator-to-kernel privilege escalation	Admin loads drivers; drivers run in kernel; structural
Same-user post-authentication	One user, one trust scope; per-process isolation not declared

The not-a-boundary table is the doctrine learning. Each new entry is a primitive an attacker class repeatedly tried to treat as a boundary, and Microsoft explicitly classified as a feature so the operational question -- does this report receive a CVE? -- has a stable answer.

Two tables. Sixteen total entries. One operational question per report. But how does Microsoft actually apply this -- and why is the application correct, not a cop-out?

6. The Two-Question Triage Rule

Here is the load-bearing engineering decision of the entire document: the classification question is decoupled from the severity question. Microsoft does not ask "is this report important enough to fix" as a single judgment call. It asks two separate questions, and both have to be answered yes.

The MSRC servicing-criteria page states the rule verbatim:

"The criteria used by Microsoft when evaluating whether to provide a security update or guidance for a reported vulnerability involves answering two key questions:

Does the vulnerability violate the goal or intent of a security boundary or a security feature?

Does the severity of the vulnerability meet the bar for servicing?" [@msrc-criteria]

The second question is parameterised by a separate document, the Microsoft Vulnerability Severity Classification for Windows, often called the Windows Bug Bar [@msrc-bugbar]. The Bug Bar defines four severity levels -- Critical, Important, Moderate, Low -- with worked examples for each vulnerability type (remote code execution, elevation of privilege, information disclosure, denial of service, spoofing, tampering). It also pivots between server and client severity. A bug that earns Critical on a server can earn Important on a client, and the disposition can change accordingly.

The first question answers the eligible-by-doctrine half. A boundary crossing is in scope. A feature defeat is also in scope -- Microsoft does service security features when the severity bar is met, but the path is different. The second question answers severity-meets-bar. Critical and Important on the Bug Bar route to a security update via Patch Tuesday (or out-of-band when the impact warrants it). Moderate and Low route to "consider for the next version or release of Windows."

The doctrine has an explicit relief valve.

If the answer to both questions is yes, then Microsoft's intent is to address the vulnerability through a security update and/or guidance ... If the answer to either question is no, then by default the vulnerability will be considered for the next version or release of Windows but will not be addressed through a security update or guidance, though exceptions may be made. -- Microsoft Security Servicing Criteria for Windows [@msrc-criteria]

Notice the work the and is doing. Two independent gates, both required. A feature defeat with Critical impact (for example, a Defender bypass that enables ransomware deployment at scale) can still ship as a Patch Tuesday item -- but it does so via the second question, with the explicit exception clause as the framing. A boundary crossing with Low severity (a process-isolation primitive bypass that requires preconditions no realistic attacker would arrange) might not ship as a bulletin.

flowchart TD Report["Vulnerability report arrives at MSRC"] Q1{"Q1: Does it violate a boundary or feature?"} Q2{"Q2: Does severity meet the bar (Critical or Important)?"} Excp{"Exception applies?"} Service["Service via security update / Patch Tuesday"] Defer["By design / consider for next release"] Report --> Q1 Q1 -- "No" --> Excp Q1 -- "Yes" --> Q2 Q2 -- "Yes" --> Service Q2 -- "No" --> Excp Excp -- "Yes" --> Service Excp -- "No" --> Defer

Key idea: Classification and severity are decoupled. The and of the two questions is the doctrine. Every "by design" reply the community has ever received is generated by this exact rule, applied with the published boundary list, the published feature list, the published severity bar, and the published exception clause.

The rule, restated as runnable pseudocode, looks like this. Try the three example inputs to see the doctrine in action.

{` // The MSRC servicing-criteria triage, in pseudocode. const BOUNDARIES = new Set([ "network", "kernel", "process", "session", "user", "appcontainer", "vm", "vtl", "administrator-protection", ]); const FEATURES = new Set([ "uac", "defender", "hvci", "driver-signing", "ppl", "admin-to-kernel", "same-user", ]);

function disposition(report) { const { primitive, severity, exception } = report; const isBoundary = BOUNDARIES.has(primitive); const isFeature = FEATURES.has(primitive); const violatedSomething = isBoundary || isFeature; const meetsBar = (severity === "Critical" || severity === "Important"); if (violatedSomething && meetsBar) return "Service via security update"; if (exception) return "Service via security update (exception)"; return "By design / consider for next version"; }

// Example 1: a fresh UAC bypass (consent.exe registry hijack) console.log("UAC bypass ->", disposition({ primitive: "uac", severity: "Important" }));

// Example 2: a pre-auth SMB RCE like CVE-2017-0144 EternalBlue console.log("SMB pre-auth ->", disposition({ primitive: "network", severity: "Critical" }));

// Example 3: a PPLFault-class bypass loading unsigned code into a PPL console.log("PPLFault ->", disposition({ primitive: "ppl", severity: "Important" })); `}

Run it. The UAC bypass returns "Service via security update" only because UAC is on the feature table -- so the first question is yes (a feature defeat) and the second question is yes (Important severity) -- and both questions matter. If you change the severity to Moderate the disposition flips to "by design / consider for next version." If you change the primitive to one that is not on either table, the disposition again becomes "by design" unless the exception clause fires.

That is the entire MSRC triage rule. Nine boundary entries, seven feature entries, one severity scheme, one exception clause. Every "by design" reply the community has ever received is generated by this exact rule.

Note: A single-question rule would collapse the doctrine. "Is this report important enough to fix" without a published classification turns every disposition into MSRC engineers' personal judgment. "Is this a boundary crossing" without a severity gate would force Microsoft to ship a Patch Tuesday bulletin for every low-impact boundary-adjacent finding, including the ones with no realistic attack path. Decoupling lets Microsoft commit to a published taxonomy on the first question while retaining engineering judgment on the second, with the exception clause as the explicit relief valve in either direction.

With the rule in hand, the next three sections walk the parameters of the rule -- the nine boundary entries, the seven feature entries, and the bounty schedule that mechanically follows both -- at one consistent pedagogical depth per entry.

7. The Nine Boundaries, Walked

One subsection per boundary. Each follows the same template: the architectural primitive that enforces the boundary, the canonical CVE-eligible violation pattern, and one verified historical case study.

7.1 Network boundary

Primitive. The NDIS / TCP-IP / SMB / RPC / HTTP server stacks treat remote callers as the lowest trust tier. Any code that processes attacker-influenced bytes off the wire before authenticating the caller sits at this boundary.

Violation. Pre-authentication remote code execution. A remote attacker reaches SYSTEM (or any local code execution) without first satisfying an authentication primitive.

Case study. EternalBlue, CVE-2017-0144, MS17-010. The SMBv1 server in Windows Vista SP2 through Windows 10 1607 accepted crafted packets that triggered a memory-corruption primitive in the kernel-mode driver, yielding pre-authentication remote code execution [@nvd-2017-0144]. NSA-developed; Shadow Brokers-leaked; weaponised within weeks by WannaCry and NotPetya. Critical severity, mandatory patch, the canonical network-boundary case in the entire taxonomy. SMBGhost (CVE-2020-0796) [@nvd-2020-0796] and PrintNightmare (CVE-2021-34527) [@nvd-2021-34527] are the supporting cases. PrintNightmare is particularly instructive because it crosses two boundaries simultaneously -- remote code execution via a malicious shared printer driver (network) and local privilege escalation via the same primitive on the spooler service (kernel).

7.2 Kernel boundary

Primitive. The user-mode-to-kernel-mode transition is enforced by the CPU's privilege rings and the SYSCALL/SYSRET instruction pair. The syscall service table is the only legal way to enter the kernel. Driver Verifier and HVCI run on top of this transition.

Violation. User-mode code achieves kernel-mode code execution without using the legitimate syscall interface, typically by exploiting a memory-safety bug in a kernel driver that the user-mode caller can reach.

Case study. CVE-2014-4113, the Win32k.sys tagWND elevation-of-privilege bug, exploited in the wild in October 2014.The Win32k subsystem is a recurring source of kernel-boundary findings because it processes window-manager state from user mode in kernel context, an architectural choice that predates the boundary doctrine. MS14-058 / KB3000061 was the Patch Tuesday fix on October 14, 2014 [@ms-bulletin-ms14-058]. The bug allowed a local user to run arbitrary code in kernel mode by crafting calls to the kernel-mode portion of the Win32 subsystem [@nvd-2014-4113]. Important severity; canonical kernel-boundary case; the kind of finding the doctrine was built to service cleanly.

*`SeAccessCheck`* is the Windows kernel's reference-monitor function that decides whether a thread holding a specific access token may perform a requested access against a securable object. It takes the object's security descriptor, the requesting token, and the desired access mask; it returns granted access or `STATUS_ACCESS_DENIED`. Every cross-process memory access, every securable kernel-object open, and every registry-key access ultimately routes through this function. It is the architectural enforcement point for both the process boundary and the user boundary.

7.3 Process boundary

Primitive. SeAccessCheck mediates PROCESS_VM_READ, PROCESS_VM_WRITE, PROCESS_DUP_HANDLE, and the access mask passed to NtOpenProcess [@ms-learn-process-access-rights]. A process cannot read another process's memory without holding a token that grants the requested access against the target's security descriptor.

Violation. One process reads or writes another process's address space without having been granted permission.

Case study. Thread injection canon: CreateRemoteThread, SetWindowsHookEx, NtMapViewOfSection. Each violation routes through a documented OS primitive that Microsoft has hardened repeatedly. The hardening culminated in the Protected Process Light (PPL) signer-hierarchy enforcement introduced in Windows 8.1, which lets specially-signed processes refuse code injection even from administrator processes [@ms-learn-am-ppl]. PPL itself is on the feature side of the doctrine -- the canonical example of how the process boundary and PPL interact is the AM-PPL extension that anti-malware vendors use to protect their services from administrator-level interference, which Landau's research has explored at length [@landau-pplfault].The access-mask argument to NtOpenProcess is the load-bearing enforcement point. A thread that opens a target process with PROCESS_VM_READ and then calls ReadProcessMemory is exercising an audited boundary crossing; a thread that obtains the target's handle through a more circuitous route (handle duplication, named-object games) still routes through SeAccessCheck somewhere. The taxonomy is what gives the audit something to anchor against.

7.4 Session boundary

Primitive. Session 0 (system services) is isolated from interactive user sessions (Session 1, Session 2, and so on). Each session has its own \Sessions\<id>\BaseNamedObjects namespace, its own window station, and its own desktop [@ms-learn-kernel-object-namespaces]. Services that previously ran in the interactive session of the first logged-in user now run in Session 0 with no GUI.

Violation. A low-privilege interactive process sends window messages to a SYSTEM-level service on the same desktop, driving the service's UI into executing attacker-controlled code paths.

Case study. The August 2002 Shatter class, generalised by Brett Moore in Shattering By Example (2003) [@exploit-db-21691]. Microsoft's architectural response shipped with Windows Vista: Session 0 isolation. Services were moved to Session 0 with no interactive desktop; user applications run in Session 1 and higher. The Microsoft Learn Interactive Services page records the engineering decision verbatim: "Services cannot directly interact with a user as of Windows Vista. Therefore, the techniques mentioned in the section titled Using an Interactive Service should not be used in new code" [@ms-learn-interactive-services].

7.5 User boundary

Primitive. Per-user SIDs in the SAM database (or the domain database for joined hosts), file-system DACL inheritance, per-user HKCU registry hives, the user profile directory, and the access token that travels with every thread [@ms-learn-access-tokens]. A process running as one user cannot access objects owned by another user unless the DACL explicitly permits it.

Violation. One user's process reads another user's data without permission. Classic targets: NTUSER.DAT of another logged-on user, the other user's %USERPROFILE%, the other user's tokens via NtOpenProcess or NtOpenProcessToken.

Case study. The user boundary is the example Russinovich uses in his June 2007 article when contrasting boundaries with conveniences [@russinovich-vista-uac-wayback]. User-to-user separation is the canonical "yes, this is a boundary" case in the entire taxonomy; the closest same-user counter-example -- Forshaw's June 2024 Recall ACL post -- explicitly notes that user-to-user would be a boundary, but same-user per-process isolation is not [@forshaw-tyranid-acl]. The boundary granularity matters: the same primitive class can be a boundary at one granularity and a non-boundary at a finer granularity.

This is the cleanest illustration of how granularity drives classification. *User to user* is a boundary -- Alice's process cannot read Bob's data without explicit permission. *Same user, process to process* is not a boundary -- Alice's text editor, Alice's browser, and Alice's media player all run with Alice's identity and any one of them can read the others' resources. PPL adds a feature-class barrier within the same user, but Microsoft has explicitly classified PPL as not a boundary [@landau-pplfault]. The taxonomy is consistent: the same primitive (the access token) can guarantee separation across user identities and *not* guarantee separation between two processes that share an identity.

7.6 AppContainer / sandbox boundary

Primitive. A LowBox token with a capability SID list; default-DENY ACLs against any object that has not explicitly granted the relevant capability; restricted access to the file system, the registry, named objects, and the network stack. AppContainer is built on top of the Mandatory Integrity Control mechanism but is strictly more restrictive than a Low IL token.

*MIC* is the Windows mechanism that assigns each securable object and each access token an integrity level: Untrusted, Low, Medium (the default for standard users), High (the default for administrators), and System. The access-check rules state that a lower-integrity subject cannot write to a higher-integrity object, regardless of DACL permissions. Introduced in Vista alongside UIPI, MIC underpins both the AppContainer boundary and the UAC feature.

Violation. A LowBox or AppContainer process escapes its capability list to perform operations the container was supposed to deny.

Case study. Edge sandbox escape canon, from the Anniversary Update (Windows 10 1607, August 2016) forward. AppContainer as a mechanism predates 1607 (it shipped in Windows 8 alongside the Modern UI app model, where it was originally named LowBox) [@ms-learn-appcontainer-legacy], but the Edge sandbox is the flagship demonstration that AppContainer can serve as a browser-grade sandbox boundary. Edge sandbox escapes route through MSRC as boundary violations and earn the Microsoft Edge Bounty Program payouts [@msrc-bounty-edge].

7.7 Virtual machine (guest-to-host) boundary

Primitive. Hyper-V's root partition versus L1 guest partitions, the VMBus inter-partition channel, the synthetic device model, the virtualization-service-provider (VSP) and virtualization-service-client (VSC) split. A guest VM communicates with the host only via VMBus, and only through the synthetic devices the host exposes.

Violation. A guest VM achieves code execution on the host (or in a sibling guest).

Case study. CVE-2024-21407, a use-after-free in a Hyper-V root-partition component reachable from a guest VM (the MSRC advisory does not name the component), shipped as a Critical-severity Patch Tuesday item on March 12, 2024 [@nvd-2024-21407]. The guest-to-host class pays the highest bounty in the Microsoft Bounty Programs portfolio.

Note: The Microsoft Hyper-V Bounty Program pays $5,000 to $250,000 USD for guest-to-host escape vulnerabilities [@msrc-bounty-hyperv]. That is the highest single-finding payout in the Microsoft bounty catalogue [@msrc-bounty-root], and it maps directly to the VM boundary on the servicing-criteria table. The bounty schedule is one of the cleanest market-side confirmations available that the boundary list drives every other operational artifact: the boundary that protects the most consequential trust separation (cloud tenant from cloud tenant on shared hypervisor hardware) also pays the most.

7.8 VTL (VTL0 to VTL1) boundary

Primitive. Hypervisor-enforced second-level address translation (SLAT, implemented as Intel EPT or AMD NPT) separates the address spaces of VTL0 (the normal kernel and user mode) and VTL1 (the Secure Kernel and Isolated User Mode). The hypervisor mediates every cross-VTL access. The only documented cross-VTL channel is the Virtual Secure Mode hypercall pair (HvCallVtlCall and HvCallVtlReturn).

Violation. A VTL0 attacker observes or modifies VTL1 memory or Trustlet state.

Case study. Credential Guard / Isolated LSA is the canonical VTL1 success story. The LSA Trustlet (LsaIso) holds the credential material Credential Guard protects; even an NT AUTHORITY\SYSTEM-class attacker in VTL0 cannot read those credentials because the relevant pages are not mapped into the VTL0 kernel's address space at all [@ms-learn-vbs-ci]. The doctrine has a row that says so, and the bounty schedule pays Critical-class amounts under the Windows Insider Preview Bounty Program for VTL violations.

*Virtual Trust Levels* are the hypervisor-enforced trust tiers Hyper-V introduces inside a single guest partition [@ms-learn-vbs-ci]. VTL0 is the "normal" Windows world: the regular kernel, regular drivers, and regular user-mode processes. VTL1 is the secure world: the Secure Kernel and Isolated User Mode (IUM), where Trustlets like LsaIso run. The hypervisor's SLAT tables enforce the separation: VTL0 page-table entries that would let the normal kernel read VTL1 memory simply fail the SLAT check at hardware-page-fault granularity. The only cross-VTL channel is the VSL hypercall pair. The VTL boundary is the strongest local boundary on Windows.

7.9 Administrator Protection elevation path (2025 addition)

Primitive. The System Managed Administrator Account (SMAA) sits in the SAM database with its own SID, profile, and home directory. The appinfo.dll consent service authorises SMAA-scoped elevation via Windows Hello. When a user requests an elevation, appinfo.dll walks the Windows Hello flow, the SMAA token is created in a fresh logon session, the elevated process runs, and the token is destroyed when the process exits [@ms-learn-admin-protection].

Violation. A standard-user process obtains the SMAA's elevated token without Windows Hello consent, typically by exploiting a primitive in the elevation path that lets the attacker substitute their own controlled object for one the SMAA elevation flow expects to create.

Case study. James Forshaw's January 2026 nine pre-GA Administrator Protection bypass series, disclosed via the Project Zero issue tracker [@pz-tracker-432313668]. The canonical illustration is the "lazy DOS device directory hijack" (Project Zero issue 432313668): DOS device object directories are created on demand for each logon session rather than at session creation time, and an attacker can race the SMAA elevation flow to create the directory first, with attacker-controlled permissions. Microsoft fixed all nine pre-GA -- not "by design"-replied. The boundary classification is operationally enforced.

flowchart TB subgraph Network["Network boundary"] Remote["Remote / unauthenticated attacker"] end subgraph Hypervisor["Hyper-V root partition"] subgraph Guest["L1 guest VM"] subgraph VTL0["VTL0 (normal kernel)"] Kernel["Kernel mode"] subgraph Session1["Session 1+ interactive"] subgraph User["Per-user identity"] ProcA["Process A"] ProcB["Process B"] subgraph AppC["AppContainer / LowBox"] Sandbox["Sandboxed renderer"] end end end subgraph Session0["Session 0 services"] Svc["SYSTEM services"] end subgraph AP["Administrator Protection elevation path"] SMAA["SMAA token"] end end subgraph VTL1["VTL1 (Secure Kernel + IUM)"] Trustlet["LsaIso Trustlet"] end end end Remote -.->|"Network boundary"| Kernel ProcA -.->|"Process boundary"| ProcB Session1 -.->|"Session boundary"| Session0 Sandbox -.->|"AppContainer boundary"| ProcA Kernel -.->|"VTL boundary"| Trustlet ProcA -.->|"Administrator Protection boundary"| SMAA

Nine boundaries. Every one of them backed by a real architectural primitive, every one of them carrying a documented violation history. But the doctrine is only half a table. The other half is the table of primitives Microsoft has explicitly chosen not to commit to.

8. What Is Not a Boundary

For every primitive on the boundary list, there is a primitive Microsoft has named in the same document and chosen not to commit to. The seven entries, with the structural reason for each classification.

8.1 UAC

Russinovich's June 2007 sentence is the doctrinal source: "UAC elevations are conveniences and not security boundaries" [@russinovich-vista-uac-wayback]. The structural reason is the shared-resources model -- same SID, same profile, same logon session, same DOS device object directory between the standard-user and elevated tokens. UACMe is the operational catalogue: more than 80 documented auto-elevation methods, zero CVEs [@uacme]. The reply to a UAC bypass report is "by design, please refer to the servicing criteria," and that reply is operationally correct.

8.2 Driver Signing / Code Integrity / KMCS

Local administrator can, by design, install drivers. Once a driver is installed, it runs in kernel mode. Classifying admin-to-kernel as a boundary would require redesigning the Administrators group itself. The downstream operational consequence is the BYOVD attack family: an administrator installs a legitimately-signed driver with an exploitable vulnerability and uses the driver to obtain arbitrary kernel-mode code execution. Microsoft maintains the Vulnerable Driver Blocklist as feature hardening, and the Windows Defender Application Control (WDAC) infrastructure as a tighter enforcement option, but those are features layered over a primitive Microsoft has not classified as a boundary [@leviev-downdate-update].

8.3 Microsoft Defender / Antimalware

A heuristic detection layer cannot, by construction, be a boundary. Antivirus operates by recognising patterns -- signature, behaviour, reputation -- and an adversary tuning a payload against those patterns can always find a path that the detector does not recognise.

Note: A boundary requires that "security policy dictates what can pass through." Heuristic detection cannot meet that requirement. There is no policy oracle that can decide, in finite time with finite memory, whether an arbitrary binary will exhibit malicious behaviour. The decision problem is undecidable in the general case (Rice's theorem); in practice antivirus is a probabilistic filter, not a guarantee. Microsoft's classification of Defender as a feature acknowledges this constraint. Defender will be improved, hardened, and updated -- but the doctrine does not promise that it will catch any specific malware. Bypassing Defender is expected and continuous, and a Defender-bypass report on its own does not earn a CVE.

Tavis Ormandy's 2014 to 2017 Defender disclosures earned CVEs not because they bypassed Defender's detection but because they crossed other boundaries [@ms-advisory-4022344]. The bugs were memory-corruption primitives in the Defender parsing engine reachable from attacker-controlled inputs the engine fetched from email or web traffic. The flagship example is CVE-2017-0290, the crazy bad MsMpEng RCE Microsoft addressed with out-of-band Security Advisory 4022344 on May 8, 2017 [@ms-advisory-4022344]. The network boundary crossing is what earned the CVE.This is the operational lesson for anyone reporting a Defender finding: lead with the boundary, not the feature. If your bypass is a clever signature evasion, expect a "by design" reply. If your bypass is a parsing-engine memory-corruption primitive that fires from attacker-controlled input arriving over the network, that is a network-boundary crossing and you have a CVE-eligible report.

8.4 HVCI / Memory Integrity

The doctrinally subtle one. HVCI is the kernel-mode code integrity check that lives inside VTL1, running under the protection of the hypervisor. The VTL boundary is what protects HVCI from attacker tampering. HVCI itself is a feature enforced at the VTL boundary, not a boundary in its own right.

The operational consequence: an HVCI bypass that does not also cross VTL0 to VTL1 is a feature defeat. Critical-severity HVCI bypasses may still ship as security updates through the exception clause -- but the primary disposition path is feature-hardening rather than boundary-servicing. Microsoft's Virtualization-based protection of code integrity page documents the architecture in detail and is the canonical reference [@ms-learn-vbs-ci].

8.5 Protected Process Light (PPL)

Introduced in Windows 8.1 to protect anti-malware services and other specially-signed processes from administrator tampering [@ms-learn-am-ppl]. PPL uses code integrity to refuse unsigned code injection into protected processes, and refuses termination requests even from administrators.

Gabriel Landau's PPLFault chain demonstrated loading unsigned code into a PPL process by racing the kernel's signature check against attacker-controlled storage during catalog load -- the False File Immutability primitive [@landau-pplfault], [@landau-ffi-elastic]. Microsoft's response was the Canary build 25941 mitigation on September 1, 2023 -- feature hardening that ships out-of-cycle when the impact warrants it, not boundary-class servicing. Landau's article preserves the verbatim MSRC position.

The PPL mechanism was introduced in Windows 8.1, enabling specially-signed programs to run in such a way that they are protected from tampering and termination, even by administrative processes ... Microsoft does not consider PPL to be a security boundary, meaning they won't prioritize security patches for code-execution vulnerabilities discovered therein, but they have historically addressed some such vulnerabilities on a less-urgent basis. -- Gabriel Landau, Elastic Security Labs, September 2023 [@landau-pplfault]

8.6 Administrator-to-kernel privilege escalation

The structural impossibility argument applies cleanly here. By Saltzer-Schroeder's complete mediation principle [@saltzer-schroeder-mit], a boundary requires that every access through it be mediated by policy. Administrators are policy-authorised to load drivers; drivers run in kernel mode; therefore admin-to-kernel is the expected operation, not a policy violation. Reclassifying this as a boundary would mean redesigning the Administrators group itself.

The Landau ItsNotASecurityBoundary GitHub repository name is an explicit homage to this Microsoft policy [@landau-itsnotasb-gh]. The repository's research extends False File Immutability into kernel space: the Windows Code Integrity subsystem (ci.dll) is itself susceptible to FFI, letting an attacker who controls a catalog file on attacker-controlled storage race the CI signature check and then load unsigned drivers. Microsoft fixed the specific FFI primitive but did not move the admin-to-kernel classification.

Alon Leviev's Windows Downdate is the recent flagship demonstration. Microsoft assigned CVE-2024-21302 to the chain because it crossed the VTL boundary; the underlying Windows Update takeover -- the admin-to-kernel piece -- remained unpatched [@leviev-downdate-update]. The classification stood. Specific chains earn CVEs when they cross another boundary; the primitive itself does not become a boundary by accumulation of exploitation evidence.

While CVE-2024-21302 was patched because it crossed a defined security boundary, the Windows Update takeover which was reported to Microsoft as well, has remained unpatched, as it did not cross a defined security boundary. Gaining kernel code execution as an Administrator is not considered as crossing a security boundary (not a vulnerability). -- Alon Leviev, SafeBreach Labs, October 26, 2024 [@leviev-downdate-update]

8.7 Same-user post-authentication

The most recent addition to the feature table, articulated by James Forshaw in Working your way Around an ACL (June 3, 2024). Once a process has executed under a user's session, it inherits the user's trust. Per-process isolation within the same user is not a declared boundary. Forshaw's verbatim formulation: "any privilege escalation (or non-security boundary cough) is sufficient to leak the information" [@forshaw-tyranid-acl].

The operational stakes here are higher than they look. AI-mediated features like Windows 11 Recall continuously record sensitive user state into a same-user-readable database. If same-user is not a boundary, every non-PPL local process under the same user identity can read that database. The "ACLed to SYSTEM" mitigation that protects the Recall storage is operationally weak under the doctrine, because any same-user privilege escalation -- including the entire UACMe catalogue, all of the same-user-post-authentication footguns, and every UI-Access trick -- is a sufficient predicate.

flowchart TD Report["Vulnerability report arrives"] Cls{"Classify primitive"} BdyQ2{"Boundary path: severity Critical or Important?"} FtrQ2{"Feature path: severity Critical or Important?"} Excp{"Exception applies?"} SvcBdy["Boundary servicing: Patch Tuesday CVE"] SvcFtr["Feature servicing: Patch Tuesday CVE (Q2 yes path)"] SvcExc["Exception servicing: feature hardening, possible bulletin"] Defer["By design / consider for next version"] Report --> Cls Cls -- "Boundary" --> BdyQ2 Cls -- "Feature" --> FtrQ2 BdyQ2 -- "Yes" --> SvcBdy BdyQ2 -- "No" --> Excp FtrQ2 -- "Yes" --> SvcFtr FtrQ2 -- "No" --> Excp Excp -- "Yes" --> SvcExc Excp -- "No" --> Defer

The central insight: the not-a-boundary table is not a list of bugs Microsoft has not gotten around to fixing. It is a list of primitives Microsoft has deliberately chosen not to commit to, because guaranteeing those primitives as boundaries would require either reorganising the architecture (admin-to-kernel) or operating against an inherent impossibility (heuristic detection cannot guarantee detection).

Nine boundaries that Microsoft commits to. Seven features Microsoft hardens but does not commit to. One remaining structural artifact ties the two together: the bounty schedule.

9. The Bounty Schedule Mirrors the Boundary List

If you wanted a market-side confirmation that the boundary list is the operational anchor, you would look at the bounty schedule. The two documents are mechanically linked.

Bounty program	Payout range	Primary boundary (or boundaries)	Source
Microsoft Hyper-V Bounty Program	$5,000 to $250,000 USD	Virtual machine (guest-to-host)	[@msrc-bounty-hyperv]
Windows Insider Preview Bounty Program	$500 to $100,000 USD	Kernel, network, sandbox, VBS / VTL	[@msrc-bounty-wip]
Microsoft Edge Bounty Program	$250 to $30,000 USD	AppContainer / sandbox, network	[@msrc-bounty-edge]
Microsoft Bounty Programs (landing)	Varies by program	Identity, Cloud, M365, Azure (cloud-side boundaries)	[@msrc-bounty-root]
Standalone UAC bypass bounty	None	(UAC is on the feature list, no bounty)	--

Hyper-V is the highest payout. Up to $250,000 USD for a guest-to-host escape, which is the largest single-finding payout in the Microsoft bounty catalogue [@msrc-bounty-hyperv]. The program's verbatim definition of an eligible submission is a remote-code-execution vulnerability that lets an L1 guest virtual machine compromise the hypervisor, escape from the guest to the host, or escape to another L1 guest. That maps directly to the VM boundary on the servicing-criteria table. The market signal is unambiguous: the boundary whose violation matters the most pays the most.

Windows Insider Preview is the kernel / network / VBS catch-all. Up to $100,000 USD for vulnerabilities found on the latest Canary Channel build, with the eligibility requirement that the vulnerability "must be Critical or Important severity as defined in the Microsoft Vulnerability Severity Classification for Windows" [@msrc-bounty-wip]. That severity requirement is the Question 2 gate from the two-question rule, written directly into the bounty's eligibility clause. The bounty program inherits Question 2 mechanically.

Microsoft Edge is the sandbox program. Up to $30,000 USD for Edge-unique vulnerabilities (not reproducing on the equivalent Google Chrome channel) in the Dev, Beta, or Stable channels [@msrc-bounty-edge]. The "unique to Edge" requirement reflects that Chromium engine bugs upstream are Google Chrome's bounty scope; the Microsoft Edge program covers the Edge-specific shell, AppContainer integration, and Windows integration code.

The absence of a UAC bounty. There is no standalone UAC bypass bounty program. Not because Microsoft does not care about UAC bypasses, but because UAC is not on the boundary list -- the market signal follows the doctrine.

Note: The bounty schedule is the most reliable cross-check available for the boundary list. Reading the bounty page is a reasonable proxy for reading the boundary list, because Microsoft only pays for findings that violate primitives the company has committed to defending. The absence of a UAC bounty, the presence of a $250,000 Hyper-V tier, and the Critical-or-Important severity gate baked into the Windows Insider Preview bounty are all consequences of the servicing-criteria classification. The classification drives the payout. The payout reveals the classification.

The mapping is dominantly tight, not strictly tight. The exception clause from the servicing criteria applies here too: a sufficiently impactful feature defeat may receive an out-of-band bounty under the broader Microsoft Bounty Programs umbrella [@msrc-bounty-root]. But the structural mapping is consistent enough that the bounty page is a fair proxy for the classification.

You have now read the doctrine in full. Two tables, one rule, one bounty overlay. The next question is the one the doctrine itself cannot answer: where are the gaps?

10. What the Doctrine Cannot Decide

The doctrine is the most enumerated vulnerability-classification policy any major OS vendor has published. It still has gray zones.

Resourcing versus security. Microsoft's admin-to-kernel position is at least partly a resourcing decision: finite engineering capacity to harden the admin elevation path. The structural impossibility argument (admin loads drivers; drivers run in kernel) is genuine, but it does not by itself force the classification -- a sufficiently invasive architectural change (sealed-system mode; VTL Enclaves hosting the entire kernel) could in principle move the line. What "guaranteed by Windows" means in a model that admits BYOVD, Windows Downdate, and False File Immutability is a question reasonable researchers can disagree on.

Severity-meets-bar as the second filter. Two findings that cross the same boundary can receive different fates depending on Question 2. The Bug Bar [@msrc-bugbar] documents the types of severity (RCE, EoP, info disclosure, DoS, spoofing, tampering) and the pivots (server vs client; default-on vs default-off; user interaction required vs not), but the thresholds within each type are not exhaustively published. A researcher who knows the boundary list still cannot, from the document alone, predict severity to single-step accuracy.

The "exceptions may be made" clause. The doctrine itself admits exceptions exist. PPLFault shipped a feature-hardening mitigation in Canary build 25941 [@landau-pplfault] even though PPL is a feature; CVE-2024-21302 received a Patch Tuesday bulletin even though the underlying admin-to-kernel primitive remained on the feature side [@leviev-downdate-update]. Researchers cannot fully predict the MSRC reply from the document alone; the exception clause is structural relief, not an edge case.

Boundary classification of paths, not just components. Administrator Protection is the elevation path, not the account [@ms-learn-admin-protection]. Admin-to-kernel via driver load is still not a boundary even when the elevation path is. The two coexist: a researcher who finds a way for a standard-user process to obtain an SMAA elevated token without consent has a CVE-eligible boundary crossing; a researcher who finds a way for an administrator process to install a vulnerable driver and pivot to kernel has a feature defeat.

Saltzer and Schroeder's 1975 *The Protection of Information in Computer Systems* [@saltzer-schroeder-mit] articulates the *open design* principle: the security design should be public, "the mechanisms should not depend on the ignorance of potential attackers." A published classification doctrine like Microsoft's satisfies open design. Their *complete mediation* principle is the other constraint at work: a boundary requires that every access through it be mediated by policy. The Microsoft doctrine lives precisely in the gap between *enumerable* (an upper bound: a published doctrine must list the boundaries it commits to) and *complete* (a lower bound: no doctrine can list every primitive that will ever matter). The "exceptions may be made" clause is the doctrine's explicit acknowledgment of the gap.

Note: The doctrine does not promise that every reported finding will be serviced. It does not promise that severity thresholds are publicly enumerated to single-step accuracy. It does not promise that the boundary list will not grow or contract. It does not promise that two reports against the same primitive at the same severity will receive identical disposition. What it promises is that the classification half of the triage will follow the published list, and that the exception clause exists as the explicit relief valve when the published list does not fit. The promise is procedural, not absolute. That procedural promise is what makes the doctrine more legible than any comparable vendor policy.

Microsoft's doctrine has gray zones -- but it has more enumerated certainty than any comparable doctrine. How does it compare to Apple's, Chromium's, Mozilla's, and the Linux kernel's?

11. How Other Vendors Classify the Same Primitives

Microsoft's document is one of five major published doctrines. Each draws the line differently.

Vendor	Taxonomic structure	Primary URL	Example divergence from Microsoft
Microsoft	Enumerated boundary + feature tables; two-question rule	[@msrc-criteria]	The Microsoft baseline
Apple (macOS / iOS)	Architectural-by-section; sealed system + SIP	[@apple-platform-security]	SIP classifies admin-to-OS-modification as a boundary
Chromium	Design-time Rule of 2; severity guidelines for triage	[@chromium-rule-of-2]	Design-time pre-commitment, not post-hoc classification
Mozilla	sec-rating (sec-critical / sec-high / sec-moderate / sec-low)	[@mozilla-client-bounty]	Severity-only, no primitive enumeration
Linux	Per-subsystem implicit classification	[@linux-security-bugs]	No central table; maintainer-driven

Apple's Platform Security Guide. A sealed-system / Signed System Volume model with stricter user/kernel separation. macOS System Integrity Protection (SIP) restricts the root user account and limits the actions root may perform on protected parts of the OS [@apple-sip-ht204899]. Some admin-to-system-modification paths that Windows classifies as features (Driver Signing, Code Integrity, admin-to-kernel) are classified by SIP as boundaries the OS protects against modification, including by the local administrator. The Apple guide is less enumerated than Microsoft's -- it organises by section rather than by table -- but it commits to architectural separations that the open-driver-loading Windows model cannot match [@apple-platform-security].

Chromium's Rule of 2 plus Severity Guidelines. A design-time pre-commitment, fundamentally different from Microsoft's post-hoc triage. The Rule of 2 states: "When you write code to parse, evaluate, or otherwise handle untrustworthy inputs from the Internet ... Pick no more than 2 of: untrustworthy inputs; unsafe implementation language; and high privilege" [@chromium-rule-of-2]. Code that violates the rule must be sandboxed before it ships. Site isolation (each origin in its own renderer process) is the operational boundary equivalent. The Severity Guidelines parameterise triage with a Critical (S0) / High / Medium / Low scheme [@chromium-severity-guidelines].The Chromium Rule of 2 and Microsoft's servicing criteria are not substitutes -- they live at different layers. The Rule of 2 is an engineering rule that forecloses entire vulnerability classes at design time. The Microsoft doctrine is a triage rule that classifies findings at disclosure time. A Chromium project can adopt both, and Microsoft Edge does.

Mozilla's Client Bug Bounty Program. A severity-only rating: sec-critical, sec-high, sec-moderate, sec-low. The bounty page states verbatim: "Typically, the security rating given by the Bounty Committee for a bug must be rated a 'sec-high' or 'sec-critical' in order for it to be eligible for a bounty" [@mozilla-client-bounty]. There is no published boundary enumeration. The Bounty Committee's judgment is the deciding factor.

The Linux kernel security-bugs process. Per-subsystem, not per-boundary. The verbatim policy: "By definition if an issue cannot be reproduced, it is not exploitable, thus it is not a security bug" [@linux-security-bugs]. CVE assignment runs through the kernel's CVE Numbering Authority since 2024. There is no Linux equivalent of the MSRC servicing-criteria document; classification is implicit in the maintainer's response.

Microsoft's document is the most enumerated, most operationally legible vulnerability-classification doctrine published by any major OS vendor. That legibility is itself a vendor commitment, and is what makes "by design" a predictable answer rather than an arbitrary one. All five doctrines agree that boundaries exist. They disagree on which primitives count, how to enumerate them, and how to communicate the result. Microsoft has chosen the most-enumerated point in that gap. The next question is whether the enumeration will keep growing.

12. The 2026 Frontier

The boundary list grew by accretion for twenty years. Four pressures are pushing the next additions.

Cloud-side boundaries. Conditional Access policy enforcement (Microsoft Entra), the Primary Refresh Token (PRT), and the Microsoft 365 service boundary that Copilot operates within. These are not currently in the Windows servicing criteria -- they are governed by separate MSRC documents and per-product bounty programs [@msrc-bounty-root]. Modern Windows attack chains routinely involve both client-side (Windows) and cloud-side (Entra / Azure) primitives. A finding that crosses a cloud-side boundary may or may not also cross a client-side boundary, and the Windows document does not yet arbitrate.

The open question is whether the Windows servicing criteria document will expand to cover cloud-side primitives, or whether a parallel Microsoft Identity Security Servicing Criteria document will appear. The bounty pages function as a derived boundary list today -- reading them tells a researcher which cloud-side primitives Microsoft commits to servicing -- but the unified document does not yet exist.

Agentic / AI-mediated privilege expansion. Copilot in Windows and Copilot for Microsoft 365 can take actions on behalf of a user. Prompt injection from untrusted content can cause Copilot to perform actions the user did not intend. Is that a boundary crossing?

A prompt-injected Copilot action operates *within* the user's identity and the user's authorisations. By the same-user-post-authentication classification, that should be a feature defeat, not a boundary crossing. But the *intent* the user expressed (summarise my email; do not exfiltrate it) is defeated by the injected prompt. The doctrine was designed to classify primitives in terms of policy-enforced separations, not in terms of user-intent-vs-attacker-intent. The MITRE ATT&CK framework has begun to enumerate prompt-injection-class techniques [@mitre-attack]; the Microsoft document has not yet. Whichever way Microsoft decides -- a new boundary entry, a new feature entry, or a deferral -- will be the most consequential doctrinal move since the 2025 Administrator Protection addition.

Administrator Protection rollout resumption. The December 2025 revert was an application-compatibility decision; the boundary classification stands [@ms-learn-admin-protection]. What would have to be true for the rollout to resume: Win32 application compatibility validated across the long tail, Visual Studio elevation flows verified, the WebView2 installer regression resolved [@ms-blogs-admin-protection-dev]. What stays the same when it does: Forshaw's nine pre-GA bypasses all fixed; the elevation path still on the boundary side.

Same-user as a possible new boundary. The Recall disclosure and the broader same-user post-authentication class push on this question. The community position, articulated by Forshaw, is that same-user should not be expected to be a boundary [@forshaw-tyranid-acl]. Microsoft's response has been feature hardening (Personal Data Encryption, VTL Enclave use) rather than reclassification.

Note: If VTL Enclaves and Personal Data Encryption become a per-user attestable substrate -- a per-user equivalent of VTL1 -- then same-user could become a boundary in the same way user-to-user already is. The structural ingredient that VTL1 added to the user boundary (hypervisor-mediated separation that even SYSTEM cannot cross) would be added to a per-process scope within a user's identity. This is a research-track conjecture, not a Microsoft commitment; no public Microsoft statement has confirmed the direction. But the shape of how same-user could become a boundary is now legible, in a way it was not before Administrator Protection demonstrated that re-using an existing boundary (user-to-user) for a new primitive (the SMAA elevation path) is a viable engineering pattern.

flowchart LR subgraph Existing["Existing boundaries (current doctrine)"] Net["Network"] Krn["Kernel"] Prc["Process"] Sess["Session"] Usr["User"] AC["AppContainer"] VM["Virtual machine"] VTL["VTL0 to VTL1"] AP["Administrator Protection"] end subgraph Ingredients["Structural ingredients pushing the frontier"] PRT["Primary Refresh Token"] CA["Conditional Access policy"] PI["Prompt injection primitives"] PDE["Personal Data Encryption"] Enc["VTL Enclaves"] end subgraph Candidate["Candidate future boundaries"] Cloud["Cloud-side: PRT / Conditional Access"] AI["AI-mediated action expansion"] SU["Same-user per-process"] end Usr --> PRT Usr --> CA PRT --> Cloud CA --> Cloud PI --> AI Sess --> PI PDE --> SU Enc --> SU VTL --> Enc

None of these candidates is on the table yet. All four are being pushed by primitives -- the Primary Refresh Token, prompt injection, Administrator Protection, the Recall directory ACL -- that have already shipped. The next decade's boundary list is being negotiated now, in real research posts and MSRC replies. The question is how you file a report into that negotiation.

13. How to File a Useful MSRC Report

Everything in this article has been theory until this section. Here is how the doctrine becomes a checklist you can apply to your own findings before the submit button.

Read the servicing-criteria document first [@msrc-criteria]. Map your finding to a boundary entry. If it does not map, expect a feature-defeat reply. If it maps cleanly, you know in advance that the disposition path goes through Question 2.
Lead the MSRC submission with the boundary claim in the first sentence. "This issue violates the [process | kernel | session | network | user | AppContainer | VM | VTL | Administrator Protection] boundary because <reason>." The triage engineer reading your report should never have to infer which boundary you are claiming. Name it.
Include the severity-meets-bar argument in the second paragraph. Critical / Important / Moderate / Low per the Bug Bar [@msrc-bugbar]. Cite the specific bug-type cell (RCE, EoP, info disclosure, DoS, spoofing, tampering) and the pivot (server vs client; default-on vs default-off; user interaction required vs not). Worked examples beat assertions.
If the finding crosses a feature and a boundary, lead with the boundary. The feature defeat is supporting evidence, not the primary claim. A Defender bypass that also crosses the network boundary is a network-boundary report with a Defender defeat as supporting detail, not the other way around.
Expect the reply to be operationally predictable. If the finding is on the feature side and severity is not Critical, the reply will be "by design / consider for next version." Plan publication accordingly. A 90-day Project Zero clock that lines up with a probable "by design" reply is not a failed disclosure -- it is a successful one, because the reply was predicted in advance [@project-zero-9030].
For bounty-eligible classes, read the program-scope page carefully. Hyper-V ($5K - $250K) [@msrc-bounty-hyperv], Windows Insider Preview ($500 - $100K) [@msrc-bounty-wip], Edge ($250 - $30K) [@msrc-bounty-edge], plus the Identity / Cloud / M365 / Azure programs [@msrc-bounty-root]. The boundary-payout mapping is dominantly tight; the program-scope page tells you whether the bounty fires.
If the reply surprises you, the "exceptions may be made" clause is the framing [@msrc-criteria]. A feature defeat that does receive a bulletin does not contradict the doctrine; it invokes the exception. A boundary crossing that does not receive a bulletin invokes the exception in the other direction (severity below bar). Either way, the doctrine is not broken; the exception clause is doing its job.

Note: Before you spend three weeks reverse-engineering a primitive, spend three minutes reading the relevant Microsoft Bounty Program scope page. The page tells you, in plain language, whether Microsoft considers the primitive class you are attacking to be bounty-eligible. If the bounty program does not list your primitive class -- if there is no UAC-bypass bounty, no Defender-bypass-by-detection-evasion bounty, no PPL-bypass bounty -- the boundary classification has already told you the operational answer. You can still publish the research; you just know the disposition in advance.

Subject: Boundary violation -- Hyper-V guest-to-host escape via
         root-partition heap UAF (Critical, RCE, default-on)

Section 1 -- Boundary claim
  This issue violates the Hyper-V virtual machine (guest-to-host)
  security boundary as enumerated in the Microsoft Security Servicing
  Criteria for Windows. The attack flow: a malicious L1 guest VM
  triggers a use-after-free in a Hyper-V root-partition component
  reachable via VMBus; the freed allocation is reclaimed with
  attacker-controlled data via a follow-up VMBus message; the
  resulting type confusion yields remote code execution in the host
  root-partition context with SYSTEM privileges.

Section 2 -- Severity argument
  Per the Microsoft Vulnerability Severity Classification for Windows
  bug bar, this is Critical severity:
    - Vulnerability type: Remote Code Execution
    - Server severity: Critical (server pivot: Hyper-V host is by
      definition a server role)
    - Client severity: Critical (client pivot: same primitive on
      client Hyper-V used by Windows Sandbox / WSL2)
    - Default-on: Yes (the affected root-partition component ships
      and runs by default on all Hyper-V hosts)
    - User interaction required: No
    - Attack complexity: Low

Section 3 -- Reproduction
  - Attached: minimal L1 guest exploit binary (Linux x86_64),
    deterministic on Windows Server 2025 Hyper-V build 26100.4061.
  - Attached: WinDbg crash dump showing the UAF and the controlled
    write primitive.
  - Attached: video of the SYSTEM shell on the host opened by an
    unprivileged user in the guest.

Section 4 -- Bounty eligibility
  Microsoft Hyper-V Bounty Program scope: L1 Guest Escape -- RCE on
  the host from the guest. Requested payout tier per program scope
  page.

That is the checklist. The doctrine is internalised. You can predict the disposition of any Windows finding from the boundary list, the severity scheme, and the exception clause. The only thing left is the closing -- the return to the researcher we opened with.

14. Frequently Asked Questions and Closing

Return to the researcher we opened with. Their "UAC bypass" was filed against a primitive that was never on the boundary list, and the MSRC reply was operationally correct, not a cop-out. The doctrine the reply invoked is the one this article has just walked.

No. UAC was never officially classified as a boundary. Mark Russinovich's June 2007 *Inside Windows Vista User Account Control* article stated verbatim that *"UAC elevations are conveniences and not security boundaries"* -- two years before the January 2009 Long Zheng and Rafael Rivera Windows 7 beta UAC auto-elevation disclosure [@russinovich-vista-uac-wayback]. What Microsoft changed in 2009 was the *implementation* (UAC slider promoted to High integrity; UAC-settings changes prompting), not the *classification*. Russinovich's July 2009 follow-up article restated the original position [@ms-learn-russinovich-win7]. No. "By design" means the doctrine explicitly chose not to service this primitive class as a boundary violation. Microsoft may still harden the feature in a future Windows release, ship out-of-band Canary build mitigations (as with PPLFault build 25941) [@landau-pplfault], or assign CVEs to specific exploitation chains that cross *other* boundaries (as with Windows Downdate's CVE-2024-21302) [@leviev-downdate-update]. The finding is interesting research. It simply does not receive a CVE under the published doctrine. Probably not, but the Administrator Protection elevation *path* is now a boundary [@ms-learn-admin-protection], and the Landau / Leviev disclosures keep pressure on the unmoved part of the classification. The structural impossibility argument (admin loads drivers; drivers run in kernel) makes a doctrinal reclassification unlikely without a deeper architectural change. The most plausible architectural change would be the extension of VTL Enclaves and VBS Trustlets to host security-critical kernel components, such that *admin-to-VTL1* becomes the boundary even as *admin-to-VTL0-kernel* stays a feature [@ms-learn-vbs-ci]. No. Defender bypasses that do not also cross another boundary typically do not receive bulletins. Tavis Ormandy's 2014 to 2017 Defender disclosures earned CVEs because the bugs were memory-corruption primitives reachable from attacker-controlled inputs over the network -- they crossed the network boundary, not because the Defender bypass itself was a boundary crossing. The CVE-2017-0290 *crazy bad* MsMpEng RCE, addressed by Microsoft Security Advisory 4022344 (May 8, 2017), is the flagship instance [@ms-advisory-4022344]. A clever signature-evasion technique alone earns "by design." No. It has grown by accretion: Session 0 isolation (Vista, 2007); AppContainer / Edge sandbox (Windows 8 / 1607, 2012 to 2016); VBS / VTL (Windows 10 1507, 2015); Administrator Protection elevation path (2025) [@ms-learn-admin-protection]. The list is expected to keep growing. Candidate future entries include cloud-side primitives (Conditional Access, Primary Refresh Token) and possibly an AI-mediated action-expansion entry. Not on its own. BYOVD only earns a Microsoft CVE if a second primitive (network, user, AppContainer) is also crossed, or if the *driver vendor* receives the CVE. The Microsoft *Vulnerable Driver Blocklist* is feature hardening that ships in Windows updates, but the loadability of a properly-signed driver by an administrator is not a boundary crossing under the doctrine [@leviev-downdate-update]. No. AM-PPL is a *feature*. The Microsoft Learn page documents PPL as a hardening mechanism for anti-malware services [@ms-learn-am-ppl], and Gabriel Landau's *Inside Microsoft's Plan to Kill PPLFault* preserves the verbatim MSRC position: *"Microsoft does not consider PPL to be a security boundary"* [@landau-pplfault]. Microsoft will still ship PPLFault-class mitigations as feature hardening (build 25941 was the canary), but PPL-bypass reports that do not also cross another boundary do not earn standard Patch Tuesday bulletins.

Closing

The Administrator Protection addition is the most interesting recent move because it closes the elevation-path gap that the entire UAC era could not close. Microsoft added the SMAA elevation path to the boundary table while leaving the admin-to-kernel primitive on the feature side. The result is a two-tier classification: UAC bypasses still do not get CVEs, but Administrator Protection bypasses do -- and Forshaw's nine pre-GA disclosures, all of which Microsoft fixed (not "by design"-replied) are the public-record evidence that the new classification is operationally enforced [@pz-tracker-432313668]. The 2026 frontier is cloud-side and AI-mediated. The boundary list is still growing.

Key idea: The doctrine of what is a boundary is the silent gatekeeper of MSRC triage. Reading it is the difference between filing a useful report and getting back "by design -- UAC is not a security boundary." Every Windows security engineer should be able to recite the boundary list from memory. After this article, you can.

The boundary list. From memory. Now.

Adminless: How Windows Finally Made Elevation a Security Boundary

noreply@paragmali.com (Parag Mali) — Sun, 10 May 2026 00:00:00 GMT

**Administrator Protection (informally "Adminless") replaces Windows 11's split-token UAC with a separate, system-managed local user account.** The operating system creates this **System Managed Administrator Account (SMAA)** per local admin, links it to the primary admin via paired SAM attributes, and uses it to host elevated processes in a fresh logon session gated by Windows Hello. The kernel asks LSA to authenticate "a new instance of the shadow administrator" without any SMAA credential because the SMAA has none. The mechanism makes the elevation path a security boundary for the first time, with bulletin-grade fixes when it fails. Microsoft shipped it in KB5067036 on October 28, 2025, then reverted it on December 1, 2025 over an application-compatibility issue, not a security failure. This article walks the twenty-year argument that produced the design, the nine pre-GA bypasses Forshaw found and Microsoft fixed, and exactly where the new boundary still leaks.

1. Two tokens, one user, twenty years

Open an elevated console on a Windows 11 device with the registry value TypeOfAdminApprovalMode = 2 set, and run whoami /all. The user name is no longer yours. It is ADMIN_<sixteen random characters> -- a local account you never created, owned by an operating-system component you never ran, in a logon session that did not exist five seconds ago and will not exist five seconds after the console closes.

For twenty years, an elevated Windows command prompt reported the same user name as the unelevated one. The integrity level changed. The token changed. The user did not. That single architectural fact is the load-bearing premise of every UAC bypass ever published. The Vista User Account Control design from 2006 issued two tokens at logon for a member of the local Administrators group: a filtered standard-user token for everyday work, and a full admin token linked to it via the TokenLinkedToken field [@ms-uac-how-it-works]. When the user clicked Yes on a consent prompt, the Application Information service called CreateProcessAsUser with the linked token. Same user. Same profile. Same HKCU. Same logon session. Different integrity level.

Four resources stayed shared between the filtered and full tokens, and four categories of attack grew out of them. Files dropped in a writable directory the elevated process trusts. Registry values planted under HKEY_CURRENT_USER that an elevated binary reads before it consults HKEY_CLASSES_ROOT. COM elevation monikers that hand the attacker an elevated IFileOperation interface. Path-resolution overrides that redirect %SystemRoot% for a single auto-elevating process. The UACMe project [@uacme] catalogues 81 such methods, each one a load against the shared-resource shape of Vista's split token.

Administrator Protection inverts that shape. The elevated administrator becomes a different account with a different security identifier, a different profile directory, a different NTUSER.DAT hive, a different authentication-ID LUID, and a different DOS device object directory under \Sessions\0\DosDevices\. The operating system manages the account itself. It is created on demand the first time the policy is enabled, linked to the primary admin via paired Security Account Manager attributes, used in a fresh logon session for every elevation, and the elevated token is destroyed when the process exits [@ms-developer-blog-2025, @call4cloud-osint].

The feature ships under four names -- Administrator Protection in Microsoft Learn, Adminless as the community shorthand this article uses, ShadowAdmin in the samsrv.dll engineering symbols, System Managed Administrator Account (SMAA) in the Windows Developer Blog [@ms-admin-protection, @ms-developer-blog-2025, @call4cloud-osint] -- and §6 walks each in turn. The launch arc was short: announced at Ignite 2024 by David Weston on November 19, 2024 [@bleepingcomputer-2024], surfaced earlier that fall in Insider Preview build 27718 on October 2, 2024 [@ms-insider-build-27718], shipped to stable Windows in KB5067036 on October 28, 2025 [@ms-kb5067036], and disabled on December 1, 2025 over a WebView2 application-compatibility regression [@forshaw-pz-jan2026, @ms-admin-protection].

This article walks what changed and what did not. By the end you will know exactly which UAC bypass families are dead, exactly which survive, exactly what the December 2025 revert was about, and exactly where the new boundary still leaks. The path runs through twenty years of design tradeoffs and seven years of binary-level fixes that never converged on a real boundary. It runs through nine Project Zero bypasses Microsoft fixed before shipping. It ends at a question Microsoft's own design documents do not yet answer: when the prompt is a credential gate instead of a click-through, what is left for the attacker to do?

The first thing to understand is what UAC was trying to do, and why Microsoft said for twenty years it was not a security boundary.

2. "Convenience, not boundary": UAC as Microsoft conceived it

Why did Vista ship UAC at all? For most of Windows history, every interactive logon for a member of the local Administrators group produced one full-admin token. The desktop shell ran as a full administrator. Every child process inherited those rights. The worm era of 2003 to 2005 demonstrated, repeatedly, that one process running in user context owned the whole machine. By 2006 the cost of admin-by-default had become impossible to defend [@wikipedia-uac].The pre-Vista Limited User Account (LUA) was Microsoft's first attempt at a fix. The conceptual ancestor of the filtered token failed in practice because roughly half of the third-party application base broke under it, and the documented workaround -- RUNAS.EXE -- was operationally hostile enough that almost no one used it.

The redesign that produced UAC pivoted on a single observation. Forcing administrators to run as standard users had failed because too much software assumed admin rights. So Vista would give each admin user two identities. One would be standard-user enough to run the desktop, the browser, and the day-to-day applications without privilege. The other would carry the admin rights, and the operating system would arrange for the user to opt into it on a per-task basis.

Mark Russinovich's June 2007 article Inside Windows Vista User Account Control in TechNet Magazine [@russinovich-2007-vista] remains the canonical reference for the design. The mechanism is two tokens at logon; the integrity-level taxonomy (Low, Medium, High, System) gating object access; file-system and registry virtualisation rerouting writes by legacy apps; and Mandatory Integrity Control enforcing the no-write-up rule at the kernel-object boundary.

The mechanism by which Vista UAC assigns two distinct access tokens to a single interactive logon for a member of the local Administrators group. The Local Security Authority issues both at logon: a filtered standard-user token with most privileges removed and the Administrators group marked as deny-only, and a linked full administrator token referenced from the filtered token's `TokenLinkedToken` field [@ms-uac-how-it-works].

The disclaimer that follows the design is the single most quoted sentence Russinovich ever published about UAC. The article will lift it verbatim once, because every Administrator Protection design decision falls out of its absence:

It's important to be aware that UAC elevations are conveniences and not security boundaries. -- Mark Russinovich, *Inside Windows Vista User Account Control*, TechNet Magazine, June 2007 [@russinovich-2007-vista]

This is not an accidental disclaimer. It is the canonical Microsoft classification, preserved into the Microsoft Security Servicing Criteria document [@msrc-servicing-criteria]. James Forshaw of Google Project Zero, writing in January 2026, re-states the position verbatim: "due to the way it was designed, it was quickly apparent it didn't represent a hard security boundary, and Microsoft downgraded it to a security feature" [@forshaw-pz-jan2026]. The classification is what determined what Microsoft would and would not pay attention to. A "security boundary" gets a security bulletin when an attacker crosses it. A "security feature" does not. A bypass of a boundary is a vulnerability. A bypass of a feature is a quality bug. For twenty years, UAC bypasses were quality bugs.

The two-tokens-at-logon mechanism is the shape from which the entire bypass canon grows. The twenty years of evolution that follow run along a single timeline.

timeline title Privilege separation in Windows, NT 3.1 to Administrator Protection 1993 : NT 3.1 ships multi-user accounts and DACLs but admin-by-default desktop culture 2006 : Vista UAC introduces the split-token model and Mandatory Integrity Control 2009 : Davidson publishes the first UAC bypass; Windows 7 ships auto-elevation 2014 : hfiref0x's UACMe catalogue collects the bypass canon 2016 : enigma0x3 publishes the registry-hijack family (eventvwr, fodhelper, sdclt) 2019 : CVE-2019-1388 (consent.exe certificate dialog) is the lone UAC LPE bulletin 2024 : Insider Preview build 27718 surfaces Administrator Protection; Ignite 2024 announces it 2025 : KB5067036 ships the SMAA on stable Windows, then reverts on December 1 2026 : Forshaw's nine pre-GA bypasses all fixed; the elevation path is now a security boundary

To see why the entire bypass canon grew out of the split-token shape, the next section walks the mechanic at function-name granularity. It is the load-bearing pre-history of everything that comes after.

3. The Vista UAC split-token in detail

The mechanics at logon. The Local Security Authority Subsystem Service (LSASS) validates credentials. For a user in the local Administrators group, it constructs two tokens. The filtered token has its dangerous privileges removed and the Administrators SID marked deny-only; the full token retains them. The Token Manager wires the filtered token's TokenLinkedToken field to a handle on the full token. LSASS hands the filtered token to winlogon.exe. Winlogon launches userinit.exe. Userinit launches explorer.exe. The shell, holding the filtered token, becomes the parent process from which every user-initiated process inherits [@ms-uac-how-it-works].

The kernel structure that connects the filtered standard-user token to the linked full administrator token in Vista's split-token model. A process holding the filtered token can read the `TokenLinkedToken` field via the `GetTokenInformation` API to discover the handle of the full token, and pass that handle to `CreateProcessAsUser` to launch an elevated child. The same link is the structural premise of token-stealing attacks: any code path that can read or impersonate the linked token bypasses the consent UI entirely [@ms-uac-how-it-works, @forshaw-pz-jan2026].

The shell shares four resources with anything launched under the full token.

The same user security identifier. Both tokens carry the same primary SID. Files, registry keys, and kernel objects that grant access to the user grant identical access to both processes.
The same %USERPROFILE% directory tree. C:\Users\<user>\ is the home of both. The Documents folder, the Downloads folder, the AppData hives, and any application-specific subdirectory belong to one user.
The same HKEY_CURRENT_USER hive. Both tokens map HKCU to the same NTUSER.DAT file. An elevated process that reads a user setting reads the value the unelevated user wrote.
The same logon-session LUID. The Locally Unique Identifier that identifies an interactive logon session is the same on both tokens. The kernel uses that LUID as a key for per-logon-session caching: the DOS device object directory at \Sessions\0\DosDevices\<LUID>, drive-letter mappings, mapped network drives, and the credential cache.

The elevation pipeline. A user clicks Yes on a UAC prompt. The mechanism beneath that click runs through a chain of named function calls.

sequenceDiagram participant User as User shell (filtered token) participant AppInfo as appinfo.dll (Application Information service) participant Consent as consent.exe (secure desktop) participant LSA as LSASS participant New as Elevated child process

User->>AppInfo: ShellExecute / CreateProcess "as admin"
AppInfo->>AppInfo: RAiLaunchAdminProcess RPC
AppInfo->>AppInfo: Read manifest requestedExecutionLevel
AppInfo->>AppInfo: Check ConsentPromptBehaviorAdmin
AppInfo->>Consent: Launch consent.exe on Winlogon desktop
Consent->>User: Show Yes / No prompt
User-->>Consent: Click Yes
Consent-->>AppInfo: Approved
AppInfo->>LSA: Resolve TokenLinkedToken handle
AppInfo->>New: CreateProcessAsUser(linked full token)
Note over New: Same SID and profile and HKCU and logon session
Note over New: Integrity level High

The prompt runs on the secure desktop, the same Winlogon-owned Winsta0\Winlogon desktop where the credential-entry dialog appears at logon, not the user's interactive Winsta0\Default desktop [@ms-uac-how-it-works]. User Interface Privilege Isolation (UIPI) blocks lower-integrity input from reaching higher-integrity windows; the secure-desktop switch is its first defence against synthetic-keystroke attacks against the prompt itself.The secure desktop is not invulnerable. It changes the integrity-isolation context, but a process holding the filtered token can still trigger the switch (that is the whole point of clicking Yes), and code running before the switch can in principle modify the surrounding UI state. CVE-2019-1388 in late 2019 turned out to exploit a different aspect entirely -- a UI-interaction path through the consent.exe certificate-viewer dialog -- and not the secure-desktop switch itself.

Compare this to what comes next. Both tokens share four resources. Each of those resources is a category of attack waiting for a researcher to find it. The next section is the story of what happened when Microsoft tried to make UAC less annoying by silently elevating its own Microsoft-signed binaries -- and what the bypass canon did with the change.

4. Windows 7 auto-elevation and the birth of the bypass canon

A specific moment. December 2009. Leo Davidson publishes Windows 7 UAC whitelist: Code-injection Issue / Anti-Competitive API / Security Theatre on pretentiousname.com [@davidson-2009]. The title is the argument. The page itself is sprawling, contentious, and on a few key technical points exactly right. Microsoft's response, in Davidson's own words: "this is a non-issue, and ignored my offers to give them full details for several months." Microsoft Security Essentials eventually classified the binary (not the technique) as HackTool:Win32/Welevate.A and HackTool:Win64/Welevate.A; in Davidson's pointed observation, "recompiling the binaries in VS2010 means they are no longer detected" [@davidson-2009].Davidson kept writing into his original page over the following decade. A marker buried inside the text reads "As I was typing more words into this page, this appeared in my text editor at the 10,000th word!" In March 2020 he removed the proof-of-concept binaries, noting "I got sick of the page being marked as malware, even by Google (FFS)." The prose remains the canonical first source on UAC bypasses [@davidson-2009].

What Windows 7 added, in October 2009, to fix Vista's prompt-fatigue problem [@russinovich-2009-win7]:

The autoElevate=true manifest attribute, embedded in selected Microsoft-signed Windows binaries.
An internal whitelist of Microsoft-signed binaries living under %SystemRoot%\System32.
The COM Elevation Moniker -- already shipping in Vista (BIND_OPTS3, syntax Elevation:Administrator!new:<CLSID>) -- was the activation primitive. Windows 7 extended implicit auto-elevation to qualifying COM servers whose registrations matched the new whitelist criteria, so callers such as IFileOperation, ICMLuaUtil, and IColorDataProxy could be launched elevated without a consent prompt under the Win7 model [@russinovich-2009-win7, @uacme]. The dedicated registry-curation surface, the COMAutoApprovalList (HKLM\Software\Microsoft\Windows NT\CurrentVersion\UAC\COMAutoApprovalList) that UACMe Method 49 references verbatim, did not ship in Windows 7; it was introduced seven years later in Windows 10 RS1 (build 14393, August 2016) as a Redstone-1 hardening that replaced implicit COM auto-elevation with explicit list curation [@uacme].
The default consent-prompt behaviour ConsentPromptBehaviorAdmin = 5: prompt for consent for non-Windows binaries [@russinovich-2009-win7].

The Windows 7 mechanism by which selected Microsoft-signed binaries elevate without showing the consent prompt to a user who is a member of the local Administrators group. The Application Information service consults a whitelist of signature, path, and manifest attributes; if the binary qualifies, `appinfo.dll` calls `CreateProcessAsUser` with the linked full token and no UI step at all [@russinovich-2009-win7]. A COM activation syntax introduced in Windows Vista that lets an unelevated caller request an elevated instance of a COM server class. The `IBindCtx` is augmented with a `BIND_OPTS3` structure carrying a window handle to attribute the prompt to. The bind moniker `Elevation:Administrator!new:<CLSID>` causes the COM Service Control Manager to launch the server elevated. UACMe methods that target `IFileOperation`, `ICMLuaUtil`, and `IColorDataProxy` all descend from this mechanism [@russinovich-2009-win7, @uacme].

Davidson's technique against the new whitelist is one paragraph of detail. Use the IFileOperation COM elevation moniker, which itself auto-elevates, to write a planted CRYPTBASE.DLL into %SystemRoot%\System32\sysprep\. The path is a writable destination from the limited token because IFileOperation runs elevated. Then launch sysprep.exe, which is auto-elevated as a Microsoft-signed binary in System32. Sysprep loads CRYPTBASE.DLL from its own directory before the system path. The attacker's DLL runs at High integrity in the elevated sysprep process [@davidson-2009, @uacme]. No prompt. The whitelist did the work.

The bypass canon. Davidson's technique was the start, not the totality. The successors walked the same shape across families.

The DLL side-load family. Sysprep was the canonical instance. Subsequent variants targeted cliconfg.exe, mcx2prov.exe, migwiz.exe, and setupsqm.exe -- each an auto-elevating Microsoft binary that loaded a DLL from a writable directory before consulting the system path. Microsoft removed the auto-elevation attribute from many of these binaries over the Windows 10 1709 cycle, but did so one binary at a time [@uacme].
The registry-hijack family. Matt Nelson's August 2016 disclosure of an eventvwr.exe plus HKCU\Software\Classes\mscfile\shell\open\command bypass [@enigma0x3-2016-eventvwr] established the pattern. An auto-elevating binary consults HKEY_CURRENT_USER before HKEY_CLASSES_ROOT for a value the binary trusts to dispatch a child process. The limited user, who owns HKCU, writes whatever they want into the value. The elevated binary executes the attacker's command line. March 2017 produced sdclt.exe plus App Paths [@enigma0x3-2017-app-paths] and sdclt.exe plus IsolatedCommand [@enigma0x3-2017-sdclt]; May 2017 produced the fodhelper.exe plus ms-settings variant [@uacme]. All fileless. All generalising to any auto-elevating binary that walks HKCU before HKCR.
The COM-elevation-moniker abuse family. UACMe's Method 1 (Davidson's original IFileOperation) ages into Methods 41 (ICMLuaUtil, Oddvar Moe, via ucmCMLuaUtilShellExecMethod) and 43 (IColorDataProxy paired with ICMLuaUtil, Oddvar Moe derivative, via ucmDccwCOMMethod), each one a different COM interface that auto-elevates and exposes a method useful for arbitrary file or registry write [@uacme].
The environment-variable and path-poisoning family. Per-process %windir% or %SystemRoot% redirection via registry shims and Image File Execution Options, redirecting auto-elevating binaries to load resources from attacker-controlled directories.

Key idea: The Windows 7 auto-elevation whitelist was the bypass. The day Microsoft shipped a class of binaries that could elevate silently based on signing and path, the entire problem of UAC bypass reduced to "make one of those binaries do something the attacker wants it to do." Every UACMe method that targets a Microsoft-signed binary in System32 descends from this design choice. The 81-method catalogue is not a list of separate vulnerabilities; it is one architectural mistake spreading through the binary inventory.

Enter hfiref0x's UACMe [@uacme]. The project has been on GitHub since 2014. It currently lists 81 named methods. Each entry pairs the method number with the author credit, the target binary, the technique class, and the "Fixed in" build number. The README, taken together, is the institutional memory of UAC's failure as a boundary. Forshaw's January 2026 framing is the operational summary: "A good repository of known bypasses is the UACMe tool which currently lists 81 separate techniques for gaining administrator privileges" [@forshaw-pz-jan2026].

Microsoft chose to fix individual bypasses rather than redesign the model. The next section asks whether seven years of fixes ever caught up.

5. 2017-2024: incremental hardening, no convergence

The middle Windows 10 era was the moment Microsoft treated UAC bypasses as a quality problem and shipped fixes at quality-fix cadence, not security-bulletin cadence. The work was real, but it was always one binary or one interface at a time.

The named milestones, kept short.

Windows 10 1709 (October 2017). Beginning with this build, IFileOperation auto-elevation for callers other than Explorer was restricted [@uacme]. The originating Davidson 2009 family of bypasses, against the sysprep + planted-CRYPTBASE shape, ceased to function for processes other than the shell itself.
Tighter appinfo.dll manifest parsing across multiple Windows 10 builds. Stricter binary-signature checks. Stricter path checks. Stricter manifest checks. Each of these closed individual bypass methods; none of them closed a family.
Per-binary hardening recorded in UACMe's "Fixed in" column. UACMe version 3.5.0 retired roughly eighty percent of the 2014-vintage catalogue as obsolete; the v3.2.x branch retains the full historical record. The project's README warns that "since version 3.5.0, all previously 'fixed' methods are considered obsolete and have been removed. If you need them, use v3.2.x branch" [@uacme].
CVE-2019-1388 (November 2019; reporter: Eduardo Braun Prado via Trend Micro's Zero Day Initiative). The lone departure from the "UAC bypasses get no CVE" rule. A UI-interaction path through consent.exe's certificate-viewer dialog: an unsigned application could trigger consent.exe to display a certificate dialog whose "View Certificate" link launched Internet Explorer running as NT AUTHORITY\SYSTEM, and IE's File menu opened cmd.exe at the same integrity level [@nvd-cve-2019-1388]. Microsoft fixed it on the November 2019 Patch Tuesday and gave it an LPE bulletin.

CVE-2019-1388 was a prompt-UI bug -- specifically, a crash-path that surfaced an IE process at SYSTEM integrity via the certificate viewer -- not a UAC-bypass bug in the categorical sense. The classification distinction matters: Microsoft did not change its position that UAC was not a boundary; the bulletin treated this as a separate UI defect that incidentally crossed the boundary. CISA later added the CVE to the Known Exploited Vulnerabilities Catalog [@nvd-cve-2019-1388].

The accumulating evidence by 2024 was three observations.

UACMe's catalogue has grown from its 2014 origins to 81 methods today [@uacme]. Each family of attack survived the individual fixes. As Davidson predicted in 2009, the auto-elevation whitelist was the structural problem; patching each whitelisted binary as a separate bug was a treadmill, not a convergence.

Microsoft's own Security Servicing Criteria continued to classify UAC as a security feature, not a boundary, throughout the period [@msrc-servicing-criteria, @forshaw-pz-jan2026]. The decision was load-bearing. Fixing the elevation pipeline at quality cadence meant accepting that bypasses would appear quarterly and would not appear in the Patch Tuesday bulletins until the day Microsoft changed its mind about the classification.

The third piece of evidence is what the attackers were doing while the defenders were churning the binary list. Microsoft's own number, quoted by the Windows Developer Blog from the Microsoft Digital Defense Report 2024, is 39,000 token-theft incidents per day [@ms-developer-blog-2025]. A token, once stolen from an elevated process, requires no further bypass: it is a bearer credential good for the lifetime of the logon session. The same logon session is the one the unelevated user and the elevated process share under the split-token model. The "one logon session" property of UAC's design is the structural premise that token theft depends on.

There is one further thread worth naming here. Forshaw's broader 2022 Kerberos work in the user-credential-delegation space is a thread that survives the elevation-redesign question entirely. The May 2022 Exploiting RBCD using a normal user account post [@forshaw-2022-rbcd] is the representative artifact. Network-credential delegation primitives -- Resource-Based Constrained Delegation, User-to-User Kerberos, S4U2Self -- operate at a layer beneath token-level elevation, and survive even a perfect SMAA design because they do not run through the elevation path at all.

Piecewise fixes never converged on a boundary. The question that drove the next five years of Microsoft work was the obvious one: if the issue is the shared-resource model itself, what is the smallest plausible change that fixes it?

6. The breakthrough: the System Managed Administrator Account

The load-bearing design decision is one sentence. Stop trying to make one user account play both roles. The elevated administrator should be a different account with a different SID, a different profile, a different HKCU, a different logon session, and a different DOS device object directory -- and the operating system should manage that account itself.

What is striking about the design is how prosaic the underlying mechanism is. Multi-user accounts have shipped with Windows NT since version 3.1 in 1993. The architecture for running an elevated process under a separate local user has been present in NT for thirty-three years. What changed is that Microsoft finally chose to enforce the multi-user model for privilege separation, by making the operating system itself create and manage the second account, link it to the primary admin via paired Security Account Manager attributes, and use it for every elevation. The sophistication is in linkage, in lifecycle, and in removing auto-elevation, not in any single new primitive.

Note: The thing that changes between UAC and Administrator Protection is not the elevation mechanism (a manifest, a prompt, a CreateProcessAsUser call) but the elevation classification. An elevation bypass used to be a quality bug. It is now a security-bulletin vulnerability. Every Administrator Protection design decision -- separate account, fresh logon session, removed auto-elevation, Hello-gated consent -- is a consequence of the classification change.

The names. Microsoft Learn's term is Administrator Protection [@ms-admin-protection]. Microsoft's announcement material at Ignite 2024 and in the Insider Preview build 27718 post uses the same "Administrator Protection" label [@ms-insider-build-27718]; Adminless is the community shorthand that stuck. The internal engineering term in samsrv.dll (the Security Account Manager service DLL) is ShadowAdmin [@call4cloud-osint]. The Windows Developer Blog's canonical term for the underlying entity is the System Managed Administrator Account (SMAA) [@ms-developer-blog-2025].

The hidden local user account that Windows creates per primary administrator when the `TypeOfAdminApprovalMode` policy is set to 2. The SMAA has its own random user name (typically `ADMIN_`), its own SID, its own profile directory under `C:\Users\ADMIN_\`, its own `NTUSER.DAT` and therefore its own `HKCU`, and its own membership in the local Administrators group. The operating system uses it to host elevated processes; the user never logs into it directly [@ms-developer-blog-2025, @call4cloud-osint].

The SMAA lifecycle. Four beats. Each anchored to a verified source.

Provisioning. When TypeOfAdminApprovalMode = 2 is set under HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System (either by Group Policy or by the Intune Settings Catalog), samsrv.dll's ShadowAdminAccount::CreateShadowAdminAccount runs once per existing local-administrator account. CreateRandomShadowAdminAccountName produces an ADMIN_<random> name. AddAccountToLocalAdministratorsGroup adds the new account to the Administrators group. Accounts managed by Windows LAPS (Local Administrator Password Solution) are skipped; their lifecycle is owned by a different subsystem and Microsoft did not want the SMAA mechanism to fight LAPS rotation [@call4cloud-osint].

Linking. Two paired SAM attributes encode the trust relationship between the two accounts. The primary admin's user record gets a ShadowAccountForwardLinkSid attribute pointing at the SMAA's SID. The SMAA's user record gets a ShadowAccountBackLinkSid attribute pointing back at the primary admin. These two attributes are the only structural relationship between the two accounts; everything else -- profile, HKCU, group memberships -- is independent [@call4cloud-osint].

Two paired SAM-database attributes that encode the trust relationship between a primary admin user and its System Managed Administrator Account. The forward link sits on the primary admin's record and points at the SMAA's SID. The back link sits on the SMAA's record and points back at the primary admin. The Application Information service uses the forward link at elevation time to resolve which SMAA to launch the elevated process under [@call4cloud-osint]. The registry value under `HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System` that selects the elevation policy. Value 0 disables UAC. Value 1 selects classic Admin Approval Mode (the Vista / Win7 / Win10 split-token behaviour). Value 2 selects Admin Approval Mode with Administrator Protection: every elevation routes through the SMAA path. The value is set by Group Policy ("User Account Control: Configure type of Admin Approval Mode") or by an Intune Settings Catalog policy and requires a reboot to take effect [@ms-admin-protection, @call4cloud-osint].

Per-elevation use. appinfo.dll's RAiLaunchAdminProcess RPC endpoint reads TypeOfAdminApprovalMode. When the value is 2, it walks the forward link to find the calling user's SMAA, launches consent.exe on the secure desktop in credential prompt mode (not Yes/No), authenticates the primary user via Windows Hello (PIN, fingerprint, face, or password fallback), asks the kernel to ask LSA for a fresh primary token for the SMAA in a brand-new logon session, and calls CreateProcessAsUser with that token, the user's requested executable, and the SMAA's profile environment [@ms-developer-blog-2025, @ms-admin-protection, @forshaw-pz-jan2026]. The credential-less LSA logon at the heart of step three of this beat is walked in §7.

Teardown. When the elevated process exits, the SMAA's token handle goes out of scope. The logon session is reaped. The elevated profile directory remains on disk at C:\Users\ADMIN_<random>\ -- it has to, to preserve per-elevation user state across reboots -- but the live admin token does not. There is no persistent High-integrity process running between elevations [@ms-developer-blog-2025].

flowchart TD Start[Policy enabled: TypeOfAdminApprovalMode = 2] --> Provision Provision[samsrv.dll: CreateShadowAdminAccount per local admin] --> Naming Naming[CreateRandomShadowAdminAccountName -> ADMIN_random] --> AddGroup AddGroup[AddAccountToLocalAdministratorsGroup] --> Link Link[SAM linkage: ShadowAccountForwardLinkSid /
ShadowAccountBackLinkSid] --> Idle[SMAA exists, no token live] Idle -->|Each elevation| RPC[appinfo.dll: RAiLaunchAdminProcess] RPC --> Prompt[consent.exe: Hello credential prompt] Prompt --> LSA[Kernel asks LSA: credential-less logon for SMAA] LSA --> Run[CreateProcessAsUser with SMAA token] Run -->|Process exits| Teardown[Token handle released;
logon session reaped] Teardown --> Idle Windows creates a temporary isolated admin token to get the job done. This temporary token is immediately destroyed once the task is complete, ensuring that admin privileges do not persist. -- David Weston, Microsoft Ignite 2024 keynote, November 19, 2024 [@bleepingcomputer-2024]

Key idea: The single design decision behind Administrator Protection: the elevated and unelevated halves of an administrator must be different accounts. Different SID, different profile, different HKCU, different logon session, different DOS device object directory. The shared-resource attacks of the UAC bypass canon cannot persist if there are no shared resources.

The mechanism is now described. The next section walks it at function-name granularity for a single elevation, end to end -- and in particular, the credential-less LSA logon at step six that does the load-bearing work of minting the SMAA token without any SMAA credential.

7. The elevation pipeline end to end

Walk a single elevation. Nine steps.

The caller invokes ShellExecute or CreateProcess with an elevation request. For the shell-launched case the user right-clicks an executable and selects "Run as administrator"; the same RPC endpoint serves manifest-declared requestedExecutionLevel = "requireAdministrator" callers and Elevation:Administrator!new:<CLSID> COM moniker requests.
appinfo.dll's RAiLaunchAdminProcess RPC endpoint, hosted inside the Application Information service in svchost.exe, receives the call [@ms-uac-how-it-works].
appinfo reads HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\TypeOfAdminApprovalMode.
If the value is 2 (Admin Approval Mode with Administrator Protection), appinfo reads the calling user's SAM record, locates the ShadowAccountForwardLinkSid attribute, and validates the corresponding ShadowAccountBackLinkSid on the SMAA's SAM record. The linkage check is what binds a given elevated process to a given primary user; without both attributes pointing at each other, the elevation is refused [@call4cloud-osint].
appinfo launches consent.exe on the secure desktop in credential prompt mode rather than the classic Yes/No mode. The prompt asks the primary user to authenticate via Windows Hello (PIN, fingerprint, face, or password fallback), not the SMAA. The SMAA has no human credentials. The Windows Developer Blog states the property explicitly [@ms-developer-blog-2025], and Forshaw's January 2026 post restates it in operational terms: "The user does not need to know the credentials for the shadow administrator as there aren't any. Instead UAC can be configured to prompt for the limited user's credentials, including using biometrics if desired" [@forshaw-pz-jan2026].
On a positive Hello result, appinfo.dll -- running as NT AUTHORITY\SYSTEM inside the Application Information service -- asks the kernel to ask LSA for a fresh primary access token for the SMAA's SID in a brand-new logon session. The LSA logon is credential-less. The kernel asks LSA to authenticate "a new instance of the shadow administrator," and LSA fulfils the request without any SMAA credential because the SMAA has no credential to verify. The trust architecture mirrors the way the Service Control Manager asks LSA for service-account tokens: SCM is trusted to ask for the token; LSA mints it on the strength of the request rather than on the strength of any credential. In Administrator Protection, appinfo.dll is the trusted requester, and its request is gated on the user-side Hello result it received in step 5. The Forshaw verbatim that anchors the mechanism is below this section [@forshaw-pz-jan2026, @ms-developer-blog-2025].
appinfo calls CreateProcessAsUser with the SMAA token, the user's requested executable, and the SMAA's profile environment block (USERPROFILE=C:\Users\ADMIN_<random>, USERNAME=ADMIN_<random>, the SMAA's NTUSER.DAT mapped as HKCU).
The new process loads at High integrity, holding the SMAA's primary token, in a fresh logon session with a freshly minted authentication-ID LUID. The DOS device directory at \Sessions\0\DosDevices\<LUID> does not yet exist; the kernel will create it on first reference.
Subsequent SeAccessCheck calls on system objects evaluate against the SMAA's local Administrators group membership and succeed. The elevated process can write to HKLM, modify program files, install services, load WHQL-signed drivers (subject to App Control for Business and HVCI), and otherwise behave as a member of the Administrators group [@ms-developer-blog-2025].

The mechanism by which the Local Security Authority mints a primary access token for the SMAA without verifying any SMAA credential. `appinfo.dll`, running as `NT AUTHORITY\SYSTEM` inside the Application Information service, requests the logon on the SMAA's behalf after the primary user has succeeded against the Hello credential gate. LSA fulfils the request because the *requester* is trusted; the architecture mirrors the way the Service Control Manager requests service-account tokens. The "credential-less" label is descriptive of the SMAA side of the exchange: the SMAA never has a human credential to verify, so LSA cannot and does not ask for one [@forshaw-pz-jan2026, @ms-developer-blog-2025].

The trust architecture is not new in Administrator Protection. The Service Control Manager has asked LSA for service-account tokens since Windows NT 3.1 in 1993; LSA accepts the request because SCM is the trusted requester, not because the service account presented a credential. Administrator Protection generalises the same pattern to elevation: appinfo.dll is the trusted requester, and the SMAA is its functional analogue of a service account. What is new is the user-side gate -- the trusted requester only makes the request after a positive Hello result on the primary user's credential.

in Administrator Protection the kernel calls into the LSA and authenticates a new instance of the shadow administrator. This results in every token returned from `TokenLinkedToken` having a unique logon session, and thus does not currently have the DOS device object directory created. -- James Forshaw, *Bypassing Windows Administrator Protection*, Google Project Zero, January 26, 2026 [@forshaw-pz-jan2026]

The "unique logon session" property in Forshaw's quote is exactly the structural property the lazy-DOS-device-directory bypass exploits, and §12 walks that exploit in full. For now, the load-bearing observation is the credential-less logon itself: the SMAA token is real, the logon session is real, the integrity level is real, but no SMAA credential ever changes hands. The trust is in the requester, gated by a Hello gesture from the primary user.

sequenceDiagram participant User as User shell (primary admin filtered token) participant AppInfo as appinfo.dll (NT AUTHORITY\SYSTEM) participant SAM as samsrv.dll / SAM database participant Consent as consent.exe (secure desktop) participant Hello as Windows Hello / TPM participant LSA as LSASS participant Elev as Elevated SMAA process

User->>AppInfo: ShellExecute "as admin"
AppInfo->>AppInfo: RAiLaunchAdminProcess RPC
AppInfo->>AppInfo: Read TypeOfAdminApprovalMode = 2
AppInfo->>SAM: Resolve ShadowAccountForwardLinkSid
SAM-->>AppInfo: SMAA SID + backlink check OK
AppInfo->>Consent: Launch consent.exe (credential mode)
Consent->>Hello: Request Hello gesture for primary user
Hello-->>Consent: PIN / biometric / password verified
Consent-->>AppInfo: Approved
AppInfo->>LSA: Credential-less logon for SMAA (trusted-requester pattern)
LSA-->>AppInfo: Fresh SMAA primary token and fresh LUID
AppInfo->>Elev: CreateProcessAsUser with SMAA token and profile
Note over Elev: Different SID and USERPROFILE and HKCU and LUID
Note over Elev: Integrity level High -- DOS device dir not yet created

A practical illustration of the shift, displayed as the diff between the pre-AP and post-AP elevated console session.

{` // Modelled output of 'whoami /all' run from an elevated console. // Before: TypeOfAdminApprovalMode = 1 (classic UAC). // After: TypeOfAdminApprovalMode = 2 (Administrator Protection).

const before = { user: 'CONTOSO\\alice', sid: 'S-1-5-21-123456789-987654321-1122334455-1001', profile: 'C:\\Users\\alice', authId: '0x3e7:0x000abcde', integrity: 'S-1-16-12288 (High)', groups: ['BUILTIN\\Administrators (Enabled)'] };

const after = { user: 'WIN11-PC\\ADMIN_9f2c7e1bdc4a8033', sid: 'S-1-5-21-123456789-987654321-1122334455-1051', profile: 'C:\\Users\\ADMIN_9f2c7e1bdc4a8033', authId: '0x3e7:0x000abf42', integrity: 'S-1-16-12288 (High)', groups: ['BUILTIN\\Administrators (Enabled)'], shadowBacklink: 'CONTOSO\\alice' };

console.log('Different user name:', before.user !== after.user); console.log('Different SID:', before.sid !== after.sid); console.log('Different profile:', before.profile !== after.profile); console.log('Different LUID:', before.authId !== after.authId); console.log('Same integrity:', before.integrity === after.integrity); `}

The pipeline is now a single chain of named function calls. The next section asks what changed about the four shared-resource properties from §3, and which UAC-bypass family each fix forecloses.

8. The four shared-resources fixes, precisely

Each of the four shared resources from §3 maps to a precise Administrator Protection fix, and each fix maps to a named UAC-era attack class it forecloses.

Shared resource (UAC)	Administrator Protection fix	UAC-era attack class foreclosed
Same SID across both tokens	SMAA has its own SID; no shared user identity	Same-user file and registry ACE confusion
Same `%USERPROFILE%`	SMAA has `C:\Users\ADMIN_<random>\`	DLL side-load family (sysprep / CRYPTBASE)
Same `HKCU` hive	SMAA has its own `NTUSER.DAT`	Registry-hijack family (eventvwr, fodhelper, sdclt)
Same logon-session LUID	SMAA gets a fresh LUID per elevation	Token-theft via `TokenLinkedToken`; logon-session DOS device hijack

Profile separation. The SMAA owns its own %USERPROFILE% directory tree under C:\Users\ADMIN_<random>\. Files created by elevated processes land there by default. Library folder divergence is the most visible consequence: an elevated Notepad's File > Save dialog opens at the SMAA's Documents, not the primary user's. The primary user cannot see those files in their own Explorer without explicit cross-profile navigation. The structural property that closes is the writable-shared-directory premise of the Davidson 2009 DLL side-load family. Sysprep + CRYPTBASE was a profile-shared attack; without a shared profile, the elevated binary searches a different directory tree from the one the limited user can write to [@ms-developer-blog-2025].

Registry separation. The SMAA's HKCU maps to the SMAA's NTUSER.DAT, not the primary user's. When eventvwr.exe, running in an SMAA process, queries HKCU\Software\Classes\mscfile\shell\open\command, it reads the SMAA's hive, not the primary user's. The primary user has no write access to the SMAA's NTUSER.DAT. The entire registry-hijack family -- eventvwr / mscfile [@enigma0x3-2016-eventvwr], fodhelper / ms-settings, sdclt / IsolatedCommand [@enigma0x3-2017-sdclt], sdclt / App Paths [@enigma0x3-2017-app-paths] -- forecloses on the same property: the elevated binary's HKCU lookup walks a hive the attacker does not control [@ms-developer-blog-2025].

Logon-session separation. Every SMAA elevation gets a fresh authentication-ID LUID. The Local Security Authority allocates a new logon session for each elevation; when the elevated process exits, the session is reaped. Per-logon-session kernel resource caches, including the DOS device object directory at \Sessions\0\DosDevices\<LUID> and the credential cache, do not flow across the boundary. Token handles cannot be reused. Drive-letter overrides under the limited user's logon session do not appear in the SMAA's session [@forshaw-pz-jan2026].

No auto-elevation. The autoElevate=true manifest attribute is no longer honoured by appinfo.dll under TypeOfAdminApprovalMode = 2. Every elevation that previously went silent now prompts. The Windows Developer Blog states the change directly: "With administrator protection, all auto-elevations in Windows are removed and users need to interactively authorize every admin operation" [@ms-developer-blog-2025]. Forshaw's January 2026 framing of the consequence: "as auto-elevation is no longer permitted they will always show a prompt, therefore these are not considered bypasses" [@forshaw-pz-jan2026]. This is the single most consequential fix in the design. The auto-elevation whitelist was the bypass; removing the whitelist eliminates the class at the source, including the entire silent-elevation primitive class that Forshaw's older RAiProcessRunOnce research relied on.

Multi-user separation is the original UNIX privilege model. The `root` user holds privilege; ordinary users do not; the boundary between them is the file-permission system enforced by the kernel. Windows NT shipped the same primitives in 1993 -- discretionary access control lists on every securable object, per-user profiles, multi-user logon sessions -- but the surrounding culture treated Administrator-as-default as the path of least resistance. The architectural sophistication in Administrator Protection is in *linkage* (the SAM forward / back attributes), *lifecycle* (provisioning on policy enable, teardown on process exit), and *enforcement* (removal of auto-elevation as a mechanism). The primitives themselves are old.

The four fixes share a property. Each one breaks a shared resource that an attacker depends on. But there is one more piece of the redesign that has not yet been described: the prompt itself is no longer a Yes/No click-through. The next section asks what happens when the consent UI becomes a credential.

9. Windows Hello as the consent gate

The classic UAC prompt is a Yes / No on the secure desktop. Administrator Protection turns the prompt into a credential prompt for the primary user's Windows Hello: a PIN, a fingerprint, a face match, or a password fallback. The credential is for the primary user, not the SMAA, because the SMAA has no human credentials; the Hello verification is what authorises the cross-profile elevation [@ms-admin-protection, @ms-developer-blog-2025, @forshaw-pz-jan2026].

To talk precisely about what the gate does, name the primitive it closes. Under classic UAC, the consent prompt treated a click on the secure desktop as sufficient evidence of consent; physical presence was the entire evidence requirement. That primitive shows up in three sub-cases that the UAC literature has documented for two decades.

The primitive by which the legacy UAC consent dialog accepted a click on the secure desktop as sufficient evidence of consent, without verifying *who* clicked. Three operational sub-cases follow. *Unattended-session click-through* -- an attacker (or co-located third party) with brief physical access to an unlocked screen showing a UAC prompt clicks Yes on the presumption that whoever is at the keyboard is the legitimate user. *Habituated-click click-through* -- the legitimate user has clicked Yes on hundreds of UAC prompts and clicks one more without conscious attention. *Pretext click-through* -- a malicious application argues a legitimate-looking case to the user and elicits the Yes click. Administrator Protection's credential gate cost-raises all three sub-cases without fully eliminating any [@forshaw-pz-jan2026, @ms-admin-protection].

Unattended-session click-through. An attacker who walks up to an unlocked screen showing a UAC prompt can click Yes and elevate. The legitimate user has authenticated; the prompt assumes the person at the keyboard is the legitimate user. Post-AP, the click is not sufficient. The Hello biometric or PIN is required, and the attacker (who does not know either) cannot complete the gesture. Microsoft's Ignite 2024 framing addresses this primitive implicitly with "elevation rights only when needed" and "interactively authorize every admin operation" [@bleepingcomputer-2024].

Habituated-click click-through. A user who has clicked Yes on hundreds of UAC prompts over the course of a year clicks Yes on a malicious one as reflex. The classic UAC prompt requires no attentional engagement beyond physical presence and a click. Hello's gesture (a four-digit PIN entry, a fingerprint press, a face-recognition glance) is higher-friction and harder to perform inattentively. The Windows Developer Blog frames the property as "just-in-time administrator privileges, incorporating Windows Hello to enhance both security and user convenience" [@ms-developer-blog-2025].

Pretext click-through. A malicious application that argues its case to the user -- a fake installer, a re-skinned setup utility, a Trojan masquerading as a legitimate update -- can elicit a Yes click pre-AP. Post-AP, the user is also asked for a credential, which is a stronger user-side check. The user is more likely to interrogate "why am I being asked for my PIN again?" than "why is a prompt appearing?" Microsoft Learn captures the intent as "users are aware of potentially harmful actions before they occur, providing an extra layer of defense against threats" [@ms-admin-protection].

None of the three sub-cases is fully eliminated. Forshaw is explicit that visible-prompt bypasses are not classified as security vulnerabilities by Microsoft's design-document position: bypasses that result in a visible prompt are not security bulletins, because the user could equivalently have launched the prompt themselves [@forshaw-pz-jan2026]. What the gate does is cost-raise each sub-case. The unattended-screen attack requires a stolen PIN or coerced biometric. The habituated user must perform a gesture they cannot perform inattentively. The pretext attack must justify the second authentication, not just the first.

What it does not close is worth naming, because three primitives that look like they belong on the credential gate's account sheet were already closed by independent mechanisms, and the article should say so to avoid the common over-attribution mistake.

Synthetic-keystroke SendInput against consent.exe. Already closed by UIPI in Vista 2006, and doubly closed by the secure-desktop switch to Winsta0\Winlogon. Even UI Access processes -- whose purpose is to bypass UIPI for accessibility -- cannot reach into the secure desktop [@forshaw-pz-feb2026].
Headless UI Automation against the prompt. Same UIPI / secure-desktop boundary closes it. Redundant with respect to the credential gate.
CVE-2019-1388-class UI-interaction paths surfaced through the prompt's own UI. Closed by Microsoft's November 2019 HHCtrl patch and the cert-viewer UI redesign, prior to any Administrator Protection development [@nvd-cve-2019-1388].

The credential is hardware-rooted via TPM or Pluton on capable hardware. The PIN is unsealed only under the user's gesture; the biometric flows through Enhanced Sign-in Security (ESS) on capable hardware; the credential itself never leaves the Trusted Platform Module or Pluton enclave when ESS is engaged [@ms-windows-hello-ess]. The detail of the Hello architecture itself -- FIDO2 attestation, the ngc protector, the ESS isolation path through the Secure Kernel -- belongs to the Windows Hello article in this series, and is not re-derived here.

The new risk the gate does not close is the obvious one. Phishing the prompt now phishes a real credential, not just consent. A malicious application that can convince the user to authenticate on its behalf gets the elevation the user would otherwise have given to a legitimate request. The credential remains hardware-rooted and is not exfiltrated to the malware, but the elevation produces a working SMAA token in the attacker's process. This is the surface §15 carries forward to open problems.

Key idea: The credential gate closes one specific primitive: consent-without-identity-verification. It cost-raises three sub-cases (unattended-session, habituated-click, pretext click-through) without eliminating any. The structural boundary is profile separation plus fresh logon session plus auto-elevation removal; the credential gate is the fourth, defence-in-depth, property that ensures the boundary cannot be silently crossed by anyone holding only the limited user's physical access.

The prompt is a credential gate, but it remains a UI element. The next section asks how this elevation model compares to what other operating systems do.

10. Competing approaches: what other operating systems do

Three one-paragraph treatments. The article does not re-derive each system; it positions Administrator Protection against the field.

Linux: sudo plus PolKit pkexec plus PAM modules. The authority model on Linux is file-based. /etc/sudoers (or its LDAP equivalent) is the policy table; the sudoers plugin reads it and decides whether to permit a given user to run a given command [@sudo-ws-sudoers]. PolKit -- polkitd and its authentication-agent helpers -- is the parallel mechanism for GUI privileged-service requests, with actions and mechanisms separated in the polkit configuration files [@polkit-docs]. Biometric integration arrives through the PAM stack: pam_fprintd for fingerprint, pam_u2f for FIDO2 tokens, pam_yubico for Yubikeys. There is no profile separation by default; sudo -i switches HOME to root's home directory but does not separate per-elevation. The model is per-command authorisation, not per-account isolation.

macOS: Authorization Services plus Touch ID via pam_tid. GUI elevation prompts are gated by authorizationdb, a property-list-format policy database whose rules name which credentials (admin password, Touch ID, system-wide entitlements) authorise which actions [@apple-auth-services]. Touch ID is verified by the Secure Enclave Processor; the credential never leaves the SEP, and Authorization Services integrates with pam_tid to allow sudo invocations to use the gesture [@apple-pam-tid]. There is no separate admin profile; Transparency, Consent, and Control (TCC) guards privileged resource access at the per-action level, not the per-profile level. The Mac architecture privileges hardware-rooted consent (Touch ID, Secure Enclave) over account separation.

Microsoft's own sudo.exe (Windows 11 24H2). An inbox terminal transport that triggers the existing UAC or Administrator Protection pipeline; not an alternative to either [@ms-sudo-docs]. The forceNewWindow mode opens an elevated console in a new window. The disableInput mode keeps the elevated console in the current window but blocks keyboard input to it from the unelevated terminal. The normal (inline) mode preserves POSIX-style pipes between the unelevated and elevated processes. Microsoft Learn warns explicitly about the inline mode: "Sudo for Windows can be used as a potential escalation of privilege vector when enabled in certain configurations" [@ms-sudo-docs]. The mechanism is RPC between the unelevated and elevated sudo.exe processes; the elevation itself still goes through appinfo.dll.

Intune Endpoint Privilege Management (EPM). Cloud-policy-driven virtual-account elevation [@ms-epm-overview]. EPM performs elevation via a virtual account that is not a member of the local Administrators group; the elevation rights are conferred only for the duration of the policy-permitted action. Three elevation modes are available: Automatic (no user interaction), User-confirmed (a prompt), and Elevate as Current User (the action runs as the user's elevated identity rather than the virtual account). EPM is architecturally complementary to Administrator Protection: EPM is the enterprise policy story, Administrator Protection is the per-device architecture story. The two can coexist on the same device.

The distinguishing property of Administrator Protection in this comparison is whole-profile separation: the SMAA's own profile, the SMAA's own HKCU, the SMAA's own library folders, plus a fresh logon session per elevation. Neither Linux sudo nor macOS Authorization Services provides that property as a default desktop primitive. EPM provides per-elevation isolation via the virtual account but does not give the elevated process a persistent profile, which is what makes Administrator Protection's compatibility story so different from EPM's.

Administrator Protection is the architecturally tightest desktop elevation model now in production. The next section asks where the boundary still leaks.

11. Theoretical limits: what Administrator Protection cannot fix

Four structural ceilings.

Showing a prompt is not crossing the boundary. Microsoft's design position is explicit: bypasses that result in a visible elevation prompt are not security bulletins, because the user could equivalently have right-clicked "Run as administrator." Forshaw's January 2026 post states the position verbatim: "I expect that malware will still be able to get administrator privileges even if that's just by forcing a user to accept the elevation prompt" [@forshaw-pz-jan2026]. The operational consequence is that social-engineering the consent dialog remains a structural attack surface. The prompt is a UI element. The boundary is the credential gate. The gate is only as strong as the user's resistance to whatever pretext induces them to authenticate.

The MSRC servicing-criteria definition of a security boundary: a logical separation between code or data of different trust levels, intended to be enforced by the operating system and accompanied by a Microsoft commitment to issue a security update when an unauthorised crossing is found. UAC under the classic split-token model is classified as a *security feature*, not a boundary; bypasses receive quality-fix attention but not security-bulletin attention. Administrator Protection is the first elevation mechanism classified as a security boundary, with bulletin-grade fixes when it fails [@msrc-servicing-criteria, @forshaw-pz-jan2026].

Admin equals kernel. Once code is running inside an SMAA elevated process, it has the local Administrators group; it can write to HKLM; it can install services; it can load WHQL-signed drivers; it can call into kernel-mode interfaces gated by SeLoadDriverPrivilege and the App Control for Business policy. The MSRC servicing-criteria position that "admin-to-kernel is not a security boundary" continues to apply inside the SMAA [@msrc-servicing-criteria]. Administrator Protection makes the path to admin into a boundary; it does not change the relationship between admin and kernel. Driver-loading controls remain the domain of WHQL signing, the Microsoft Vulnerable Driver Blocklist (default-on in Windows 11 since the 2022 update), App Control for Business policies, and Hypervisor-protected Code Integrity (HVCI) [@ms-vuln-driver-blocklist]. The App Identity article in this series covers the App Control mechanism in detail.

The SMAA is in the local Administrators group. Discretionary access control list-based exposures of admin-only resources -- CREATOR OWNER ACEs on persistent objects, world-writable DACLs on certain \Sessions\0\DosDevices entries, default-permissive ACLs on a handful of legacy registry trees -- still grant the SMAA full access. The boundary is between standard user and SMAA, not between SMAA and SYSTEM. The SMAA is a high-privilege actor inside the operating system; the relationship between it and the rest of the privileged surface is unchanged.

Out of scope per Microsoft Learn. Remote logon, roaming profiles, backup-admin accounts, Managed Service Accounts and group Managed Service Accounts (MSAs and gMSAs), virtual accounts for services, and domain-admin scenarios are explicitly outside the Administrator Protection model in its current form [@ms-admin-protection]. The feature is local-machine-only, interactive-admin-only. Domain administrators who log into a workstation will not see the SMAA path; service accounts under LOCAL SERVICE, NETWORK SERVICE, or IIS_IUSRS are unaffected.

Key idea: A genuine architectural ceiling on consent-prompt elevation: the prompt is a UI element; the boundary is the credential gate; the gate is only as strong as the user's resistance to social engineering. Closing the gap requires out-of-band consent (smartcard, phone push) or per-action policy without human consent in the loop (EPM's automatic mode). Neither is the default.

Four limits, four sentences. The next section walks the concrete evidence of what actually leaked in the pre-GA Insider Preview builds, and what Microsoft did about it.

12. Forshaw's nine bypasses, classified

Between October 2024, when Administrator Protection first appeared in Insider Preview build 27718, and October 2025, when KB5067036 made the feature available on stable Windows, James Forshaw of Google Project Zero audited the mechanism and found nine separate silent-bypass paths. Microsoft fixed all nine -- either in the KB5067036 ship or in subsequent security bulletins [@forshaw-pz-jan2026]. The fact pattern is the structural confirmation that Administrator Protection is now treated as a security boundary. Under the UAC classification, none of those nine would have received CVEs. Each one would have been a quality bug. The bypass canon ran for twenty years without bulletins. The fact that the first cohort of Administrator Protection bypasses produced nine bulletin-eligible fixes is exactly the change in posture the classification change implies.

All the issues that I reported to Microsoft have been fixed, either prior to the feature being officially released (in optional update KB5067036) or as subsequent security bulletins. -- James Forshaw, *Bypassing Windows Administrator Protection*, Google Project Zero, January 26, 2026 [@forshaw-pz-jan2026]

Walk the nine as three classes.

The lazy DOS device directory hijack

The single most interesting vulnerability in the feature's history; Forshaw's January 26, 2026 deep analysis [@forshaw-pz-jan2026]; Project Zero issue 432313668 [@pz-issue-432313668]. The mechanism turns on a behaviour change Administrator Protection itself introduced. Every SMAA elevation gets a fresh logon session, which means the per-logon-session DOS device object directory at \Sessions\0\DosDevices\<LUID> is not created at SMAA logon time. The kernel routine SeGetTokenDeviceMap creates the directory lazily, on the first reference. The owner of the new directory is the owner of the access token that triggered the creation [@forshaw-pz-jan2026, @theregister-2026].

The impersonation level (`SecurityIdentification`) at which an impersonating thread can read security information about the impersonated token -- the SID set, the privilege set -- but cannot perform privileged operations or open kernel objects as the impersonated user. The kernel allows access checks to consult an identification-level token for *reading* the security information; certain code paths inadvertently use that information for *granting* operations, which is the structural primitive Forshaw's lazy DOS device directory exploit depends on [@forshaw-pz-jan2026].

The SECURITY_IMPERSONATION_LEVEL enumeration in winnt.h defines four levels in ascending order: SecurityAnonymous (value 0), SecurityIdentification (1), SecurityImpersonation (2), SecurityDelegation (3). SecurityIdentification is the second-lowest -- it sits one above SecurityAnonymous -- and is the level Windows uses when it wants to ask the kernel "what would this token be allowed to do?" without actually doing the operation. The trap is when a code path that runs as the caller uses an identification-level impersonation to read a token property -- here, the linked-token field -- and the resulting object inherits the caller's owner SID rather than the impersonated token's.

The exploit chain. An attacker running as the primary user (filtered token, Medium integrity) starts an elevation. Before the SMAA process touches its DOS device directory, the attacker impersonates the SMAA's TokenLinkedToken at identification level and triggers a code path that walks the directory. The kernel creates \Sessions\0\DosDevices\<SMAA_LUID> lazily; in the affected code path, the owner of the new directory becomes the attacker's primary token's owner SID rather than the SMAA's.

The attacker plants a C: symbolic link inside the directory pointing at an attacker-controlled location. When the elevated SMAA process loads its DLLs, the resolution walks \Sessions\0\DosDevices\<SMAA_LUID>\C: first; the symlink redirects the load to the attacker's directory; the attacker's DLL runs in the High-integrity SMAA process [@forshaw-pz-jan2026].

sequenceDiagram participant Att as Attacker (limited user) participant Kern as "Kernel (SeGetTokenDeviceMap)" participant SMAA as SMAA elevated process

Note over SMAA: Fresh logon session -- DOS device dir not yet created
Att->>Att: Impersonate SMAA TokenLinkedToken at Identification level
Att->>Kern: Reference \Sessions\0\DosDevices\<SMAA_LUID>
Kern->>Kern: Lazy-create directory
Note over Kern: Owner SID inherited from impersonating token
Att->>Kern: Create C: symlink under attacker control
SMAA->>Kern: Resolve C: at first DLL load
Kern-->>SMAA: Returns attacker symlink target
SMAA->>SMAA: Load attacker DLL at High integrity

What makes this bypass extraordinary is that it is caused by the feature's design. Pre-Administrator-Protection, the user's primary logon session was created at desktop logon and the DOS device directory existed before any elevation. Lazy directory creation never came up. The SMAA design's "fresh logon session per elevation" property -- the same property Forshaw's January 2026 pull-quote in §7 establishes via the credential-less LSA logon -- is exactly the precondition the lazy-creation path exploits.

Microsoft's pre-GA fix has two parts. First, the manifest-parsing access check uses the SYSTEM-impersonating-the-low-user identity rather than the user's primary token. Second, the DOS device directory is materialised with the correct owner before any user-controlled code path can trigger the lazy-creation path [@forshaw-pz-jan2026]. The Register's coverage of the disclosure noted "the most notable of the nine bugs he reported was a Logon Sessions flaw that relied upon five different Windows behaviors. He added that he likely only found it because he was previously familiar with the OS's 'weird behavior when creating the DOS device object directory'" [@theregister-2026].

The five UI Access bypasses

Forshaw's February 2026 post details the second class, comprising five of the nine bypasses [@forshaw-pz-feb2026]. UI Access is a token flag retrofitted in Vista to let accessibility applications cross UIPI. To qualify, an executable needs three things: a manifest declaring uiAccess="true", a trusted code-signing certificate, and an installation location under an administrator-only directory (typically %ProgramFiles%). The Application Information service's RAiLaunchAdminProcess endpoint launches qualifying UI Access processes without showing the consent prompt, on the theory that the three-criteria check is itself sufficient evidence of administrator approval [@forshaw-pz-feb2026].

The token flag (`TOKEN_UIACCESS`) that allows a process to interact with windows of higher integrity level than its own, bypassing User Interface Privilege Isolation. UI Access is meant for accessibility software (screen readers, on-screen keyboards) that needs to interact with elevated UI. To qualify, an executable must carry a `uiAccess="true"` manifest, a trusted code-signing certificate, and an administrator-only installation directory; qualifying processes run without showing the consent prompt and at integrity level High [@forshaw-pz-feb2026].

Under classic UAC, a UI Access process ran with the filtered standard-user token bumped from Medium to High integrity -- not with the full admin token. Forshaw's February 2026 post states the mechanism verbatim: "the service will take a copy of the caller's access token, enable the UI Access flag and increase the integrity level... If the caller is a limited user of an UAC administrator it will set the integrity level to High" [@forshaw-pz-feb2026].

Under Administrator Protection, the pre-GA design preserved that behaviour unchanged: the UI Access process inherited the limited user's primary token (not the SMAA's), bumped to High integrity. That decision was the structural flaw. A High-integrity process under the limited user can interact with the SMAA's windows whenever a High-integrity SMAA process exists on the same desktop, send messages to them, read clipboard data, and -- through GetProcessHandleFromHwnd -- obtain a process handle on the SMAA process that lets the limited-user process inject code into it.

The five UI Access variants exploit different sub-categories of the same structural property. The Quick Assist binary, a remote assistance application on Windows 10 and 11 that carries the uiAccess flag, is one such variant; R41N3RZUF477 published a public proof-of-concept that exploits the BrowserExecutableFolder group policy to make Quick Assist load WebView2 from an attacker-controlled directory [@quickassist-bypass]. The remaining four exploit, respectively, weaknesses in the secure-application-directory check, the manifest parsing routine, COM marshalling in UI Access contexts, and message-only window handling [@forshaw-pz-feb2026].

Microsoft's pre-GA fix is structural: UI Access processes no longer run as the limited user. They are created with a filtered copy of the SMAA's token (the SMAA's SID, the SMAA's profile, but with SeLoadDriverPrivilege and similar removed). Profile separation is restored at the cost of a more complex token-creation path [@forshaw-pz-feb2026].

The remaining three: implementation flaws

The third class -- three bypasses described by Forshaw only as "implementation flaws and long-standing UAC issues" -- is not detailed publicly [@forshaw-pz-jan2026]. The article does not invent details. Forshaw names the category and cites the framing; the engineering specifics are presumably in Microsoft Security Response Center advisories or are still under disclosure. What can be said is that two of the three appear from Forshaw's framing to be UAC-era bugs that Administrator Protection inherited rather than introduced, and one is an Administrator-Protection-specific implementation flaw.

The bypass canon ran for twenty years without bulletins. The fact that all nine pre-GA Administrator Protection bypasses received fixes -- including a deep one rooted in the feature itself -- is the structural confirmation that the elevation path is now a boundary. The next section asks why Microsoft pulled the feature in December 2025.

13. The compatibility surface and the December 2025 revert

About one month after KB5067036 made Administrator Protection available, Microsoft pulled it. Forshaw, writing in January 2026, gives the canonical attribution: "As of 1st December 2025 the Administrator Protection feature has been disabled by Microsoft while an application compatibility issue is dealt with. The issue is unlikely to be related to anything described in this blog post so the analysis doesn't change" [@forshaw-pz-jan2026]. Microsoft Learn confirms: "The feature previously listed in the October 2025 non-security update (KB5067036) has been reverted and will roll out at a later date" [@ms-admin-protection, @ms-kb5067036].The November 2025 KB5067036 amendment is worth knowing. Microsoft included an unrelated fix for an AutoCAD MSI-repair UAC-prompt regression in the same cumulative; that fix shipped and was not reverted. The WebView2 installer regression is what caused the Administrator Protection revert specifically [@ms-kb5067036].

The structural causes. The Windows Developer Blog (May 2025) [@ms-developer-blog-2025] enumerates the surface where applications break under the SMAA model.

Single sign-on does not cross. Domain and Microsoft Entra credentials cached for the primary user's session are not available inside the SMAA's session. Any elevated process touching Microsoft Graph, Entra ID, or Kerberos-protected resources must re-authenticate. The login dialogs an elevated installer triggers are not failures of the application; they are consequences of the separated logon session.
Network drives do not carry. Drive-mapping in the primary user's session is not inherited by the SMAA. Installers that mount network shares to install per-machine components break. The workaround for affected installers is to use UNC paths directly rather than drive letters.
Library folders diverge. Files saved to Documents, Desktop, Downloads, or Pictures from an elevated app land in C:\Users\ADMIN_<random>\ rather than the primary user's home. A user clicks Save in an elevated text editor and saves to "Documents"; from their own Explorer, the file is invisible.
HKCU diverges. Application settings -- theme, recent-files lists, per-user COM registrations, last-opened paths -- live in the SMAA's HKCU, not the primary user's. The canonical example in Microsoft's documentation is Notepad's dark-mode theme [@ms-developer-blog-2025]: the primary user sets the theme; an elevated Notepad opens in the default theme; the two sessions never agree.
WebView2 installers fail. The error message "Microsoft Edge can't read and write to its data directory" is the recognisable symptom of an installer that assumes one shared profile. The WebView2 runtime stores per-user state in AppData\Local\Microsoft\EdgeWebView\ under whichever profile is active at install time; if the runtime is installed under the SMAA's profile and then used by an unelevated application running as the primary user, the data-directory write fails. This is the regression that triggered the December 2025 revert.
Hyper-V and WSL incompatibilities. Microsoft Learn explicitly tells IT administrators not to enable Administrator Protection on devices that require Hyper-V or WSL [@ms-admin-protection].
Visual Studio. Microsoft's own development environment is "not supported in such a configuration" when run elevated. Extensions don't carry; settings don't carry; project-dialog paths point at the SMAA's profile rather than the developer's actual workspace.

Note: Microsoft Learn explicitly excludes Hyper-V and WSL devices from the recommended enablement set [@ms-admin-protection]. Symptoms of incorrect enablement include WSL distribution startup failures (the WSL service runs under a different account from the launching user, and the SMAA's logon-session-isolation properties interact badly with WSL's named-pipe communication) and Hyper-V Manager connection errors that are difficult to attribute to the elevation model.

I guess app compatibility is ultimately the problem here, Windows isn't designed for such a radical change. I'd have also liked to have seen this as a separate configurable mode rather than replacing admin-approval completely. -- James Forshaw, *Bypassing Windows Administrator Protection*, Google Project Zero, January 26, 2026 [@forshaw-pz-jan2026] Administrator Protection is the right architecture, and the compatibility surface is the bill of materials for twenty years of admin-as-default assumption. Application developers have written installer logic, theme-persistence code, drive-letter assumptions, and HKCU-shared state into shipping software for two decades, on the structural premise that the elevated process and the unelevated user share a profile. The December 2025 revert is the first iteration's learning round, not a structural failure. The same revert pattern accompanied the Windows Vista UAC rollout in 2006-2007, the Windows 7 auto-elevation introduction in 2009 (which itself softened the Vista prompt fatigue at the cost of the bypass canon), and the Smart App Control rollout in Windows 11 22H2. Microsoft will re-enable Administrator Protection when the WebView2 regression and a handful of installer-pattern fixes have shipped.

The architecture survives audit. The deployment is held back by twenty years of accumulated software assumptions. The next section asks what tools defenders now have that they did not have before.

14. The audit and detection surface

Every privileged operation on a device with Administrator Protection enabled now generates an ETW (Event Tracing for Windows) event in the Microsoft-Windows-LUA provider [@ms-admin-protection]. This is the first time the elevation pipeline itself is the source of a stable, operationally useful audit trail.

The basics.

Provider: Microsoft-Windows-LUA, GUID {93c05d69-51a3-485e-877f-1806a8731346}.
Event ID 15031: Elevation Approved.
Event ID 15032: Elevation Denied or Failed.

Each event carries the caller user SID, the application name and path, the elevation outcome, the SMAA used to host the elevation, and the authentication method (Hello PIN, biometric, password) [@ms-admin-protection]. The authentication method field records the primary user's Hello credential, not the SMAA's; the SMAA's authentication in step 6 of §7 is the credential-less LSA logon and has no method field of its own. The Microsoft Learn-documented logman invocation to capture the trace is short:

The Event Tracing for Windows provider that surfaces Administrator Protection elevation events. Provider GUID `{93c05d69-51a3-485e-877f-1806a8731346}`. Event ID 15031 marks an elevation that succeeded; Event ID 15032 marks an elevation that was denied or failed. Each event carries fields for the caller's SID, the application path, the elevation outcome, the SMAA used, and the authentication method [@ms-admin-protection].

{` // Pseudocode for a detection pipeline that reads ETW Event 15031 // (Administrator Protection elevation approved) and flags unusual // application paths per SMAA correlation key.

const allowList = new Set([ 'C:\\Windows\\System32\\mmc.exe', 'C:\\Windows\\System32\\regedit.exe', 'C:\\Windows\\System32\\cmd.exe', 'C:\\Program Files\\Microsoft VS Code\\Code.exe', ]);

function onEtwEvent(event) { if (event.provider !== 'Microsoft-Windows-LUA') return; if (event.id !== 15031) return;

const smaa = event.fields.shadowAccountName; const app = event.fields.applicationPath; const auth = event.fields.authenticationMethod; const user = event.fields.callerUserSid;

if (!allowList.has(app)) { emit({ severity: 'high', title: 'Unexpected elevation under Administrator Protection', smaa, app, auth, user, hint: 'Was the Hello prompt phished?' }); } } `}

Note: For detection engineers, the ADMIN_<random> name is the highest-value correlation key on the device. It is stable per primary admin (the SMAA name is created once and persists across elevations), distinct from the limited-user SID (the SMAA has its own SID, so user-by-SID correlations and SMAA-by-name correlations are independent axes), and present in every ETW 15031 / 15032 event. A detection rule that groups elevations by SMAA name and flags unexpected application paths is the canonical "someone phished a Hello prompt" alert pattern.

Defenders now have the audit trail they did not have under UAC. The next section asks what residual attack surface survives the SMAA architecture, the Hello gate, and the new audit trail.

15. Open problems: what survives

Five residual attack surfaces, each acknowledged in Microsoft's own documentation, Forshaw's Project Zero posts, or the operational literature on Windows privilege escalation.

The user is still the weak link. Every elevation depends on a human accepting the prompt. The Hello credential gate makes that human's decision more costly to fake than the classic Yes/No, but the gate does not change the fact that a successful prompt is a successful elevation. The three sub-cases of consent-without-identity-verification from §9 -- unattended-session, habituated-click, pretext click-through -- are cost-raised, not closed. Phishing-the-prompt remains a live attack surface and Microsoft does not classify it as a vulnerability [@forshaw-pz-jan2026]. Out-of-band consent -- a phone-push approval channel, a smartcard tap, a separate hardware key tap -- would close the gap; none of these is the Administrator Protection default.

Loopback authentication. The structural property that Windows services authenticate to themselves over the local network stack is independent of the SMAA model. SMB to localhost, Kerberos against the local machine account, NTLM challenge-response between processes on the same box -- these protocols predate UAC and are not changed by Administrator Protection. Forshaw's broader 2022 Kerberos research [@forshaw-2022-rbcd] catalogues the class. The NTLMless article in this series covers SMB signing, Extended Protection for Authentication (EPA), and channel binding mitigations that defenders should pair with Administrator Protection to close the loopback path.

Service-account SeImpersonatePrivilege. The Potato lineage of attacks (cataloged in the Access Control article in this series) runs in service accounts (IIS_IUSRS, LOCAL SERVICE, NETWORK SERVICE), not in interactive admin sessions. Administrator Protection scopes itself to interactive admin elevation; the Potato class is structurally out of scope.

Service-account Potato attacks run inside `IIS_IUSRS`, `LOCAL SERVICE`, and `NETWORK SERVICE` rather than in interactive admin sessions. The attacker has compromised a service that holds `SeImpersonatePrivilege`, then uses one of several primitives (the SSPI / NEGOEX dance, the EFS RPC interface, a printer-spooler endpoint) to coerce a higher-privileged service into authenticating against the attacker's local socket, and impersonates the resulting token. Administrator Protection's promise is around the *interactive elevation* path -- the flow from a logged-in user clicking an installer to an elevated process running. Potato is a separate problem class with its own mitigations: removing `SeImpersonatePrivilege` from service accounts that don't need it, applying EPA, and patching the named primitives one by one.

Driver loading once inside an SMAA elevation. Admin equals kernel applies once a process is running inside the SMAA. Vulnerable-driver loading, kernel-mode code execution, and rootkit installation fall under the §11 "admin equals kernel" ceiling -- WHQL signing, the Vulnerable Driver Blocklist, App Control for Business, and HVCI remain the four-mechanism mitigation surface, with the App Identity article in this series covering the App Control mechanism. Administrator Protection does not change the relationship between admin and kernel; it changes the relationship between standard user and admin.

The Hello credential phishing surface. The prompt now phishes a real credential rather than a click-through approval. A malicious application that successfully argues its case to the user gets a Hello gesture against the primary user's PIN or biometric. The credential remains hardware-rooted; ESS-engaged biometrics never leave the TPM or Pluton enclave; the malware does not learn the PIN. But the malware does get the elevation. The Windows Hello article in this series covers FIDO2 / ESS / PIN architecture hardening. Defender-side mitigation is the ETW 15031 / 15032 detection rule set on unexpected application paths [@ms-admin-protection].

The boundary is real, the audit trail is new, and the five-class residual surface is the next decade of work. The next section turns to operator-side practicalities.

16. Practical guide

Six tips, each tied to one Microsoft Learn or Windows Developer Blog primary source. Remember that, as of December 2025, Microsoft has reverted the rollout and the feature is currently disabled on stable Windows; the guidance below applies once Microsoft re-enables it. The Spoiler below contains the verbatim commands.

Enable. Set TypeOfAdminApprovalMode = 2 via Group Policy ("User Account Control: Configure type of Admin Approval Mode" -> "Admin Approval Mode with Administrator Protection") or via the Intune Settings Catalog OMA-URI. A reboot is required for the new policy to take effect [@ms-admin-protection, @ms-kb5067036].
Verify. Run whoami in an elevated console. The profile name shows ADMIN_<random>. Run whoami /priv to confirm the SMAA has the Administrators group enabled [@ms-admin-protection, @call4cloud-osint].
Capture. Start the ETW trace with the documented logman invocation; filter for Event IDs 15031 and 15032 [@ms-admin-protection]. The provider GUID is stable across builds.
Do not enable on devices that require Hyper-V or WSL. Re-evaluate when Microsoft re-enables the broad rollout [@ms-admin-protection, @forshaw-pz-jan2026].
For application developers, follow the Windows Developer Blog (May 19, 2025) guidance [@ms-developer-blog-2025]: install per-user packages unelevated; use %ProgramFiles% (and accept the elevated install path); avoid context switching during install; avoid sharing files between elevated and unelevated profiles; remove auto-elevation dependencies. The auto-elevation manifest attribute is no longer honoured under Administrator Protection, so any installer that relied on silent elevation needs to be reworked.
For IT admins on already-enabled devices broken by an elevated install: disable Administrator Protection temporarily, reinstall the application unelevated, then re-enable [@ms-developer-blog-2025].

Enable via Group Policy registry value (administrator console, persists across reboots):

# Set TypeOfAdminApprovalMode to 2 (Admin Approval Mode with Administrator Protection)
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v TypeOfAdminApprovalMode /t REG_DWORD /d 2 /f
# Reboot required:
shutdown /r /t 0

Capture the elevation event trace:

logman start AdminProtectionTrace -p {93c05d69-51a3-485e-877f-1806a8731346} -ets
:: After some elevations:
logman stop AdminProtectionTrace -ets
:: Process the .etl with PerfView, Message Analyzer, or:
wevtutil qe Microsoft-Windows-LUA/Operational /q:"*[System[(EventID=15031 or EventID=15032)]]" /f:text

Verify the SMAA presence after enablement:

Get-LocalUser | Where-Object Name -like 'ADMIN_*'
# After an elevation, run from the elevated console:
whoami
# Expect: WIN11-PC\ADMIN_<random16hex>

Note: The single most common mistake in response to an Administrator Protection compatibility problem is to disable UAC globally by setting EnableLUA = 0. This returns the device to the Windows XP single-token model, removes Mandatory Integrity Control enforcement on application processes, and effectively defeats every layer of UAC and Administrator Protection together. It is universally discouraged. The correct fix is per-application, via manifest, or per-device, via the documented Administrator Protection compatibility list.

Six tips, one boundary, one operational checklist. The next section answers the most common misconceptions.

17. Frequently asked questions

No. Administrator Protection runs in `appinfo.dll` inside the Application Information service, which runs in `svchost.exe` in VTL0 (the normal Windows kernel context). The SMAA itself is a normal SAM-database account, not a Virtual Secure Mode trustlet. The cross-process protections of Virtualization-Based Security apply to LSASS Credential Guard and a handful of other VTL1 services; the elevation pipeline is not one of them. The Secure Kernel article in this series treats VTL0 / VTL1 separation in detail. Partially. Administrator Protection replaces Admin Approval Mode UAC when `TypeOfAdminApprovalMode = 2`. The credential-prompt path (the over-the-shoulder elevation that asks a standard user to enter an administrator's credentials) and classic Admin Approval Mode (`TypeOfAdminApprovalMode = 1`) coexist with Administrator Protection across different configurations [@ms-admin-protection]. On a device with Administrator Protection enabled, only the interactive admin's elevation path goes through the SMAA; the standard-user-asking-for-admin-credentials path is unchanged. No. There is absolutely an admin token; it lives in a different account, in a different logon session, for a bounded lifetime. The marketing language describes lifetime and isolation, not nonexistence [@ms-developer-blog-2025, @bleepingcomputer-2024]. The SMAA's token persists for the lifetime of the elevated process; when the process exits, the token handle is released and the logon session is reaped. Between elevations, no SMAA token exists in memory. No. Malware can still elevate if the user accepts the Hello prompt. The boundary Administrator Protection creates is between *silent* elevation and *consented* elevation, not between any elevation and none. Microsoft's design position is explicit: "I expect that malware will still be able to get administrator privileges even if that's just by forcing a user to accept the elevation prompt" [@forshaw-pz-jan2026]. The three sub-cases of consent-without-identity-verification from §9 are cost-raised, not eliminated. What changes is that the elevation must be visible. Defenders gain the ETW 15031 audit trail as a result. No. EPM uses a virtual elevated account on a per-request basis with cloud-side policy, and the virtual account is *not* a member of the local Administrators group [@ms-epm-overview]. Administrator Protection uses a persistent local SMAA per admin user, with on-box `appinfo.dll` policy, and the SMAA *is* a member of the local Administrators group [@call4cloud-osint]. EPM is centrally policy-driven and works on standard-user devices; Administrator Protection is per-device architecture and applies only to interactive admin users. The two can coexist on the same device. No. Per Microsoft Learn, remote logon, roaming profiles, and backup admins are out of scope [@ms-admin-protection]. A domain administrator who logs into a workstation interactively will not see the SMAA path. Microsoft has stated that domain scenarios may be added in future iterations; the current GA-target form is local-machine-only, interactive-admin-only. No. Mimikatz inside the elevated SMAA session still has `SeDebugPrivilege` and can call `OpenProcess` on `lsass.exe` to dump LSASS unless LSA Protection (Run As Protected Process Light) and Credential Guard are also enabled. Administrator Protection protects the *elevation path*; it does not protect the *resulting privileged session*. To protect the privileged session, pair Administrator Protection with LSA Protection (`RunAsPPL=1`), Credential Guard, App Control for Business, and HVCI. The Secure Kernel article in this series covers the LSA Protection mechanism.

The misconceptions are cleared. The next section returns to the opening hook with the new vocabulary the article has built.

18. The user-elevation companion to Credential Guard

Return to the two whoami /all outputs from §1, this time with the vocabulary the article has built.

The first output shows the primary user under classic UAC. One SID, one profile, one HKCU, one logon-session LUID; the elevated console is the same user as the unelevated console, distinguished only by the integrity level on the token.

The second output shows the same login under Administrator Protection. A different user name -- ADMIN_<random> -- with a different SID linked to the primary admin via ShadowAccountForwardLinkSid and ShadowAccountBackLinkSid. A different profile under C:\Users\ADMIN_<random>\. A different NTUSER.DAT mapped as HKCU. A fresh authentication-ID LUID minted by LSASS through the credential-less logon path described in §7, on the strength of appinfo.dll's trusted request and a Hello gesture the primary user just performed. An ETW Event 15031 in the Microsoft-Windows-LUA provider, freshly emitted, recording the elevation as approved, the application path, and the authentication method.

The thesis lands. The elevation path is now itself a security boundary, with bulletin-grade fixes when it fails. Administrator Protection is the user-elevation companion to Credential Guard. Where Credential Guard isolated LSA secrets from admin-equals-kernel inside the machine -- the Secure Kernel article in this series covers the VBS-rooted isolation in detail -- Administrator Protection isolates the elevation path from the standard-user session. The two answer the two halves of the question the foundational Access Control article in this series left open: if admin equals kernel and tokens are bearer credentials, what is left to harden? The answer is the path that gets you there (Administrator Protection) and the data that is there once you arrive (Credential Guard).

The December 2025 revert is the first iteration's learning round. The architecture is the right one. The application base catches up next. Forshaw's framing in February 2026 -- that Microsoft might have shipped this as a configurable mode rather than replacing admin approval completely -- is a reasonable critique, and the re-enablement is likely to address it. Until then, the operational reality on most stable Windows devices is the classic split-token model, with all the bypass canon it implies, and the SMAA design remains an Insider-Preview-and-policy-opted-in posture.

What stays unchanged is the structural insight. The mechanism Microsoft used to make the elevation path a boundary is not novel; multi-user accounts have shipped in Windows NT since 1993. What changed is the classification. Microsoft accepted, after twenty years of evidence, that the elevation pipeline needed to be a security boundary, and accepted with it the engineering cost: separate accounts, separate profiles, separate logon sessions, removal of auto-elevation, a credential gate instead of a click-through, an audit-trail ETW provider, and a willingness to ship bulletin-grade fixes for every Forshaw finding. The classification was the engineering decision. Everything else followed.

This is what it took, in mechanism and in time, to make the elevation path real [@forshaw-pz-jan2026].