VBS Trustlets: What Actually Runs in the Secure Kernel

1. Four Locked Rooms#

It is 3:14 a.m. and a red-team operator on a fully patched Windows 11 25H2 box has, after eight hours of careful work, achieved the prize: a SYSTEM-privilege write primitive in the NT kernel. For two decades that has been the moment when the engagement ends and the report writes itself. SYSTEM in the kernel meant every process, every page, every secret. Game over.

It is not game over.

The operator's target list has four items on it. The NTLM hashes and Kerberos Ticket-Granting Tickets sitting in lsass.exe. The user's fingerprint template, in whatever process the Windows Hello biometric pipeline puts it. The just-in-time admin token that Administrator Protection issued thirty seconds ago. The keys of the four Hyper-V virtual machines running on the box, including the one hosting the user's corporate VPN. Four secrets. Four user-mode processes. And on this 2026 machine, four locked rooms whose pages the operator's kernel write primitive cannot touch and whose contents the operator's kernel does not have permission to ask.

Those four processes are trustlets. They run in a different kernel from the one the operator just compromised, on a different virtual trust level enforced by a hypervisor running underneath both. The operator owns the NT kernel; the NT kernel does not own them. That sentence is what changed in 2015, and the rest of this piece is what it actually means.

This is not "Microsoft hid the memory better." It is not obfuscation, not a clever access-control rule, not a kernel mitigation that the next CVE will erase. It is an architectural relocation: the user-mode processes that hold the secrets no longer live in the operating system the attacker compromised. The hypervisor refuses to map their pages into Virtual Trust Level 0 ("VTL0"), and the operator's kernel is in VTL0.

Four user-mode processes survive a SYSTEM kernel write primitive on a 2026 Windows 11 box. That is what changed in 2015, and trustlets are the reason.

