The Servicing Bar

How Microsoft's Patch Policy Became the Most Profitable Line in Cybersecurity

June 4, 2026 - From the Editor's desk

Introduction: One Click. No Patch. No Apology.

There is a class of cyberattack that security vendors love to demonstrate at conferences because it produces a visceral reaction in any room. No sophisticated toolchain. No weeks of reconnaissance. No vulnerability in some obscure third-party dependency buried six layers deep in a software supply chain. Just a link. You click it. Somewhere across the internet, on a server controlled by someone who means you harm, a credential arrives. Your credential. Handed over by your own operating system, automatically, before you see so much as an error message.

This is not a theoretical attack. It is not a proof-of-concept that requires laboratory conditions. In June 2026, researchers at Huntress disclosed exactly this capability in the Windows search URI handler — a built-in component present on every modern Windows endpoint. An attacker crafts a link embedding a location parameter pointed at a server they control. The target clicks it — in a browser, in an email client, in any application that resolves URLs. Windows, helpfully, attempts SMB authentication against the attacker's server before rendering any indication that anything has gone wrong. The user's Net-NTLMv2 hash is delivered clean. No malware dropped. No payload executed. No complex exploit chain required. In a credential-relay or pass-the-hash environment — which describes most enterprise Windows networks — that hash is a door key.

Microsoft's response, when Huntress reported the finding, was to acknowledge it, assess it at CVSS 4.3, rate it Moderate, and decline to patch it. The company's Security Response Center explained that only Important and Critical severity cases typically meet the bar for servicing, and that exceptions exist on a case-by-case basis. The researchers noted, pointedly, that this was technically identical to CVE-2026-33829 — a vulnerability Microsoft had patched one day earlier in the Windows Snipping Tool, which used the same attack primitive, carried the same severity score, and produced the same outcome. One was patched. One was not. The difference, as best anyone can determine from the outside, is that one attracted enough attention to qualify as an exception.

This would be a routine, if frustrating, story about the gap between vulnerability disclosure and vendor remediation — the kind of story that gets published, generates a week of discussion in security forums, and is forgotten before the next Patch Tuesday. Except that this particular story has a history. The same primitive was documented by Varonis in 2024. Closed without a patch. Documented again by Trellix a year before that. The same outcome. The researchers keep finding it. Microsoft keeps declining to fix it. And in the background, largely unremarked upon in the technical coverage of each individual disclosure, a single fact sits in plain view in Microsoft's public earnings reports: the company's security division — the business unit that sells the detection products, the monitoring platforms, the enterprise licensing bundles that justify their cost partly by reference to the threat surface of Windows endpoints — crossed twenty billion dollars in annual revenue in 2023 and has been growing since.

This piece is about that fact. Not about the Huntress disclosure specifically, though we will spend considerable time on it. Not about NTLM, though NTLM will feature prominently as a twenty-five year case study in the economics of deferred remediation. This piece is about what it means that the world's dominant endpoint platform vendor is also one of the world's largest cybersecurity vendors — and about whether the consistent, long-running pattern of decisions that keeps the attack surface of that platform intact can plausibly be explained by engineering conservatism, compatibility constraints, and resource allocation, or whether it requires a simpler and more uncomfortable explanation.

The comfortable explanation, widely accepted in security industry commentary, is that Microsoft's patch decisions reflect misaligned incentives baked into a complex organization — that the security team and the product team aren't the same people, that MSRC engineers aren't sitting in revenue planning meetings, and that the conflict of interest is structural and emergent rather than deliberate. This piece contests that framing directly. Microsoft has a board with fiduciary duties to shareholders. It has a CEO who has announced security revenue milestones on earnings calls. It has senior executives whose compensation is indexed to metrics that someone, consciously, set. The "emergent conflict of interest" defense requires us to believe that these people — highly paid precisely for their ability to understand exactly these dynamics — have somehow failed to notice a relationship that is visible to any outside analyst who reads the annual report.

That credulity is not available to us. What follows is the evidence for why.

Section I: The Bar, Defined — By the People Who Set It

There is a document somewhere inside Microsoft — not published, not audited, not subject to external review — that defines what the company is obligated to fix. It is called, in the sanitized language of corporate security operations, the "servicing threshold." In practice, it works like this: a vulnerability is disclosed, a CVE is assigned, a CVSS score is calculated, and then Microsoft decides whether that score clears an internal bar that Microsoft itself has set, using criteria Microsoft has not fully published, subject to appeal by precisely no one.

The Huntress disclosure of June 2026 made this mechanism visible in unusually clean terms. On April 14, Microsoft patched CVE-2026-33829 — a credential-leakage vulnerability in the Windows Snipping Tool. The bug was straightforward: an attacker could craft a link pointing the handler at an attacker-controlled server, and Windows would dutifully attempt SMB authentication before rendering any error, handing over the user's Net-NTLMv2 hash in the process. One click. No malware. No payload. No exploit chain. The hash arrives on the attacker's listening server like room service.

One day after that patch shipped, Huntress reported the identical primitive in the Windows search URI handler — the same underlying COM activation path, the same location parameter accepting an unvalidated server address, the same outbound SMB authentication, the same hash delivered to whoever is listening. The severity score is letter-for-letter identical to CVE-2026-33829. The attack surface is, if anything, broader — the search handler is more universally invoked than the Snipping Tool, embedded across a wider range of application contexts and more likely to appear in everyday link interactions.

Microsoft's response, provided directly by the Microsoft Security Response Center, is worth quoting because the language is doing a great deal of work: "Typically, only Important and Critical severity cases meet our bar for servicing... Unfortunately, there are different factors that come in to play which sometimes causes exception to our standard processes."

Read that carefully. The rule is: don't fix it. The exception — the thing described as unfortunate, as a deviation from standard processes — is fixing it. CVE-2026-33829, the Snipping Tool bug, was the exception. The search handler bug, technically identical, is the rule. The bar was not applied differently because the vulnerabilities are meaningfully different. It was applied differently because one attracted enough attention to become an exception, and one didn't. The bar is not a standard. It is a discretionary gate operated by the vendor whose products sit on the other side of it.

This would be troubling enough in isolation. It becomes a pattern when you look back even eighteen months. Varonis documented the same UNC path leakage primitive on the search-ms URI handler in February 2024 — the same technique, a closely related handler. Microsoft closed it Moderate, no patch. A separate URI handler leakage from the same Varonis research received identical treatment. Trellix had documented the search handler as an attack surface a year earlier still, in 2023. Each disclosure was evaluated atomically — assessed in isolation, scored without reference to the growing record of identical primitives being reported by different researchers across different handlers over successive years. Each one cleared the disclosure process and hit the servicing bar. Each one stopped there.

