Microsoft Uses Rust Language

Key Takeaways:

Rust 1.91 promoted aarch64-pc-windows-msvc to Tier 1, joining the x86_64 MSVC, x86_64 MinGW, and 32-bit MSVC Windows targets already at that level.

Microsoft’s MSRC assigns roughly 70% of the CVEs it tracks to memory-safety issues, which motivated the Rust adoption.

Microsoft’s windows-drivers-rs repo (1,923 stars, Apache-2.0) provides crates for building kernel-mode and user-mode drivers in Rust.

The current driver crates still require a “significant” amount of unsafe Rust, and Microsoft is developing safer abstractions with Rust experts.

What Tier 1 Actually Means

The Rust project organizes every compilation target into three tiers, and the difference between them is a guarantee about testing, not just a label. As the Rust 1.91 release announcement explains, Tier 3 targets are “technically supported” but nobody verifies whether the code builds or passes tests, and no prebuilt binaries are provided. Tier 2 targets are guaranteed to build, with prebuilt binaries available, but the test suite is not run on them, so a produced binary might contain bugs. Tier 1 is the highest level: the project runs its full test suite on that platform for every change merged into the compiler, and prebuilt binaries are published.

For a developer targeting Windows on Arm, that distinction matters. Before 1.91, aarch64-pc-windows-msvc was a Tier 2 target. You could build for it, but a subtle codegen or standard-library regression could appear in a stable release without being caught on that specific architecture. Promotion to Tier 1 means every merged compiler change is now tested against the Arm64 Windows build, so regressions are detected in CI before they reach a stable release rather than in a user’s production environment.

The practical upgrade path is one command. If you have a previous Rust toolchain installed through rustup, you move to 1.91 with:

rustup update stable

# Then confirm the Arm64 Windows target is available as a host tool
rustup target list --installed
# Expected output on an Arm64 Windows machine includes:
# aarch64-pc-windows-msvc

# Note: on an x86_64 host you would cross-compile by adding the target
# explicitly with `rustup target add aarch64-pc-windows-msvc` and providing
# a Windows Arm64 linker and import libraries.

Windows Targets Across the Tiers

Target triple	Platform	Tier
`x86_64-pc-windows-msvc`	64-bit MSVC (Windows 10+, Server 2016+)	Tier 1 with host tools
`aarch64-pc-windows-msvc`	ARM64 Windows MSVC	Tier 1 with host tools (promoted in 1.91)
`x86_64-pc-windows-gnu`	64-bit MinGW (Windows 10+, Server 2016+)	Tier 1 with host tools
`<\|im_end\|>UNSALVAGEABLE`	32-bit MSVC (Windows 10+, Server 2016+, Pentium 4)	Tier 1 with host tools

Why Microsoft Bet on Rust

Microsoft’s strategic reasoning goes back several years and is unusually well documented for an internal technology decision. In July 2019, the Microsoft Security Response Center published a post titled “Why Rust for safe systems programming” that laid out the case with numbers. About 70% of the security issues that MSRC assigns a CVE to are memory-safety issues. The post concluded that if that software had been written in Rust, 70% of those issues “would most likely have been eliminated.”

The argument was not that Rust is the only safe language. The MSRC team explicitly named C#, F#, Swift, Go, and Python as memory-safe options already widely used inside and outside Microsoft. The distinction they made was about systems programming: workloads that need the speed and predictable performance of C and C++, where a garbage-collected runtime causes “unpredictable performance and unnecessary overhead.” Rust is the language that provides memory safety without a GC, and with a standard library that is optional, so it can run on platforms without an operating system.

That 2019 post also noted something important for understanding the current moment: other teams at Microsoft had started adopting Rust for reasons beyond security, and an internal survey was already showing uptake. The MSRC team presented the safety argument as the starting point, not the whole story. Performance parity with C and C++, fine-grained control over allocation, and the ability to wrap unsafe operations in statically-enforced safe abstractions all contributed to why the language spread.

The public escalation came later. In 2022, Azure CTO Mark Russinovich posted that it was “time to halt starting any new projects in C/C++ and use Rust” for security and reliability, arguing the industry should declare those languages deprecated, as ZDNET reported. That is a strong position from the executive tier of Azure, and it indicates that the Rust commitment runs through the cloud division, not just the Windows kernel teams.

Rust in Windows Drivers

