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

> Microsoft maintains a single public document that decides which Windows vulnerability reports receive a CVE, a Patch Tuesday bulletin, and a bounty payout. Here is how to read it.

*Published: 2026-05-24*
*Canonical: https://paragmali.com/blog/windows-security-boundaries-the-document-that-decides-what-g*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*

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

## 1. A UAC Bypass Walks Into MSRC

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

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

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

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

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

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

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

## 2. The Pre-Doctrine Era

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

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

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

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

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).<Sidenote>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.</Sidenote> A tier presented operationally as a boundary that turned out never to have been one.

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

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

<Mermaid caption="The pre-doctrine timeline: architectural primitives existed, but the disposition rules that named them did not.">
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
</Mermaid>

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

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

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

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

<PullQuote>
"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
</PullQuote>

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

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

<Mermaid caption="The Vista UAC split-token model. The two tokens share too many resources to be a guaranteed separation.">
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]
</Mermaid>

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.

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

The historical record matters because so much downstream doctrine rests on it. In late January 2009, Long Zheng and Rafael Rivera demonstrated a Windows 7 beta UAC auto-elevation flaw via `rundll32.exe`: Microsoft-signed binaries inside `%SystemRoot%` auto-elevated when invoked from a process holding the user's administrator token, and `rundll32.exe` accepted arbitrary DLL paths [@crn-uac-flaw-2009].<Sidenote>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.</Sidenote> Microsoft's *initial* reply ("by design; UAC is not a security boundary") was operationally consistent with the June 2007 article. The *engineering* response that followed -- UAC slider promoted to High integrity, UAC-settings changes prompting -- was implementation hardening, not reclassification. The doctrinal position did not move. Russinovich's July 2009 follow-up, *Inside Windows 7 User Account Control*, restated the convenience-vs-boundary argument with the same architectural reasoning [@ms-learn-russinovich-win7].

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

## 4. The Document Accumulates

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

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

**Generation 2 -- the enumerated MSRC page (roughly 2010 to 2015).** The `microsoft.com/en-us/msrc/windows-security-servicing-criteria` page appears in something close to its current form. It states the two-question triage rule. It includes the verbatim definition of a security boundary. It enumerates a list of boundaries -- process, kernel, network, session, user, AppContainer, virtual machine, web browser -- and a parallel list of security features. The doctrine moves from a single magazine article to a vendor commitment with a URL [@msrc-criteria].<Sidenote>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.</Sidenote>

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

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

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

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

<Definition term="System Managed Administrator Account (SMAA)">
The *System Managed Administrator Account* is the elevation primitive at the heart of Administrator Protection [@ms-learn-admin-protection]. Each interactive user with administrator privileges has a hidden, system-generated, profile-separated SMAA companion account provisioned in the SAM database. Elevations route through Windows Hello consent and run against the SMAA token, which has a *different* SID, a *different* profile directory, and a *different* logon session from the user's standard-user token. The token is destroyed when the elevated process ends. The shared-resources structural reason UAC could not be a boundary no longer applies, because the SMAA token does not share those resources with the user's standard token.
</Definition>