This is the procedural problem beneath the headline problem. The CVSS framework, whatever its merits as a snapshot severity tool, was not designed to evaluate recurrence. It produces a score for a specific vulnerability instance, not for a vulnerability class. A location-parameter UNC leakage in the search-ms handler is a 4.3. The same leakage in the search handler is a 4.3. The same leakage in whatever handler surfaces next year will also be a 4.3. The pattern history does not accumulate in the score. The underlying behavior — the component that accepts unvalidated server paths and triggers outbound authentication — is never the subject of the CVE. Only its most recent manifestation is. And each manifestation, evaluated fresh, clears the servicing bar on its own terms.

Microsoft has operationalized CVSS not as a risk communication tool but as a patch obligation threshold. Below a certain number, the company is not obligated to act. Above it, the company generally will. The number is set by Microsoft. The threshold has never been subject to external governance, regulatory review, or customer consent. It is a unilateral commercial decision dressed in the borrowed authority of a technical standard. And as the Huntress case demonstrates with unusual clarity, it is applied on a case-by-case basis — in which "case-by-case" means "sometimes we fix the ones that generate enough noise."

What that does not mean — and what no one at Microsoft has been willing to say plainly — is: we will fix this class of vulnerability. We will address the handler architecture. We will ensure that no future invocation surface can reintroduce the same primitive. That commitment has not been made. The search handler leaks credentials today. Whatever handler Varonis or Huntress or Trellix documents next year will leak them too, evaluated fresh, scored in isolation, measured against a bar that is set precisely where it needs to be set to make fixing optional.

Section II: Twenty Billion Reasons to Leave the Window Open

In January 2023, Satya Nadella took a moment during Microsoft's fiscal second quarter earnings call to share a milestone. The company's security division, he told analysts, had crossed twenty billion dollars in annual revenue. This was not a quiet disclosure buried in supplementary financial tables. It was a highlight — the kind of number a CEO announces with pride, the kind of number that moves analysts and shapes market narratives. Microsoft Security had reached ten billion in 2021. Fifteen billion in 2022. Twenty billion in 2023. A clean doubling in two years, in a division that didn't exist as a coherent business unit a decade earlier.

Nadella's framing of the milestone is worth sitting with. "We are the only company," he told the call, "with integrated, end-to-end tools spanning identity, security, compliance, device management and privacy, informed and trained on over 65 trillion signals each day. We are taking share across all the major categories we serve." This is the language of competitive dominance. Microsoft Security is not positioned internally as a cost center, a regulatory obligation, or a reputational investment. It is positioned as a growth business — one taking share, expanding margin, and compounding at a rate that would be the envy of most standalone security vendors.

The products driving that revenue are not incidental to this story. Defender for Endpoint. Microsoft Sentinel. Defender for Identity. Purview. The E5 enterprise licensing bundle, which packages security capabilities at a discount steep enough to displace pure-play competitors and lock enterprise customers into the Microsoft detection and response stack. These are the products that monitor Windows endpoints for threats. They are the products that detect credential theft, flag lateral movement, alert on anomalous authentication patterns. They are, in the plainest possible terms, the products that exist because Windows endpoints have an attack surface that requires active management.

Follow that logic to its conclusion. Every URI handler that silently leaks Net-NTLMv2 hashes is a detection opportunity for Defender for Identity. Every NTLM relay attempt that crosses an enterprise network is a signal for Sentinel. Every pass-the-hash lateral movement event that follows a credential leak is a Defender for Endpoint alert. The attack surface and the security product stack are not separate concerns. They are, structurally, complementary goods. The threat generates the revenue. The platform that hosts the threat is the same platform that sells the remedy.

This is not an unusual observation. Security researchers and industry analysts have noted the tension for years, typically in the careful language of "potential conflicts of interest" and "misaligned incentives." What is unusual — and what the boardroom-emergent framing consistently obscures — is the scale at which this dynamic now operates. Twenty billion dollars is not a rounding error. It is not a side business. Microsoft Security is, by annual revenue, one of the largest cybersecurity companies on the planet, competing directly with CrowdStrike, Palo Alto Networks, and a field of pure-play vendors who have no complementary interest in the persistence of the threats they are paid to detect.

Those pure-play vendors have a straightforward incentive structure: their reputation depends entirely on the quality of their detection and response. They do not also sell the operating system whose vulnerabilities generate the incidents they respond to. They do not set the threshold at which those vulnerabilities are deemed worth patching. They have no servicing bar. Microsoft occupies a position that is, in the history of the technology industry, essentially without precedent: it is simultaneously the dominant endpoint platform vendor responsible for closing vulnerabilities, and the dominant enterprise security vendor selling detection and response for the same vulnerabilities. It is the landlord and the locksmith. The arsonist and the fire brigade. Pick your metaphor — the structural reality is the same in all of them.

The standard defense at this point is to invoke organizational complexity. Microsoft is a large company. The engineers who triage CVEs at the Microsoft Security Response Center are not the same people who set revenue targets for Sentinel. The incentive misalignment is emergent, not designed. Nobody is sitting in a room deciding not to patch credential-leakage primitives because doing so would reduce Defender for Identity's detection surface.

We will examine that defense in detail in Section IV. For now, note only this: the defense requires us to accept that the executives who set the servicing threshold — who decide, at a policy level, that Moderate severity vulnerabilities do not obligate a patch — are operating in isolation from the commercial context in which that decision sits. It requires us to believe that Satya Nadella, who announced a twenty billion dollar security revenue milestone on an earnings call, has not considered the relationship between the patch obligations of the platform division and the addressable market of the security division. It requires us to believe that the CFO who models both revenue lines has not noticed that they move in relation to each other. It requires, in short, a portrait of executive incompetence that the compensation structures, board disclosures, and public statements of Microsoft's leadership directly contradict.

The servicing bar is set by people who understand exactly what it costs to lower it. The evidence for that claim is not in leaked internal documents. It is in the consistency of outcomes, measured over years, against a financial backdrop that makes the incentive structure not merely plausible but arithmetically obvious. Twenty billion dollars in security revenue does not emerge accidentally from a platform whose vulnerabilities are being closed as aggressively as engineering resources allow. It emerges from a platform whose vulnerabilities are being managed — triaged, rated, serviced selectively — by an organization with a precise and quantified interest in the answer.

Section III: A Pattern of Profitable Inaction — The Case History

