Parag Mali - tag: security-boundaries

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

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

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

1. A UAC Bypass Walks Into MSRC

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

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

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

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

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

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

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

2. The Pre-Doctrine Era

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

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

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

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

Three failures accumulated pressure during the implicit-boundary era.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. The Document Accumulates

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

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

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

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

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

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

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

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

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

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

5. The Not-a-Boundary Table Also Accumulates

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

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

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

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

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

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

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

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

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

Here are the two tables side by side.

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

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

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

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

6. The Two-Question Triage Rule

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

The MSRC servicing-criteria page states the rule verbatim:

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

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

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

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

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

The doctrine has an explicit relief valve.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. The Nine Boundaries, Walked

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

7.1 Network boundary

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

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

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

7.2 Kernel boundary

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

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

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

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

7.3 Process boundary

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

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

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

7.4 Session boundary

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

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

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

7.5 User boundary

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

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

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

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

7.6 AppContainer / sandbox boundary

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

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

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

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

7.7 Virtual machine (guest-to-host) boundary

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

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

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

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

7.8 VTL (VTL0 to VTL1) boundary

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

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

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

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

7.9 Administrator Protection elevation path (2025 addition)

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

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

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

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

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

8. What Is Not a Boundary

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

8.1 UAC

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

8.2 Driver Signing / Code Integrity / KMCS

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

8.3 Microsoft Defender / Antimalware

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

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

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

8.4 HVCI / Memory Integrity

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

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

8.5 Protected Process Light (PPL)

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

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

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

8.6 Administrator-to-kernel privilege escalation

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

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

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

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

8.7 Same-user post-authentication

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

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

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

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

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

9. The Bounty Schedule Mirrors the Boundary List

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

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

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

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

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

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

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

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

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

10. What the Doctrine Cannot Decide

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

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

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

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

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

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

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

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

11. How Other Vendors Classify the Same Primitives

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

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

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

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

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

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

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

12. The 2026 Frontier

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

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

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

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

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

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

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

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

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

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

13. How to File a Useful MSRC Report

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

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

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

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

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

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

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

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

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

14. Frequently Asked Questions and Closing

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

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

Closing

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

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

The boundary list. From memory. Now.

The Object Manager Namespace: The Hierarchical Filesystem Underneath Every Windows Security Boundary

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

