# Adminless: How Windows Finally Made Elevation a Security Boundary
> Administrator Protection replaces UAC with a system-managed admin account created per elevation, gated by Windows Hello, and destroyed when the job is done.
*Published: 2026-05-10*
*Canonical: https://paragmali.com/blog/adminless-how-windows-finally-made-elevation-a-security-boun*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
**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_` -- 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, @russinovich-2007-archive] 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.
1. **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.
2. **The same `%USERPROFILE%` directory tree.** `C:\Users\\` is the home of both. The Documents folder, the Downloads folder, the AppData hives, and any application-specific subdirectory belong to one user.
3. **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.
4. **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\`, 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 crash-path in the consent.exe certificate-viewer UI -- 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]:
1. The `autoElevate=true` manifest attribute, embedded in selected Microsoft-signed Windows binaries.
2. An internal whitelist of Microsoft-signed binaries living under `%SystemRoot%\System32`.
3. The **COM Elevation Moniker** -- already shipping in Vista (`BIND_OPTS3`, syntax `Elevation:Administrator!new:`) -- 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].
4. 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).** Removed `IFileOperation` auto-elevation for callers other than Explorer [@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 crash-path in `consent.exe`'s certificate-viewer UI: 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 [@zdi-19-975, @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 grew from 53 methods in 2018 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, @mddr-2024-pdf]. 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-experience-blog-ignite, @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_` 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_\` -- 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, @ms-experience-blog-ignite]
> **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.
1. 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:` COM moniker requests.
2. `appinfo.dll`'s `RAiLaunchAdminProcess` RPC endpoint, hosted inside the Application Information service in `svchost.exe`, receives the call [@ms-uac-how-it-works].
3. `appinfo` reads `HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\TypeOfAdminApprovalMode`.
4. 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].
5. `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].
6. 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].
7. `appinfo` calls `CreateProcessAsUser` with the SMAA token, the user's requested executable, and the SMAA's profile environment block (`USERPROFILE=C:\Users\ADMIN_`, `USERNAME=ADMIN_`, the SMAA's `NTUSER.DAT` mapped as `HKCU`).
8. 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\` does not yet exist; the kernel will create it on first reference.
9. 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_\` | 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_\`. 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\` 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.
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" [@ms-experience-blog-ignite, @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 crash-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](https://paragmali.com/blog/the-tpm-in-windows-one-primitive-twenty-five-years-and-the-c/) or [Pluton](https://paragmali.com/blog/pluton-a-tpm-on-silicon-microsoft-can-patch/) 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](https://paragmali.com/blog/your-face-is-not-your-password-inside-windows-hellos-hardwar/) 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, @ms-sudo-intro-blog, @github-microsoft-sudo]. 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, @ms-epm-policies]. 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](https://paragmali.com/blog/who-is-this-code----the-quiet-33-year-reinvention-of-app-ide/) 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\` 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\` 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\\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\
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, an inbox accessibility tool on Windows 10 and 11, 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, @pz-issue-437291456, @pz-issue-437868751].
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.
1. **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.
2. **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.
3. **Library folders diverge.** Files saved to `Documents`, `Desktop`, `Downloads`, or `Pictures` from an elevated app land in `C:\Users\ADMIN_\` 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.
4. **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.
5. **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.
6. **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].
7. **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]
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_` 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](https://paragmali.com/blog/ntlmless-the-death-of-ntlm-in-windows/) 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](https://paragmali.com/blog/can-this-code-do-this----twenty-five-years-of-attacks-on-the/) 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.
**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.
1. **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].
2. **Verify.** Run `whoami` in an elevated console. The profile name shows `ADMIN_`. Run `whoami /priv` to confirm the SMAA has the Administrators group enabled [@ms-admin-protection, @call4cloud-osint].
3. **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.
4. **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].
5. **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.
6. **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):
```powershell
# 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:
```cmd
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:
```powershell
Get-LocalUser | Where-Object Name -like 'ADMIN_*'
# After an elevation, run from the elevated console:
whoami
# Expect: WIN11-PC\ADMIN_
```
> **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_` -- with a different SID linked to the primary admin via `ShadowAccountForwardLinkSid` and `ShadowAccountBackLinkSid`. A different profile under `C:\Users\ADMIN_\`. 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](https://paragmali.com/blog/when-system-isnt-enough-the-windows-secure-kernel-and-the-en/) 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].