Microsoft's new default is Rust

Roughly 70 percent of the security patches Microsoft shipped every year for more than a decade fixed one category of bug: memory safety. Microsoft’s own Security Response Center put that number on a conference slide in 2019, and it barely moved in the years that followed. That statistic is why Rust now sits beside C, C++, and C# as a tier-1 language inside the company that built Windows on those older languages.

What “tier-1” actually buys you

When a company names a language tier-1, it signs a support contract with itself. A tier-1 language gets a compiler the company maintains or funds, first-class build tooling, security review, internal training, and clearance to ship in production code that millions of people run. C and C++ held that status at Microsoft for thirty years. C# earned it. Adding Rust to that list means an engineer can start a new systems component in Rust without writing a justification memo, fighting the build pipeline, or getting a special exception signed off.

Mark Russinovich, the chief technology officer of Microsoft Azure, said the direction out loud in September 2022. New projects, he wrote, should use Rust rather than C or C++ for reasons of security and reliability. That is a striking instruction from the person accountable for the cloud platform underneath a large share of the internet. He was not describing a lab experiment. He was setting a default for how new code gets written.

Defaults decide what actually gets built. An engineer under deadline reaches for whatever the tooling makes easy. Moving Rust to tier-1 changes the path of least resistance, and over a few years that reshapes what ships.

The bug class that refuses to die

Memory safety sounds abstract until you see what it costs. In C and C++, the programmer manages memory by hand. You ask the system for a block of memory, you use it, and you give it back. Every step is an opportunity to get it wrong.

Three mistakes account for most of the damage. A buffer overflow writes past the end of the space you reserved, spilling attacker-controlled data into memory that runs code or holds other values. A use-after-free keeps using a pointer to memory you already handed back, so an attacker who reclaims that space controls what your program reads. A double free releases the same block twice and corrupts the bookkeeping that tracks what is free.

These are not exotic. Heartbleed, the 2014 flaw that leaked private keys and passwords from servers running OpenSSL, was a buffer over-read: the code trusted a length field and copied back far more memory than it should have. EternalBlue, the Windows SMB flaw that powered the WannaCry ransomware outbreak in 2017 and shut down hospitals in the United Kingdom, traced back to memory corruption in how the protocol parsed packets. Different decades, same root cause.

A skilled C programmer can avoid these bugs on a good day. The problem is that a large system has millions of lines written by hundreds of people over many years, and the language offers no help catching the mistake. One wrong pointer in a codebase that size is a security incident waiting for a researcher to find it.

What Rust checks before the code runs

Rust attacks the problem where it starts, at compile time. Its compiler enforces a set of ownership rules: every piece of data has one owner, the compiler tracks how long that data lives, and it refuses to build code that could read or write memory after it has been released. The borrow checker, the part of the compiler that does this, rejects the exact patterns that produce use-after-free and data races. The program does not compile until the mistake is gone.

This matters because it moves the discovery of the bug from production, where an attacker finds it, to the developer’s screen, where it costs a few minutes. A memory safety flaw that would have become a CVE, a patch cycle, and a scramble instead shows up as a red error message before the code ever merges.

Rust gets there without a garbage collector, the background process that languages like Java and Go use to reclaim memory automatically. Garbage collection adds pauses and overhead that make those languages a poor fit for an operating system kernel or a network driver. Rust does its checking during compilation and adds nothing at runtime, which is why it can replace C and C++ in the low-level systems work where they had no real competition.

Rust is not magic, and it does not pretend to be. It includes a keyword, unsafe, that lets a programmer switch off some of the compiler’s checks for the rare block of code that needs to talk directly to hardware or to old C libraries. The value is that unsafe marks those spots. Instead of auditing millions of lines for memory bugs, a security team reviews the small fraction the programmer had to flag by hand.

Where the Rust code already runs

This is not a plan on a whiteboard. In 2023, David Weston, who leads OS security at Microsoft, confirmed that Rust code had reached the Windows kernel itself. The company rewrote a portion of the graphics and font-handling code, historically a rich source of exploits, in Rust and shipped it in Windows 11 preview builds. Kernel code is the most privileged and least forgiving place to run software, and Microsoft chose it as a proving ground rather than a toy project on the edge.

Azure runs Rust in production infrastructure. Microsoft also put money and governance behind the language: in 2021 it joined the Rust Foundation as a founding member, alongside Amazon Web Services, Google, Huawei, and Mozilla, which created Rust in the first place. Competitors who agree on almost nothing agreed that the memory safety problem was worth funding a shared solution.

Google reported the payoff from its own side. In a 2024 writeup, Google’s Android security team said the share of memory safety vulnerabilities in Android fell from 76 percent in 2019 to 24 percent in 2024. They did not rewrite the old code to get there. They wrote new code in memory-safe languages, and the vulnerability rate dropped as the proportion of risky new code shrank. That is direct evidence that the strategy works at the scale of a shipping operating system.

Why this is a start, not a finish line

Rust closes one class of bug. It does not close the others, and pretending otherwise sets you up to be surprised.

A Rust program will still ship logic errors. It will still trust input it should reject, expose an API without an authorization check, build a SQL query by pasting strings together, or leave a cloud storage bucket open to the world. None of those are memory safety problems, and the borrow checker has nothing to say about them. The 30 percent of Microsoft’s CVEs that were never about memory do not go away.

The unsafe keyword is a real seam. Code inside an unsafe block can reintroduce every bug Rust was meant to prevent, and any Rust program that talks to an existing C library crosses a boundary where the guarantees stop. Those boundaries are where a careful attacker looks first.

Rewrites are slow and expensive. Windows and Azure contain tens of millions of lines of C and C++ that work, carry decades of hard-won fixes, and will not be rewritten in Rust in this decade or the next. Most of the safety gain comes from writing new code in Rust and leaving stable old code alone, which means the payoff arrives gradually rather than all at once.

The supply chain is a live risk too. Rust projects pull in outside packages, called crates, from a public registry. A memory-safe language does not protect you from a malicious or compromised dependency, and that attack has already hit other ecosystems repeatedly.

What this means beyond Microsoft

Microsoft moving Rust to tier-1 is one data point in a pattern that now includes governments. The United States Cybersecurity and Infrastructure Security Agency, together with the National Security Agency and international partners, has published guidance urging software makers to adopt memory-safe languages and to publish roadmaps for doing so. In February 2024, the White House Office of the National Cyber Director released a report, “Back to the Building Blocks,” that named memory-safe languages as a way to reduce entire categories of vulnerability at the source. The regulator is now in the room where the language choice gets made.

For most readers, the practical takeaway is a question to ask rather than code to write. If you buy, commission, or depend on software, ask the vendor what language new systems components are written in and whether memory-safe languages are the default for new code. A vendor still starting fresh projects in C with no plan to change is carrying a risk that the largest software companies and several governments have already decided to spend money to retire. The answer will not tell you everything about their security, but it tells you whether they are paying attention to the single bug class that produced most of the last decade’s memory-corruption CVEs.