**The Windows Object Manager namespace is the kernel-resident, filesystem-shaped tree that every Windows security boundary quietly assumes.** Every named kernel object -- processes, threads, sections, files, registry keys, tokens, mutants, semaphores, ALPC ports, devices, drivers, jobs, silos -- lives somewhere under `\`. Six generations of isolation primitives (Session 0 isolation, AppContainer lowbox, integrity levels, VBS trustlets, Server Silos, and the `ObRegisterCallbacks` EDR sensor surface) are all path rewrites, per-directory ACLs, or kernel callbacks layered on the same 1993 Cutler-era four-piece structure. This article builds the namespace bottom-up -- `OBJECT_HEADER`, `OBJECT_TYPE`, `ParseProcedure`, `OBJECT_DIRECTORY` -- walks the 2026 top-level directory atlas on Windows 11 25H2, surveys the exploit tradition (symbolic-link redirection, namespace squatting, bait-and-switch on `\??` and `\Device`, arbitrary directory creation), and closes on the EDR pivot in `ObRegisterCallbacks`.

1. The path that isn't a path

Open WinObj.exe as administrator on any Windows 11 25H2 machine (Windows 11 version history). For about ten seconds the screen looks like a filesystem. The root is named \. Below it sit folders called \Device, \BaseNamedObjects, \Sessions, \RPC Control, \KnownDlls, and \ObjectTypes. Double-click any of them and you see children. Right-click any node and you can read a security descriptor. This is essentially the same UI a 1996 SysAdmin would have recognised; the tool first shipped that year as part of Mark Russinovich and Bryce Cogswell's Winternals [@en-wikipedia-mark-russinovich], and the current build is a Microsoft-signed Sysinternals binary whose navigation surface has not been redesigned in three decades [@ms-winobj].

Navigate to \Sessions\1\AppContainerNamedObjects and the picture starts to fracture. Inside that directory you will find one subdirectory per running AppContainer-sandboxed app, each named after a long Security Identifier of the form S-1-15-2-.... Pick the one belonging to the Microsoft Edge renderer process you are reading this article in. Every named mutant, event, section, semaphore, and ALPC port the renderer can ever name lives inside that one subdirectory. The renderer cannot escape it. Not because of a permission check that comes second, but because the kernel rewrites every name the renderer asks for, transparently, before path resolution begins. Microsoft's AppContainer Isolation documentation [@ms-appcontainer-isolation] calls this "sandboxing the application kernel objects."

This tree is not a filesystem. There is no disk persistence; nothing under \ survives a reboot. It is not the Windows registry either; the registry is a separate subsystem with its own hive format that hangs off the namespace only through a parse procedure on the Key object type. What this tree is, instead, is the Object Manager namespace: the in-memory, kernel-resident, hierarchical name service that the Windows kernel uses to locate every nameable kernel object [@ms-managing-kernel-objects]. Its top-level directories are catalogued in the driver kit's Object Directories reference [@ms-object-directories].

The Windows Object Manager, internally called `Ob`, is a kernel-mode subsystem of the Windows Executive that manages the lifetime, naming, security, and accounting of every resource the kernel exposes to user mode as a named object. Wikipedia summarises it as a "subsystem implemented as part of the Windows Executive which manages Windows resources... each [resource] reside[s] in a namespace for categorization" [@en-wikipedia-object-manager].

Here is the thesis the rest of this article spends nine thousand words unpacking. Every Windows security boundary you have read about -- Session 0 isolation, Mandatory Integrity Control, AppContainer, the Virtualization-Based Security trustlets, Server Silos and Windows containers, the EDR sensor surface that fires when something opens a handle to lsass.exe -- is physically realised in this tree. Each boundary is either a path rewrite at lookup time, a per-directory ACL, a token-keyed name substitution, or a kernel callback registered against an OBJECT_TYPE. The boundaries you read about elsewhere are the policies; this tree is the mechanism.

The Object Manager has shipped without architectural change for thirty-three years. Whose decision was that? And why did a 1993 data structure survive untouched while the GUI, the driver model, the security subsystem, and the boot path around it were rewritten more than once?

2. Where the namespace came from

The decision belongs to Dave Cutler. In 1988 Microsoft hired Cutler away from Digital Equipment Corporation. The Wikipedia biography records the line of operating systems Cutler had developed at DEC: "RSX-11M, VAXELN, VMS, and MICA" [@en-wikipedia-dave-cutler]. Three of those shipped commercially; the fourth, MICA, was cancelled with the Prism RISC program. Cutler walked out, and Microsoft signed him with a charter from Bill Gates to build a portable next-generation kernel that could host the existing Windows API on top of a 32-bit, multi-architecture base [@en-wikipedia-architecture-of-windows-nt]. Cutler brought a small team of DEC veterans with him.

The Object Manager is one of that team's earliest design decisions. The architectural bet was to unify every named kernel object under one filesystem-shaped tree, with each type carrying a parse procedure so a single family of syscalls (NtCreateFile, NtOpenSection, NtOpenProcess, and so on) could address files, registry keys, processes, ports, sections, drivers, devices, jobs, and synchronization primitives using the same path-walk algorithm. That was an unusual choice in 1989. VMS had a more typed, less unified resource broker. Mach treated kernel objects as capability-style port rights and never gave them a hierarchical name. Cutler's choice was, at heart, a Plan-9-style "every named resource is a filesystem path" idea, imported into a Windows shell.Plan 9 from Bell Labs (Pike, Thompson, et al.) was the academic articulation of the "everything is a path" property: every kernel-named resource, including processes and network connections, surfaced as a file under a 9P-served namespace. Plan 9 never reached commercial scale, but its design idea reached production through NT, and through Linux's /proc, /sys, and FUSE.

Windows NT 3.1 shipped on July 27, 1993. It was "Microsoft's first 32-bit operating system," supported on IA-32, DEC Alpha, and MIPS [@en-wikipedia-windows-nt-3-1]. The Object Manager was already one of its executive subsystems, sitting alongside the I/O Manager, the Memory Manager, the Process Manager, the Security Reference Monitor, and the Local Procedure Call subsystem [@en-wikipedia-architecture-of-windows-nt]. The four pieces this article will rebuild from scratch -- the OBJECT_HEADER that prefixes every object in memory, the OBJECT_TYPE singleton that owns each type's method table, the ParseProcedure that delegates path resolution to the owning subsystem, and the OBJECT_DIRECTORY hash table that maps names to objects -- were all in the NT 3.1 kernel. None of them has been rearchitected since.

That same year, Microsoft Press published Inside Windows NT, written by technical writer Helen Custer with a Foreword by Cutler himself. The book's Object Manager chapter is the canonical pre-2000 description of the namespace, cited on the Sysinternals WinObj page [@ms-winobj] as "Helen Custer's Inside Windows NT provides a good overview of the Object Manager namespace." Custer's book has been out of print for two decades, but the citation chain through Russinovich's tool is durable.

Three years later, in 1996, Russinovich and Cogswell co-founded Winternals and released WinObj 1.0 [@en-wikipedia-mark-russinovich]. WinObj was the first publicly distributed tool to walk \ from user mode, using the native NtOpenDirectoryObject and NtQueryDirectoryObject syscalls that the Object Manager exposed through NTDLL [@ms-winobj]. The following year, Russinovich's October 1997 Windows IT Pro column "Inside the Object Manager" gave the namespace its first treatment in the trade press. The original URL did not survive changes to TechTarget's web property portfolio in 2025 (TechTarget was acquired by Informa PLC in 2025), but the WinObj page still cites the column by name as "Mark's October 1997 [WindowsITPro Magazine] column, 'Inside the Object Manager'."The Russinovich 1997 column has no surviving direct URL because the URL did not survive changes to TechTarget's web property portfolio in 2025. The most accessible surviving citation is through the WinObj page itself. The same archive failure also explains why Helen Custer's 1993 biography returns HTTP 404 on Wikipedia in 2026; the book (ISBN 1-55615-481-X) survives in used-book channels only.

The line of book-length internals references that began with Custer continued through Inside Windows 2000 (third edition) and the Windows Internals series that succeeded it. The 7th edition Part 1 was published by Microsoft Press in May 2017, authored by Russinovich, Alex Ionescu, and David A. Solomon [@microsoftpressstore-wininternals7-part1]; its Chapter 8 is the current canonical reference for the Object Manager. James Forshaw's April 2024 Windows Security Internals [@nostarch-windows-security-internals] is the contemporary companion that ties the namespace into the access-check pipeline.

The 1993 design assumed a single global namespace. One process tree, one \BaseNamedObjects, one \Windows\WindowStations\WinSta0, one \?? view of DOS device letters. Everyone shared everything. Did that assumption survive the Internet?

3. The pre-Vista namespace and how it broke

It did not. By the late 1990s every interactive Windows user was sharing a name service with every running service. The single-global-namespace assumption produced three distinct exploit classes, each rediscovered repeatedly between 1996 and 2007, and each ultimately closed only by architectural change.

The most public failure was the shatter attack. In August 2002 a researcher named Chris Paget published a paper titled "Exploiting design flaws in the Win32 API for privilege escalation." Wikipedia's article on the disclosure preserves the chronology: "Shatter attacks became a topic of intense conversation in the security community in August 2002 after the publication of Chris Paget's paper" [@en-wikipedia-shatter-attack]. The proof-of-concept was about thirty lines. As an unprivileged interactive user, Paget sent a WM_TIMER window message to a service's hidden window in the same \Windows\WindowStations\WinSta0 (which all services and all interactive users shared in pre-Vista Windows), with a callback parameter pointing to attacker-placed shellcode. The shellcode ran as SYSTEM.

Microsoft's initial response, preserved in the Wikipedia article, was that "the flaw lies in the specific, highly privileged service": a per-service bug, patch the services. That stance did not survive the structural-class argument. The exploit was not a bug in one service. It was a property of the namespace: as long as services and users shared a window station and a \BaseNamedObjects, any service that ever called a Windows API processing a message from its message queue was reachable from any logged-in user.

Note: A second class of pre-Vista failure was named-object squatting. A low-privilege user pre-creates \BaseNamedObjects\Some_Global_Event with a permissive DACL. A privileged service later calls CreateEvent("Some_Global_Event") with default open-or-create semantics and ends up inheriting the squatter's object, security descriptor and all. This is not one service-author's bug; it is the consequence of every service-author trusting that names in a shared namespace would resolve to objects they themselves created. The pattern has been rediscovered approximately once a year for two decades. James Forshaw documents the contemporary named-pipe analog in his 2017 "Named Pipe Secure Prefixes" post [@tiraniddo-named-pipe-secure-prefixes], where the SMSS-created prefixes \Device\NamedPipe\ProtectedPrefix\Administrators, \Device\NamedPipe\ProtectedPrefix\LocalService, and \Device\NamedPipe\ProtectedPrefix\NetworkService are TCB-privilege-gated -- only smss.exe can create sibling protected prefixes, so a service that publishes its pipe below one of these prefixes inherits a DACL that low-privilege squatters cannot reach.

The third class was symbolic-link redirection. The pre-Vista Object Manager exposed two kinds of user-creatable symbolic link: object-manager symbolic links inside \?? (the per-session DOS-devices view) and NTFS mount points on disk. The attack pattern was the same in both. A privileged process is asked to open a path the user controls part of. The user has pre-planted a symbolic link partway through the path that redirects the residual walk into a target the user could not otherwise write. The privileged process opens the redirected file and treats it as if it were the original.

Forshaw's 2015 Project Zero post on the symbolic-link hardening generation is the canonical taxonomy: "There are three types of symbolic links you can access from a low privileged user, Object Manager Symbolic Links, Registry Key Symbolic Links and NTFS Mount Points" [@p0-symlink-mitigations]. His worked example for the Internet Explorer 11 EPM sandbox is CVE-2015-0055 [@nvd-cve-2015-0055], described in the post as "an information disclosure issue in the IE EPM sandbox which abused symbolic links to bypass a security check."

The aha moment from this section is the one Microsoft eventually conceded. The pre-Vista failure mode was not three independent bug families. It was one structural problem -- a single global namespace shared by every principal -- with three faces. No amount of per-service patching could close it. The fix had to be architectural: the namespace itself had to be partitioned.The Interactive Services Detection Service (ISDS) was Vista's backward-compatibility hack for legacy services that drew GUIs into Session 0. ISDS displayed a "An interactive service has requested attention" prompt that let the user switch to Session 0 long enough to dismiss the dialog. It was deprecated in Windows 10 1803 and is the historical artifact of just how much pre-Vista code assumed services and users would share a window station.

That fix took five years to ship. Windows Vista RTM was released on November 8, 2006 and General Availability arrived on January 30, 2007 [@en-wikipedia-windows-vista]. Vista did not ship one fix; it shipped three independent partition mechanisms in the same release window, because the structural failure had three faces and each face needed its own mechanism. The next section catalogues those mechanisms and the four additional generations of additive isolation that have built on them since.

4. Six generations of namespace isolation

The namespace itself has not been rearchitected since 1993. What has evolved, in six discrete generations between 1993 and 2026, is the set of partition primitives layered on top: the mechanisms that let the kernel hide subtrees from particular callers, rewrite paths transparently for particular tokens, or invoke a registered watcher when a particular handle is created. Each generation closes a structural class. None has rendered its predecessor obsolete. On 2026 Windows 11 25H2 all six are simultaneously load-bearing.

flowchart LR G1["Gen 1
NT 3.1, Jul 1993
Single global namespace"] --> G2 G2["Gen 2
Vista, Jan 2007 / SP1, Feb 2008
Session 0 + MIC + ObRegisterCallbacks"] --> G3 G3["Gen 3
Windows 8, Oct 2012
AppContainer / Lowbox / per-package directory"] --> G4 G4["Gen 4
Windows 10 RTM, Jul 2015
VBS / IUM secure-kernel namespace"] --> G5 G5["Gen 5
Windows Server 2016, Oct 2016
Server Silos / silo-scoped views"] --> G6 G6["Gen 6
MS15-090, Aug 2015 ->
symbolic-link class hardening"]

Generation numbering is thematic (by isolation capability introduced) rather than strictly chronological. Gen 6 (MS15-090, August 11, 2015) predates Gen 5 (Windows Server 2016, October 12, 2016) by 14 months; the numbering reflects the logical layering of isolation mechanisms, not their calendar sequence.

4.1 Generation 2 -- Session 0 isolation, integrity levels, ObRegisterCallbacks

Vista shipped three mechanisms in one release window because the structural failure had three faces.

The first was Session 0 isolation. From Vista forward, services run in Session 0 alone; the first interactive logon starts at Session 1. Each session gets its own subtree at \Sessions\<n>\BaseNamedObjects, \Sessions\<n>\Windows\WindowStations, and \Sessions\<n>\DosDevices. The Win32 Local\ prefix routes through kernel32!BaseGetNamedObjectDirectory into the per-session BNO; Global\ routes into the shared \BaseNamedObjects [@ms-termserv-kernel-object-namespaces]. The Wikipedia Shatter article preserves the architectural fix verbatim: "Local user logins were moved from Session 0 to Session 1, thus separating the user's processes from system services that could be vulnerable" [@en-wikipedia-shatter-attack]. After Vista an interactive user could no longer SendMessage(WM_TIMER) into a service's hidden window because the user and the service no longer shared a window station.

The second mechanism was Mandatory Integrity Control. Vista introduced a new ACE type, SYSTEM_MANDATORY_LABEL_ACE, attached to every object's security descriptor. Each token carries one of four integrity levels (Low S-1-16-4096, Medium S-1-16-8192, High S-1-16-12288, or System S-1-16-16384), and the Security Reference Monitor compares the requester's level against the object's level after path resolution succeeds [@en-wikipedia-mandatory-integrity-control]. MIC is not a namespace partition. A Low-IL process and a Medium-IL process resolve the same \BaseNamedObjects directory; only the open is denied at the leaf. The structural property MIC adds is that the leaf check is unbypassable from user mode; the check fires regardless of which DACL the object carries.

The third mechanism was ObRegisterCallbacks. Microsoft's wdm.h documentation records the API's first ship date verbatim: "Available starting with Windows Vista with Service Pack 1 (SP1) and Windows Server 2008" [@ms-obregistercallbacks]. The API lets a KMCS-signed driver intercept handle creation and handle duplication on PsProcessType, PsThreadType, and the desktop object type. The registration carries an Altitude (a FltMgr-style collision key) and an array of OB_OPERATION_REGISTRATION records [@ms-ob-callback-registration]. Pre-operation callbacks can strip access-mask bits before the handle is granted; post-operation callbacks fire for logging. The parallel API PsSetCreateProcessNotifyRoutineEx [@ms-pssetcreateprocessnotifyroutineex] covers process creation. Together, these are the kernel-mode primitives every modern EDR product depends on; they ship inside the Object Manager itself and they are the reason an EDR knows when something opens a handle to lsass.exe.

4.2 Generation 3 -- AppContainer and the lowbox token

Windows 8 shipped on October 26, 2012 [@en-wikipedia-windows-8]. Modern / UWP apps downloaded from the Microsoft Store needed a sandbox finer-grained than per-session BNO. The Vista path rewriting in kernel32!BaseGetNamedObjectDirectory happened in user mode, which made it the wrong layer for a sandbox: a hostile renderer could in principle bypass the user-mode rewrite. The new layer moved into the kernel.

Each UWP / MSIX process runs under a special token type, the AppContainer / LowBox token (referred to in kernel code as the lowbox token), created by NtCreateLowBoxToken. The token carries a TOKEN_APPCONTAINER_INFORMATION block that names the process's package SID (S-1-15-2-...) and an AppContainerNumber. Inside ObpLookupObjectName, before the path is walked, the kernel checks whether the caller's token is a lowbox token; if it is, lookups of \BaseNamedObjects\X, \RPC Control\X, and other rewriteable paths get redirected into \Sessions\<n>\AppContainerNamedObjects\<package-sid>\X. The user-mode caller never sees the rewrite. The package-SID directory is created by SYSTEM at process-creation time with a security descriptor that grants the package SID, and only the package SID, full access. Microsoft's wording is precise: AppContainer works by "sandboxing the application kernel objects, the AppContainer environment prevents the application from influencing, or being influenced by, other application processes" [@ms-appcontainer-isolation].

The AppInfo service, which is responsible for creating the new application, calls the undocumented API CreateAppContainerToken to do some internal housekeeping. Unfortunately this API creates object directories under the user's AppContainerNamedObjects object directory to support redirecting BaseNamedObjects and RPC endpoints by the OS. -- James Forshaw, Project Zero Issue 1550 [@p0-issue1550]

The residual class the AppContainer model has not closed is the one Forshaw's August 30, 2018 Project Zero post [@p0-issue1550] documents: because the SYSTEM-side AppInfo service has to write into the user's AppContainerNamedObjects subtree to set up redirection, an unprivileged caller can race the directory creation and end up planting a symbolic link the SYSTEM service then follows. The class -- "SYSTEM-privileged directory creation in user-controllable territory" -- is the worked example of why "the kernel rewrites the name" is an isolation property only when the SYSTEM helpers also use the rewrite.

4.3 Generation 4 -- VBS trustlets and the IUM secure-kernel namespace

Windows 10 RTM shipped on July 29, 2015 [@en-wikipedia-windows-10-version-history]. The Virtualization-Based Security (VBS) feature set introduced a parallel object-manager-shaped namespace that lives in Virtual Trust Level 1 (VTL1) and is inaccessible to the VTL0 NT kernel. Inside VTL1 the Secure Kernel (securekernel.exe) maintains its own root, its own type registry, and its own handle-table machinery. The VTL0 NT kernel can see trustlet processes -- the per-trustlet user-mode containers running in Isolated User Mode (IUM) -- but it cannot reach into their secure-side state.

Alex Ionescu's Black Hat USA 2015 talk Battle of SKM and IUM [@ionescu-bh2015-pdf] is the canonical inventory of the inbox Trustlet IDs at ship: Trustlet 0 is the Secure Kernel Process hosting Device Guard; Trustlet 1 is LSAISO.EXE for Credential Guard; Trustlet 2 is VMSP.EXE hosting the virtual TPM; Trustlet 3 is the vTPM provisioning trustlet. Each is identified by a Trustlet ID and reachable only through narrow Secure Kernel ALPC ports. The VBS Trustlets piece in this series unpacks the threat model.

4.4 Generation 5 -- Server Silos and the silo-scoped namespace

Windows Server 2016 shipped on October 12, 2016 [@en-wikipedia-windows-server-2016]. Microsoft needed a Linux-namespaces equivalent so that container runtimes -- Docker, containerd, and the Azure Kubernetes Service Windows-node pods that followed -- could host adjacent workloads on one kernel. The answer was Server Silo: a new OBJECT_TYPE registered alongside Job, Process, and Thread, that carries its own RootDirectory, DosDevicesDirectory, and ServerSiloGlobals. A process attached to a silo via PsAttachSiloToCurrentThread sees the silo's namespace as its root; the silo's \GLOBAL??\C: resolves to the silo's \Device\HarddiskVolume*, which is a different Device object from the host's. Job objects [@ms-job-objects] provide the cgroups-equivalent resource-accounting dimension; the Silo type builds on top.

The canonical reverse-engineering reference is Daniel Prizmant's July 2020 Unit 42 writeup, which spells out the architecture: "job objects are used in a similar way control groups (cgroups) are used in Linux, and... server silo objects were used as a replacement for namespaces support in the kernel" [@unit42-rev-eng-windows-containers].

The companion piece, Prizmant's June 2021 Siloscape [@unit42-siloscape], is the first known malware family that escapes the silo boundary: Prizmant named the malware "Siloscape (sounds like silo escape) because its primary goal is to escape the container, and in Windows this is implemented mainly by a server silo." James Forshaw's April 2021 Project Zero post Who Contains the Containers? [@p0-who-contains-containers] is the four-LPE companion disclosure. Microsoft's standing position is that Server Silo is not a security boundary; the Hyper-V Container, which adds a Hyper-V VM around the container's silo, is the security-boundary product.

4.5 Generation 6 -- the symbolic-link hardening continuum

The cross-cutting hardening generation closes the symlink subclass that recurred in Generations 1, 3, and 5. MS15-090 shipped on August 11, 2015 [@ms-ms15-090] and "corrects how Windows Object Manager handles object symbolic links created by a sandbox process, by preventing improper interaction with the registry by sandboxed applications, and by preventing improper interaction with the filesystem by sandboxed applications." The bulletin's canonical Object Manager CVE is CVE-2015-2428 [@nvd-cve-2015-2428], described verbatim as the case where the "Object Manager in Microsoft Windows... does not properly constrain impersonation levels during interaction with object symbolic links that originated in a sandboxed process." Subsequent Windows 10 builds added OBJ_DONT_REPARSE, an open-time flag that disables symbolic-link substitution for callers willing to opt in, and post-Siloscape patches in 2021 closed NtSetInformationSymbolicLink retargeting from inside a silo.

The scope document for this article originally attributed MS15-090 to CVE-2015-2528 and CVE-2015-1463. Independent NVD verification confirmed neither is correct: CVE-2015-2528 [@nvd-cve-2015-2528] is the MS15-102 Task Management EoP, and CVE-2015-1463 [@nvd-cve-2015-1463] is a ClamAV denial-of-service crash. The canonical MS15-090 OM-symlink CVE is CVE-2015-2428. Separately, CVE-2018-0824 [@nvd-cve-2018-0824] is a CWE-502 COM deserialization issue that joined the CISA KEV catalog on 2024-08-05, not a namespace-squatting CVE.

The residual subclass MS15-090 did not close was the per-session \?? DosDevices remapping path under impersonation. A low-privileged process whose token is impersonated by a SYSTEM service can plant a DefineDosDevice remapping that survives into the impersonation-time \?? view, and the SYSTEM-side activation-context resolver then opens the redirected path while running with elevated privileges. The canonical 2023 worked example is HackSys's Activation Context Hell -- DosDevices Remapping Attack under Impersonation [@hacksys-activation-context-hell], which targets the CSRSS / SxS activation-context resolver and shipped as CVE-2023-35359 [@nvd-cve-2023-35359], with the closely-related CVE-2022-22047 [@nvd-cve-2022-22047] covering the underlying CSRSS surface. The mitigation has to live inside the impersonation-aware \?? resolver in the SYSTEM caller, not at the symlink-creation gate.

Note: Every generation since Generation 1 has layered a new isolation primitive on top of the prior generation. None has rendered its predecessor obsolete. On 2026 Windows 11 25H2 all six generations coexist simultaneously: a UWP / MSIX app inside a Server Silo on a VBS-enabled host is session-partitioned, lowbox-rewritten, silo-scoped, VTL0-confined, integrity-gated, and watched by every loaded EDR's ObRegisterCallbacks filter. Each layer adds an independent enforcement point at ObpLookupObjectName time.

Six generations of isolation primitives is a tidy story, but it has glossed the most important question. What is the actual kernel data structure all six generations parameterize? What does the path-walk algorithm look like, what is the type registry, and where does the hash table live?

5. The four load-bearing primitives

If you remember one paragraph from this article, make it this one. The Object Manager namespace is built out of four kernel data structures: an OBJECT_HEADER that prefixes every named object in memory, an OBJECT_TYPE singleton that owns each type's method table, a ParseProcedure that delegates path resolution to the owning subsystem when needed, and an OBJECT_DIRECTORY hash table that maps names to objects. Every Windows security boundary you have read about is a parameter to one of these four pieces. The next eight subsections rebuild them one at a time.

flowchart TB OD["OBJECT_DIRECTORY
(37-bucket hash table)"] -->|"hash(name) % 37"| OH OH["OBJECT_HEADER
(PointerCount, HandleCount,
TypeIndex, InfoMask,
SecurityDescriptor, Body offset)"] -->|"TypeIndex XOR
ObHeaderCookie"| OT OT["OBJECT_TYPE singleton
(in nt!ObTypeIndexTable)"] -->|"TypeInfo"| TI TI["TYPE_INFO method table
(Dump, Open, Close, Delete,
ParseProcedure,
Security, QueryName, ...)"] OH -->|"Body[]"| BODY["Type-specific body
(EPROCESS, FILE_OBJECT,
SECTION_OBJECT, ...)"]

5.1 OBJECT_HEADER

Every named kernel object lives in non-paged pool. Immediately before each object's typed body sits an OBJECT_HEADER, a 0x30-byte (48-byte on x64) structure that the Object Manager owns. PointerCount and HandleCount are the two reference counts: the former tracks raw kernel-mode pointer references, the latter tracks user-mode handles. TypeIndex is a single byte that indexes into the nt!ObTypeIndexTable to find the object's type singleton; since Windows 10 1709, the byte is XOR-obfuscated against the per-boot nt!ObHeaderCookie so that simple type confusion is non-trivial.

InfoMask is a bitmap of optional sub-headers that may precede the main header: OBJECT_HEADER_NAME_INFO for named objects, OBJECT_HEADER_QUOTA_INFO for objects that charge a quota block, OBJECT_HEADER_HANDLE_INFO for objects that need per-process handle accounting. SecurityDescriptor is a tagged pointer to the object's DACL/SACL. Body[] is the offset at which the type-specific payload begins; for a process object that payload is an EPROCESS, for a file it is a FILE_OBJECT, and so on. The canonical reference is Chapter 8 of Windows Internals 7th Edition Part 1 [@microsoftpressstore-wininternals7-part1].

The per-object header (`nt!_OBJECT_HEADER`) that precedes every named kernel object in non-paged pool. Carries reference counts (`PointerCount`, `HandleCount`), a `TypeIndex` byte that points into `nt!ObTypeIndexTable` (XOR-obfuscated against `nt!ObHeaderCookie` since Windows 10 1709), an `InfoMask` describing optional sub-headers, a `SecurityDescriptor` pointer, and the offset to the typed `Body[]`.

The TypeIndex XOR-with-cookie is one of the smallest kernel hardening changes Microsoft has shipped: a single byte that prevents a poisoned OBJECT_HEADER from naming an arbitrary type after a heap-corruption primitive. The cookie is per-boot and lives in nt!ObHeaderCookie. The hardening is documented in Windows Internals 7th Edition Chapter 8 [@microsoftpressstore-wininternals7-part1] and in Geoff Chappell's reverse-engineering studies; Microsoft has not, as of 2026, published a Learn-hosted reference for the cookie itself.

5.2 OBJECT_TYPE

OBJECT_TYPE is the per-type singleton. There is exactly one OBJECT_TYPE per registered kernel type, and they live in \ObjectTypes. On Windows 11 25H2 the count sits at roughly seventy-five: Type, Directory, SymbolicLink, Token, Job, Process, Thread, Section, Key, File, Event, Mutant, Semaphore, Timer, WindowStation, Desktop, Device, Driver, IoCompletion, ALPC Port, EtwRegistration, Silo, and dozens more.

The per-type singleton (`nt!_OBJECT_TYPE`) that owns each kernel type's method table. The `TypeInfo` field carries eight procedure pointers and one offset field (WaitObjectFlagOffset): `DumpProcedure`, `OpenProcedure`, `CloseProcedure`, `DeleteProcedure`, `ParseProcedure` (the path-resolution callback), `SecurityProcedure`, `QueryNameProcedure`, `OkayToCloseProcedure`, and a `WaitObjectFlagOffset` offset for waitable types. Every `OBJECT_TYPE` instance is reachable through `\ObjectTypes`.

The TypeInfo field on each OBJECT_TYPE carries eight procedure pointers and one offset field (WaitObjectFlagOffset). The most consequential is the ParseProcedure. When ObpLookupObjectName is walking a path component-by-component, and a step lands on an object whose OBJECT_TYPE defines a ParseProcedure, the OM hands the residual path and the desired access to that procedure, which becomes the namespace authority below that point. That is how the registry's Key type, the I/O Manager's Device type, and the various WMI / Volume-Manager subsystems insert themselves into the namespace without the Object Manager having to know any of their internal structure [@en-wikipedia-object-manager].

5.3 The parse procedure

ObpLookupObjectName walks \Foo\Bar\Baz\...\Leaf left-to-right. At each component the walker does one of three things. The common case is a hash-table lookup in the current OBJECT_DIRECTORY's 37 buckets to find the child object by name. The second case is SymbolicLink substitution: if the child object's type is SymbolicLink, the walker substitutes the link target and re-enters the walk at the substitution. The third and most consequential case is parse-procedure handoff. If the child object's OBJECT_TYPE has a non-null ParseProcedure, the walker stops, hands the residual path string to that procedure, and lets it decide what to do.

The load-bearing method pointer on each `OBJECT_TYPE`'s `TypeInfo` field. When `ObpLookupObjectName` encounters an object whose type defines a `ParseProcedure`, the residual path is handed to that procedure for resolution. The two canonical parse procedures are `IopParseDevice` (for the `Device` type, which delegates further resolution to the device's owning driver via `IRP_MJ_CREATE`) and `CmpParseKey` (for the `Key` type, which walks the registry hive).

IopParseDevice is the parse procedure for the Device type. When the walker reaches \Device\HarddiskVolume1 and is asked to continue with \Users\me\file.txt, the I/O Manager builds an IRP_MJ_CREATE packet, dispatches it to the filesystem driver that owns the volume (NTFS, ReFS, ExFAT, FAT32, or one of several others), and lets that driver walk the rest of the path inside its own on-disk structures. The driver returns a FILE_OBJECT, which the Object Manager packages into a handle.

CmpParseKey is the parse procedure for the Key type. When the walker reaches \REGISTRY and is asked to continue with \MACHINE\Software\Microsoft\Windows, the Configuration Manager takes over and walks the in-memory hive structures.

The structural consequence is profound. Every named file in Windows is, technically, a leaf in the Object Manager namespace. NTFS, ReFS, ExFAT, and the registry are not separate naming systems; they are parse-procedure callbacks that hand FILE_OBJECT or KEY bodies back to the OM.

sequenceDiagram participant User as User Process participant OM as ObpLookupObjectName participant Dir as \GLOBAL?? OBJECT_DIRECTORY participant Dev as \Device\HarddiskVolume1 (Device type) participant Drv as NTFS Driver User->>OM: NtCreateFile("\??\C:\Users\me\file.txt") OM->>OM: rewrite \??\ -> \Sessions\\DosDevices\ OM->>Dir: lookup "C:" Dir-->>OM: SymbolicLink -> \Device\HarddiskVolume1 OM->>OM: substitute, re-enter walk OM->>Dev: lookup \Device\HarddiskVolume1 Dev-->>OM: type=Device, has ParseProcedure OM->>Drv: IopParseDevice with "\Users\me\file.txt" Drv->>Drv: IRP_MJ_CREATE: walk MFT, find file Drv-->>OM: FILE_OBJECT OM-->>User: HANDLE

5.4 The 37-bucket directory hash

OBJECT_DIRECTORY is a 37-bucket open-hash table. The hash function is RtlHashUnicodeString, applied to each component name. Thirty-seven was the prime Cutler picked in 1993; the constant has not changed in thirty-three years. The folk-knowledge corroboration is in Chapter 8 of Windows Internals 7th Edition Part 1 and in Forshaw's Windows Security Internals Chapter 8; Microsoft has never published a Learn-hosted spec for the constant [@nostarch-windows-security-internals].

The 37-bucket open-hash table (`nt!_OBJECT_DIRECTORY`) that lives at every interior node of the Object Manager tree. Keys are `UNICODE_STRING` component names; the hash is `RtlHashUnicodeString` modulo 37. Each bucket is a linked list of `OBJECT_DIRECTORY_ENTRY` records that point at the next-level `OBJECT_HEADER`. Reading the tree requires `Directory`-`TRAVERSE` rights on the parent.

The 37-bucket constant from 1993 has not changed in thirty-three years. On a 2026 Windows 11 25H2 box with several hundred MSIX packages each owning an \AppContainerNamedObjects\<package-sid>\ subtree, average bucket chains run several entries deep. Collision pressure on the constant is the open problem returned to in Section 9.

5.5 The lowbox redirect inside ObpLookupObjectName

This is the subsection that earns the second aha moment of the article.

When the calling thread's primary token is a lowbox token, ObpLookupObjectName consults the token's AppContainerNumber and package SID before it begins the walk. Lookups that would otherwise resolve into \BaseNamedObjects or \RPC Control are rewritten into \Sessions\<n>\AppContainerNamedObjects\<package-sid>\. The rewrite happens transparently to the user-mode Win32 caller, which still thinks it asked for \BaseNamedObjects\X.

A specialised token type produced by `NtCreateLowBoxToken` that carries a `TOKEN_APPCONTAINER_INFORMATION` block (with a package SID `S-1-15-2-...` and an `AppContainerNumber`). When a process runs under a lowbox token, `ObpLookupObjectName` rewrites every named-object lookup into the per-package directory `\Sessions\\AppContainerNamedObjects\\` before path walking begins. The user-facing brand for the lowbox-token mechanism. Every UWP / MSIX / Windows Store app runs in an AppContainer. The Windows API surface is unchanged for the app; the Object Manager rewrites every named-object name into a per-package subtree, gating cross-package coordination at the namespace layer. The Microsoft Learn page describes this as "Sandboxing the application kernel objects, the AppContainer environment prevents the application from influencing, or being influenced by, other application processes" [@ms-appcontainer-isolation].

The aha moment is structural. AppContainer is not a containment mechanism the way you might first picture it. It is a name-translation mechanism. The lowbox token tells the kernel which directory to rewrite every name into; the sandbox is, at root, a hash-table indirection inside the kernel's path-walk function. The Edge renderer process cannot name \BaseNamedObjects\GlobalEvent_Foo because the kernel rewrites that name into \Sessions\1\AppContainerNamedObjects\S-1-15-2-...\Global\GlobalEvent_Foo before lookup even begins. The "sandbox" is a hash-table redirect.

5.6 The Silo OBJECT_TYPE and silo-scoped views

Silo is itself a registered OBJECT_TYPE. Each silo instance carries a silo-scoped RootDirectory, DosDevicesDirectory, and ServerSiloGlobals (with the silo's own registry-hive root and per-silo BaseNamedObjects root). PsAttachSiloToCurrentThread switches the thread's namespace view; once attached, every Object Manager lookup runs through the silo's roots instead of the host's. Job objects, which provide the cgroups-equivalent resource-accounting substrate, are the underlying primitive the Silo type extends [@ms-job-objects]. The structural design history is in Prizmant's reverse-engineering writeup [@unit42-rev-eng-windows-containers].

A specialised `Job`-derived kernel object (`OBJECT_TYPE` Silo) introduced in Windows Server 2016 that carries silo-scoped `RootDirectory`, `DosDevicesDirectory`, and `ServerSiloGlobals` fields. A thread attached to a silo via `PsAttachSiloToCurrentThread` sees the silo's namespace as its root; the silo's `\GLOBAL??\C:` resolves to the silo's `\Device\HarddiskVolume*`, which is a different `Device` object from the host's. Server Silo is the substrate underneath Windows Server Containers and WSL1.

5.7 The Secure Kernel's parallel namespace

Inside VTL1, the Secure Kernel maintains a separate Object Manager tree with its own root, its own type registry, and its own handle-table machinery. The VTL0 NT kernel cannot enumerate this tree; the only cross-VTL traffic is the narrow ALPC interface each trustlet publishes. Ionescu's BH2015 inventory (Trustlet IDs 0 through 3 at ship, growing in subsequent releases) is the canonical primary [@ionescu-bh2015-pdf].

A user-mode process running in Isolated User Mode under the VTL1 Secure Kernel. Each trustlet is signed with both the Windows System Component Verification EKU (1.3.6.1.4.1.311.10.3.6) and the IUM EKU (1.3.6.1.4.1.311.10.3.37), runs at Signature Level 12, and is reachable from VTL0 only through narrow ALPC ports. LSAISO.EXE (Credential Guard), VMSP.EXE (virtual TPM host), and the vTPM provisioning trustlet are the inbox examples.

5.8 The handle table

The namespace is the name side; the per-process HANDLE_TABLE is the access side. Once a handle exists in a process, no name lookup happens on subsequent use; the kernel dereferences the handle through a three-level radix tree indexed by the 32-bit handle value, lands on an OBJECT_HEADER, and operates on the body. This is why ObRegisterCallbacks fires on handle creation and duplication rather than on every use, and why an inherited handle bypasses the callback entirely. The structural consequence -- that the Object Manager is the gate at name resolution but not at every operation -- comes back in Section 8.

Now you know the data structure. But what does the actual tree look like in 2026? What does \ contain on a Windows 11 25H2 box, and which security boundary lives in each top-level directory?

6. The 2026 top-level directory atlas

Open WinObj.exe as administrator on a Windows 11 25H2 machine and the root directory at \ carries roughly twenty entries. The table below catalogues the load-bearing ones. Each row names the directory, the security boundary it physically realises, and a representative exploit class that has been thrown at it. The driver kit's Object Directories reference [@ms-object-directories] is Microsoft's canonical inventory.

Top-level directory	What it contains	Which boundary it enforces	Exploit class
`\ObjectTypes`	The ~75 `OBJECT_TYPE` singletons (`Process`, `Thread`, `Section`, `Key`, `File`, `Token`, `Job`, `Silo`, etc.)	Meta -- the type registry the rest of the namespace depends on	Type confusion (mitigated by `ObHeaderCookie` since Windows 10 1709)
`\Device`	Driver-published device objects (`\Device\HarddiskVolume*`, `\Device\Tcp`, `\Device\Tpm`, `\Device\NamedPipe`, `\Device\Mailslot`, `\Device\Vmbus`, `\Device\KsecDD`, `\Device\CNG`)	The I/O Manager's surface; each driver's parse procedure consumes residual paths	Bait-and-switch on `\Device` (a low-privilege user redirects a privileged opener through a planted symbolic link)
`\Driver`, `\FileSystem`	Loaded `DRIVER_OBJECT` registries	KMCS / HVCI driver-load gate	Vulnerable signed-driver class (BYOVD)
`\GLOBAL??`	The machine-wide DosDevices view -- where `C:` and `D:` are symlinks to `\Device\HarddiskVolume*`	Cross-session drive-letter map	Symlink redirect across session boundary
`\??`	The per-session DosDevices alias, falling through to `\GLOBAL??`	Session-scoped drive-letter map	The HackSys / CVE-2023-35359 worked example: a low-privilege caller plants a `DefineDosDevice` remapping that survives into the impersonation-time `\??` view, and the SYSTEM-side activation-context resolver opens the redirected path
`\BaseNamedObjects`	The global / `Global\`-prefixed-only BNO	Cross-session named-object visibility	Pre-Vista squatting class (closed by Generation 2)
`\Sessions\<n>\`	Per-session subtrees (BNO, DosDevices, WindowStations, AppContainerNamedObjects)	Session boundary (Generation 2)	Shatter attacks (closed by Generation 2)
`\Sessions\<n>\AppContainerNamedObjects\<package-sid>\`	Per-package UWP / MSIX lowbox namespace	AppContainer / lowbox boundary (Generation 3)	Forshaw P0 Issue 1550 arbitrary-directory creation race
`\RPC Control`	Every named LRPC ALPC port (every COM call lands here)	RPC endpoint visibility	Endpoint squatting against named LRPC ports
`\KnownDlls`, `\KnownDlls32`	Pre-mapped `Section` objects for system DLLs	Loader supply-chain	`DefineDosDevice` + `\??` symlink-plant trick (closed in NTDLL July 2022, build 19044.1826)
`\KernelObjects`	System-defined events (`LowMemoryCondition`, `HighMemoryCondition`, etc.)	Kernel-internal visibility	None public
`\Callback`	System-defined `Callback` objects (`ExCallback` slots drivers register against)	Kernel API extension surface	Driver-callback abuse
`\Security`	LSA-private endpoints	LSA / authentication isolation	Credential-theft (the LSAISO trustlet via Generation 4)
`\Windows`	BNO-redirect surface and `SharedSection`	Win32 subsystem shared state	Cross-session Win32 state leakage
`\Silos\<id>`	Per-container silo subroots on Server SKUs	Server Silo boundary (Generation 5)	Siloscape -- symlink retarget out of the silo
`\BNOLINKS`	The boundary-keyed private-namespace index	`CreatePrivateNamespace` cross-session/cross-package IPC	None public; the directory itself is RE-derived

flowchart LR subgraph EdgeRenderer["Microsoft Edge Renderer (lowbox token)"] K32["CreateMutexW(L'Global\\Foo')"] end K32 -->|"NtCreateMutant, OBJECT_ATTRIBUTES"| OB subgraph KernelOb["ObpLookupObjectName"] OB["Read caller token
token.AppContainerNumber
token.PackageSid"] OB -->|"rewrite name"| RW["Rewrite '\\BaseNamedObjects\\Global\\Foo'
to
'\\Sessions\\1\\AppContainerNamedObjects\\
S-1-15-2-...\\Global\\Foo'"] RW --> WALK["walk the rewritten path"] end WALK --> Dir["\\Sessions\\1\\AppContainerNamedObjects\\
S-1-15-2-...\\Global\\
(per-package OBJECT_DIRECTORY,
DACL allows only package SID)"]

The \BNOLINKS directory deserves a separate paragraph because it is not on Microsoft Learn. NtCreatePrivateNamespace is the kernel-side syscall behind the Win32 CreatePrivateNamespace API [@ms-createprivatenamespacew]; the caller passes a boundary descriptor built by CreateBoundaryDescriptor [@ms-createboundarydescriptorw] plus one or more SIDs added via AddSIDToBoundaryDescriptor [@ms-addsidtoboundarydescriptor]. The kernel materialises one \BNOLINKS entry per (alias_prefix, boundary_descriptor_hash) tuple; two callers that pass the same lpAliasPrefix but different boundary descriptors land on different directories. The native signature is documented in the PHNT-derived NtDoc mirror [@ntdoc-ntcreateprivatenamespace], and the OBJECT_BOUNDARY_DESCRIPTOR structure layout is at ntdoc.m417z.com/object_boundary_descriptor [@ntdoc-object-boundary-descriptor]. The Win32 Object Namespaces overview [@ms-object-namespaces] is Microsoft's only published user-mode reference; the \BNOLINKS directory name itself is reverse-engineering-derived.The \BNOLINKS directory is documented only through reverse engineering of ntoskrnl.exe -- via Forshaw's NtObjectManager and System Informer's PHNT headers -- not on Microsoft Learn. The user-mode API surface (CreatePrivateNamespace, CreateBoundaryDescriptor, AddSIDToBoundaryDescriptor) is fully documented. The provenance gap is worth flagging when you cite the directory by name.The \KnownDlls LPE class was, for a decade, the canonical example of how a DACL plus loader-side validation could lock down a supply-chain anchor. Forshaw's August 2018 P0 post first sketched a DefineDosDevice + \?? symlink-plant chain that could land a forged Section object into \KnownDlls; Clement Labro (itm4n) implemented the attack as the PPLdump tool and wrote companion posts on both itm4n.github.io [@itm4n-lsass-runasppl] and the SCRT team blog [@blog-scrt-bypassing-lsa-protection-in-userland]. The class was closed in NTDLL by Windows 10 21H2 build 19044.1826; itm4n confirms the patch in The End of PPLdump [@itm4n-the-end-of-ppldump]: "A patch in NTDLL now prevents PPLs from loading Known DLLs."

{` const MAX_DIRECTORY_BUCKETS = 37;