Arguments about incentive structures are only as strong as the pattern of outcomes they explain. If Microsoft's servicing bar were genuinely an engineering policy — a neutral, resource-driven triage mechanism applied consistently against a backlog of disclosed vulnerabilities — we would expect its application to be roughly uniform across severity classes, and we would expect the attack surfaces it leaves unaddressed to reflect genuine compatibility constraints or engineering complexity rather than commercial convenience. What we find instead, across four distinct case histories spanning more than two decades, is something considerably less flattering: a consistent pattern in which the vulnerabilities that remain unaddressed are precisely the ones whose persistence generates the most sustained commercial value, and in which remediation accelerates sharply when external pressure — regulatory, congressional, or reputational — makes inaction more expensive than action.

This is not coincidence. Coincidence does not reproduce itself across product lines, leadership regimes, and a quarter century of disclosed vulnerabilities. What follows is the record.

NTLM: Twenty-Five Years of Legacy, On Schedule

NT LAN Manager authentication was introduced in 1993 with Windows NT 3.1. It was the authentication mechanism of its era — a challenge-response protocol that solved real problems for business networks of the time and that became deeply embedded in the Windows ecosystem over the following decade. By the year 2000, it was already obsolete in design terms. Kerberos arrived with Windows 2000 as the default authentication protocol for domain-joined devices, offering modern cryptography, resistance to relay attacks, and the kind of security architecture that NTLM's challenge-response model structurally cannot provide. Microsoft's own documentation described NTLM as the legacy fallback. The transition away from it was, in the language of every subsequent advisory, roadmap, and deprecation notice, a matter of when rather than if.

That was twenty-six years ago. NTLM was formally deprecated in June 2024. Not disabled. Not removed. Deprecated — meaning it remains available, continues to function as a fallback mechanism across the Windows install base, and will continue to do so through at least the next major Windows Server release, after which it will be disabled by default but remain re-enableable via policy override. The three-phase deprecation roadmap currently being executed envisions full default disablement at some point in the future that has not been assigned a firm date.

In the intervening twenty-six years, NTLM has been exploited continuously and comprehensively. Pass-the-hash attacks, NTLM relay attacks, credential coercion via PetitPotam, ShadowCoerce, DFSCoerce, and RemotePotato0 — the catalogue of NTLM-dependent attack techniques is not a list of exotic, nation-state-only capabilities. It is the standard lateral movement playbook for ransomware operators, penetration testers, and opportunistic attackers alike. Microsoft's own advisory on the deprecation acknowledges that NTLM "is susceptible to various attacks, including replay and man-in-the-middle attacks, due to its use of weak cryptography" and that its ongoing use "exposes organizations to" a range of well-documented risks. This is not a recent discovery. Microsoft has been warning developers to stop using NTLM since at least 2010.

The question that the deprecation timeline raises — and that no Microsoft communications have answered satisfactorily — is why. Why, given that Kerberos superseded NTLM in 2000, given that the attack techniques dependent on NTLM persistence have been in active use for decades, given that Microsoft's own teams have understood the risk profile throughout, did formal deprecation not arrive until 2024, and why does actual disablement remain a future event in 2026? Compatibility with legacy applications is the standard answer, and it is not entirely wrong — there are genuine environments where Kerberos cannot be implemented due to legacy dependencies or network limitations, and Microsoft bears some responsibility for the smooth operation of those environments.

But compatibility does not explain the timeline. It explains the need for a migration path. It does not explain why that migration path required twenty-four years to begin in earnest, why the deprecation announcement arrived in 2023 and not in 2013 or 2003, or why the pace of action correlates so precisely with the maturation of Microsoft's detection product stack. Defender for Identity — the product that monitors for NTLM relay attacks, pass-the-hash attempts, and credential coercion — was launched in 2016 as Azure Advanced Threat Protection, rebranded and expanded through subsequent years, and is now a cornerstone of the E5 security bundle. Every year of NTLM persistence between 2016 and 2024 was a year in which the credential-leakage attack surface that Defender for Identity exists to monitor remained fully intact. Every Huntress disclosure, every Varonis research report, every PetitPotam proof-of-concept is, from a certain angle, a Defender for Identity product demonstration.

The deprecation timeline does not prove intent. It does not need to. It demonstrates that the pace of remediation on a known, decades-old attack surface bears no relationship to the known risk profile of that surface and a highly suggestive relationship to the commercial maturation of the products positioned to detect its exploitation.

PrintNightmare: Patching the Symptom, Preserving the Disease

In June 2021, a researcher accidentally published proof-of-concept code for a critical vulnerability in the Windows Print Spooler service — a component that has existed in Windows since the earliest NT releases and that runs, by default, as NT AUTHORITY\SYSTEM on virtually every Windows installation. The vulnerability, eventually assigned CVE-2021-34527 and christened PrintNightmare by the research community, allowed an authenticated attacker to remotely execute arbitrary code with system privileges by abusing the Print Spooler's driver installation functionality. The impact was immediate and severe. PrintNightmare was exploited in the wild within days of the proof-of-concept becoming public.

Microsoft's response followed a now-familiar pattern. An out-of-band patch was issued in July 2021 — unusually fast by Patch Tuesday standards, reflecting the severity and the public nature of the disclosure. Microsoft's Security Response Center stated that the patch was "working as designed and effective against known printer spooling exploits." Multiple independent researchers, including Kevin Beaumont and Will Dormann, promptly demonstrated that this was not accurate. The local privilege escalation still functioned post-patch under default configurations. The patch addressed the specific exploitation path that had been demonstrated publicly. The underlying architecture — the RpcAddPrinterDriver API executing as SYSTEM, the Print Spooler's fundamental design as a privileged service that installs third-party code — remained intact.

What followed was a months-long sequence of additional CVEs, additional patches, and additional bypasses. Each patch addressed the specific technique most recently demonstrated. Each bypass found a new path through the same underlying attack surface. The Print Spooler architecture was never the subject of a remediation commitment. It was the stable foundation on which a succession of CVEs were built and individually addressed, while the foundation itself persisted.

This is phenotype patching — treating the expressed symptom while leaving the genetic code that produces it unchanged. It is the same pattern visible in the search URI handler situation: individual manifestations remediated, underlying primitive intact, next researcher to find the next manifestation starting the process again from the beginning. And it is a pattern that generates a steady, predictable stream of CVE activity, patch cycles, detection opportunities, and managed response engagements — all of which have commercial value to a vendor that sells detection and response products alongside the platform generating the incidents.

The Exchange Migration: Insecurity as a Sales Funnel