The most tangible result of Microsoft’s Rust investment is the windows-drivers-rs repository, which the company consolidated to provide Rust developers with the same tooling C developers have long had through the Windows Driver Kit. It is an Apache-2.0 licensed project created in September 2023, actively maintained, with 1,923 stars and 136 forks as of September 2026.

The repo includes several crates. wdk-build configures Cargo build scripts. wdk-alloc provides a global allocator suitable for kernel contexts. wdk-macros offers macros that simplify interaction with the WDK’s direct bindings. A companion project, cargo-wdk, is a Visual Studio extension that generates empty driver projects pre-populated with the linkage, build steps, and dependencies a driver needs, mirroring the templates C programmers have used for years.

A minimal driver skeleton in Rust using these crates looks roughly like this, though the exact API surface is still evolving:

The honest caveat, stated by Microsoft itself in its “Towards Rust in Windows Drivers” post, is that the current crates still require developers to write a “significant” amount of unsafe Rust. The Windows Driver Framework team is working with Rust experts to build safer abstractions, but Windows kernel APIs are difficult to handle, and Microsoft said addressing this will take time and cooperation across multiple teams. The long-term goal for cargo-wdk is to provide Rust developers with the same build tools and configuration options C programmers already have, with additional driver templates, code deployment to test machines, and full Arm64 support planned.

The 2030 Goal and What It Does Not Mean

The most attention-grabbing Rust-related statement from Microsoft came from distinguished engineer Galen Hunt, who wrote that his goal is to “eliminate every line of C and C++ from Microsoft by 2030,” with a strategy of combining AI and algorithms to translate Microsoft’s largest codebases to Rust. As ZDNET’s Steven Vaughan-Nichols reported, Hunt later clarified the most dramatic interpretation, writing that “Windows is not being rewritten in Rust with AI.”

The clarification is important because the two statements describe different things. Eliminating C and C++ from new and actively maintained components over five years is an ambitious but limited goal. Rewriting the entire Windows codebase in Rust is a different project, and Hunt explicitly denied it. The difference matters for anyone trying to understand Microsoft’s actual plans: the company is expanding Rust into security-critical components and new systems work, not attempting a full translation of the operating system.

The AI aspect is real but separate. Microsoft CEO Satya Nadella said 20% to 30% of Microsoft’s code was “written by software,” and Russinovich has described AI agents that take an issue, set up an environment, modify code, and open pull requests. But Russinovich also warned that LLM hallucination, prompt injection, and jailbreaks pose “significant but surmountable” challenges, and ZDNET noted that Torvalds has called using AI to generate long-lived production code a “horrible idea” for maintainability. The Rust commitment and the AI commitment are related but distinct, and mixing them misrepresents both.

Limitations and Trade-offs

The tier promotion and the driver tooling do not make Rust completely smooth at Microsoft, and the company’s own documentation is clear about where the gaps remain. Three points stand out.

First, the unsafe boundary is real and large in kernel work. Writing a driver still means interacting with raw kernel APIs that the safe abstraction layer does not yet cover. Rust’s memory-safety guarantee applies to code outside unsafe blocks; in a driver, a meaningful portion of the code is inside them, which reduces the benefit until Microsoft’s safer abstractions arrive.

Second, Rust is not the only safe language Microsoft uses, and the MSRC team said so directly. For workloads that do not require systems-level performance, C#, F#, and other managed languages were already memory-safe and widely deployed. Rust’s advantage applies to the niche where a GC is unacceptable, and pushing Rust into every project would be a category error, not a security improvement.

Third, the broader software ecosystem is still catching up on Arm64 Windows. Promoting the target to Tier 1 fixes the compiler’s guarantee, but dependencies, build scripts, and native libraries in a given crate graph still need Arm64 Windows binaries. A Tier 1 target does not make every third-party crate cross-compile cleanly; it makes the foundational toolchain reliable so that the rest of the stack can build on a stable base.

For developers following this area, the signal to watch is not the tier label itself but the pace of safer abstraction work in windows-drivers-rs and the rate at which Rust appears in shipping Windows components. As we covered in our breakdown of the Rust compiler pipeline and borrow checker, the language’s guarantees are only as valuable as the safe surface area a team actually exposes. Microsoft’s tier-1 status for Rust is the foundation; the safe abstractions built on top of it are where the security benefits will actually appear.

More in-depth coverage from this blog on closely related topics:

Sources and References

Sources cited while researching and writing this article: