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

1. A UAC Bypass Walks Into MSRC#

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

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

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

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

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

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

2. The Pre-Doctrine Era#

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

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

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

Three failures accumulated pressure during the implicit-boundary era.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. The Document Accumulates#

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

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

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

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

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

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

timeline
title Five generations of the boundary doctrine
section Generation 1 - Scattered prose (2007 to 2010)
2007 : Russinovich publishes the convenience-vs-boundary distinction
2009 : Long Zheng and Rafael Rivera force UAC implementation hardening
2009 : Russinovich Windows 7 follow-up restates the doctrine
section Generation 2 - Enumerated page (2010 to 2015)
2010 : MSRC servicing-criteria page goes live with two-question rule
2014 : hfiref0x publishes UACMe v1.0
2014 : CVE-2014-4113 Win32k EoP becomes canonical kernel-boundary case
section Generation 3 - VTL added (2015 to 2017)
2015 : Windows 10 1507 ships VBS, Secure Kernel, Credential Guard
2016 : Edge AppContainer sandbox cements the browser boundary entry
2017 : EternalBlue and MS17-010 anchor the network-boundary case study
section Generation 4 - Stabilised reference (2018 to 2024)
2023 : Landau PPLFault names PPL as not a security boundary
2024 : Landau ItsNotASecurityBoundary homages MSRC policy in repo name
2024 : Leviev Windows Downdate at Black Hat USA 2024
section Generation 5 - Administrator Protection (2024 to 2026)
2024 : Ignite keynote announces Administrator Protection as new boundary
2025 : Developer-blog detail post lands
2025 : October non-security update KB5067036 rolls out and is reverted
2026 : Forshaw publishes nine pre-GA bypasses via Project Zero

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

5. The Not-a-Boundary Table Also Accumulates#

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

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

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

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

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

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

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

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

Here are the two tables side by side.

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

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

6. The Two-Question Triage Rule#

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

The MSRC servicing-criteria page states the rule verbatim:

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

1. Does the vulnerability violate the goal or intent of a security boundary or a security feature?
2. Does the severity of the vulnerability meet the bar for servicing?" ^[2]

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

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

The doctrine has an explicit relief valve.

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

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

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

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

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

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

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

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

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

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

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

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

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

7. The Nine Boundaries, Walked#

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

7.1 Network boundary#

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

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

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

7.2 Kernel boundary#

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

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

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

7.3 Process boundary#

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

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

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

7.4 Session boundary#

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

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

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

7.5 User boundary#

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

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

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

7.6 AppContainer / sandbox boundary#

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

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

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

7.7 Virtual machine (guest-to-host) boundary#

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

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

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

7.8 VTL (VTL0 to VTL1) boundary#

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

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

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

7.9 Administrator Protection elevation path (2025 addition)#

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

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

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

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

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

8. What Is Not a Boundary#

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

8.1 UAC#

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

8.2 Driver Signing / Code Integrity / KMCS#

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

8.3 Microsoft Defender / Antimalware#

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

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

8.4 HVCI / Memory Integrity#

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

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

8.5 Protected Process Light (PPL)#

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

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

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

8.6 Administrator-to-kernel privilege escalation#

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

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

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

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

8.7 Same-user post-authentication#

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

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

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

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

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

9. The Bounty Schedule Mirrors the Boundary List#

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

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

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

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

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

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

10. What the Doctrine Cannot Decide#

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

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

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

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

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

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

11. How Other Vendors Classify the Same Primitives#

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

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

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

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

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

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

12. The 2026 Frontier#

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

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

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

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

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

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

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

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

13. How to File a Useful MSRC Report#

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

1. Read the servicing-criteria document first ^[2]. Map your finding to a boundary entry. If it does not map, expect a feature-defeat reply. If it maps cleanly, you know in advance that the disposition path goes through Question 2.

2. Lead the MSRC submission with the boundary claim in the first sentence. "This issue violates the [process | kernel | session | network | user | AppContainer | VM | VTL | Administrator Protection] boundary because <reason>." The triage engineer reading your report should never have to infer which boundary you are claiming. Name it.

3. Include the severity-meets-bar argument in the second paragraph. Critical / Important / Moderate / Low per the Bug Bar ^[27]. Cite the specific bug-type cell (RCE, EoP, info disclosure, DoS, spoofing, tampering) and the pivot (server vs client; default-on vs default-off; user interaction required vs not). Worked examples beat assertions.

4. If the finding crosses a feature and a boundary, lead with the boundary. The feature defeat is supporting evidence, not the primary claim. A Defender bypass that also crosses the network boundary is a network-boundary report with a Defender defeat as supporting detail, not the other way around.

5. Expect the reply to be operationally predictable. If the finding is on the feature side and severity is not Critical, the reply will be "by design / consider for next version." Plan publication accordingly. A 90-day Project Zero clock that lines up with a probable "by design" reply is not a failed disclosure -- it is a successful one, because the reply was predicted in advance ^[54].

6. For bounty-eligible classes, read the program-scope page carefully. Hyper-V ($5K - $250K) ^[40], Windows Insider Preview ($500 - $100K) ^[45], Edge ($250 - $30K) ^[38], plus the Identity / Cloud / M365 / Azure programs ^[41]. The boundary-payout mapping is dominantly tight; the program-scope page tells you whether the bounty fires.

7. If the reply surprises you, the "exceptions may be made" clause is the framing ^[2]. A feature defeat that does receive a bulletin does not contradict the doctrine; it invokes the exception. A boundary crossing that does not receive a bulletin invokes the exception in the other direction (severity below bar). Either way, the doctrine is not broken; the exception clause is doing its job.

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

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

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

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

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

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

14. Frequently Asked Questions and Closing#

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

Closing#

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

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

The boundary list. From memory. Now.