Between 2021 and 2022, Microsoft's on-premises Exchange Server became, in the words of one security firm's post-incident analysis, a product that drove "spoofing and remote code execution vulnerabilities at almost a monthly rate." The sequence began with ProxyLogon in March 2021 — a server-side request forgery vulnerability allowing unauthenticated remote code execution against exposed Exchange instances, exploited at mass scale by the Chinese state-affiliated group HAFNIUM and subsequently by a range of criminal and espionage actors. Tens of thousands of organizations were compromised. Before the dust settled, ProxyShell arrived in August 2021 — three separate CVEs in Exchange's Client Access Services proxy component, demonstrated at Black Hat, exploited widely before a significant portion of the install base had patched ProxyLogon. ProxyToken followed. ProxyNotShell followed that, in 2022, exploiting path confusion flaws that ProxyShell's patches had not addressed because they targeted a different expression of the same underlying architectural problem.

Each of these vulnerability chains shared a root cause: the CAS proxy architecture of on-premises Exchange, which had accumulated years of complexity, trust assumptions, and authentication handling decisions that created, when examined by skilled researchers, a remarkably target-rich environment. The patches addressed individual chains. The architecture was not redesigned. Researchers who looked closely enough at the CAS component kept finding new paths through it.

What is notable about the Exchange saga in the context of this argument is not simply the pattern of incomplete remediation. It is who benefited. Exchange Online — Microsoft's cloud-hosted email service, the product Microsoft has been driving customers toward for years — was not affected by any of these vulnerability chains. It runs on infrastructure Microsoft controls, patches on Microsoft's schedule, and is not exposed to the CAS proxy architecture that made on-premises Exchange a recurring emergency. The sustained insecurity of on-premises Exchange, and the operational burden of emergency patching with complex cumulative update prerequisites, downtime requirements, and post-patch remediation work, made the managed cloud alternative increasingly attractive with each successive incident. ProxyShell alone, arriving months after ProxyLogon on the same architectural surface, significantly accelerated many organizations' migration decisions.

It would be imprecise to say that Microsoft deliberately left Exchange vulnerable to sell Exchange Online. The vulnerabilities were patched — eventually, individually, incompletely. What can be said is that the architectural decisions that made on-premises Exchange a recurring emergency were never addressed at the source, that the product most harmed by those decisions was the on-premises product Microsoft was actively trying to migrate customers away from, and that the product unaffected by them was the cloud product Microsoft was actively trying to migrate customers toward. The commercial outcome and the remediation pattern are consistent. Whether that consistency reflects strategy or fortune is, at this point, a question about the benefit of the doubt — and Microsoft has spent considerable credit on that account.

SMBv1 and the Lesson of Catastrophe

The story of SMBv1 is the clearest illustration of what happens when Microsoft's servicing calculus is forced to change by external events rather than internal risk assessment. Server Message Block version 1 is a network file-sharing protocol that dates to the mid-1980s. By the mid-2000s it was broadly understood within the security community to be architecturally insecure — a legacy protocol with no encryption, weak authentication handling, and a design that reflected the threat model of a decade when enterprise networks were not connected to the public internet. Microsoft shipped newer SMB versions with Windows Vista and subsequently with Windows 8, each offering meaningful security improvements. SMBv1 remained enabled by default throughout, on every Windows installation, for years after its successor protocols were available and stable.

The security community's concerns about SMBv1 were not quiet or obscure. They were documented, discussed at conferences, and reflected in security guidance that recommended disabling SMBv1 in environments that did not require it. Microsoft's response, over this period, was to acknowledge the concerns and continue shipping SMBv1 enabled by default. The compatibility argument was the stated rationale — legacy applications and network devices that depended on SMBv1 would break if it were disabled. This was true for some environments. It was not a technical obstacle to disabling it by default and requiring explicit enablement for those environments. That decision — to flip the default — was not made.

In April 2017, the Shadow Brokers published EternalBlue, an NSA-developed exploit for a critical vulnerability in SMBv1. In May 2017, WannaCry used EternalBlue to propagate across unpatched Windows networks globally, encrypting files at hospitals, telecommunications companies, and government agencies across 150 countries. The economic damage ran to billions of dollars. In June 2017, NotPetya used the same exploit, this time as a wiper rather than ransomware, causing what remains among the most economically destructive cyberattacks in history.

Following WannaCry and NotPetya, Microsoft moved. SMBv1 was removed from the default installation in Windows 10 version 1709, released in October 2017. The decision that had not been made despite years of documented security concern was made within months of a catastrophic, globally visible event.

This is the revealed preference that the servicing bar framework cannot explain away. The engineering constraints did not change between 2015 and 2017. The compatibility concerns were identical. What changed was the reputational and regulatory cost of inaction. When that cost exceeded the commercial value of the status quo, the default flipped. The servicing bar, in other words, is not fixed. It moves in response to external pressure. Which means that for the years during which it was not moving — during which SMBv1 remained a default-enabled legacy protocol on every Windows installation despite documented, specific, credible risk — the calculation was being made that the cost of action was higher than the cost of inaction. That is not engineering conservatism. That is a business decision.

Taken together, these four case histories describe something more coherent than a series of independent triage decisions. They describe a posture — a consistent, durable orientation toward the attack surface of the Windows platform that favors managed persistence over aggressive remediation, that accelerates only under external compulsion, and that has generated, across the period in question, tens of billions of dollars in security product revenue for the same company making the remediation decisions. The pattern is the argument. We turn next to the defense.

Section IV: The "Emergent" Defense Is a Lie They're Telling for You

When confronted with the conflict of interest outlined in the preceding sections, the technology industry and its sympathetic commentariat reliably produce a specific counter-argument. It goes like this: Microsoft is a large, complex organization. The engineers who triage vulnerabilities at the Microsoft Security Response Center are not the same people who set revenue targets for Sentinel or model the addressable market for Defender for Identity. The incentive misalignment, to the extent it exists, is structural and emergent — an unfortunate consequence of organizational complexity rather than a product of deliberate policy. Nobody, the argument insists, is in a room making conscious decisions to leave attack surfaces intact for commercial reasons. To suggest otherwise is to impute bad faith where incompetence, or at worst negligence, is the more parsimonious explanation.

This is a comfortable argument. It is also, on examination, constructed almost entirely from assumptions that serve Microsoft's interests and contradict what we know about how large technology companies actually function.

Begin with what the argument concedes. It concedes that the conflict of interest is real. It concedes that Microsoft profits from the persistence of threats on its own platform. It concedes that the servicing bar, as applied, produces outcomes that happen to align with those commercial interests. What it disputes is the mechanism — specifically, whether that alignment is the product of conscious decision-making at any level. The claim is not that the outcomes are acceptable. The claim is that no individual or group can be held accountable for them because they emerge from the aggregate of many independent decisions made by people who are each, individually, acting in good faith within their narrow remit.

This is the organizational equivalent of the Nuremberg defense dressed in the language of complexity theory, and it deserves the same skepticism.