The promise of this piece is to explain trustlets at the level of "what does LsaIso.exe actually do, how is it built, how does it talk to the rest of the system, and where does the model end." Not at the level of "VBS isolates them." By the end, four locked rooms will have become something you can name, list, audit, and reason about. Where the public record runs out (some trustlet binary names and IDs are not on Microsoft's published list as of mid-2026), the piece will say so, and it will tell you what the actual records look like instead of inventing replacements.

So how does a user-mode process become unreachable from SYSTEM-in-the-NT-kernel? The answer is not new. It begins, like much of operating-system security, at MIT in the early 1970s.

2. The User-Mode-In-A-Higher-Privilege Problem#

In March 1972 Michael Schroeder and Jerome Saltzer published a paper in the Communications of the ACM describing an unusual machine. The Multics team at MIT had been wrestling with a question that does not, at first glance, sound like a security question. What should happen when a user program calls a password-checking routine that needs to read the system password file? The user program must not be allowed to read that file directly. The routine must be allowed to read it. The two pieces of code run in the same process. How does the machine know which one is asking?

Schroeder and Saltzer's answer was eight hardware-enforced rings of privilege, with each segment in memory carrying a ring bracket in its descriptor word, and with cross-ring calls validated automatically by the hardware ^{[1] [2]}. The hardware that shipped this design was the Honeywell 6180 in 1973 ^[3]. The pattern matters more than the gear. Some user code needed to run with more privilege than its caller and less privilege than the kernel. Multics arranged eight such layers from user code at the outermost ring down to the supervisor at ring 0 ^[4].

A few years later at Carnegie Mellon, William Wulf, Roy Levin, and the Hydra team took a different swing at the same problem. Hydra was a capability-based, object-oriented microkernel that ran on the C.mmp multiprocessor between 1971 and 1975 ^[5]. Where Multics multiplied rings, Hydra multiplied vocabulary: every protected resource was an object addressable only through capability tokens, and security-critical subsystems lived not inside the kernel but as user-mode capability-holders trusted by the kernel to enforce their own policy. Levin et al.'s 1975 SOSP paper "Policy/Mechanism Separation in HYDRA" gave the design its slogan, and that slogan has outlived the system that produced it ^[6].

For two decades the L4 family answered "but is this fast enough to be practical?" Jochen Liedtke's 1993 prototype, hand-coded in i386 assembly, ran inter-process communication twenty times faster than Carnegie's Mach microkernel ^[7]. His 1995 SOSP paper "On µ-Kernel Construction" was inducted into the ACM SIGOPS Hall of Fame in 2015 and is the foundational statement of the minimal-kernel, maximal-user-mode-trusted-services design. By the mid-2000s OKL4, a commercial L4 derivative, was shipping in billions of mobile devices ^[7].

In 2009 the lineage reached an end that nobody had reached before. Gerwin Klein, Kevin Elphinstone, Gernot Heiser and the NICTA team published seL4: Formal Verification of an OS Kernel at SOSP, reporting a machine-checked proof of functional correctness from a formal specification down to the C implementation ^[8]. seL4 was open-sourced in July 2014 ^[9]; the seL4 Foundation's About page states plainly that seL4 stands out because of its thoroughgoing formal verification ^[10]. A kernel of about ten thousand lines of C, proved correct down to the byte, with sub-microsecond inter-process calls.

Schroeder and Saltzer asked it for hardware rings. Hydra asked it for capabilities. Liedtke asked it for inter-process speed. Klein and Heiser asked it of formal logic. The question stayed the same: how do you let some user-mode code hold a secret that some other code in the same machine is not allowed to read, when both pieces of code are scheduled by the same kernel? The Multics answer was rings. The Hydra answer was capabilities. The L4 answer was a tiny kernel plus IPC. The seL4 answer was a tiny kernel plus IPC, plus a proof.

The Microsoft answer, in July 2015, was a hypervisor.

timeline
title User-mode-in-higher-privilege lineage
1972 : Multics 8-ring hardware
: Honeywell 6180 ring brackets
1974 : Hydra capabilities
: Policy vs mechanism
1993 : L4 microkernel
: Fast user-mode IPC
: Windows NT ships ring 0/3
2007 : Vista Protected Processes
2009 : seL4 verification
2013 : Windows 8.1 PPL
2015 : Windows 10 IUM ships
: Trustlets 0-3 enumerated
2024 : VBS Enclaves go third-party
2026 : Administrator Protection

If the architectural answer was already in the 1970s academic literature, why did Microsoft wait until 2015 to ship it on Windows? Because three earlier attempts to ship user-mode isolation on Windows -- under three different names, in three different decades -- each failed in the same way.

3. Three Tries Before Trustlets#

Before 2015 Microsoft tried three times to ship user-mode isolation on Windows. All three shipped in production. All three failed in the same way.

2007: Vista Protected Processes#

Windows Vista introduced Protected Processes in January 2007. The motivation was not credential security; it was Digital Rights Management. The Protected Media Path required a set of binaries -- audiodg.exe, mfpmp.exe, and a handful of others involved in Blu-ray playback -- whose memory non-protected processes could not read, whose threads could not be debugged from outside, and whose DLL imports could not be hijacked at runtime ^[11]. The kernel enforced these rules by refusing to grant the relevant access masks (PROCESS_VM_READ, PROCESS_VM_WRITE, THREAD_ALL_ACCESS) to handles requested from non-protected processes.

The mechanism was elegant. The threat model was not. Alex Ionescu announced in January 2007 -- within weeks of Vista's general availability -- that he had developed a bypass method for the Protected Media Path ^[11]. The same NT kernel that enforced the protection was the kernel an attacker would compromise to bypass it. A signed kernel driver, or any of the long stream of subsequent kernel vulnerabilities, would walk straight through.

2012: AppContainer and the LowBox token#

Windows 8 introduced AppContainer process isolation in October 2012, originally to support Universal Windows Platform store apps ^[12]. Each AppContainer process ran with a LowBox token: a low-integrity primary token plus a SID, plus a set of named capabilities (internetClient, picturesLibrary, and so on), plus a per-AppContainer named-object subtree under \Sessions\<N>\AppContainerNamedObjects\<SID>. The NT kernel checked the SID against object DACLs at every object access, denying access by default and granting it only where the AppContainer's declared capabilities matched the requested operation.

This is a Hydra-style capability lattice bolted onto NT's existing access-control system. It is a useful sandboxing primitive for untrusted code, and modern browsers (the Edge renderer, the Chromium sandbox) consume it for exactly that purpose. It is not a defence against an attacker who already has kernel code execution. In August 2018 James Forshaw at Google Project Zero published an exploit for Issue 1550 that turned the AppContainer named-object namespace itself into an arbitrary-directory-creation primitive ^[13]:

The AppInfo service... calls the undocumented API CreateAppContainerToken... As the API is called without impersonating the user... the object directories are created with the identity of the service, which is SYSTEM.

A low-integrity caller could direct that SYSTEM-owned creation at any directory it pleased and use the result to elevate. The lattice held; the lattice's enforcer did not. AppContainers continue to ship, doing their actual job (sandboxing untrusted code) reasonably well. They were never going to answer the trustlet question (isolating trusted code from a compromised kernel) because they are NT-kernel-enforced.

2013: Protected Process Light (PPL) and RunAsPPL#

Windows 8.1 generalised the Vista mechanism into a signer-level lattice. Each protected process now had a two-dimensional protection level: a signer (WinTcb, Windows, Antimalware, Authenticode, others) and a protection type (PsProtectedSignerTcb, PsProtectedSignerAuthenticode, others). Higher-signer processes could manipulate lower-signer ones; same-signer processes could not see across the line. The first canonical use case was anti-malware services that registered an Early Launch Anti-Malware (ELAM) driver and then ran their user-mode service as a Protected Process Light ^[14].

Alex Ionescu's 2013 essay "The Evolution of Protected Processes Part 3" documented the resulting Signing Levels table -- Signature Level 12 named "Windows," Level 13 "Windows Protected Process Light," Level 14 "Windows TCB" ^{[16] [17]}. That table is the load-bearing reference for every later trustlet design: every IUM binary on a 2026 Windows machine must satisfy at least Signature Level 12. Microsoft shipped LSASS-as-PPL ("LSA Protection," exposed through the RunAsPPL registry value under HKLM\SYSTEM\CurrentControlSet\Control\Lsa) as the canonical example: a way to keep the lower-privileged half of an administrator's session from reading credential material out of LSASS memory.

It worked, for some values of "worked." It worked against pass-the-hash tools that ran as an ordinary administrator without a signed kernel driver. It did not work against an attacker willing to load any signed driver, and -- as became clear in 2021 -- it did not work even from userland once the bypass class was identified.

In August 2018 James Forshaw, in the same Project Zero post that exposed the AppContainer issue, also documented a DefineDosDevice plus Known-DLL hijack technique. By creating a symbolic link in the NT object manager namespace that aliased a Known DLL section, an administrative caller could induce a target PPL process to load arbitrary code at the next image load ^[13]. In 2021 the researcher who blogs as itm4n weaponised the same primitive into PPLdump, a fileless userland tool that dumped lsass.exe memory from an administrator command prompt with no kernel driver involved ^[15]. itm4n's writeup is honest about what this means:

Like any other protection though, it is not bulletproof and it is not sufficient on its own, but it is still particularly efficient.

Microsoft closed the DefineDosDevice corner of this class in Windows 10 21H2 build 19044.1826, shipped in July 2022 ^[18]. That is nine years of mainstream PPL deployment during which the LSASS-as-PPL credential boundary was bypassable without ring 0 access at all.

The pattern#

Three primitives. Three different protection mechanisms. One common failure mode.

Three rows, one diagnosis. Every NT-kernel-enforced isolation primitive shares the attacker's TCB. Improving the lattice the NT kernel enforces does not move the security ceiling, because the NT kernel itself can be compromised; once it is, any policy decision the NT kernel makes is the attacker's policy decision. Microsoft's own VBS hardware-requirements page admits the diagnosis verbatim:

"VBS uses hardware virtualization and the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised." -- Microsoft, OEM VBS hardware requirements ^[20]

If every primitive the NT kernel enforces shares the attacker's TCB, the kernel that enforces user-mode isolation has to be a different kernel. In July 2015 Microsoft shipped one.

4. July 2015: The Hypervisor Becomes the Arbiter#

On 29 July 2015 Microsoft shipped Windows 10 build 10240 ^[21]. Two new ideas shipped with it. The first was Hyper-V's hypervisor running underneath the NT kernel even on a laptop, not just on a server hosting virtual machines ^[22]. The second was a separate kernel running alongside the NT kernel, at a different Virtual Trust Level. Together those two ideas produce a substrate where the long-time equation "SYSTEM kernel write primitive equals every secret in user-mode memory" is no longer true.

The Hyper-V Top-Level Functional Specification states the rule directly: "VSM achieves and maintains isolation through Virtual Trust Levels (VTLs)... Architecturally, up to 16 levels of VTLs are supported; however a hypervisor may choose to implement fewer than 16 VTL's. Currently, only two VTLs are implemented" ^[23]. The NT kernel runs in VTL0 ring 0; user-mode applications run in VTL0 ring 3. The Secure Kernel runs in VTL1 ring 0; trustlets run in VTL1 ring 3. Each VTL transition takes the CPU through a VMEXIT and back, with VMCS save and restore on each crossing ^[24].

Quarkslab's reverse-engineering team put the practical consequence in one sentence in their IUM-debugging writeup: "VTL0 is the Normal World, where the traditional kernel-mode and user-mode code run in ring 0 and ring 3, respectively. On top of that, a new world appears: VTL1 is the privileged Secure World, where the Secure Kernel runs in ring 0, and a limited number of IUM processes run in ring 3. Code running in VTL0, even in ring 0, cannot access the higher-privileged VTL1" ^[25].

That sentence is the architectural fact the whole article rests on. The hypervisor configures each guest physical page's permissions on a per-VTL basis using the CPU's Second Level Address Translation tables. A page can be readable from VTL0 and VTL1, readable from VTL1 only, or readable from neither. ※ On Intel hardware, the per-VTL permissions are implemented with Extended Page Tables (EPT); on AMD they use Nested Page Tables (NPT). The hypervisor keeps the per-VTL EPT/NPT entries in its own memory, not in the guest's.

flowchart LR
subgraph VTL0["VTL0 (Normal World)"]
ring3_0["Ring 3: lsass.exe, vmwp.exe, user apps"]
ring0_0["Ring 0: NT kernel + signed drivers"]
ring3_0 --> ring0_0
end
subgraph VTL1["VTL1 (Secure World)"]
ring3_1["Ring 3: LsaIso.exe, vmsp.exe, trustlets"]
ring0_1["Ring 0: Secure Kernel (securekernel.exe)"]
ring3_1 --> ring0_1
end
VTL0 -. ALPC over agent ALPC port .-> VTL1
VTL1 -. read VTL0 memory .-> VTL0
hv["Hyper-V hypervisor: per-VTL SLAT permissions"]
VTL0 --> hv
VTL1 --> hv

The VTL hierarchy is not symmetric. VTL1 code can read VTL0 memory; that is how a trustlet can dispatch the contents of an lsass.exe RPC request the moment after VTL0 wrote it. VTL0 code cannot read VTL1 memory under any condition the hypervisor permits. A kernel write primitive in VTL0 lets the attacker corrupt the NT kernel's data structures, modify drivers, and walk every VTL0 process's pages. The attacker can do every one of those things and not be one byte closer to the contents of LsaIso.exe.

Microsoft's IUM documentation at Windows 10 RTM named two trustlets explicitly: Trustlet ID 0 = the Secure Kernel Process (hosts Device Guard and Hypervisor-protected Code Integrity policy decisions), and Trustlet ID 1 = LSAISO.EXE (Credential Guard's isolated LSA, holding NTLM hashes and Kerberos Ticket-Granting Tickets out of VTL0 reach). Two more (IDs 2 and 3, covered in §6) also shipped on the RTM image and were enumerated a week later by Ionescu's Black Hat reverse-engineering ^{[26] [27]}. Microsoft Learn's IUM page introduces the vocabulary the rest of this piece will use:

