Not in the Brief, Episode 02
Open Microsoft Edge. The browser silently decrypts every password it has ever saved for you, and keeps the entire collection in process memory, in cleartext, for as long as the browser is running. The credentials for the site you visit today are decrypted; so are the credentials for the site you have not visited since 2021. Microsoft's response, when this was reported by the security community, was that the behaviour is intentional, and that the design "balances performance, usability, and security".
This is an architectural review of a default the user did not configure, written from the point of view of the user who can find it on their own machine in about five minutes.
The Feature
Edge's password manager is, in surface terms, the standard browser-built-in vault: 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 at startup.
When the browser launches, the saved credentials are loaded into the msedge.exe process and decrypted en bloc. From that point until the browser is closed, the entire vault sits in process memory in cleartext. Whether the user visits any of the corresponding sites in this session is irrelevant; the credentials are decrypted whether they are needed or not. The decryption is not lazy. It is eager, complete, and silent.
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" conference on 29 April 2026. A demonstration video was published on LinkedIn on 4 May; it accumulated several thousand engagements within hours and was picked up across the security press (Cybernews, DarkReading, SANS Internet Storm Center, PCWorld, Security Magazine, Heise) over the following days.
Microsoft's official response, attributed to the Edge team via media contacts, treated the finding as a design statement rather than a vulnerability. The wording reported across multiple outlets is consistent: the behaviour is "by design"; access to the affected memory requires the device to be compromised at administrative or SYSTEM level; the relevant trade-off is between "performance, usability, and security"; and the company does not, on this analysis, consider it a security issue requiring a fix.
That position is, on its own terms, internally coherent. It is also incomplete in a way the rest of this article will set out.
The Mechanics
To understand why the design is unusual, the comparison with the rest of the Chromium family is necessary. Chrome, on which Edge is technically based, takes two architectural steps that Edge does not.
First, Chrome decrypts saved credentials lazily. The vault is encrypted at rest in the user profile and stays that way until a particular credential is needed; only at the moment of autofill or password reveal does Chrome decrypt the relevant entry, and the decrypted value lives in memory only as long as the operation requires. The vast majority of the vault remains encrypted in memory at any given moment.
Second, since 2024, Chrome adds Application-Bound Encryption (ABE) to the Windows credential store. ABE ties the decryption keys to the authenticated Chrome process running as SYSTEM, so even an attacker with administrative privileges on the local machine cannot trivially extract the keys: the SYSTEM-level binding makes the decryption non-portable across processes. The mechanism is documented in Chrome's security blog and is standard behaviour in current releases.
Edge, as Rønning reports and multiple outlets have replicated, takes neither step. Decryption is eager and complete at launch. There is no analogue of ABE; the credential vault is opened against the user's Windows credentials and the cleartext result lives in msedge.exe memory without further binding. Of the major Chromium-based browsers tested by the researcher (Chrome, Edge, Brave, Opera, Vivaldi), Edge is the only one with this architecture.
The Risk
The Microsoft argument is straightforward: process-memory inspection requires elevated privileges; if an attacker has those, the device is already lost; cleartext credentials in memory are a non-issue against an attacker who can already read arbitrary memory. The first half of that argument is true. The second half is the part that does not survive the contact with how credential-harvesting actually works in 2026.
Process-memory inspection is the standard technique used by credential-stealing malware against three categories of machine where it routinely succeeds even when the local-admin / SYSTEM distinction is more than a footnote. Shared workstations in healthcare, education, retail, and contact-centre environments routinely give multiple users administrative-equivalent rights on the same desktop without granting SYSTEM, and process-memory inspection across other users' Edge sessions is a real path. Kiosk and unattended machines (logged-in, unlocked, often left running) have always been a credential-harvesting target; "Edge stores everything decrypted whether or not it is being used" is precisely the wrong design for them. Forensic and IR tools that legitimately read process memory (and the malware that imitates them) operate in the same address space; defence-in-depth is what other browsers' lazy decryption and ABE were specifically meant to deliver.
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 a legitimate position to take. It is not, however, the position that other browsers in the same Chromium family have taken, and it is not the position that 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.
The choice is not malice. It is, the company says, a balance between performance, usability, and security. The performance benefit, in 2026 hardware, is negligible: lazy decryption of an individual password takes microseconds. The usability benefit is inferential: marginal latency on autofill is the case the company is making. The security cost is the difference between "encrypted vault with on-demand decryption" and "fully decrypted vault, always, regardless of need". That is a real cost, and the architecture pays it whether or not the user is informed.
The most precise form of the criticism is structural. Edge is, by virtue of being on Windows, the default browser on the largest installed base of consumer operating systems in the world. Its password-manager is the path of least resistance for users who simply tick "yes, save this password" when prompted. The architectural decision affects, in aggregate, hundreds of millions of credential vaults that the user did not consciously enrol in this design.
How To See It
The architecture is verifiable on any Windows machine running a current Edge with at least one saved password. The procedure takes under five minutes.
Step 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 (a throwaway login on a test page works) before continuing.
Step 2: Open a process inspector. Either Process Explorer (procexp.exe, Microsoft Sysinternals, free download) or System Informer (open-source successor to Process Hacker) will work. Locate the parent msedge.exe process; Edge spawns multiple children, the parent is the one with the highest memory footprint and the longest uptime.
Step 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 string list for the site URL of the saved credential. The cleartext password value is typically visible in plain ASCII near the URL string.
The verification is reproducible without any privileged tooling beyond the standard Windows administrator role. No exploit is involved. The browser is operating exactly as Microsoft has documented its architecture to operate.
The simpler mitigation, for the user who has now seen it: do not save credentials in Edge. Move them to KeePassXC or Proton Pass. Both treat memory hygiene as a first-class concern in their threat models, and both stand outside the jurisdictional and commercial structures that make several of the better-known SaaS-based managers harder to recommend with full confidence in 2026. Disable Edge's password-manager via edge://settings/passwords (toggle off "Offer to save passwords") or, in managed environments, via the Group Policy PasswordManagerEnabled = 0. The autofill convenience is replaced cleanly by either manager's browser extension.
The honest qualification. A 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. That is meaningfully different from "decrypt everything at launch and leave it there". The defence is not perfect; it is the difference between a vault that is open for milliseconds during an autofill and a vault that is open for the entire browsing session.
A Note on Tone
This article does not argue that Microsoft's response is dishonest. It is internally consistent and openly published; the Edge team responded to a security researcher's finding with a documented architectural rationale, which is what an engineering organisation should do under disclosure. The article argues that the rationale is wrong about the threat model, and that the user, on installing the browser, was not given the chance to decline the trade-off the rationale defends.
That is the entire grammar of the series. 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
The vault was always going to be a difficult building. 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 a vast attack surface. Different browsers have made different compromises along the same axis. Chrome chose lazy decryption and Application-Bound Encryption. 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.
If you have not looked, you do not know what is in memory. The looking is not difficult. It just has to start.
Read the full article on vivianvoss.net →
By Vivian Voss, System Architect and Software Developer. Follow me on LinkedIn for daily technical writing.
Top comments (1)
One angle this doesn't cover: crash dumps. When Edge crashes or Windows BSODs, process memory gets written to disk — minidumps in %LocalAppData%\CrashDumps, full dumps in %SystemRoot%\MEMORY.DMP. With eager decryption, those dump files contain the entire vault in cleartext, sitting on disk indefinitely. If Windows Error Reporting is enabled (it is by default), they can get uploaded to Microsoft's telemetry servers too. So it's not just a volatile-memory problem — the credentials get persisted to unencrypted files that survive reboots and potentially leave the machine entirely. Chrome's lazy decryption limits crash dump exposure to whichever single credential was mid-autofill at the instant of the crash, which is usually none.