The Vault That Stays Open

Not in the Brief ■ Episode 02

Open Microsoft Edge. Do nothing in particular: do not visit your bank, do not visit your email, do not even open a new tab. The browser, working diligently in the background and without any prompt from you, has just unlocked every password it has ever saved on your behalf, decrypted them in one go, and laid the entire collection out as plain ASCII inside the msedge.exe process. The credentials for the site you have not visited since the second lockdown sit there, fully readable, next to the ones for the site you opened five minutes ago. They will stay there until you close the browser.

This is not a bug. It is, in Microsoft's own words, a design decision. The Edge team's response to a security researcher's disclosure, reported across the press in late April and early May 2026, contains the phrase that gives this episode its title in spirit: the architecture "balances performance, usability, and security", and the company does not, on its own analysis, consider the behaviour a defect to be fixed.

This is the second episode of Not in the Brief: a series on the documented mechanics of software added to your machine without you being asked. Episode 01 covered the AI model your browser downloaded silently. Episode 02 covers the password vault your browser opens silently. The same grammar; a different chamber of the same building.

The Feature

Edge's password manager is, on the surface, the standard browser-built-in vault. You enter a credential on a site, the browser offers to remember it, the next visit autofills the field. That part is in the brief. The part that is not in the brief is what happens between the moment Edge launches and the moment any of those credentials is actually needed.

When the browser starts, the saved credentials are pulled from the encrypted store on disk and decrypted en bloc into msedge.exe. The decryption is eager: it does not wait for the user to visit a site, click into a field, or use the autofill UI. It is complete: every stored credential is decrypted, not only the ones for domains the user happens to visit in this session. From the end of the launch sequence until the browser exits, the entire vault sits in cleartext inside the parent Edge process.

If the user opens Edge for the morning, leaves it running until lunch, then locks the workstation and walks to a meeting, the vault is open the entire time. No active session is required, no use of any saved password is required, no interaction with the password manager UI is required. The browser is running. The vault is open.

The Introduction

The behaviour was disclosed by security researcher Tom Jøran Sønstebyseter Rønning at Palo Alto Networks Norway's "BIG Bite of Tech" event on 29 April 2026, with a short demonstration video posted to LinkedIn on 4 May. The video accumulated several thousand engagements within hours and was picked up over the following days by Cybernews, DarkReading, the SANS Internet Storm Center, PCWorld, Security Magazine, Heise, PC Gamer, Windows Central and a dozen smaller outlets. The mechanics are reproducible: any reader can verify the entire claim on their own machine in under five minutes, with two free downloads and no exploit.

Microsoft's response, attributed to the Edge team via media contacts and consistent across outlets, treats the finding as an architectural statement rather than a vulnerability. The reported wording is uniform: the behaviour is "by design"; access to the affected memory requires the device to be compromised at administrative or SYSTEM level; the trade-off is between "performance, usability, and security"; and the company does not consider the matter a security issue requiring a fix. On its own terms, that response is internally coherent. On the terms of how credential-harvesting actually proceeds in 2026, it is missing a fairly important wing of the building.

The Mechanics

To understand why this design is unusual rather than ordinary, one has to set it next to the other Chromium browsers in the same room. Chrome, on which Edge is technically based, takes two architectural steps that Edge does not.

The first is laziness, used here in its precise technical sense. Chrome's saved-credential store remains encrypted in the user profile and stays that way in memory until a particular credential is needed. Only at the moment of autofill, password reveal, or password-manager UI use does Chrome decrypt the relevant entry, and the cleartext value lives in process memory only as long as the operation requires. The vast majority of the vault is encrypted at any given moment, including at any moment an attacker with memory-read access happens to look.

The second is Application-Bound Encryption, or ABE. Since mid-2024 Chrome has tied the decryption keys for the Windows credential store to the authenticated Chrome process running as SYSTEM. The mechanism makes the keys non-portable: an attacker with local administrator rights but without SYSTEM cannot simply extract the keys and decrypt the vault outside Chrome's own process tree. ABE is documented in Chrome's security blog, shipped by default, and present in the Chromium sources that Brave, Opera and Vivaldi inherit from.

