On April 29, researchers at Palo Alto Networks Norway published a finding about Microsoft Edge: the browser loads every saved password into unencrypted memory at launch and keeps them there for the entire session. Not just passwords you actively use. All of them. Plaintext. Accessible to any process or administrator with sufficient privilege on the same machine.
Microsoft's response: this is working as intended.
"By design" is becoming one of the most dangerous phrases in enterprise security. It shows up every time a researcher finds something that looks like a vulnerability, Microsoft confirms the behavior, and nobody is required to fix it. PrinterBug was by design. Several Active Directory Certificate Services escalation paths were by design. And now Edge password storage is by design.
For most enterprise environments, this is a meaningful but manageable credential theft risk. For OT environments, the picture is different.
What the finding actually means
The difference between Edge and Chrome comes down to when decryption happens:
| Browser | When passwords are decrypted | How long they sit in plaintext |
|---|---|---|
| Microsoft Edge | On launch, all at once | Entire session — until browser closes |
| Google Chrome | On demand, per credential | Brief window during autofill or manual view only |
Chrome uses App-Bound Encryption, introduced in 2024, to tie credential decryption to a specific application and moment in time. Edge doesn't. The result: any process running as administrator on a Windows machine with an active Edge session can walk the browser's memory and extract every saved credential.
Edge still prompts you for your Windows password before displaying credentials in its settings UI. That's the only visible security layer. It doesn't prevent memory access. It's a UX gate, not a security control.
An attacker with local admin access doesn't need to go through the settings UI. They read memory directly. The UI authentication is irrelevant to the actual threat model.
Why this matters specifically in OT environments
In a typical enterprise environment, the blast radius of this vulnerability requires an attacker who already has local admin on a workstation. That's a meaningful bar. In OT environments, that bar is routinely lower:
- Engineering workstations are often shared among shift operators. Shared accounts with elevated permissions are standard practice, not the exception.
- Terminal server environments are common in SCADA deployments, where multiple operators access a single Windows session hosting the HMI client. A compromised session means compromised credentials for everyone who has ever saved a password in that profile.
- OT networks frequently run with flat or poorly segmented architecture. An attacker who achieves lateral movement from IT to OT doesn't need to escalate much further to reach engineering workstation access.
- Patch cycles in OT are slow. An Edge version from 18 months ago is running production HMI access at facilities that can't take downtime for a browser update.
- Browser-based access to industrial systems is increasingly common. Historian web interfaces, remote HMI sessions, vendor support portals, and SCADA dashboards are frequently accessed through Edge because it's the default Windows browser and nobody changed it.
The combination is a realistic attack path. An adversary achieves any foothold on the OT network, finds a Windows engineering workstation running Edge, and extracts credentials for the historian server, the DCS, the vendor remote access portal, and the plant's OT management tooling in one memory scrape.
The "by design" pattern in OT security
A comment on the original disclosure put it well: "by design" is becoming Microsoft's most dangerous phrase in security, noting that PrinterBug and ADCS privilege escalation chains received the same response. This isn't about any single bug. It's about a pattern of decisions where the security tradeoff was made in favor of compatibility or performance, and the answer to researchers is that the behavior is intentional and therefore not subject to remediation.
That pattern lands harder in OT than in IT. Enterprise teams have security operations centers, endpoint detection, credential monitoring, and rapid incident response. Water utilities and electric cooperatives typically have none of those. When a "by design" decision creates an attack path, the ability to detect and respond to exploitation is far lower on the OT side.
The threat isn't theoretical. Credential theft from OT engineering workstations has appeared in multiple ICS incident investigations. The tooling to exploit browser memory has been commodity for years. This disclosure just names which browser is the easier target.
What to do about it
The fix is straightforward where it's possible: stop using Edge on OT workstations with saved credentials. Chrome with App-Bound Encryption meaningfully reduces the attack surface for this specific vector. But the better answer is to address the conditions that make this dangerous in the first place:
- Remove saved browser credentials from OT workstations entirely. Use a dedicated password manager with its own encryption, or use certificate-based authentication for industrial systems where possible.
- Audit shared accounts on engineering workstations. Every shared account is a shared blast radius.
- Segment terminal server environments so a credential harvest from one session can't pivot to control-layer access.
- Know which Windows systems on your OT network are running browser-based access to industrial applications. Most operators don't have that inventory.
- Treat browser credential storage as a data store that needs the same protection as any other credential vault on the network.
The underlying issue, as with most OT security problems, is visibility. You can't protect credentials you don't know are being stored, on workstations you haven't inventoried, in an environment you haven't mapped.