Saved passwords in Edge memory: what we're changing and why
Browsers help protect some of the most sensitive data people have, including passwords. That’s why we continuously review how Edge handles that data, and where we can further reduce exposure through defense-in-depth improvements as part of Microsoft’s Secure Future Initiative (SFI).
Last week, a security researcher publicly disclosed that Edge loads saved passwords into process memory in cleartext at startup. Based on our existing criteria, this behavior falls within the expected threat model, since the risk begins after an attacker has already compromised the device. At the same time, we believe there’s opportunity to improve. In this blog, we’ll show you what we’re changing and why.
We’re addressing the originally reported issue immediately
We will no longer load passwords into memory on startup. This defense-in-depth change will come to every supported version of Edge (Stable, Beta, Dev, Canary, and the Extended Stable channel our enterprise customers run), and we’re prioritizing the rollout. The change is live now in Edge Canary and included in the next update for all Edge releases, build 148 and newer.
If you use Edge’s password manager today, you don’t need to take any action. The change will reach you through the normal update channel.
Why there is no new customer exposure
We care deeply about the trust customers place in Edge, especially when it comes to protecting sensitive data like passwords. Your first question and our first investigation is the same: ‘Does this mean I’m exposed?’
In this case, the answer is no.
This is because the reported scenario requires an attacker who already has control of the user’s device. Once the attacker can run unsafe software locally as admin, the situation is beyond the defenses of the browser (or any application). The threat model for our password manager is explicit that physically local attacks and malware running with elevated privileges are out of scope, and that’s consistent with every modern browser.
In other words, the report does not raise a new avenue for attackers to access credentials through the browser itself.
Our commitment to defense-in-depth
Even for issues that don’t meet the security criteria, Edge invests heavily in defense-in-depth. We run sophisticated sandboxes, we isolate renderers, and we work hard to break attack chains even within a single privilege boundary, because real-world attacks are almost never a single clean step. We have proactive defenses like Scareware blocker to protect users from sites acting in bad faith.
With our commitment to the Secure Future Initiative and customer feedback, we are taking a broader view. That means looking not only at whether something meets the bar for a security issue, but also at where we can reduce exposure through defense-in-depth improvements. In this case, reducing the exposure of passwords in memory is a practical step in that direction.
Report handling in the future
Keeping customers safe requires not just strong defenses, but strong processes. Our initial response was based on the shared security criteria for the Chromium project. That’s a baseline and we hold ourselves to a higher bar. So we’re reviewing how we handle researcher reports, with a focus on speed, clarity, and applying defense-in-depth thinking earlier. We’ll share what we’ve learned, along with the improvements we’re making.
We thank the security research community for raising concerns. We take your reports seriously and remain focused on earning and keeping our customers’ trust.