Microsoft is not a slime mold. It does not produce emergent behavior from the undirected interactions of independent agents operating without oversight or strategic coordination. It is a company with a market capitalization that has at various points exceeded three trillion dollars, governed by a board with explicit fiduciary duties, led by a CEO whose strategic vision is communicated in exhaustive detail through earnings calls, investor presentations, annual reports, and public interviews. It has a Chief Financial Officer who models revenue across every business unit. It has a Chief Information Security Officer whose remit encompasses both the security of Microsoft's products and the commercial positioning of its security division. It has Vice Presidents of Security whose compensation packages are structured against objectives that someone, with full awareness of the commercial context, defined.

These people are not unaware that Microsoft Security generates twenty billion dollars in annual revenue. They are not unaware that this revenue is downstream of the threat surface of the Windows platform. Satya Nadella announced the twenty billion dollar milestone on an earnings call — not in an internal memo, not in a whispered conversation with the CFO, but in a public statement to Wall Street analysts whose job is to model the relationship between Microsoft's various revenue lines and the strategic decisions that sustain them. The relationship between platform vulnerability and security product revenue is not a hidden variable that requires sophisticated analysis to uncover. It is legible to anyone who reads the earnings transcript alongside the CVE database.

The "emergent" framing asks us to believe that this legibility somehow stops at the executive suite — that the analysts, researchers, and security professionals who can read the relationship clearly are seeing something that Microsoft's own leadership, with full access to internal data, cannot. This requires a portrait of executive incapacity that the compensation structures make immediately implausible. Satya Nadella earned approximately eighty-seven million dollars in fiscal year 2024. That compensation reflects, among other things, the board's assessment of his strategic acuity — his ability to identify and exploit relationships between Microsoft's various business lines, to allocate resources in ways that maximize long-term value, and to make decisions whose consequences he understands. The claim that he does not understand this particular consequence is not a defense. It is an insult to the board that set his compensation.

But we do not need to rely on inference about what executives understand. We have direct evidence of how Microsoft behaves when external accountability mechanisms are actually applied — and that evidence makes the "emergent" framing untenable.

In 2023, the Chinese state-affiliated group Storm-0558 compromised Microsoft Exchange Online mailboxes belonging to senior U.S. government officials, including the Secretary of Commerce and the U.S. Ambassador to China. The breach was enabled by a cascade of security failures inside Microsoft — failures in key management, failures in authentication architecture, failures in detection and logging — that the Department of Homeland Security's Cyber Safety Review Board subsequently investigated and described in a report remarkable for its directness. The CSRB concluded that the intrusion was preventable, that it never should have occurred, and that Microsoft's security culture was inadequate — attributing the breach to a cascade of avoidable errors reflecting an organizational failure to prioritize security.

The CSRB's findings prompted Congress to act. Brad Smith, Microsoft's Vice Chairman and President, was summoned to testify before the House Committee on Homeland Security in June 2024. The hearing was not gentle. Lawmakers challenged Smith's characterizations of Microsoft's notification practices, its response timeline, and its accountability for the failures the CSRB had identified. One congressman told Smith directly that his answers did not encourage trust and that he did not accept them as thoroughly honest.

Microsoft's response to this pressure was the Secure Future Initiative — a company-wide security program launched in November 2023 and expanded twice in 2024, ultimately dedicating the equivalent of thirty-four thousand full-time engineers to security improvements and describing itself as the largest cybersecurity engineering effort in history. This is an extraordinary commitment of resources. It is also, notably, a commitment made in direct response to congressional scrutiny and a devastating government review board report — not in response to the known risk state of Microsoft's platform, which had been documented in CVE databases, research publications, and security advisories for years before Storm-0558.

This is the pattern that the "emergent" defense cannot accommodate. If the servicing bar and the broader posture of incomplete remediation were genuinely the product of organizational complexity and misaligned incentives operating below the level of executive awareness, we would not expect that posture to change in direct, rapid response to external accountability pressure. Emergent behavior does not respond to congressional testimony. Structural incentive misalignment does not reverse itself when a Vice Chairman is summoned to Capitol Hill. What responds to congressional testimony is conscious policy — policy that was made deliberately, that is understood by the people who made it, and that can be changed when the political cost of maintaining it exceeds the commercial benefit.

The SFI is evidence not that Microsoft was previously unaware of its security failures, but that Microsoft was previously unwilling to prioritize addressing them at the cost that genuine remediation would require. The trigger for that willingness was not the CVSS score of any particular vulnerability. It was not the Huntress disclosure, or the Varonis research, or the PrintNightmare bypass sequence. It was the spectacle of a government review board calling Microsoft's security culture inadequate and a congressional committee calling its president to account. The bar moved when the political environment made it move. That is not emergence. That is governance — opaque, self-interested governance that responds to power rather than to risk, but governance nonetheless.

There is a final dimension to the "emergent" defense worth addressing directly, because it is the most rhetorically effective version of the argument and the one most likely to appear in responses to this piece. It holds that even if executive awareness of the conflict of interest is conceded, the causal chain between that awareness and specific patch decisions is impossible to establish. We cannot prove, the argument goes, that any specific decision not to patch a specific vulnerability was made with commercial considerations in mind. The servicing bar may be set where it is for entirely legitimate engineering and resource reasons. The commercial alignment may be coincidental. Without a leaked memo, a whistleblower, or a documented internal discussion explicitly linking patch decisions to revenue considerations, the charge of conscious commercial motivation cannot be proven.

This is true in the narrow sense that direct documentary evidence of executive intent is not available to outside analysts. It is also, as an epistemological standard, one that would make it impossible to hold any large organization accountable for any pattern of self-interested decision-making that falls short of explicit written confession. We do not require documentary evidence of specific intent to conclude that a tobacco company knew cigarettes caused cancer, that an oil company understood its products contributed to climate change, or that a pharmaceutical manufacturer was aware that its pricing strategies caused patient harm. We require a pattern of outcomes that is consistent with informed self-interest and inconsistent with the alternative explanations offered. The Microsoft case meets that standard on all counts.

The pattern is consistent. The beneficiary is identified. The decision-makers had full awareness of the commercial context. The alternative explanation — genuine, uninformed, structurally emergent misalignment — requires us to believe that sophisticated executives are systematically blind to a dynamic visible to any outside analyst. The "emergent" defense is not a serious engagement with the evidence. It is the argument that Microsoft benefits from having accepted as conventional wisdom, dressed up in the language of organizational theory and offered, repeatedly, as a reason to extend a charity that the record no longer supports.

Section V: The Open Source Mirror