Trustlets (also known as trusted processes, secure processes, or IUM processes) are programs running as IUM processes in VSM... With VSM enabled, the Local Security Authority (LSASS) environment runs as a trustlet.

A week after Windows 10 shipped, on 5 August 2015, Alex Ionescu walked into a Black Hat USA briefing room in Mandalay Bay and reverse-engineered the entire thing in front of an audience ^[28]. His talk, "Battle of the SKM and IUM: How Windows 10 Rewrites OS Architecture," is the canonical first public account of the trustlet model and the source from which Microsoft's own later documentation borrows terminology one for one ^[27]. Almost every concrete fact in the next section -- the syscall allow-list, the EKUs, the .tpolicy section, the Trustlet Instance GUID -- traces back to that single deck.

Now we know what world a trustlet lives in. What architecturally is one?

5. The Five Gates#

A trustlet is not a special process class the way a Protected Process is. It is an ordinary Portable Executable binary that has been loaded under five very specific conditions. Walk through them once and you will be able to recognise a trustlet in a dumpbin /headers listing. The status is mechanical, not categorical. Chapter 9 of Windows Internals, Seventh Edition, Part 2 (Allievi, Russinovich, Ionescu, Solomon) covers the same architecture from the kernel-team side as a reference complement to Ionescu's BH2015 reverse-engineering ^[29].

Gate 1: the process attribute#

VTL0 user-mode code cannot call CreateProcess and produce a trustlet. The Win32 API does not expose the necessary primitive. A trustlet is born via a direct NtCreateUserProcess syscall that carries a PsAttributeSecureProcess attribute with a 64-bit Trustlet ID. Only callers that already live in VTL1, or callers in VTL0 that hold a specific brokering capability, can request that attribute and have the Secure Kernel honour it ^[27].

This is intentional. The Win32 layering is one of the surfaces an attacker can compromise, so the trustlet boot path bypasses it. There is no "trustlet via shell" -- not for an administrator, not for SYSTEM, not for the Secure Kernel itself other than through the documented internal path.

Gate 2: two EKUs at Signature Level 12#

The binary must be signed with a certificate chain that contains two specific Enhanced Key Usage identifiers, and the resulting Signing Level must be 12 or higher. From Ionescu's BH2015 deck verbatim: "They must have a Signature Level of 12... This means they must have the Windows System Component Verification EKU (1.3.6.1.4.1.311.10.3.6)... They must have the IUM EKU 1.3.6.1.4.1.311.10.3.37" ^[27].

Both EKUs are required. The Windows System Component Verification EKU establishes the binary as a Microsoft-signed Windows component. The IUM EKU asserts the binary's intent to load as a trustlet. A PPL EKU may sit on top, layering the PPL signer-level check on the trustlet check, but the two-EKU minimum is what Signing Level 12 enforces.

Gate 3: the .tpolicy section and s_IumPolicyMetadata#

Every trustlet image must contain a PE section named .tpolicy marked IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ. The section must export the symbol s_IumPolicyMetadata, a structure with three required components: a version byte set to 1, a 64-bit Trustlet ID that must match the one the process attribute requested, and a per-trustlet policy table containing entries for ETW (event tracing), debug permissions, crash-dump key release, and other trustlet-specific runtime knobs ^[27].

The Secure Kernel parses this section at load time via an internal routine the deck names SkpspFindPolicy. A binary with no .tpolicy section, or with one whose Trustlet ID disagrees with the process-attribute Trustlet ID, or whose version byte is anything other than 1, fails the gate. The Secure Kernel does not "infer" a trustlet identity; it reads it out of the binary the attacker would have had to sign.

Gate 4: the Trustlet Instance GUID#

Once gates 1-3 pass, the trustlet calls a secure-service routine the deck names IumSetTrustletInstance, identified by secure-call ordinal 0x80000001. That routine binds the running process to a Trustlet Instance GUID, the runtime identity by which the Secure Kernel discriminates one instance of a trustlet from another. Hyper-V partition GUIDs flow into this identifier for the vTPM trustlets, so that the secrets a partition's vTPM holds are scoped to that partition's Instance GUID.