<Mermaid caption="Five generations of the servicing-criteria doctrine, with the canonical inflection events along the way.">
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
</Mermaid>

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

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](https://www.loldrivers.io/) are the institutional memory [@loldrivers].

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

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

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

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

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

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

Here are the two tables side by side.

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

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

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

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

## 6. The Two-Question Triage Rule

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

The MSRC servicing-criteria page states the rule verbatim:

> "The criteria used by Microsoft when evaluating whether to provide a security update or guidance for a reported vulnerability involves answering two key questions:
>
> 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?" [@msrc-criteria]

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

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

The doctrine has an explicit relief valve.

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

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.

<Mermaid caption="The two-question MSRC triage decision tree. Both questions must be yes, with the exceptions clause as the relief valve.">
flowchart TD
    Report["Vulnerability report arrives at MSRC"]
    Q1&#123;"Q1: Does it violate a boundary or feature?"&#125;
    Q2&#123;"Q2: Does severity meet the bar (Critical or Important)?"&#125;
    Excp&#123;"Exception applies?"&#125;
    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
</Mermaid>

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

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

<RunnableCode lang="js" title="The MSRC triage rule, executed against three real-shaped inputs">{`
// 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" }));
`}</RunnableCode>

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

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

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

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

## 7. The Nine Boundaries, Walked

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

### 7.1 Network boundary

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

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

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

### 7.2 Kernel boundary

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

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

**Case study.** CVE-2014-4113, the Win32k.sys `tagWND` elevation-of-privilege bug, exploited in the wild in October 2014.<MarginNote>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.</MarginNote> MS14-058 / KB3000061 was the Patch Tuesday fix on October 14, 2014 [@ms-bulletin-ms14-058]. The bug allowed a local user to run arbitrary code in kernel mode by crafting calls to the kernel-mode portion of the Win32 subsystem [@nvd-2014-4113]. Important severity; canonical kernel-boundary case; the kind of finding the doctrine was built to service cleanly.

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

### 7.3 Process boundary

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

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

**Case study.** Thread injection canon: `CreateRemoteThread`, `SetWindowsHookEx`, `NtMapViewOfSection`. Each violation routes through a documented OS primitive that Microsoft has hardened repeatedly. The hardening culminated in the [Protected Process Light](/blog/protected-process-light-when-the-administrator-isnt-enough/) (PPL) signer-hierarchy enforcement introduced in Windows 8.1, which lets specially-signed processes refuse code injection even from administrator processes [@ms-learn-am-ppl]. PPL itself is on the feature side of the doctrine -- *the* canonical example of how the process boundary and PPL interact is the AM-PPL extension that anti-malware vendors use to protect their services from administrator-level interference, which Landau's research has explored at length [@landau-pplfault].<Sidenote>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.</Sidenote>

### 7.4 Session boundary

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

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

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

### 7.5 User boundary

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

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

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

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

### 7.6 AppContainer / sandbox boundary

**Primitive.** A [LowBox token](/blog/appcontainer-and-lowbox-tokens-windowss-capability-sandbox/) 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.

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

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

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

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

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

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

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

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

### 7.8 VTL (VTL0 to VTL1) boundary

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

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

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

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

### 7.9 Administrator Protection elevation path (2025 addition)

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

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

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

<Mermaid caption="A spatial map of the nine boundaries inside a running Windows 11 system.">
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
</Mermaid>

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

## 8. What Is Not a Boundary

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

### 8.1 UAC

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

### 8.2 Driver Signing / Code Integrity / KMCS

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

### 8.3 Microsoft Defender / Antimalware

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

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

Tavis Ormandy's 2014 to 2017 Defender disclosures earned CVEs not because they bypassed Defender's detection but because they crossed *other* boundaries [@ms-advisory-4022344]. The bugs were memory-corruption primitives in the Defender parsing engine reachable from attacker-controlled inputs the engine fetched from email or web traffic. The flagship example is CVE-2017-0290, the *crazy bad* MsMpEng RCE Microsoft addressed with out-of-band Security Advisory 4022344 on May 8, 2017 [@ms-advisory-4022344]. The network boundary crossing is what earned the CVE.<Sidenote>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.</Sidenote>

### 8.4 HVCI / Memory Integrity

The doctrinally subtle one. [HVCI](/blog/wdac--hvci-code-integrity-at-every-layer-in-windows/) is the kernel-mode code integrity check that lives *inside* VTL1, running under the protection of the hypervisor. The VTL boundary is what protects HVCI from attacker tampering. HVCI itself is a *feature* enforced *at* the VTL boundary, not a boundary in its own right.

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

### 8.5 Protected Process Light (PPL)

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

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

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

### 8.6 Administrator-to-kernel privilege escalation

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

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

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

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

### 8.7 Same-user post-authentication

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

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

<Mermaid caption="The triage flow for a feature defeat vs. a boundary crossing. Both can ship as security updates, but the path through the doctrine is different.">
flowchart TD
    Report["Vulnerability report arrives"]
    Cls&#123;"Classify primitive"&#125;
    BdyQ2&#123;"Boundary path: severity Critical or Important?"&#125;
    FtrQ2&#123;"Feature path: severity Critical or Important?"&#125;
    Excp&#123;"Exception applies?"&#125;
    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
</Mermaid>

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

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

## 9. The Bounty Schedule Mirrors the Boundary List

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

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

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

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

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

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

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

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

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

## 10. What the Doctrine Cannot Decide

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

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

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

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

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

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

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

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

## 11. How Other Vendors Classify the Same Primitives

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

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

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

**Chromium's Rule of 2 plus Severity Guidelines.** A *design-time* pre-commitment, fundamentally different from Microsoft's post-hoc triage. The Rule of 2 states: *"When you write code to parse, evaluate, or otherwise handle untrustworthy inputs from the Internet ... Pick no more than 2 of: untrustworthy inputs; unsafe implementation language; and high privilege"* [@chromium-rule-of-2]. Code that violates the rule must be sandboxed before it ships. Site isolation (each origin in its own renderer process) is the operational boundary equivalent. The Severity Guidelines parameterise triage with a Critical (S0) / High / Medium / Low scheme [@chromium-severity-guidelines].<Sidenote>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.</Sidenote>

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

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

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

## 12. The 2026 Frontier

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

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

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

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

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

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

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

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

<Mermaid caption="The 2026 candidate-boundary frontier. Existing boundaries on the left; candidate boundaries on the right; structural ingredients in between.">
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
</Mermaid>

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** [@msrc-criteria]. Map your finding to a boundary entry. If it does not map, expect a feature-defeat reply. If it maps cleanly, you know in advance that the disposition path goes through Question 2.

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 [@msrc-bugbar]. Cite the specific bug-type cell (RCE, EoP, info disclosure, DoS, spoofing, tampering) and the pivot (server vs client; default-on vs default-off; user interaction required vs not). Worked examples beat assertions.

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 [@project-zero-9030].

6. **For bounty-eligible classes, read the program-scope page carefully.** Hyper-V (\$5K - \$250K) [@msrc-bounty-hyperv], Windows Insider Preview (\$500 - \$100K) [@msrc-bounty-wip], Edge (\$250 - \$30K) [@msrc-bounty-edge], plus the Identity / Cloud / M365 / Azure programs [@msrc-bounty-root]. The boundary-payout mapping is dominantly tight; the program-scope page tells you whether the bounty fires.

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

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

<Spoiler kind="solution" label="Worked example: an MSRC report template for a Hyper-V guest-to-host escape">

```
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.
```

</Spoiler>

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.

<FAQ title="Frequently asked questions">

<FAQItem question="Microsoft retracted UAC's boundary classification in 2009, right?">
No. UAC was never officially classified as a boundary. Mark Russinovich's June 2007 *Inside Windows Vista User Account Control* article stated verbatim that *"UAC elevations are conveniences and not security boundaries"* -- two years before the January 2009 Long Zheng and Rafael Rivera Windows 7 beta UAC auto-elevation disclosure [@russinovich-vista-uac-wayback]. What Microsoft changed in 2009 was the *implementation* (UAC slider promoted to High integrity; UAC-settings changes prompting), not the *classification*. Russinovich's July 2009 follow-up article restated the original position [@ms-learn-russinovich-win7].
</FAQItem>

<FAQItem question="If MSRC's reply is 'by design,' Microsoft does not care, right?">
No. "By design" means the doctrine explicitly chose not to service this primitive class as a boundary violation. Microsoft may still harden the feature in a future Windows release, ship out-of-band Canary build mitigations (as with PPLFault build 25941) [@landau-pplfault], or assign CVEs to specific exploitation chains that cross *other* boundaries (as with Windows Downdate's CVE-2024-21302) [@leviev-downdate-update]. The finding is interesting research. It simply does not receive a CVE under the published doctrine.
</FAQItem>

<FAQItem question="Admin-to-kernel will never be a boundary, right?">
Probably not, but the Administrator Protection elevation *path* is now a boundary [@ms-learn-admin-protection], and the Landau / Leviev disclosures keep pressure on the unmoved part of the classification. The structural impossibility argument (admin loads drivers; drivers run in kernel) makes a doctrinal reclassification unlikely without a deeper architectural change. The most plausible architectural change would be the extension of VTL Enclaves and VBS Trustlets to host security-critical kernel components, such that *admin-to-VTL1* becomes the boundary even as *admin-to-VTL0-kernel* stays a feature [@ms-learn-vbs-ci].
</FAQItem>

<FAQItem question="Bypassing Defender always gets a CVE, right?">
No. Defender bypasses that do not also cross another boundary typically do not receive bulletins. Tavis Ormandy's 2014 to 2017 Defender disclosures earned CVEs because the bugs were memory-corruption primitives reachable from attacker-controlled inputs over the network -- they crossed the network boundary, not because the Defender bypass itself was a boundary crossing. The CVE-2017-0290 *crazy bad* MsMpEng RCE, addressed by Microsoft Security Advisory 4022344 (May 8, 2017), is the flagship instance [@ms-advisory-4022344]. A clever signature-evasion technique alone earns "by design."
</FAQItem>

<FAQItem question="The boundary list is fixed, right?">
No. It has grown by accretion: Session 0 isolation (Vista, 2007); AppContainer / Edge sandbox (Windows 8 / 1607, 2012 to 2016); VBS / VTL (Windows 10 1507, 2015); Administrator Protection elevation path (2025) [@ms-learn-admin-protection]. The list is expected to keep growing. Candidate future entries include cloud-side primitives (Conditional Access, Primary Refresh Token) and possibly an AI-mediated action-expansion entry.
</FAQItem>

<FAQItem question="Bringing your own vulnerable driver is a Microsoft CVE, right?">
Not on its own. BYOVD only earns a Microsoft CVE if a second primitive (network, user, AppContainer) is also crossed, or if the *driver vendor* receives the CVE. The Microsoft *Vulnerable Driver Blocklist* is feature hardening that ships in Windows updates, but the loadability of a properly-signed driver by an administrator is not a boundary crossing under the doctrine [@leviev-downdate-update].
</FAQItem>

<FAQItem question="PPL is a security boundary because Defender runs as PPL, right?">
No. AM-PPL is a *feature*. The Microsoft Learn page documents PPL as a hardening mechanism for anti-malware services [@ms-learn-am-ppl], and Gabriel Landau's *Inside Microsoft's Plan to Kill PPLFault* preserves the verbatim MSRC position: *"Microsoft does not consider PPL to be a security boundary"* [@landau-pplfault]. Microsoft will still ship PPLFault-class mitigations as feature hardening (build 25941 was the canary), but PPL-bypass reports that do not also cross another boundary do not earn standard Patch Tuesday bulletins.
</FAQItem>

</FAQ>

### Closing

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

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

<StudyGuide slug="windows-security-boundaries-the-document-that-decides-what-gets-a-cve" keyTerms={[
  { term: "Security boundary", definition: "A logical separation between security domains with different levels of trust, with security policy dictating what can pass through. Boundary crossings receive CVEs under the MSRC servicing criteria when severity meets the bar." },
  { term: "Security feature", definition: "A mechanism that raises the difficulty of attack but does not carry a vendor guarantee that policy holds. Feature defeats may still ship as security updates via the exception clause, but they are not boundary crossings." },
  { term: "Two-question rule", definition: "(1) Does the vulnerability violate the goal or intent of a security boundary or a security feature? (2) Does the severity meet the bar for servicing? Both yes = service via security update. Either no = by design / next version, with exceptions." },
  { term: "System Managed Administrator Account (SMAA)", definition: "The Administrator Protection elevation primitive: a hidden, profile-separated user account with its own SID, profile, and logon session, used to host elevated-administrator tokens authorised via Windows Hello." },
  { term: "Trustlet", definition: "A process running in VTL1 (Isolated User Mode), protected by the hypervisor from VTL0 (the normal kernel). LsaIso, the Isolated LSA Trustlet that holds Credential Guard credentials, is the canonical example." },
  { term: "BYOVD", definition: "Bring Your Own Vulnerable Driver: an administrator installs a legitimately-signed driver containing an exploitable vulnerability and uses the driver to obtain arbitrary kernel-mode code execution. Not a Microsoft boundary crossing because admin loads drivers by design." },
  { term: "Protected Process Light (PPL)", definition: "A signer-hierarchy mechanism introduced in Windows 8.1 that lets specially-signed processes refuse code injection and termination even from administrators. Microsoft explicitly classifies PPL as not a security boundary." },
  { term: "Mandatory Integrity Control (MIC)", definition: "Each securable object and access token carries an integrity level: Untrusted / Low / Medium / High / System. Lower-integrity subjects cannot write to higher-integrity objects regardless of DACL permissions." }
]} flashcards={[
  { front: "Is UAC a security boundary?", back: "No. UAC has been classified as a security feature, not a boundary, since Russinovich's June 2007 TechNet article. UACMe has documented more than 80 auto-elevation bypasses and zero CVEs." },
  { front: "Is admin-to-kernel a security boundary?", back: "No. Administrators can load drivers by design; drivers run in kernel mode. The Landau ItsNotASecurityBoundary repo name is an explicit homage to this MSRC policy." },
  { front: "Is the Administrator Protection elevation path a security boundary?", back: "Yes, as of 2025. The SMAA token has a separate SID, separate profile, and separate logon session from the user's standard-user token; the user boundary applies." },
  { front: "Is HVCI a security boundary?", back: "No. HVCI is a feature enforced inside VTL1. The VTL boundary is on the boundary list; HVCI is a feature that lives at that boundary." },
  { front: "Is PPL a security boundary?", back: "No. Microsoft has stated verbatim that 'Microsoft does not consider PPL to be a security boundary.' AM-PPL is a feature that protects anti-malware services." },
  { front: "Is bypassing Defender a CVE?", back: "Only if the bypass also crosses another boundary. Defender-itself bypasses are feature defeats; Tavis Ormandy's 2014 to 2017 CVEs crossed the network boundary." },
  { front: "Is same-user post-authentication a security boundary?", back: "No. Once a process executes under a user's session, it inherits the user's trust. Forshaw's June 2024 Recall ACL post is the doctrinal anchor." },
  { front: "Is guest-to-host on Hyper-V a security boundary?", back: "Yes. It pays \$5,000 to \$250,000 USD under the Microsoft Hyper-V Bounty Program -- the highest single-finding payout in the Microsoft bounty catalogue." }
]} questions={[
  { q: "Why is decoupling Question 1 (classification) from Question 2 (severity) the load-bearing engineering decision of the entire doctrine?", a: "Because a single-question rule would collapse the doctrine into opaque MSRC judgment. Decoupling lets Microsoft commit to a published taxonomy on the classification half while retaining engineering judgment on severity, with the explicit exception clause as the relief valve in either direction." },
  { q: "Explain why HVCI is on the feature list even though VTL is on the boundary list.", a: "HVCI is a feature enforced inside VTL1, under the protection of the hypervisor. The VTL boundary protects HVCI from VTL0 attackers, but HVCI itself does not enforce a separation between security domains. The boundary is the VTL line; HVCI is one of the features that runs at that boundary." },
  { q: "How did Administrator Protection close a gap that the entire UAC era could not?", a: "By creating a new elevation primitive (the SMAA token) with a separate SID, separate profile, and separate logon session, so that the existing user boundary applies. The Russinovich-2007 shared-resources structural argument that disqualified UAC from boundary status no longer applies because the SMAA token does not share those resources with the standard-user token." },
  { q: "Why does the absence of a UAC-bypass bounty matter for understanding the doctrine?", a: "Because the bounty schedule mirrors the boundary list mechanically. Microsoft only pays standalone bounties for findings that violate primitives the company commits to defending. The absence of a UAC bounty is structural, not oversight: there is no boundary to violate, so there is nothing to pay for." },
  { q: "Predict the MSRC disposition of a Defender bypass that allows malware to evade signature detection but does not introduce any other primitive. Justify your prediction.", a: "By design / consider for next version. Defender is on the feature list (heuristic detection cannot guarantee detection); a signature-evasion technique is a feature defeat with no boundary crossing; the severity gate is satisfied only by Critical / Important impact, and a pure detection evasion typically does not meet the bar. The exception clause could fire for an unusually impactful detection-evasion technique, but the default disposition is by design." }
]} />

The boundary list. From memory. Now.