There is a natural objection to the argument constructed in the preceding sections, and it is worth taking seriously before dismissing it. The objection runs like this: software is complex, vulnerabilities are inevitable in any codebase of sufficient size, and the challenges of patching legacy attack surfaces while maintaining compatibility across a heterogeneous install base are genuine engineering problems that any platform vendor at Microsoft's scale would face. The pattern of incomplete remediation documented here might reflect not commercial calculation but the universal difficulty of securing large, mature software ecosystems. Perhaps every platform vendor behaves this way. Perhaps this is simply what software security looks like at scale.

The open source ecosystem exists to test that claim. And the results of that test are not kind to Microsoft.

The comparison requires some care. Open source projects vary enormously in governance, resources, and organizational maturity. The Linux kernel is not curl. OpenSSL is not a university research project maintained by two volunteers. The meaningful comparison is not between Microsoft and the median open source project — it is between Microsoft and the class of open source infrastructure that operates at equivalent scale, with equivalent exposure, and with a mature security response process. The Linux kernel, OpenSSL, and the broader critical open source infrastructure that underpins the majority of the world's servers, cloud platforms, and embedded systems constitute that class. The comparison is instructive.

The Linux kernel's CVE volume has grown dramatically in recent years — from roughly three hundred recorded vulnerabilities in 2023 to over three thousand five hundred in 2024 and over five thousand five hundred in 2026. This is not evidence of deteriorating security. It is evidence of a maturing disclosure process in which the kernel team became its own CVE Numbering Authority in 2024, dramatically increasing the granularity with which vulnerabilities are tracked and reported. What the data also shows is that the upstream kernel team continues to ship patches within twenty-four to forty-eight hours of critical vulnerability confirmation — a remediation cadence that no commercial platform vendor at comparable scale approaches.

The structural reason for this difference is not engineering resources. Microsoft, as noted, has dedicated the equivalent of thirty-four thousand full-time engineers to security under the Secure Future Initiative — a commitment it describes as the largest cybersecurity engineering effort in history. The Linux kernel is maintained by a community of contributors that, while substantial and well-resourced through the Linux Foundation and major corporate sponsors, does not approach that headcount. Resources are not the variable that explains the difference in remediation speed and completeness.

The variable is incentive alignment. Linux kernel maintainers have no commercial stake in the persistence of vulnerabilities in their software. There is no Linux Kernel Security Division generating twenty billion dollars in annual revenue by selling detection products for kernel-level exploits. There is no business unit whose addressable market expands when a privilege escalation primitive remains unpatched. The reputational incentives for maintainers run entirely in the opposite direction — a kernel vulnerability that persists because a maintainer declined to address it is a reputational failure with no compensating commercial upside. The decision calculus is clean. Fix it.

This alignment produces observable behavioral differences that go beyond raw patch speed. When an open source project declines to patch a reported vulnerability — which does happen, typically due to genuine resource constraints or disagreement about severity — that decision is made in public, subject to community scrutiny, and reversible through social pressure, forking, or the intervention of downstream distributors. There is no opaque servicing bar. There is no internal threshold set by an entity with a commercial interest in the outcome. The researcher who reported the vulnerability can see the discussion, challenge the assessment, and escalate publicly if they believe the maintainer's judgment is wrong. The entire process is legible.

Contrast this with what Huntress experienced. A vulnerability is reported to Microsoft. Microsoft's Security Response Center triages it internally, applies an internal severity framework, measures the result against an internal threshold, and returns a verdict: below the servicing bar. The researcher has no visibility into the triage process. There is no forum in which the assessment can be publicly challenged. There is no community that can apply pressure, fork the codebase, or route around the decision. The conversation ends when Microsoft says it ends. The primitive remains.

The governance difference is as significant as the incentive difference, and the two are related. Open source security processes are transparent precisely because there is no commercial interest in opacity. The Linux kernel's CVE process, the OpenSSL Security Advisory process, the coordinated disclosure frameworks used across major open source infrastructure — these are designed to be auditable, because auditability serves the interests of the community that depends on the software. Microsoft's servicing threshold is not auditable because auditability would expose the relationship between patch decisions and commercial outcomes. The opacity is not incidental. It is structural.

There is a second comparison worth making, one that sharpens the incentive argument considerably. Consider how the open source ecosystem handles the class of vulnerability closest to the NTLM credential-leakage primitive — authentication protocol weaknesses that have been known for years and that persist in the ecosystem due to legacy compatibility requirements. The most instructive example is the handling of SSLv3 and its successor weak cipher suites across the open source web server and library ecosystem following the POODLE vulnerability disclosure in 2014. SSLv3 was, like NTLM, a legacy protocol whose security weaknesses were broadly understood long before a specific, named vulnerability forced the issue. Unlike NTLM, the response from the open source ecosystem — Apache, nginx, OpenSSL, and the major Linux distributions — was to disable SSLv3 by default within months of the POODLE disclosure, accepting the compatibility costs and providing clear migration guidance. There was no twenty-year deprecation roadmap. There was no three-phase disablement schedule extending years into the future. There was a known risk, a community consensus that the risk was unacceptable, and a remediation timeline measured in release cycles rather than decades.

The difference is not that the open source ecosystem faced fewer compatibility constraints. SSLv3 was deeply embedded in web infrastructure in 2014. The difference is that no entity in the open source ecosystem had a financial interest in the continued vulnerability of the systems that SSLv3 exposed. The decision to disable it by default was made by people whose only consideration was whether the security benefit outweighed the compatibility cost. It was. It was addressed.

This is the comparison that the "resources and complexity" defense cannot survive. The open source ecosystem, with a fraction of Microsoft's engineering headcount, a fraction of its financial resources, and no lesser compatibility burden, has consistently demonstrated a capacity for aggressive remediation of known attack surfaces when the incentive structure of the maintainers is aligned with security rather than with revenue. Microsoft, with the largest cybersecurity engineering effort in history by its own description, has demonstrated a consistent pattern of deferred remediation on precisely the attack surfaces whose persistence generates the most commercial value.

The mirror is clear. What it reflects is not an engineering problem. It is a governance problem — one that the open source ecosystem has largely solved by eliminating the commercial incentive for opacity, and one that the proprietary platform ecosystem has not solved because the commercial incentive for opacity remains intact and profitable. The Linux kernel does not have a servicing bar. It has maintainers. The difference in outcomes is not coincidental.

Section VI: What Defenders Are Actually Owed

The preceding sections have made a case about Microsoft's conduct. This section is about everyone else's — specifically, about what the organizations and individuals who depend on Windows infrastructure are owed by the vendor they pay, the regulatory frameworks they operate within, and the security industry that is supposed to be working on their behalf.

The starting point is an uncomfortable acknowledgment. The defender community has, to a significant degree, accommodated itself to the situation this piece describes. The pattern of incomplete remediation, deferred deprecation, and selectively applied servicing thresholds is not a secret. Security researchers know it. CISOs know it. The vendor community that sells managed detection and response services on top of Windows infrastructure knows it intimately — because their product value proposition depends, in part, on the persistence of the attack surface that Microsoft declines to close. The accommodation is not born of ignorance. It is born of a pragmatic recognition that Microsoft's platform dominance makes alternatives difficult, that the security product stack built on top of Windows is genuinely useful, and that the path of least resistance is to manage the threat surface rather than demand its remediation.

That accommodation has a cost, and the Huntress disclosure makes it legible. When Microsoft declines to patch a credential-leakage primitive, the cost is not borne by Microsoft. It is borne by every enterprise whose patch management program is built on the assumption that CVE assignment and vendor remediation are linked — that a disclosed vulnerability will eventually be addressed by the vendor responsible for it. It is borne by every security team that allocated its mitigation budget to patching the Snipping Tool last month and has no organizational mechanism for acting on a Huntress blog post about a structurally identical vulnerability that Microsoft declined to assign a fix. It is borne by every user whose Net-NTLMv2 hash is on a threat actor's Responder instance because the Windows search handler does what it has always done, and Microsoft has decided that fixing it does not meet the bar.

The externalization of this cost is not accidental. It is the predictable outcome of an accountability structure in which the vendor that creates the risk is also the vendor that defines the remediation obligation, with no external check on either the risk assessment or the remediation decision. This structure needs to change. What follows is a framework for what that change should look like — not as a utopian wish list, but as a set of accountability mechanisms that are technically feasible, have partial precedents in existing regulatory frameworks, and would, if implemented, meaningfully alter the incentive calculus that produces the pattern this piece documents.

Patch Obligations Above a Contextual Threshold

The most direct intervention is the one that most directly addresses the servicing bar: regulatory patch obligations triggered by CVE assignment above a threshold that accounts for contextual risk rather than isolated CVSS scores. The current situation allows Microsoft to acknowledge a vulnerability, accept a CVE, and decline to remediate it on the basis of a severity score that it effectively controls, evaluated in isolation from pattern history, relay potential, and downstream exploitation chains. A regulatory framework that required remediation for any CVE above a threshold calculated with reference to these contextual factors would close the specific gap that the Huntress case illustrates.

The European Union's Cyber Resilience Act, which entered into force in late 2024 and whose product security requirements are being phased in through 2027, represents a partial step in this direction. The CRA imposes obligations on manufacturers of products with digital elements — including software platform vendors — to address vulnerabilities without undue delay and to provide security updates for the expected product lifetime. The precise implementation of these obligations, and the question of whether they would constrain a servicing bar framework like Microsoft's, is still being worked out in implementing regulations. The potential is significant. A CRA enforcement regime that required Microsoft to justify non-remediation decisions against an externally auditable standard, rather than an internally defined threshold, would represent a qualitative shift in accountability.

The United States has no equivalent framework at present. CISA's Known Exploited Vulnerabilities catalog is the closest domestic instrument — a list of vulnerabilities confirmed as actively exploited in the wild, against which federal agencies are required to remediate. The KEV catalog is useful and has meaningfully accelerated remediation timelines for the vulnerabilities it covers. Its limitation, in the context of this argument, is that it covers exploitation that has already occurred. It cannot address the class of unpatched primitives that Huntress and Varonis keep documenting — vulnerabilities that have not yet appeared in catalogued exploitation campaigns but that carry clear and immediate exploitation potential. By the time a credential-leakage primitive appears in the KEV catalog, the hashes have already been collected.

Structural Separation of Platform and Security Product Revenue

The deeper intervention — more difficult politically, more significant structurally — is some form of mandated separation between a vendor's platform security remediation obligations and its security product revenue. This does not necessarily require breaking up Microsoft, though the antitrust arguments for doing so on security grounds are more substantial than is generally acknowledged. It could take less radical forms: mandatory disclosure requirements that force vendors to quantify the commercial relationship between non-remediation decisions and security product revenues; conflict of interest restrictions that require independent review of servicing threshold decisions by parties without a stake in the security product business; or regulatory guidance that explicitly identifies the platform-plus-security-product structure as a conflict of interest requiring management and disclosure.

None of these interventions is straightforward to implement. Microsoft will argue, with some justification, that the integration of platform and security functions produces genuine security benefits — that the visibility afforded by operating at both levels enables threat intelligence that standalone security vendors cannot replicate. This argument is not without merit. The question is whether those benefits outweigh the structural conflict of interest, and whether the conflict can be managed through disclosure and independent oversight without eliminating the integration entirely. The answer to both questions is probably yes, but reaching it requires a regulatory conversation that has not yet seriously begun in the United States and is only beginning in Europe.

What Defenders Should Do While Waiting for Accountability That May Not Come

Regulatory and structural reform operates on timelines measured in years. The search URI handler leaks credentials today. The practical question for defenders — the CISOs, security architects, and detection engineers reading this — is what to do in the gap between the accountability structures that exist and the ones that should.

The answer is not to wait for a patch. For this class of vulnerability, on this vendor's track record, the patch is not coming on any timeline that changes the immediate risk calculus. The answer is to build a control layer that operates above the CVE layer — one that addresses vulnerability classes rather than individual CVE instances and that is not dependent on vendor remediation decisions for its effectiveness.

For the credential-leakage primitive specifically, that means blocking outbound SMB on endpoints that do not require it — TCP ports 445 and 139 — at the network egress layer, not just in host firewall policy. It means enforcing SMB signing so that captured hashes cannot be relayed against internal services even if they are obtained. It means auditing NTLM usage across the environment and, where feasible after that audit, setting the RestrictSendingNTLMTraffic policy to its most restrictive value. It means alerting on search and search-ms URI handler invocations originating from browser processes, neither of which has legitimate business justification in normal traffic flows.

These are not complex mitigations. They are, notably, the exact mitigations that Microsoft recommends in lieu of patching. This is worth observing without irony: the vendor that declines to fix the vulnerability at the source provides detailed guidance on the network and policy controls that defenders should implement to protect themselves from it. The guidance is accurate. It is also guidance that requires exactly the kind of enterprise security expertise, tooling, and operational maturity that Microsoft sells. The recommendation to implement defense in depth is not wrong. The context in which it is made — as a substitute for remediation rather than a complement to it — is a precise illustration of the commercial dynamic this piece has documented.

More broadly, defenders should treat the servicing bar as a permanent feature of the threat landscape rather than an aberration they are waiting to see corrected. The pattern documented here — NTLM, Print Spooler, Exchange, SMBv1, URI handler credential leakage — is not a series of isolated failures awaiting resolution. It is a posture. It reflects a stable set of incentives that have produced consistent outcomes across two decades and multiple leadership regimes, and that will continue to produce those outcomes until external pressure makes them more expensive to maintain than to change. Building a security program around the assumption that Microsoft will eventually close these gaps is building on a foundation that the evidence does not support.