The same Instance GUID can be shared across distinct Trustlet IDs. That is the architectural primitive Microsoft uses for trustlet-to-trustlet authentication: the host-side Hyper-V vTPM (vmsp.exe, Trustlet ID 2) and the vTPM provisioning trustlet (ID 3) cooperate on a single partition's secrets by sharing the partition's Instance GUID. The Secure Kernel's SkCapabilities table hardcodes which Trustlet IDs are permitted to invoke which secure-storage operations against an Instance GUID; for the 2015-era IUM surface, the only ID-discriminated rules are CheckByTrustletId 2 for SecureStorageGet and CheckByTrustletId 3 for SecureStorageSet ^[27].

Gate 5: the stripped-down loader#

A trustlet's image loader is not the standard NT loader. The Secure Kernel routes trustlet loads through a path the deck names LdrpIsSecureProcess, which skips an unusually long list of features. Application Verifier hooks: skipped. Image File Execution Options registry checks: skipped. SxS / Fusion DLL redirection: skipped. The CSRSS connection ordinary NT processes establish during startup: skipped (the BASE_STATIC_SERVER_DATA structure CSRSS would normally hand back is fabricated locally on the trustlet's heap so dependent calls do not crash). Safer, AuthZ, Software Restriction Policies: all skipped. Any DLL load triggered from VTL0: refused.

The result is a loader path with no attack surface against VTL0 environment variables, no susceptibility to NT's normal "load this DLL instead" knobs, and no opportunity for the user's CSRSS process to inject anything into the trustlet's address space. The system-call surface available inside the trustlet is restricted to roughly fifty allowed entries. Ionescu's deck states the count verbatim: "Only 48 system calls are currently allowed from IUM Trustlets" ^[27].

sequenceDiagram
participant Caller as Caller (VTL1 or brokered VTL0)
participant NT as NtCreateUserProcess
participant CI as ci.dll (CipMincryptToSigningLevel)
participant SK as Secure Kernel (SkpspFindPolicy)
participant Ldr as LdrpIsSecureProcess
participant Iset as IumSetTrustletInstance
Caller->>NT: Create with PsAttributeSecureProcess + Trustlet ID
NT->>CI: Verify EKUs System Component plus IUM and Signing Level ge 12
CI-->>NT: Pass or fail
NT->>SK: Parse .tpolicy, validate s_IumPolicyMetadata
SK-->>NT: Pass or fail
NT->>Ldr: Strip down loader and deny VTL0-triggered DLL loads
Ldr-->>NT: Image mapped under IUM rules
NT->>Iset: Bind Trustlet Instance GUID
Iset-->>NT: Trustlet alive in VTL1

The pseudocode below walks each gate in order against a fake binary descriptor. It is not a loader, it is not an exploit, and it is not a security tool. It is a teaching aid: if you can read it, you can read the trustlet load path.

// Trustlet load-time gate check (educational pseudocode).
// Inspired by Ionescu BH2015 reverse-engineering of Win10 RTM (2015).
// Not a real loader; not a security tool.

const WINDOWS_SYSTEM_COMPONENT_EKU = "1.3.6.1.4.1.311.10.3.6";
const IUM_EKU                      = "1.3.6.1.4.1.311.10.3.37";
const MIN_SIGNING_LEVEL            = 12; // "Windows"

function loadTrustlet(bin) {
// Gate 1: process attribute
if (!bin.attr || !bin.attr.PsAttributeSecureProcess) {
  return "fail at gate 1: no PsAttributeSecureProcess attribute";
}
const requestedId = bin.attr.PsAttributeSecureProcess.trustletId;

// Gate 2: two EKUs at Signing Level 12+
const ekus = (bin.cert && bin.cert.ekus) || [];
if (!ekus.includes(WINDOWS_SYSTEM_COMPONENT_EKU)) {
  return "fail at gate 2: missing Windows System Component EKU";
}
if (!ekus.includes(IUM_EKU)) {
  return "fail at gate 2: missing IUM EKU";
}
if ((bin.cert.signingLevel || 0) < MIN_SIGNING_LEVEL) {
  return "fail at gate 2: signing level below 12";
}

// Gate 3: .tpolicy section with s_IumPolicyMetadata
const tpol = bin.sections && bin.sections[".tpolicy"];
if (!tpol || !tpol.exports || !tpol.exports.s_IumPolicyMetadata) {
  return "fail at gate 3: no .tpolicy section with s_IumPolicyMetadata";
}
const meta = tpol.exports.s_IumPolicyMetadata;
if (meta.version !== 1 || meta.trustletId !== requestedId) {
  return "fail at gate 3: malformed or mismatched s_IumPolicyMetadata";
}

// Gate 4: Trustlet Instance GUID (bound at runtime via IumSetTrustletInstance)
const instance = bin.runtime && bin.runtime.instanceGuid;
if (!instance) {
  return "fail at gate 4: no Trustlet Instance GUID bound";
}

// Gate 5: stripped-down loader (skip Application Verifier, IFEO, SxS, CSRSS,
// Safer, AuthZ, SRP; deny VTL0-triggered DLL loads).
// We don't simulate the loader here; we just refuse VTL0-injected DLL loads.
if (bin.loaderTriggers && bin.loaderTriggers.fromVtl0) {
  return "fail at gate 5: VTL0-triggered DLL load denied";
}

return "trustlet loaded: id=" + requestedId
     + " instance=" + instance;
}

// Smoke test.
const sample = {
attr:    { PsAttributeSecureProcess: { trustletId: 1 } },
cert:    { ekus: [
  "1.3.6.1.4.1.311.10.3.6",
  "1.3.6.1.4.1.311.10.3.37",
], signingLevel: 12 },
sections: { ".tpolicy": { exports: {
  s_IumPolicyMetadata: { version: 1, trustletId: 1 },
} } },
runtime: { instanceGuid: "<lsa-iso-instance>" },
loaderTriggers: { fromVtl0: false },
};
console.log(loadTrustlet(sample));

A trustlet is what passes all five gates. There is no other definition. Status is mechanical, not categorical: it is what the Secure Kernel's load path produces when a properly signed binary with a properly formed .tpolicy section calls NtCreateUserProcess with a proper secure-process attribute.

All five gates pass. The binary is now a trustlet. It is running in VTL1 user mode. The hypervisor refuses to map its pages into VTL0. Now what does it do? Who does it talk to?

6. The Inbox Roster#