Edge takes neither step. Decryption is eager and complete at launch. There is no equivalent of ABE. The credential vault is opened against the user's Windows credentials and the cleartext result lives in msedge.exe without any further binding to the authenticated process. Of the major Chromium-based browsers tested by Rønning (Chrome, Edge, Brave, Opera, Vivaldi), Edge is the only one with this architecture; the others all defer decryption to the moment of use.

It is worth being precise about what this means. The difference is not "Edge encrypts at rest and Chrome does not". Both encrypt at rest. Both have to decrypt to fill. The difference is the lifetime of the cleartext window in memory. For Chrome it is measured in milliseconds, per credential, per use. For Edge it is measured in hours, for the entire vault, for the whole session, regardless of use.

The Risk

The Microsoft argument deserves to be stated fairly. It runs as follows. Process-memory inspection requires elevated privileges. If an attacker already has those privileges, the device is already lost; cleartext credentials in memory are a non-issue against an attacker who can already read arbitrary memory. The architecture therefore offers no extra attack surface to anyone who is not already past the door.

The first half of that argument is true. The second half is the part that does not survive contact with how credential-harvesting actually works in 2026.

Process-memory inspection is the standard technique used by credential-stealing malware. It is precisely the class of access that routinely succeeds against three categories of machine where the local-administrator versus SYSTEM distinction is more than a footnote. Shared workstations in healthcare, education, retail, and contact centres routinely give multiple users administrative-equivalent rights on the same desktop without granting SYSTEM; reading another user's msedge.exe from a parallel session is a documented path. Kiosk and unattended machines (logged-in, unlocked, often left running for the whole shift) have always been the canonical credential-harvest target; "Edge stores everything decrypted whether or not it is being used" is precisely the wrong design for them. Forensic and incident-response tools that legitimately read process memory, and the malware families that imitate them, operate against the same address space; the entire point of the lazy-decryption and ABE design that other browsers ship is defence-in-depth against this category.

The deeper architectural observation is that the Microsoft response is not, in fact, a defence of the architecture against the threat model. It is a redefinition of the threat model: "we accept that an admin-level attacker can read these credentials, and we have decided that this is the correct boundary". That is, in principle, a position an engineering organisation may take. It is not the position other browsers in the same Chromium family have taken, and it is not the position the user reasonably assumes when they enable a password manager. The brief, on installing a browser-built-in vault, includes a baseline expectation of "encrypted at rest, decrypted on demand, minimised in memory". Edge, by design, has decided to discard the third part of that expectation.

It is worth restating the company's own framing generously: the Edge team describes the trade-off as one between performance, usability and security. The performance benefit, on 2026 hardware, is negligible: the on-demand decryption of an individual password is a microsecond operation. The usability benefit is inferential: marginal autofill latency is the case being made, though no published measurement seems to support it. The security cost is the difference between a vault that opens for the second it is needed and a vault that opens for the whole session. That cost is real, it is paid by every user of Edge with at least one saved credential, and the user, on installing the browser, was not invited to weigh the trade-off the design defends.

The scale of the choice is enterprise. Edge is the default browser on Windows 11 and the mandated browser in many corporate, healthcare, government and education environments where Group Policy reduces user choice. The architectural decision, in aggregate, applies to the credential vaults of hundreds of millions of users by virtue of deployment, not by individual request.

How To See It

The architecture is verifiable on any current Windows machine running Edge with at least one saved password. The procedure takes under five minutes and uses only the standard Windows administrator role; there is no exploit and no privileged tooling beyond the Microsoft Sysinternals suite, which is a free Microsoft download.

1. Confirm a saved credential exists. Open edge://settings/profiles, select the profile, click "Passwords". A list of saved sites should be visible. If the list is empty, save a credential to a non-sensitive test account before continuing — a throwaway login on any test page will do.
2. Open a process inspector. Either Process Explorer from Microsoft Sysinternals or System Informer (the open-source successor to Process Hacker) will work. Locate the parent msedge.exe process; Edge spawns multiple children for tabs and renderers, but the parent is the one with the highest memory footprint and the longest uptime.
3. Inspect the process strings. In Process Explorer: right-click msedge.exe → Properties → Strings tab → Memory radio button. In System Informer: right-click the process → Properties → Memory tab → Strings. Search the resulting list for the site URL of the saved credential. The cleartext password value is typically visible in plain ASCII within a few lines of the URL.

