Microsoft reshapes C# unsafe code with Rust-like safety boundaries
Microsoft is turning C#’s unsafe keyword into a sharper safety boundary, borrowing Rust’s discipline without giving up the managed runtime. The catch is that ownership and borrow checking still do the hard work Rust does.

Rust keeps forcing the rest of the industry to redraw its safety lines. Microsoft is now doing that in C#, where the .NET team is recasting unsafe from a loose marker for pointer-heavy code into a compiler-enforced boundary around memory operations the compiler cannot prove safe.
The change is bigger than a keyword tweak. Microsoft’s new model broadens unsafe beyond raw pointers to any memory interaction the compiler cannot validate, and it makes unsafe code explicitly carry obligations that callers can see. Richard Lander said the team is “in the process of significantly improving memory safety in C#,” and that is the right framing: this is Microsoft tightening the contract around where managed code deliberately steps outside the guardrails, not abandoning automatic memory management.

The rollout follows a familiar Microsoft playbook. The feature is planned as a C# 16 capability, previewing in .NET 11 and becoming a production feature in .NET 12. It starts opt-in, with Microsoft saying it may become the default later, and the company plans to update templates so new projects enable the model by default, much as it did for nullable reference types. That earlier feature, introduced in 2017, taught C# developers to treat nullability as a compiler-enforced discipline instead of a convention, and the new unsafe work looks like the same move applied to memory access.
That is also where the Rust comparison gets sharp. C# can become stricter about where unsafe lives, and it can make those boundaries obvious to reviewers and AI-assisted code generators. What it still cannot do, at least not without changing its language model entirely, is replicate Rust’s ownership system and the guarantees that come with it. Managed runtime checks can keep a lot of bad memory access out, but they do not give you Rust’s compile-time proof that aliasing, lifetimes, and mutation are all being handled correctly.
Microsoft’s timing fits a wider company pattern. The Secure Future Initiative launched on November 2, 2023, and Brad Smith said on May 3, 2024 that Microsoft should prioritize security above all else. Visual Studio Magazine has traced Microsoft’s memory-safety push back to 2019, across Windows, cryptography, Azure SDKs, and systems-level guidance. Microsoft has also shipped an Azure SDK for Rust and made it stable on May 14, 2026, while its C++ team added Rust-inspired safety rules to C++ Core Check back in September 2020.
That is the real signal here. Microsoft is not turning C# into Rust, but Rust is clearly shaping what Microsoft thinks safe code should look like: explicit, reviewable, and hard to hand-wave away.
This article was produced by Prism’s automated news system from verified source data, official records, and press releases, then run through automated quality and moderation checks before publishing. The system is built and supervised by the people who set the standards it runs under. Read our full AI policy.
Know something we missed? Have a correction or additional information?
Submit a Tip