function rtlHashUnicodeString(name) { let h = 0; for (const ch of name.toUpperCase()) { h = (h * 31 + ch.charCodeAt(0)) >>> 0; } return h % MAX_DIRECTORY_BUCKETS; }

function makeDir() { return { buckets: Array(MAX_DIRECTORY_BUCKETS).fill(null).map(() => []) }; }

function addChild(dir, name, child) { dir.buckets[rtlHashUnicodeString(name)].push({ name, child }); }

const root = makeDir(); const device = makeDir(); device.parseProcedure = true; device.type = 'Device'; const sessions = makeDir(); addChild(root, 'Device', device); addChild(root, 'Sessions', sessions); addChild(root, 'BaseNamedObjects', makeDir());

lookupObjectName('\\Device\\HarddiskVolume1\\Users\\me\\file.txt', root); `}

The walk is the algorithm. The 37 is the bucket count Cutler picked in 1993. The parse-procedure handoff is where the I/O Manager and the Configuration Manager and dozens of other subsystems insert themselves into the tree. Now turn the question around: Windows bet on one tree. What did the kernels that did not bet on one tree do, and why?

7. How other kernels name kernel objects

Three kernels, three different bets. Linux took the namespace and split it into per-resource-class clones -- one for mounts, one for PIDs, one for IPC, one for the network stack, one for users, one for hostnames, one for cgroups, one for time -- and never built a unified tree. macOS / Darwin gave each task its own Mach port-right namespace and let launchd broker named-service lookups. Plan 9 from Bell Labs was the academic ancestor of "every named OS resource is a filesystem path," and the design Cutler imported into NT.

7.1 Linux: per-resource namespaces

Linux ships eight namespace types, each governed by a CLONE_NEW* flag passed to clone(), unshare(), or setns(): mount, PID, network, IPC, user, UTS, cgroup, and time. The namespaces(7) man page is precise: "A namespace wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource" [@man7-namespaces]. Docker, containerd, runc, Kubernetes pods, LXC, and systemd-nspawn all compose these eight flags into a Linux container.

The strength of the Linux design is per-class composability. A process can be in a fresh mount namespace, a fresh PID namespace, and the host's network namespace, all at once. The weakness is the absence of a unified type registry: Linux has no equivalent of \ObjectTypes, no equivalent of the OBJECT_HEADER reference counting that the kernel applies uniformly to every named object. Each resource class has its own lookup function, its own permission model, and its own ownership story. A bug in any one of them is bounded to that one resource class but is also not shared mitigation across the others.

7.2 macOS / Darwin: Mach ports and the bootstrap server

Darwin's kernel-object naming is capability-style. Apple's archive documentation describes the model directly: "each task consists of a virtual address space, a port right namespace, and one or more threads" [@apple-mach-kernel]. Tasks send messages by holding a port right -- a per-task index into a kernel-managed table of Mach ports. There is no single hierarchical namespace; ports are sent over Mach messages, and launchd operates as the bootstrap-server name broker for services that need a stable rendezvous. A separate I/O Registry tree carries device objects.

The strength of the Mach design is that capabilities cannot be forged; you cannot synthesise a port right out of a string the way you can synthesise a path string under Windows. The weakness is the split namespace: device objects live in the I/O Registry, services live behind launchd, and the kernel itself has no equivalent of \BaseNamedObjects as a one-stop shop.

7.3 Plan 9 from Bell Labs

Plan 9 is the design lineage Cutler imported. In Plan 9, every named operating-system resource -- including processes, network connections, devices, and the window system -- surfaces as a path served over 9P. The single hierarchical namespace was the central claim. Plan 9 never reached commercial scale, but its design idea reached production in three places: NT (1993, via Cutler), Linux's /proc, /sys, and FUSE (the 1990s onward), and the various capability-OS research projects (KeyKOS, EROS, seL4) that took the lessons in a different direction.

Primitive	Granularity	Enforcement point	Structural / opt-in	Bypass by privilege	Inheritance gap
Per-Session (NT)	Logon session	`ObpLookupObjectName` + DACL	Structural	`SeDebugPrivilege` short-circuit	Inherited handles cross sessions
AppContainer Lowbox (NT)	Package SID	`ObpLookupObjectName` rewrite	Structural	TCB privileges only	Brokered handles enter
Server Silo (NT)	Container	Process->Silo indirection	Structural	KMCS-signed driver	Host handles cross silos
VBS / IUM Trustlet (NT)	Trust level (VTL)	Hypervisor	Structural	Hypervisor compromise	Cross-VTL ALPC only
Mandatory Integrity Control (NT)	IL band	`SeAccessCheckByType`	Opt-in (per-object SACL)	`SeRelabelPrivilege`	Inherited handles bypass
`ObRegisterCallbacks` (NT)	Per-type, per-driver	Object Manager pre-op callback	Mediation, not partition	KMCS-signed driver	Inheritance bypasses callback
Private Namespace (NT)	Boundary SID-list	`NtCreatePrivateNamespace`	Structural	All SIDs in caller's token	Boundary-keyed
Linux Namespace	Per-resource clone	`setns`/`unshare`/`clone`	Structural	`CAP_SYS_ADMIN`	Fork inherits namespace set
Mach Port Right	Per-task	Capability check on send	Structural (capabilities)	`host_priv` / kernel	Inherited rights on fork

The Object Manager namespace is not a filesystem. There is no disk persistence, no journal, no FAT or MFT, no inode allocator, no per-file DACL in the filesystem sense. Nothing under `\` survives a reboot. Files-on-disk, registry-keys-in-a-hive, and named pipes are leaves in the OM tree, but the actual filesystem implementation lives in NTFS / ReFS / ExFAT drivers reached through the `Device` type's parse procedure.

What the OM namespace shares with filesystems is exactly three things: the path-walk algorithm (left-to-right, component-by-component, with one hash-table lookup per component), the per-directory hash table (analogous to the directory-entry hash filesystems use), and the per-object security descriptor (which the SRM enforces at the same point a filesystem would enforce its DACL).

When you read or write the phrase "Object Manager namespace," the metaphor that is doing real work is "in-memory directory tree the kernel uses to find named objects," not "filesystem in the disk-format sense."

The Windows 2000-era `CreateRestrictedToken` primitive was the wrong layer in 2000 as a standalone sandboxing mechanism -- it could not partition the namespace; it only filtered the caller's SID set against per-object DACLs. Chromium revived it in 2008 as one of four cooperating layers, and that pattern is the canonical 2026 production sandbox shape. The Chromium design document captures the constraints: "The Windows sandbox is a user-mode only sandbox. There are no special kernel mode drivers... The sandbox is provided as a static library that must be linked to both the broker and the target executables" (Chromium Sandbox Design [@chromium-sandbox-md], FAQ [@chromium-sandbox-faq]).

The four layers compose pairwise-orthogonally. The token gates which DACLs the renderer can satisfy at SeAccessCheck time; the job object gates which kernel API surface the renderer can call (UI exceptions, process creation, etc.); the integrity level gates which writes the renderer can perform across MIC label boundaries; the AppContainer lowbox-rewrites every named-object lookup into the per-package directory inside ObpLookupObjectName. A handle that survives all four checks is the only object the renderer can usefully touch. The load-bearing header is sandbox_policy.h, which declares TargetConfig::SetTokenLevel(TokenLevel initial, TokenLevel lockdown), SetJobLevel, SetIntegrityLevel, SetDelayedIntegrityLevel, and SetAppContainerSid, with one verbatim mutual-exclusion note: "Using an initial token is not compatible with AppContainer" [@chromium-sandbox-policy-h].

This is the 2026 production sandbox shape every Chromium-based browser inherits (Edge, Chrome, Brave, Vivaldi, Opera), as do Electron-based apps like Visual Studio Code's renderer processes.

The cross-VTL ALPC ports through which a VTL0 process talks to a VTL1 trustlet are still located in VTL0's `\RPC Control`. An attacker who controls VTL0 can *send* messages to LsaIso even though they cannot *read* LsaIso's internal state. Oliver Lyak's December 2022 *Pass-the-Challenge* result is the canonical worked example ([GitHub: ly4k/PassTheChallenge](https://github.com/ly4k/PassTheChallenge)): the trustlet's pages are never read, but the trustlet's RPC output exfiltrates the secret. The lesson is that VTL1 isolation is a *page-level* read barrier, not a *protocol-level* containment property. The VBS Trustlets piece in this corpus carries the deeper walkthrough.

Windows bet on one tree; Linux bet on eight clone-flag dimensions; Darwin bet on capability-style port-right tables. Each bet has theoretical limits. What are they?

8. What the namespace cannot do

The frame for this section comes from James P. Anderson's 1972 USAF technical report Computer Security Technology Planning Study (ESD-TR-73-51), Section 4.1.1. Anderson is the named originator of the reference-monitor concept and of the four properties such a monitor must satisfy. Wikipedia preserves the modern acronym verbatim: the reference-validation mechanism must be "Non-bypassable... Evaluable... Always invoked... Tamper-proof," and "according to Ross Anderson, the reference monitor concept was introduced by James Anderson in an influential 1972 paper" [@wikipedia-reference-monitor]. The NIST CSRC mirror hosts the original PDF [@csrc-nist-ande72].

Saltzer and Schroeder's 1975 paper The Protection of Information in Computer Systems [@cs-virginia-saltzer-schroeder] added the complete-mediation principle -- "every access to every object must be checked for authority" -- and seven other design principles the reference-validation mechanism must satisfy (economy of mechanism, fail-safe defaults, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability).

Map the Windows Object Manager against the four NEAT properties and the answer is uncomfortable. The namespace partially achieves two (Always-invoked and Tamper-proof), fails Non-bypassable outright, and falls one to two orders of magnitude short of Evaluable.

8.1 Always-invoked: provably gapped

The namespace achieves always-invoked for name-based opens. Every Nt*OpenObject* syscall walks ObpLookupObjectName; there is no path that returns a handle to a named object without going through the lookup. But the namespace cannot achieve always-invoked for handle inheritance. A child process inherits handles from CreateProcess(bInheritHandles=TRUE) without going through the OM at all. The handles already exist in the parent's HANDLE_TABLE; the kernel walks the parent's table, duplicates the entries into the child's table, and the child has live access. No name-lookup, no ObRegisterCallbacks callback, no SRM check. As long as the OS API exposes handle inheritance -- and it is too deeply embedded in 33 years of shipping Windows code to remove -- the Object Manager cannot be the sole reference monitor.

8.2 Tamper-proof: bounded, not absolute

The Object Manager runs in ring 0, under Kernel-Mode Code Signing (KMCS), and -- on machines with Virtualization-Based Security and Hypervisor-protected Code Integrity (HVCI) enabled -- inside a Hyper-V-enforced code-integrity policy. Any kernel-mode adversary who can load a driver bypasses the OM. KMCS and HVCI raise the cost; they do not eliminate the surface. The Bring-Your-Own-Vulnerable-Driver class of attacks (signed but exploitable drivers) is the running residual class, and the historical pattern is that one or two new vulnerable signed drivers surface every quarter.

8.3 Evaluable: provably above threshold

A small enough TCB can be machine-verified. The seL4 microkernel is the canonical demonstration: roughly 9,000 lines of C verified end-to-end against a formal specification (~11 person-years for initial functional correctness per Klein et al. SOSP 2009, and approximately 25 person-years for the full suite of subsequent proofs including information-flow and binary verification) [@sel4-project]. The Object Manager subsystem, the Security Reference Monitor, and the parse procedures the Object Manager delegates to (file-system drivers via IopParseDevice; the registry via CmpParseKey; ALPC; the I/O manager itself) collectively comprise tens of thousands of lines of C, putting the TCB for "open a named object" at one to two orders of magnitude above the verification threshold any current proof system can handle. The Object Manager is not evaluable in the formal sense Anderson required.

8.4 Non-bypassable: the privilege short-circuit

A process holding SeDebugPrivilege (or any privilege that grants PROCESS_VM_* rights) can short-circuit per-directory ACLs. The privilege evaluation happens at SeAccessCheck time, after ObpLookupObjectName has resolved the name. The Object Manager will resolve any path the privileged caller asks for; the gate fires, but it lets the call through. The namespace cannot defend against the holder of SeDebugPrivilege. This is by design -- you want a debugger to be able to attach to anything -- but it is also the structural reason why "lock down the namespace" is not by itself a containment story.

8.5 What else the namespace cannot do

It cannot prevent in-process memory disclosure -- the Pass-the-Challenge limit covered in the Section 7 aside. It cannot defend against a malicious driver -- KMCS, HVCI, and WDAC gate driver load; the namespace itself trusts already-loaded drivers. It cannot eliminate time-of-check / time-of-use racing during a path walk; the walker walks components one at a time, and any reentrant call into the walker is a TOCTOU surface. The mitigation is per-call -- callers pass OBJ_DONT_REPARSE on object-attributes, FILE_FLAG_OPEN_REPARSE_POINT on file opens, or otherwise instruct the path-walker to refuse symbolic-link substitution -- not a structural property of the namespace.

8.6 The honest accounting

The Object Manager namespace is a coordination mechanism, not a containment mechanism. Containment is in the layers above: the session ID, the package SID, the integrity level, the silo ID, the VTL split. The namespace's job is to make those layers enforceable by partitioning the path space so the bad open cannot resolve to the privileged object's name. The layers above decide which partition the caller is in; the namespace's only job is "given a path and a caller, find the object." Anderson 1972 names the kernel mechanism (the reference-validation mechanism with NEAT properties); Saltzer-Schroeder 1975 names the design principles the mechanism must satisfy. The Object Manager is the Windows realisation; it inherits both the strengths and the limits.

The namespace is a coordination mechanism, not a containment mechanism. The containment is in the layers above.

Key idea: The Object Manager is the coordination layer; the containment is in the partition primitives stacked on top (session ID, package SID, integrity level, silo ID, VTL). The namespace's only job is "given a path and a caller, find the object." Every Windows security boundary is a parameter to that one job: a per-directory ACL, a token-keyed name rewrite, or a kernel callback registered against an OBJECT_TYPE.

The provable gaps are real. What is the active research direction in 2026 -- where do attackers and defenders actually meet inside the namespace today?

9. Open problems in 2026

Five open problems sit in active research as of 2026.

9.1 Hash-bucket collision pressure

The 37-bucket constant has not changed since 1993. On a 2026 Windows 11 25H2 machine with several hundred MSIX packages, each owning an \AppContainerNamedObjects\<package-sid>\ subtree, average chain lengths inside \Sessions\1\AppContainerNamedObjects exceed two and routinely run higher under load. The structural impact is small per-lookup (O(chain length) at each component), but it compounds across deep path walks and across the per-VM hot loops in ObpLookupObjectName. Microsoft has not committed to a larger table or a different structure; the constant remains.

9.2 Cross-AppContainer object-directory privacy

Per-AppContainer isolation is the AppContainer model's promise; residual cross-package reads erode it. Forshaw's Project Zero work between 2017 and 2020 documents specific classes; Windows 11 25H2 DACLs are tighter than Windows 10 RTM, but the impersonation-mediated cases survive. The HackSys / CVE-2023-35359 family covered in Section 4.5 is the current realisation of the cross-AppContainer-plus-impersonation surface, and the same broader resource-planting taxonomy Forshaw described in the 2017 Named Pipe Secure Prefixes post [@tiraniddo-named-pipe-secure-prefixes] is still rediscovered every year.

9.3 Silo-escape via routines that ignore silo attachment

Siloscape (June 7, 2021) showed that NtSetInformationSymbolicLink could retarget a silo-scoped symbolic link at a host-scoped path. Microsoft patched the specific function; the class -- kernel routines whose path resolution does not honour Process->Silo->RootDirectory -- remains open. Microsoft's long-standing position is that Server Silo is not a security boundary; Hyper-V Container is the security-boundary product. Container runtimes that depend on Server Silo for tenant isolation are knowingly running outside the supported boundary.

9.4 ObRegisterCallbacks erosion under HVCI

ObRegisterCallbacks requires a KMCS-signed driver, and on HVCI-enabled machines the binary must additionally be HVCI-compatible. Microsoft has progressively raised the compatibility bar -- preventing unsigned drivers, banning common runtime-patching idioms, and tightening the W^X policy. EDR vendors depend on the surface staying open; if HVCI's compatibility bar ever excludes the EDR kernel driver pattern, the in-kernel callback layer is at risk. The CrowdStrike Falcon Sensor outage of July 2024 made the brittleness of in-kernel EDR a public conversation. Microsoft's Defender for Endpoint and EDR-on-Linux eBPF projects point at alternative-mediation futures, but in-kernel ObRegisterCallbacks is still the primary credential-theft sensor.

Note: As attackers ship Hell's Gate / Halo's Gate / direct-syscall stubs to bypass userland EDR hooks, the kernel callback fires regardless. The arms race accordingly shifts to the access-mask-strip vs. impersonate-trusted-parent-PID layer inside the kernel callback itself, with both sides racing to define the right pre-operation policy for lsass.exe handle opens. Watch the Microsoft Security Response Center advisories and the EDR-vendor incident postmortems for the bleeding edge.

9.5 Public benchmark vacuum

No peer-reviewed benchmark compares per-call namespace-lookup cost across the Windows Object Manager, Linux namespaces, and Mach ports. Choice of namespace design at the OS level is a multi-decade commitment; the absence of an empirical comparison forces architecture decisions on theoretical-only grounds. The Linux Kernel Test Robot, the Phoronix Test Suite, and various academic systems-conference benchmarks measure adjacent properties (filesystem-call latency, system-call vector cost), but none publishes head-to-head numbers on the named-object-lookup hot path. This is an open invitation to systems researchers.

Five open problems is a research agenda, not a how-to. How do you actually look at this thing on your own machine?

10. Reading the namespace from a live system

Three tools cover the operational practice: Sysinternals WinObj, Forshaw's NtObjectManager PowerShell module, and WinDbg in kernel mode.

10.1 WinObj on a live system

Download winobj.exe from Sysinternals [@ms-winobj] and run it as administrator. The left pane is the directory tree; the right pane shows the children of the selected directory with their object types. Navigate to \Sessions\1\BaseNamedObjects and read off the named events and mutants every Win32 app in your interactive session has created. Navigate to \Sessions\1\AppContainerNamedObjects and pick an S-1-15-2-... directory; right-click, choose Properties, and read the security descriptor. You will see a single allow-ACE granting full access only to the package SID itself. That ACE is the entire AppContainer sandbox at the namespace layer.

Note: WinObj cannot traverse \ObjectTypes, \Security, or \Sessions\0\ without administrator rights. Without traversal, the enumerate fails silently and the tree looks empty. Always run elevated, and accept that the tool will show the kernel view, not a per-process view.

10.2 NtObjectManager PowerShell

NtObjectManager is Forshaw's PowerShell module that exposes the Object Manager namespace through cmdlets (PowerShell Gallery [@powershellgallery-ntobjectmanager]; GitHub [@p0-sandbox-attacksurface-analysis-tools]). Install with Install-Module NtObjectManager. Useful commands: Get-ChildItem NtObject:\ walks the root; Get-NtType lists the registered OBJECT_TYPE singletons; Get-NtObject \BaseNamedObjects enumerates the global BNO; Get-NtAlpcPort '\RPC Control' lists every LRPC endpoint on the machine. The module wraps the same NTDLL syscalls WinObj uses, but in a scripting surface that composes into automation.

10.3 WinDbg kernel session

In a kernel-mode WinDbg session attached to a target machine (or to a live local kernel via Microsoft's local-kernel debug mode), !object \ dumps the root directory and its children. dt nt!_OBJECT_HEADER <addr>-30 reads the header preceding any object's body (the offset 0x30 is the size of OBJECT_HEADER on x64; subtract that from the body pointer to land on the header -- the field layout is documented in Windows Internals 7th Edition* Chapter 8, Microsoft Press Store [@microsoftpressstore-wininternals7-part1]). `dx -r1 ((nt!_OBJECT_TYPE)nt!PsProcessType[0]).TypeInfo` walks the Process type's method table and lists all eight procedure pointers and the WaitObjectFlagOffset, including the parse procedure.

10.4 The EDR primitive: an ObRegisterCallbacks driver template

The minimal sketch of an in-kernel EDR sensor is four steps. Register an OB_CALLBACK_REGISTRATION for PsProcessType with OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE [@ms-obregistercallbacks]. In the pre-operation callback, examine OperationInformation->Object, derive the target process's PID, and compare it against lsass.exe. If it matches, strip credential-relevant access bits from OperationInformation->Parameters->CreateHandleInformation.DesiredAccess (or duplicate-handle equivalent). The kernel grants the handle with the reduced rights, the attacker's PROCESS_VM_READ is gone before the call returns, and the post-operation callback logs the attempt. The parallel API PsSetCreateProcessNotifyRoutineEx [@ms-pssetcreateprocessnotifyroutineex] covers process creation, which is the other half of the EDR sensor surface.

sequenceDiagram participant A as Attacker process participant NT as nt!NtOpenProcess participant OM as Object Manager participant EDR as EDR Pre-Op Callback participant LSASS as lsass.exe (target) A->>NT: NtOpenProcess(lsass PID, PROCESS_VM_READ | PROCESS_QUERY_INFORMATION) NT->>OM: lookup PsProcessType, target by PID OM->>EDR: fire pre-op callback (handle create) EDR->>EDR: target == lsass.exe? EDR->>EDR: strip PROCESS_VM_READ from DesiredAccess EDR-->>OM: granted = PROCESS_QUERY_LIMITED_INFORMATION OM-->>NT: HANDLE with reduced access NT-->>A: open succeeded (but useless rights)

{` const PROCESS_VM_READ = 0x0010; const PROCESS_VM_WRITE = 0x0020; const PROCESS_VM_OPERATION = 0x0008; const PROCESS_QUERY_INFORMATION = 0x0400; const PROCESS_QUERY_LIMITED_INFORMATION = 0x1000; const PROCESS_CREATE_THREAD = 0x0002; const PROCESS_DUP_HANDLE = 0x0040;

function stripForLsass(desired) { const STRIPPED = PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_VM_OPERATION | PROCESS_CREATE_THREAD | PROCESS_DUP_HANDLE | PROCESS_QUERY_INFORMATION; return desired & ~STRIPPED; }

const desired = PROCESS_VM_READ | PROCESS_QUERY_INFORMATION | PROCESS_DUP_HANDLE; console.log('attacker asked for:', '0x' + desired.toString(16)); const granted = stripForLsass(desired) | PROCESS_QUERY_LIMITED_INFORMATION; console.log('EDR pre-op granted:', '0x' + granted.toString(16)); `}

```c OB_OPERATION_REGISTRATION op = { .ObjectType = PsProcessType, .Operations = OB_OPERATION_HANDLE_CREATE | OB_OPERATION_HANDLE_DUPLICATE, .PreOperation = MyPreOp, .PostOperation = MyPostOp, }; OB_CALLBACK_REGISTRATION reg = { .Version = OB_FLT_REGISTRATION_VERSION, .OperationRegistrationCount = 1, .Altitude = RTL_CONSTANT_STRING(L"123456"), .OperationRegistration = &op, }; ObRegisterCallbacks(®, &g_handle); ``` The driver must be KMCS-signed (`IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY`) per the wdm.h documentation; an unsigned image returns `STATUS_ACCESS_DENIED` from `ObRegisterCallbacks`. Two drivers cannot pick the same Altitude; collisions return `STATUS_FLT_INSTANCE_ALTITUDE_COLLISION`.

You can now read the namespace, register an EDR-style callback, and dump the type registry. What are the questions readers ask after they finish reading?

11. Frequently asked questions

No. The registry is a separate Windows Executive subsystem implemented in `nt!Cm*`, with its own hive on-disk format and its own in-memory hive structures. It hooks into the Object Manager namespace through one and only one mechanism: the `Key` `OBJECT_TYPE` registers a `ParseProcedure` (`CmpParseKey`) that takes over path walking when the namespace walker reaches `\REGISTRY`. The registry is therefore a *consumer* of the Object Manager, but not part of the Object Manager. Because `\BaseNamedObjects` is the *global* / `Global\`-prefixed-only view, distinct from the per-session BNO at `\Sessions\\BaseNamedObjects`. The Win32 `Local\` prefix routes through `kernel32!BaseGetNamedObjectDirectory` into the per-session BNO; `Global\` routes into the global one [@ms-termserv-kernel-object-namespaces]. Cross-session named-object coordination still needs the global view; per-session isolation lives in the per-session subtree. Because the lowbox token attached to the UWP app's process tells `ObpLookupObjectName` to rewrite the path to `\Sessions\\AppContainerNamedObjects\\Global\Foo` before path walking. Two different UWP apps have two different package SIDs and therefore land on two different directories. The Win32 names look the same; the kernel resolves them to different objects. `\??\C:` is the per-session DosDevices alias; if `C:` is not defined in the current session's `\??`, the walker falls through to `\GLOBAL??\C:`. `\GLOBAL??\C:` is the machine-wide DosDevices symbolic link to `\Device\HarddiskVolume*` -- the real on-disk volume object. The split matters because the per-session `\??` is where per-session drive-letter remappings (`net use X: \\server\share`, `subst Z: C:\foo`, `DefineDosDevice`) live, and the activation-context resolver class covered in Section 4.5 is the exploit family that lives at this boundary. Several top-level directories have `Directory`-`TRAVERSE` ACLs that restrict to SYSTEM and the local Administrators group. Without traversal, the directory enumeration silently fails. `\ObjectTypes`, `\Security`, and `\Sessions\0\` are the directories users most often notice as "missing" when running unelevated. By DACL plus loader-side validation. The directory grants `Directory`-`READ` to everyone but `Directory`-`WRITE` only to SYSTEM and TrustedInstaller. The `Section` objects inside are Authenticode-signed by Microsoft and validated at boot by `smss.exe`. The historical `DefineDosDevice` + `\??` symlink-plant bypass class survived until Windows 10 21H2 build 19044.1826 (July 2022), when an NTDLL patch closed it [@itm4n-the-end-of-ppldump]. `ObRegisterCallbacks` [@ms-obregistercallbacks] and `PsSetCreateProcessNotifyRoutineEx` [@ms-pssetcreateprocessnotifyroutineex] are both fully documented. The HVCI compatibility requirements, the KMCS attestation flow, and the exact policy interactions with Defender for Endpoint's tamper-protection layer are partly implementation-defined; EDR vendor engineering teams maintain private regression suites against successive Windows feature updates. When two or more processes that don't share a session or package must coordinate over a securable directory keyed by a SID-list they agree on at design time. The boundary descriptor is the *agreement primitive*: the kernel requires every SID in the boundary to be in the caller's token. The namespace's `OBJECT_DIRECTORY` lives in `\BNOLINKS`, keyed by the alias-prefix string plus a hash of the boundary descriptor's SID-list (CreatePrivateNamespaceW [@ms-createprivatenamespacew]; Object Namespaces overview [@ms-object-namespaces]; native NtCreatePrivateNamespace [@ntdoc-ntcreateprivatenamespace] and OBJECT_BOUNDARY_DESCRIPTOR [@ntdoc-object-boundary-descriptor] signatures). From inside an AppContainer process the lookup is rewritten into the per-package subtree, so private namespaces are not a substitute for the `windows.applicationModel.*` brokered APIs when cross-package coordination is the goal. A user-mode structure produced by `CreateBoundaryDescriptor` and populated with `AddSIDToBoundaryDescriptor` (plus the optional `CREATE_BOUNDARY_DESCRIPTOR_ADD_APPCONTAINER_SID` flag). Conceptually the descriptor is a SID-list that the caller and every other participant must share via their tokens. Kernel-side the structure is `OBJECT_BOUNDARY_DESCRIPTOR` (Version, Items, TotalSize, Flags). `NtCreatePrivateNamespace` materialises a directory in `\BNOLINKS` keyed by the `lpAliasPrefix` plus a hash of the boundary descriptor's SIDs.

12. Coming back to the WinObj screen

Open WinObj one more time. Navigate back to \Sessions\1\AppContainerNamedObjects and pick the Edge renderer's S-1-15-2-... directory. You can now name everything you are looking at. The directory is an _OBJECT_DIRECTORY instance with 37 hash buckets. You reach it through a token-keyed rewrite that the kernel applies inside ObpLookupObjectName before path walking begins. Its security descriptor grants GenericAll only to the package SID. Every EDR loaded on this machine has registered an ObRegisterCallbacks filter on PsProcessType, watching for handle creations against lsass.exe. If you are running on a Server SKU with Windows Server Containers, the directory might also be silo-scoped, with Process->Silo->RootDirectory indirecting your view of the rest of \.

The four pieces of the 1993 Cutler design have shipped without architectural change for thirty-three years. The six generations of partition primitives stacked on top are all simultaneously load-bearing on Windows 11 25H2. The namespace itself is a coordination mechanism, in Anderson 1972's sense of the reference-validation mechanism, with Saltzer-Schroeder 1975's complete-mediation principle as the design constraint it must satisfy. Containment lives in the partition layers above it: the session, the package, the integrity level, the silo, and the VTL split. Every other article in this corpus -- the Credential Guard piece, the AppContainer piece, the VBS Trustlets piece, the Hyper-V piece, the App Identity piece, the TPM piece -- quietly assumes this tree underneath them.

Key idea: Every Windows security boundary is a path rewrite, a per-directory ACL, a token-keyed name substitution, or a kernel callback against an OBJECT_TYPE. The Object Manager is the data structure underneath them all.

**Key terms.** Object Manager (`Ob`), `OBJECT_HEADER`, `OBJECT_TYPE`, `ParseProcedure`, `OBJECT_DIRECTORY`, Lowbox token, AppContainer, Server Silo, Trustlet / IUM, Boundary descriptor, Session 0 isolation, Mandatory Integrity Control, `ObRegisterCallbacks`, KMCS, HVCI, `\BaseNamedObjects`, `\Sessions\\AppContainerNamedObjects`, `\RPC Control`, `\KnownDlls`, `\BNOLINKS`, `\GLOBAL??`, `\??`.

Review questions.

Why does AppContainer isolation work even when the calling UWP app explicitly asks for Global\X?
What is the relationship between IopParseDevice, \Device\HarddiskVolume1, and IRP_MJ_CREATE?
Which of Anderson 1972's four NEAT properties does the Object Manager achieve cleanly, and which does it provably fail?
Why is ObRegisterCallbacks an enforcement gate only against handle creation and duplication, not against handle use?
Why does the canonical MS15-090 OM-symlink CVE point at CVE-2015-2428 [@nvd-cve-2015-2428] rather than CVE-2015-2528 or CVE-2015-1463?
What is the structural difference between \??\C: and \GLOBAL??\C:, and which one does the HackSys / CVE-2023-35359 worked example abuse?

Recommended reading. Russinovich, Ionescu, and Solomon, Windows Internals, Part 1 (7th edition, Microsoft Press, 2017), Chapter 8 [@microsoftpressstore-wininternals7-part1]. James Forshaw, Windows Security Internals (No Starch Press, 2024), Chapter 8 [@nostarch-windows-security-internals]. Alex Ionescu, Battle of SKM and IUM, Black Hat USA 2015 [@ionescu-bh2015-pdf]. The Google Project Zero blog's symlink mitigations [@p0-symlink-mitigations], arbitrary directory creation [@p0-issue1550], and who contains the containers [@p0-who-contains-containers] posts. James P. Anderson, Computer Security Technology Planning Study [@csrc-nist-ande72].