The organizations that have navigated this landscape most effectively are the ones that have accepted it for what it is — a vendor environment in which the platform owner has a documented, financially quantified interest in the partial persistence of the threat surface — and have built their control architecture accordingly. They do not wait for patches that are not coming. They do not treat the absence of a CVE fix as an anomaly requiring explanation. They treat the attack surface as a stable environmental condition and engineer their defenses against it directly, independent of the vendor's remediation timeline.

This is a higher bar than defenders should be required to clear. It requires more resources, more expertise, and more organizational maturity than a patching-centric security program. The additional burden is real, and it is borne entirely by the organizations and individuals that Microsoft's servicing decisions expose — not by Microsoft, which continues to collect platform licensing revenue and security product revenue from the same customer base whose exposure its decisions sustain. The externalization of that burden is, in the end, the most precise measure of what the servicing bar actually costs — and of who is paying for it.

Conclusion: The Bar Is Set Where the Money Is

Return, for a moment, to the beginning. A researcher at Huntress finds a vulnerability in a Windows URI handler. It is technically identical to a vulnerability Microsoft patched the previous day in a different handler. The CVSS score is the same. The attack primitive is the same. The outcome — Net-NTLMv2 hash delivered to an attacker-controlled server with a single link click, no malware, no payload, no complexity — is the same. Microsoft acknowledges it, rates it Moderate, and declines to patch it. The Security Response Center explains that this is the rule, and that patching it would have been the exception. The researcher publishes. The handler continues to leak credentials. Somewhere, a Defender for Identity alert fires.

This is not a story about one vulnerability. It is not even a story about one company, though Microsoft is the protagonist by virtue of scale, market position, and the particular clarity with which its conduct illustrates the underlying dynamic. It is a story about what happens when the entity responsible for securing a platform has a quantified financial interest in the partial persistence of that platform's insecurity — and when no external accountability mechanism exists to distinguish between a remediation decision made on engineering grounds and one made on commercial grounds.

The case this piece has made rests on four pillars. First, the pattern: NTLM deferred for twenty-six years while detection products matured around its exploitation; Print Spooler patched at the symptom level while the architectural primitive persisted; Exchange on-premises left architecturally vulnerable through a succession of critical incidents while the cloud product it competed against remained unaffected; SMBv1 enabled by default for years after its danger was documented, disabled only when a global ransomware catastrophe made inaction politically untenable. These are not isolated failures. They are a posture, consistent across product lines and leadership regimes, that systematically favors managed persistence over aggressive remediation.

Second, the beneficiary: a security division generating twenty billion dollars in annual revenue, doubling in two years, selling detection and response products whose commercial value is downstream of the threat surface that the platform decisions sustain. The financial relationship between incomplete remediation and security product revenue is not hidden. It is in the earnings transcripts. It is in the product marketing. It is in the architecture of the E5 licensing bundle, which packages threat detection capabilities at a price point justified partly by reference to the threats it detects.

Third, the decision-makers: not anonymous engineers operating below the threshold of executive awareness, but a leadership team whose compensation reflects their strategic acuity, who announce security revenue milestones on earnings calls, who testified before Congress about security failures they described as their own responsibility, and who launched a thirty-four-thousand-engineer security initiative in direct response to regulatory pressure — demonstrating, in that response, that the posture can change when external accountability makes change necessary. The "emergent" defense fails not because organizational complexity is fictional but because the executives responsible for the servicing threshold are precisely the people whose job it is to understand the dynamics this piece documents. Paying someone eighty-seven million dollars a year to understand these relationships and then claiming they don't understand this one is not a defense. It is an accounting error.

Fourth, the mirror: an open source ecosystem in which the same class of vulnerabilities, managed by maintainers with no commercial stake in their persistence, is addressed with a speed and completeness that Microsoft's thirty-four thousand security engineers have not matched. The difference is not resources. It is incentives. And incentives are set by people, consciously, in full awareness of what they produce.

What we are describing, to state it in the plainest possible terms, is a protection racket with better branding. Not in the criminal sense — no one at Microsoft is explicitly threatening to leave systems vulnerable unless customers pay for detection products. The mechanism is more elegant and more durable than that. The platform is left partially vulnerable because the partial vulnerability is profitable. The security products that monetize that vulnerability are sold to the same customers who bear its cost. The regulatory frameworks that might impose external accountability are managed through investment pledges, congressional testimony, and self-authored reform initiatives that define the terms of accountability before a regulator can. The researchers who document the gaps are acknowledged, thanked for responsible disclosure, and informed that their findings do not meet the bar. The bar is not lowered.

None of this requires a conspiracy. It requires only that the people making these decisions understand their interests — which, given their compensation, their public statements, and their demonstrated capacity to change course under sufficient pressure, they clearly do. The comfortable alternative — the emergent, structural, nobody's-fault framing — is not an analytical conclusion. It is a rhetorical service provided to an industry that benefits from its acceptance. The security research community, the analyst class, and the trade press that covers this space have been, on the whole, too generous in extending it.

The Huntress disclosure will be followed by another. A researcher will find the same primitive in a different handler, or a different primitive in the same handler, or something structurally equivalent in a component that neither Varonis nor Trellix nor Huntress has examined yet. It will be reported to Microsoft. Microsoft will assess it, rate it Moderate, measure it against the bar, and decline to patch it — unless the disclosure generates enough noise to qualify as an exception, in which case that specific manifestation will be addressed while the underlying architecture persists. The cycle will continue because the incentive structure that produces it has not changed, and will not change until external pressure makes it more expensive to maintain than to abandon.

That pressure has to come from somewhere. From regulators willing to impose patch obligations with teeth rather than self-reporting frameworks with none. From procurement officers willing to treat the servicing bar as a material risk factor in platform selection decisions rather than an acceptable industry norm. From the security research community treating the pattern of non-remediation as the story rather than the individual vulnerability that happens to illustrate it this month. And from defenders who understand that the security architecture they build must be constructed above the CVE layer — because the CVE layer, on the most consequential attack surface in enterprise computing, has a documented owner with a documented interest in where the bar is set.

The bar is set where the money is. It has been for twenty-six years. The question is how much longer the industry intends to pretend otherwise.

Jonathan Brown is a cybersecurity researcher and investigative journalist at bordercybergroup.com.

If you would like to support our work — useful, well-researched, ad-free cybersecurity intelligence — buy us a coffee: https://bordercybergroup.com/#/portal/support