Five gates. Pass them all and you become a trustlet. Microsoft passes them on behalf of -- as of mid-2026 -- this list.

The agent / trustlet pattern#

Before the roster, the pattern. Almost every shipping trustlet has a partner: an agent process in VTL0 that does the high-volume work of integrating with the rest of the operating system, and the trustlet itself in VTL1 holding the secret material. The two talk over an Asynchronous Local Procedure Call port whose server end is hosted by the trustlet.

flowchart LR
NetClient[Network or local client]
Agent["lsass.exe (VTL0 agent)
protocol parsing
session state
network I/O"]
SK["Secure Kernel
(VTL1 ring 0)
marshals secure calls"]
Trustlet["LsaIso.exe (VTL1 trustlet)
NTLM hashes
Kerberos TGTs
EncryptData / DecryptData"]
NetClient -->|"network protocol"| Agent
Agent -->|"ALPC: LSA_ISO_RPC_SERVER"| SK
SK -->|"IUM Base API"| Trustlet
Trustlet -->|"opaque blob"| SK
SK --> Agent

The roster below names the agent for each trustlet where Microsoft has published one. Where the agent is not publicly named, the row says so.

Trustlet ID 0 -- the Secure Kernel Process#

The first inhabitant of VTL1 user mode. Hosts Device Guard and Hypervisor-protected Code Integrity policy decisions. Architecturally close to a daemon: it does not service external clients; it provides services the Secure Kernel itself relies on for policy decisions about whether a given image is permitted to load in VTL0 ^[27].

Trustlet ID 1 -- LsaIso.exe (Credential Guard)#

The canonical trustlet. Holds NTLM hashes and Kerberos Ticket-Granting Tickets. Its agent in VTL0 is lsass.exe, the Local Security Authority Subsystem Service that has held those secrets directly for every version of Windows NT until 2015. The ALPC port name is LSA_ISO_RPC_SERVER. The IUM-side API the trustlet exposes is narrow: EncryptData and DecryptData on opaque blobs, plus a handful of internal management operations ^[30].

The Microsoft Learn explanation is the verbatim public account:

With Credential Guard enabled, the LSA process in the operating system talks to a component called the isolated LSA process that stores and protects those secrets, LSAIso.exe. Data stored by the isolated LSA process is protected using VBS and isn't accessible to the rest of the operating system. LSA uses remote procedure calls to communicate with the isolated LSA process ^[30].

A VTL0 caller -- including SYSTEM-in-the-NT-kernel -- can ask the trustlet to encrypt a freshly supplied credential or to authenticate a freshly received challenge. It cannot ask the trustlet to expose the underlying NTLM hash. The hash never leaves VTL1. That is the entire point.

Trustlet ID 2 -- vmsp.exe (Hyper-V vTPM, host side)#

The Hyper-V Virtual Trusted Platform Module on the host side. One vmsp.exe instance per guest partition; the agent is vmwp.exe, the Hyper-V Virtual Machine Worker Process for that partition. The Instance GUID is the partition's GUID, so that the keys a partition's vTPM holds are scoped to that partition and that partition only. Storage primitives include a Mailbox primitive (protected by a per-instance Security Cookie) and a Secure Storage primitive that produces Ingress and Egress blobs encrypted with per-Instance IDK material ^{[27] [31]}.

Shielded VMs on Windows Server 2016 and later consume vmsp.exe. A shielded VM, per Microsoft Learn, "has a virtual TPM, is encrypted using BitLocker, and can run only on healthy and approved hosts in the fabric" ^[31]. The vTPM keys live in the host's vmsp.exe trustlet; the BitLocker volume master key in the guest is sealed against that vTPM; and a SYSTEM-privilege NT-kernel write primitive on the host cannot read the partition's vTPM secrets even though the host can otherwise reach the partition's memory.

Trustlet ID 3 -- vTPM provisioning trustlet#

Pushes initial secrets into a partition's Instance GUID at vTPM creation time. The Secure Kernel's SkCapabilities array hardcodes CheckByTrustletId 2 for SecureStorageGet and CheckByTrustletId 3 for SecureStorageSet; those are the only Trustlet-ID-checked secure-storage operations in the 2015-era IUM secure-call surface ^[27]. The pair of trustlets cooperates on the same Instance GUID so the provisioning trustlet writes and vmsp.exe reads, with the Secure Kernel enforcing that no other trustlet can do either.

Enhanced Sign-in Security (ESS) biometric matching component (Windows 11+)#

Microsoft Learn documents the architectural placement of Windows Hello's facial-recognition algorithm verbatim:

When ESS is enabled, the face algorithm is protected using VBS to isolate it from the rest of Windows. The hypervisor is used to specify and protect memory regions, so that they can only be accessed by processes running in VBS. The hypervisor allows the face camera to write to these memory regions providing an isolated pathway... Sensors that support ESS have a certificate embedded during manufacturing ^[32].

The page also documents the certificate chain that authenticates the camera to the matcher and the match-on-sensor requirement for fingerprint readers under ESS. Microsoft does not publicly name the binary that hosts the face algorithm, and it does not publicly assign that binary a Trustlet ID. The architectural placement is a trustlet. The naming is not on the record.

Administrator Protection / Adminless issuer (Windows 11, rolling out 2025-26)#

In October 2025 Microsoft shipped a preview of Administrator Protection in KB5067036 ^[33] and reverted the rollout in the same update note ^[34]. The Microsoft Learn page describes the security model:

Once authorized, Windows uses a hidden, system-generated, profile-separated user account to create an isolated admin token. This token is issued to the requesting process and is destroyed once the process ends, ensuring that admin privileges don't persist. Administrator protection introduces a new security boundary with support to fix any reported security bugs ^[34].

The implementation surface that issues those tokens is not publicly named. The architectural family resemblance to a trustlet is strong, and the "new security boundary with support to fix any reported security bugs" line is the formal commitment Microsoft makes for VBS-isolated components. Whether the issuer is a trustlet, a VBS Enclave, or a separately isolated VTL0 process is, as of mid-2026, not on the public record.

Third-party VBS Enclaves (Windows 11 24H2 and later)#

For the first time since 2015, the trustlet primitive is exposed to third-party developers. A VBS Enclave is a DLL signed with a Trusted Signing certificate and loaded into a VTL1 enclave region of a host process via CreateEnclave and CallEnclave. The OS support is narrow:

Windows 11 Build 26100.2314 or later... Windows Server 2025 or later... Visual Studio 2022 version 17.9 or later... The Windows Software Development Kit (SDK) version 10.0.22621.3233 or later, which provides veiid.exe (the VBS Enclave import ID binding utility) and signtool.exe... A Trusted Signing account ^[35].

Azure SQL's "Always Encrypted with secure enclaves" is the public flagship consumer. The architectural difference from an inbox trustlet is the API surface and the enclave-versus-process model: a VBS Enclave is a region inside an existing process's address space, not a separately scheduled process. The threat model is identical: the host (the rest of the process, including its VTL0 code) is the attacker, the enclave is the defender ^[36].

Roster table#

The published roster stops at Trustlet IDs 0-3 from 2015. The actual roster on a 2026 box is bigger. How much bigger Microsoft hasn't said. That is one of the open problems Section 9 will pick up.

7. Competing Approaches#

Microsoft is not alone. The same threat model -- "protect user-mode code from a compromised OS kernel" -- has been answered six other ways. None is strictly better than a trustlet. None is strictly worse. The right answer depends on what platform you are on, what threat model you have, and what workload you are trying to protect.

Intel SGX#

Software Guard Extensions launched with the sixth-generation Intel Core processors (Skylake) in 2015 ^[38]. SGX adds two CPU instructions with different privilege requirements: ENCLS (ring 0; the OS issues leaves like ECREATE on behalf of a user-mode application) and ENCLU (ring 3; the application issues leaves like EENTER and EEXIT to enter and leave its enclave) ^[39]. The result is a user-mode-controllable enclave whose memory is encrypted on the way out of the CPU's Enclave Page Cache to DRAM. The CPU microcode itself, plus the Quoting Enclave, is the TCB. Neither the OS kernel nor the hypervisor sits in the trust path.

That sounded ideal in 2015. It has not aged well. Foreshadow (USENIX Security 2018, Van Bulck et al.) demonstrated that transient-execution attacks could extract not only enclave memory but the platform's attestation key ^[40]. The Foreshadow team's site states the consequence:

"Foreshadow demonstrates how speculative execution can be exploited for reading the contents of SGX-protected memory as well as extracting the machine's private attestation key... due to SGX's privacy features, an attestation report cannot be linked to the identity of its signer. Thus, it only takes a single compromised SGX machine to erode trust in the entire SGX [deployment base]." -- Foreshadow project site ^[41]

SGAxe (attestation-key extraction) ^[42], Plundervolt (software-controlled undervolting to fault SGX computations) ^[43], SgxPectre (branch-target injection across the enclave boundary) ^[44], and others followed. Intel deprecated SGX on 11th-generation Core and later client CPUs, which incidentally removed Ultra HD Blu-ray playback on officially licensed software including PowerDVD ^[38]. SGX continues on Xeon for confidential cloud workloads but is no longer a target architects pick on Windows clients.

AMD SEV-SNP and Intel TDX#

AMD's Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP), introduced on EPYC 7003 (Milan, launched 15 March 2021) ^[45], and Intel's Trust Domain Extensions (TDX), introduced on 4th-generation Xeon Scalable (Sapphire Rapids, launched 10 January 2023) ^[46], provide whole-VM confidential computing ^{[47] [48]}. AMD's verbatim claim: "SEV-SNP adds strong memory integrity protection to help prevent malicious hypervisor-based attacks like data replay, memory re-mapping, and more to create an isolated execution environment" ^[47]. Intel's verbatim claim about TDX: "A CPU-measured Intel TDX module enables Intel TDX. This software module runs in a new CPU Secure Arbitration Mode (SEAM) as a peer virtual machine manager (VMM)" ^[48]. The AMD SEV-SNP whitepaper "Strengthening VM Isolation with Integrity Protection and More" is the canonical technical reference ^[49].

The granularity is different from a trustlet. SEV-SNP and TDX isolate an entire virtual machine from its hypervisor and host. They do not isolate a process from its own VM's kernel. For "this user-mode process should be protected from a SYSTEM kernel write primitive on the same OS," a trustlet is the primitive; for "this entire VM should be protected from a compromised cloud provider," a CVM is the primitive. Use the right one.

ARM TrustZone and OP-TEE#

The two-world hardware split that has shipped on every Cortex-A processor since the mid-2000s -- the Wikipedia ARM architecture article states verbatim that "the Security Extensions, marketed as TrustZone Technology, is in ARMv6KZ and later application profile architectures," the lineage every Cortex-A core inherits ^[50]. The CPU enforces a Non-Secure World and a Secure World; switching between the two is mediated by a Secure Monitor Call (SMC) instruction. OP-TEE is the canonical open-source secure-world OS for Cortex-A TrustZone, with Trusted Applications running as user-mode binaries in Secure World EL-0 and the OP-TEE OS itself running at EL-1 ^[51]. The OP-TEE about page describes the design: "OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology" ^[51].

TrustZone is the closest non-Windows analogue to a trustlet at the architectural level. The vocabulary maps one for one.

Apple Secure Enclave Processor (SEP)#

Apple's answer is a dedicated on-die security subsystem. SEP is a separate processor core, isolated from the Application Processor on the same SoC, with its own boot ROM, its own AES engine, and its own random number generator. It has been in every iPhone since iPhone 5s (2013), every Apple Silicon Mac, every Apple Watch from Series 1 ^[52]. Apple's verbatim description:

The Secure Enclave Processor runs an Apple-customized version of the L4 microkernel. It's designed to operate efficiently at a lower clock speed that helps to protect it against clock and power attacks ^[52].

SEP is the strongest counter to microarchitectural side channels among the production options, because the cores genuinely do not share microarchitectural state with the Application Processor. The price is that everything is firmware-class: patching a SEP bug means rolling SEP firmware on every Apple device, not pushing an OS update. The cycle is slower and more centralised.

seL4 plus user-mode security servers#

The academic conscience of the lineage. About ten thousand lines of formally verified C, with machine-checked proofs of functional correctness, confidentiality, and integrity ^{[8] [10]}. Sub-microsecond IPC. The price is that seL4 is a separation microkernel, not a desktop OS; building a Credential-Guard-equivalent on seL4 means designing the application architecture from the microkernel up, not retrofitting it onto a Windows-compatible stack. seL4 has shipping deployments in defence (the DARPA HACMS programme), automotive ECUs, and Qualcomm's Hexagon DSP secure OS.

When to pick which#

A decision table of the kind a colleague would actually use.

Trustlets are the right answer for Windows. They are not the right answer for every platform, every threat model, or every workload. They are also not without limits on Windows itself. What are those?

8. The Floor of the Threat Model#

By 2020 the trustlet model had been shipping for five years. Two researchers at the Microsoft Security Response Center, Saar Amar and Daniel King, pointed a fuzzer at the secure-call interface for two weeks and reported back with five VTL0-to-VTL1 bugs ^[19]. Their Black Hat USA 2020 talk, "Breaking VSM by Attacking Secure Kernel," is the most important public document on what the trustlet model actually guarantees and what it does not ^[53].

The talk is honest in a way Microsoft is rarely honest about its own products. The slides enumerate the bugs by CVE number, name the specific Secure Kernel routines they exploited, and -- unusually -- list the hardening changes Microsoft shipped because of what was found. Reading the deck is the closest thing to a Q-and-A with the Secure Kernel team.

Bug class 1: the secure-call interface is the floor#

The Secure Kernel exposes about three dozen "secure services" callable from VTL0 via the IumInvokeSecureService dispatcher. Each takes a parameter block from VTL0, parses it inside VTL1, and returns. That dispatcher is, by definition, the largest VTL0-controllable input surface in the model. Amar and King retargeted the Hyperseed hypercall fuzzer, originally written by Daniel King and Shawn Denbow for hypercall fuzzing, at securekernel!IumInvokeSecureService ^[19]. Two weeks of fuzzing produced five bugs.

Two of them shipped with public CVE numbers in 2020. CVE-2020-0917 is an out-of-bounds read in the secure-call surface; CVE-2020-0918 is a design flaw in SkmmUnmapMdl where a VTL0 caller could pass a fully attacker-controlled Memory Descriptor List to SkmiReleaseUnknownPTEs ^{[54] [55] [19]}. The NVD entries describe both with the same boilerplate ("Windows Hyper-V Elevation of Privilege Vulnerability") and classify the CWE as "Insufficient Information"; the technical detail lives in the Amar/King deck.

Microsoft hardened in response. The Amar/King deck enumerates what changed:

• The Secure Kernel pool moved to segment heap in mid-2019, breaking the heap layout the public exploit depended on.
• Four W+X regions in VTL1 were reduced to +X only, eliminating attacker-controlled code-injection targets.
• SkpgContext, a HyperGuard-style control-flow integrity check for the Secure Kernel, was introduced ^[19].

Bug class 2: denial of service is not a security boundary#

Amar's deck states the rule that excludes liveness from the VBS threat model verbatim:

"VTL0 can DOS VTL1 by design." -- Saar Amar and Daniel King, Black Hat USA 2020 ^[19]

The hypervisor schedules VTL1; VTL0 is the agent for almost every communication channel into VTL1; VTL0 can stop talking to VTL1 at any time. None of this is, in Microsoft's stated model, a security violation. A VTL0 kernel attacker who can prevent Credential Guard from issuing tickets has not stolen any credential; they have, in the language of the threat model, achieved denial of service, which is out of scope. This matters in practice: a defender cannot reason about a trustlet "always being available." They can only reason about its memory not being readable from VTL0 when it is available.

Bug class 3: the agent RPC surface lives in VTL0#

The trustlet's pages are safe even from VTL0 ring 0. The agent process that services the trustlet's ALPC port is not safe. The agent is lsass.exe for Credential Guard, vmwp.exe for the vTPM, presumably the Hello biometric pipeline for ESS. Every byte of every protocol whose state machine the agent implements is reachable from VTL0. The hash never leaves VTL1; the authentication outcomes the hash produces can be relayed.

In December 2022 Oliver Lyak published "Pass-the-Challenge: Defeating Windows Defender Credential Guard" ^[56]. The technique recovers usable NTLM challenge responses from encrypted credential blobs that LsaIso.exe returns to lsass.exe in VTL0:

In this blog post, we present new techniques for recovering the NTLM hash from an encrypted credential protected by Windows Defender Credential Guard. While previous techniques for bypassing Credential Guard focus on attackers targeting new victims who log into a compromised server, these new techniques can also be applied to victims logged on before the server was compromised ^[56].

Microsoft documents one corner of the limit verbatim: Credential Guard "doesn't prevent an attacker with malware on the PC from using the privileges associated with any credential" ^[30]. The "use" is the agent-side operation; the trustlet is doing the cryptography, and the cryptography is being used by the attacker.

Bug class 4: trustlet-to-trustlet via shared Instance GUIDs#

Trustlets that share an Instance GUID can read and write storage blobs the Secure Kernel scopes per-Instance. The pair vmsp.exe and the vTPM provisioning trustlet uses exactly this primitive: provisioning writes, vmsp.exe reads, the Secure Kernel hard-codes which Trustlet IDs may invoke SecureStorageSet versus SecureStorageGet on each Instance GUID. The defence is in the SkCapabilities table; bugs in that table are exploit-class.

In Ionescu's vocabulary, a "malwarelet" is the worst case here: an attacker-controlled trustlet -- enabled by a Secure Boot or Test Signing compromise -- could request access to the Instance GUIDs of other trustlets, and any missing rule in SkCapabilities would let it read what those trustlets stored. There are no public exploits in this class as of mid-2026. There also is not a published audit of the table.

Bug class 5: substrate compromise (Secure Boot, firmware, signing keys)#

If Test Signing is on; if a production signing key leaks; if Secure Boot can be bypassed to boot a kernel that accepts attacker-controlled trustlet roots; if the UEFI firmware itself permits a DMA attack against early-boot memory -- the entire trustlet model is moot. Ionescu's BH2015 deck states the diagnosis: "VBS' key weakness is its reliance on Secure Boot" ^[27]. Rafal Wojtczuk's Black Hat USA 2016 attack-surface analysis empirically validated the warning, demonstrating one non-critical VBS-feature bypass and one critical firmware exploit ^[57]. The firmware below VBS is the substrate trustlets sit on; the trustlet model is no stronger than that substrate.

flowchart TD
Attacker["VTL0 kernel attacker"]
SK["Secure Kernel"]
Trustlet["Trustlet (VTL1 user)"]
Agent["VTL0 agent process (lsass.exe, vmwp.exe...)"]
Substrate["Substrate: UEFI firmware, Secure Boot, signing roots"]
Attacker -->|"1. Secure-call interface bugs
CVE-2020-0917, CVE-2020-0918"| SK
Attacker -->|"2. DoS by design (out of scope)"| SK
Attacker -->|"3. Agent RPC surface
Pass-the-Challenge"| Agent
Agent -->|"authentication outcome"| Trustlet
Attacker -->|"4. Trustlet-to-trustlet
via shared Instance GUID"| Trustlet
Substrate -->|"5. Substrate compromise
malwarelets, BootHole-class"| SK
Substrate --> Trustlet

The trustlet model is hypervisor-strong against the VTL0 kernel; it is not stronger than the substrate it sits on. Five attack classes -- secure-call interface bugs, designed-out denial-of-service, the agent RPC residual, trustlet-to-trustlet via shared Instance GUIDs, and substrate compromise -- bound what the model can guarantee. None of them invalidates trustlets; all of them are reasons to deploy trustlets alongside other controls rather than as a sole defence.

The trustlet model has a finite, audited attack surface. The surface is not zero. Liveness is not promised. The firmware and Secure Boot underneath everything still matter. What is new on this surface in 2024 to 2026?

9. Open Problems#

Three things you might expect Microsoft to have published by 2026 -- the current inbox trustlet roster, an architecture diagram of Administrator Protection on par with Credential Guard's, and a public CVE wave around VBS Enclaves -- are still partial or missing. Here is the frontier.

1. Trustlet enumeration drift. Ionescu's August 2015 enumeration of Trustlet IDs 0 through 3 remains the only authoritative published list. Eleven years later, the ESS biometric matcher has not been named with a Trustlet ID and the Administrator Protection issuer has not been committed to as a trustlet at all. A researcher with a debugger and the Quarkslab IUM-debugging recipe can recover the current roster empirically ^[25]; Microsoft has not republished it.

2. VBS Enclave trust-boundary hardening. Microsoft's Security Response Center published a blog post in June 2025 -- "Everything Old Is New Again" -- explicitly committing to host-to-enclave pointer validation, copy-before-check discipline, and TOCTOU avoidance as the active hardening surface for VBS Enclaves ^[58]. The post is unambiguous that a CVE wave is foreseeable as researchers turn their attention to the host-enclave seam. As of the publication of this article no public CVE has been issued against a VBS Enclave-using product, but Microsoft's narrowing of supported Windows builds in 2025 (from "Windows 11 24H2 or later" to "Windows 11 Build 26100.2314 or later") is the kind of build-floor adjustment that historically precedes a documented hardening change ^[35].

3. Side channels against VTL1. Transient-execution attacks against VTL1 memory have not been publicly demonstrated end to end. The Foreshadow class of attacks against SGX is the existence proof that a co-resident TEE can leak through microarchitectural side channels, and the threat model explicitly includes them ^[41]. There is no VBS-specific transient-execution mitigation; platform-wide mitigations (Kernel Virtual Address Shadow, Retpoline, Indirect Branch Restricted Speculation) are the only defence. A demonstration of "Foreshadow-against-LsaIso" would not be surprising; its absence to date is, given the research community's interest, mildly so.

4. Debugging asymmetry. Researchers have a working trustlet-debugging recipe; defenders have an explicit "no" from Microsoft. The Quarkslab writeup walks through nested virtualisation to attach to a trustlet under controlled conditions ^[25]; Microsoft's product-facing page states verbatim that "it is not possible to attach to an IUM process" and that "other APIs, such as CreateRemoteThread, VirtualAllocEx, and Read/WriteProcessMemory will also not work as expected when used against Trustlets" ^[26]. The asymmetry favours offence: an attacker with the time, hardware, and tooling Quarkslab demonstrates can study trustlet internals in ways a defender on a production box cannot. Live-system trustlet introspection for incident response is the missing capability.

5. Administrator Protection transparency. As of 10 May 2026, the Administrator Protection feature has been shipped in preview (KB5067036, 28 October 2025), then reverted in the same update note pending a future re-rollout ^{[33] [34]}. There is no architecture diagram on the level of Credential Guard's "how it works" page. There is no published Trustlet ID. There is no public commitment to whether the token issuer is a trustlet, a VBS Enclave, or something else inside the new security boundary. For a feature that materially changes the local-elevation model of Windows, that is unusual reticence.

6. Cross-architecture portability. A workload that wants to run as a trustlet on Windows, a Confidential VM on Linux, a Trusted Application on ARM, and a Secure Enclave Application on Apple silicon must, today, be written four times. GlobalPlatform's TEE Client API standardises one side of TrustZone, the Open Enclave SDK abstracts a subset of SGX and TrustZone, and VBS Enclaves do their own thing. No universal portable TEE API exists. For workloads where portability matters more than peak isolation, this is the open problem with the most direct commercial pressure behind it.

These are questions a researcher with a year of grant time could move the field on. The next section is the question a practitioner has today.

10. Practitioner Guide#

What changes in a real workflow once you know what a trustlet is? Four short answers.

Windows administrator#

Verify Credential Guard is actually running before you assume it is. Two ways.

Enumerating live trustlets on a 2026 box requires more care than enumerating ordinary processes. Process Explorer's Image tab carries an IUM marker for trustlet processes. SysInternals Sigcheck on a candidate binary surfaces the Signing Level. The Microsoft Learn IUM page is explicit that "other APIs, such as CreateRemoteThread, VirtualAllocEx, and Read/WriteProcessMemory will also not work as expected when used against Trustlets" ^[26] -- the same APIs many EDR products rely on for behavioural monitoring will silently fail or report sentinel values when targeted at a trustlet. Plan detections accordingly.

Security researcher#

The Quarkslab blog post "Debugging Windows Isolated User Mode (IUM) Processes" is the canonical recipe for attaching to a trustlet under nested virtualisation ^[25]. The empirical enumeration path is NtQuerySystemInformation with class SystemIsolatedUserModeInformation; the structure returned includes a count of running trustlets and their identifying metadata.

Application developer (VBS Enclaves)#

If you are writing third-party code that needs trustlet-class isolation, the primitive you target is a VBS Enclave, not a trustlet. The toolchain is specific:

• Visual Studio 2022 version 17.9 or later.
• Windows SDK version 10.0.22621.3233 or later (provides veiid.exe, the VBS Enclave import ID binding utility, and signtool.exe).
• A Trusted Signing account for production signing ^[35].

The architectural rule is never trust the host. The host process's address space is reachable by the enclave; the enclave's address space is not reachable by the host. Range-validate every pointer the host hands the enclave; copy before you check (so the host cannot mutate the data between your check and your use); avoid TOCTOU windows. Microsoft's "Everything Old Is New Again" post is explicit that this is the hardening surface researchers are looking at right now ^[58].

The development guide includes a sample with a comment that captures the discipline:

Every DLL loaded in an enclave requires a configuration. This configuration is defined using a global const variable named __enclave_config of type IMAGE_ENCLAVE_CONFIG... // DO NOT SHIP DEBUGGABLE ENCLAVES TO PRODUCTION ^[59].

The IMAGE_ENCLAVE_POLICY_DEBUGGABLE flag is for development only. The VbsEnclaveTooling repository on GitHub provides a NuGet package and a code generator that make the cross-VTL marshalling less error-prone, plus reference documentation including Edl.md, HelloWorldWalkthrough.md, and CodeGeneration.md ^[60].

Defender#

Know what Credential Guard does not protect, because that is where most exposure remains.

The trustlet model is finite, audited, and useful. Use the lock; do not assume the lock is the only thing on the door.

11. Frequently asked questions#