The verification is reproducible without any exploit and without any privileged tooling beyond the standard Windows administrator role. The browser is operating exactly as Microsoft has documented its architecture to operate.

The Honest Mitigation

The simpler answer, for the user who has now seen the vault on their own screen, is to stop putting credentials into Edge. Two recommendations stand out, and they are recommendations the dedicated security community has been making for several years independently of this disclosure.

KeePassXC is an open-source, locally encrypted password manager with a clean threat-model statement and explicit memory hygiene: only the credential being filled is decrypted at any given moment, and the decrypted buffer is zeroed after the operation completes. The desktop application ships with a browser extension for Edge, Chrome and Firefox; autofill behaviour, from the user's point of view, is identical to the browser-built-in.

Proton Pass is the comparable hosted option from the Swiss company that publishes Proton Mail and Proton Drive, audited, end-to-end encrypted, and with the same memory hygiene posture in its desktop and browser clients. It is a paid service; the free tier is functional. For users unwilling or unable to host a local credential database, Proton Pass occupies the same architectural slot as KeePassXC with less administrative cost.

Disabling Edge's built-in password manager itself is a two-line operation. For the individual user, navigate to edge://settings/passwords and toggle off "Offer to save passwords"; the existing entries can be exported to CSV and imported into the chosen replacement. For an enterprise estate, the Group Policy PasswordManagerEnabled = 0 disables the built-in store organisation-wide, removes the autofill UI, and removes the eager-decryption behaviour because there is nothing for Edge to decrypt.

The honest qualification, and it should be made plainly: any password manager that holds credentials in memory at any time is, in some attack scenarios, also vulnerable to memory inspection. The dedicated managers minimise the window: they decrypt only the credential being filled, then zero the buffer. The defence is not perfect; it is the difference between a vault that opens for milliseconds during one autofill and a vault that opens for the entire browsing session. In the threat model that actually shows up in incident response, that difference is the entire point.

A Note on Tone

This article does not argue that the Edge team has been dishonest. The architecture is openly documented; the researcher's finding has been met with a documented architectural rationale, which is what an engineering organisation is supposed to do under disclosure. The article argues that the rationale is wrong about the threat model in the operational environments where Edge is most heavily deployed, and that the user, on installing a browser with a password manager, was not given the chance to decline the trade-off the rationale defends.

That is the entire grammar of Not in the Brief. Software does many things. Some of them are in the brief; some of them are not. The architecture is what it is; the user's right to know is independent of whether the vendor finds the question interesting.

Closing

A password manager built into a browser is, by construction, a threat-model compromise: the convenience of autofill at the cost of holding credentials inside a process that also runs untrusted JavaScript, renders attacker-controlled HTML, and exposes one of the largest attack surfaces shipped to consumer machines. Different browsers have made different compromises along the same axis. Chrome chose lazy decryption and Application-Bound Encryption. Brave, Opera and Vivaldi inherited that shape. Edge chose neither, and named the choice a design.

The user, in 2026, can now see the vault open on their own screen in five minutes. The seeing changes the brief. From now on, leaving credentials in Edge is a choice, not an unconscious default. That is the part of awareness this series exists for: not to alarm, but to make the question visible.

The architecture answered the security question. It just answered it in the wrong direction, and quietly. The vault is open. You can close it.

Microsoft Edge loads the entire saved password vault into msedge.exe at launch and decrypts every credential into process memory in cleartext. The cleartext sits in RAM for the whole session, regardless of whether any of those sites is visited. Disclosed by Tom Jøran Sønstebyseter Rønning at Palo Alto Networks Norway's "BIG Bite of Tech", 29 April 2026; reproduced in five minutes with Process Explorer or System Informer. Microsoft's response: "by design", balancing performance, usability and security; not classified as a security issue. Chrome since 2024 decrypts lazily and binds keys to the SYSTEM-level Chrome process via Application-Bound Encryption; Brave, Opera and Vivaldi inherit the lazy behaviour. Edge, of the major Chromium family, is the only one with this architecture. Mitigations: stop saving in Edge, use KeePassXC or Proton Pass, disable per estate via Group Policy PasswordManagerEnabled = 0.