Browser password managers expose a plaintext-RAM trust problem

At a glance

What this is: Akeyless examines Microsoft Edge’s plaintext-in-RAM password handling and argues that browser password managers still rely on a trusted-endpoint model that modern malware breaks.

Why it matters: IAM teams should treat browser-native credential storage as a runtime exposure problem, not just a storage problem, because privileged and cloud access secrets can be harvested after decryption.

👉 Read Akeyless's analysis of plaintext-RAM exposure in browser password managers

Context

Browser password managers are convenience tools that keep credentials available for autofill, but that design also keeps decrypted secrets close to the browser process. Akeyless argues that Microsoft Edge’s plaintext-RAM handling shows the real problem is not whether credentials are encrypted on disk, but whether they remain exposed in memory long enough to be stolen.

For identity and access teams, this is a governance problem as much as a technical one. Browser-stored credentials can now include access to cloud consoles, production systems, and administrative portals, so the question becomes whether browser-native storage is acceptable for any account that carries meaningful privilege.

Key questions

Q: What breaks when browser password managers load secrets into plaintext RAM?

A: The browser vault still looks encrypted at rest, but the secret becomes readable once the browser decrypts it for use. That creates a runtime exposure window that memory scraping malware can exploit without breaking the underlying crypto. The practical failure is assuming storage encryption alone protects credentials on a compromised endpoint.

Q: Why do browser-stored credentials increase risk in enterprise environments?

A: They increase risk because they place valuable credentials inside a user-centric storage layer that can be exposed through endpoint compromise, browser profile theft, sync abuse, or exported files. The issue is not just theft. It is the absence of enterprise governance around secrets that should be tracked, approved, and revocable.

Q: How should teams decide which credentials should never live in a browser vault?

A: Any credential tied to cloud administration, production systems, or high-impact business services should be treated as out of scope for browser-native storage. The decision should be based on blast radius, not convenience. If compromise of the endpoint would materially affect multiple systems or users, the browser is the wrong place for that secret.

Q: What is the difference between encrypted storage and runtime exposure for passwords?

A: Encrypted storage protects a secret while it is stored on disk, but runtime exposure covers the moment the browser decrypts it for use. Infostealers focus on the second condition because the secret is readable in memory even when the vault is technically encrypted. For practitioners, runtime exposure is the control gap that matters most.

Technical breakdown

Why plaintext RAM defeats browser password protection

Browser password managers usually encrypt secrets for storage, then decrypt them when the browser needs to autofill or reuse them. That means the sensitive point is not the vault itself but the runtime window where secrets exist in process memory in usable form. Akeyless’s point is that memory scraping malware does not need to break the underlying encryption model if it can read the browser process after decryption. This is why “encrypted at rest” can still leave credentials exposed in practice. The control boundary has shifted from storage security to runtime exposure control.

Practical implication: treat process memory as part of the credential attack surface, not just the browser vault.

How infostealers harvest browser-stored credentials

Modern infostealers such as RedLine, Vidar, and LummaC2 focus on runtime theft rather than cryptographic cracking. They look for browser profiles, session data, and decrypted secrets already present on the endpoint, then extract them at machine speed. That makes the browser a credential concentration point, especially when users keep cloud console passwords, developer portal access, or admin logins in the same profile. The article’s central warning is that endpoint compromise does not need to be sophisticated if the browser has already materialised the secret in memory.

Practical implication: assume browser-based credentials are collectable once the endpoint is compromised, even if the vault is encrypted.

Why shared endpoints multiply the blast radius

In VDI, Citrix, and other shared or multi-user environments, one compromised endpoint can expose more than one user context. If the browser preloads secrets at boot or keeps them resident for convenience, an attacker with local access can harvest credentials across sessions or users. That turns a single malware event into a multi-account exposure problem, especially where privileged users share infrastructure. The governance issue is not only exposure duration but also credential compartmentalisation. Browser-native storage collapses separation between identities that should be operationally distinct.

Practical implication: map browser credential usage by endpoint class and remove privileged accounts from shared or multi-user environments.

Breaches seen in the wild

• OmniGPT breach claim 2025: A hacker claims to have leaked 34 million OmniGPT AI chat messages holding users' API keys and credentials; OmniGPT has not confirmed it.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Plaintext RAM is a runtime trust failure, not a storage failure. Browser password managers still assume the endpoint can be trusted long enough for decrypted secrets to exist safely in memory. That assumption breaks the moment malware, local compromise, or shared access can inspect the browser process after decryption. The implication is that credential security has to move from vault encryption alone to where and when the secret becomes usable.

Credential compartmentalisation is now a governance requirement, not a convenience choice. When cloud admin logins, developer portals, and business SaaS accounts all sit inside the same browser profile, one endpoint compromise creates an identity blast radius that is too broad to defend with hygiene advice. The relevant governance question is which credentials deserve browser-native handling at all. Practitioners should treat high-impact accounts as out of scope for browser vaults.

Just-in-time exposure is the control model browser managers failed to adopt. Microsoft’s design choice effectively keeps secrets available longer than the task requires, which is exactly what infostealers exploit. A more defensible model would minimise the decryption window and eliminate persistent in-memory exposure wherever possible. That is not a product preference issue; it is a control boundary issue that changes how identity teams evaluate password tooling.

Shared computing environments turn a single local compromise into an enterprise identity event. In VDI and similar estates, browser memory exposure can cross user boundaries in ways that individual workstation assumptions hide. That means endpoint security, IAM, and workstation governance need to be assessed together rather than as separate risk domains. The practitioner conclusion is simple: if the endpoint is shared, browser-stored privileged credentials should be considered structurally unsafe.

Runtime credential visibility is the named risk concept this disclosure sharpens. The issue is not whether a password manager uses encryption somewhere in its architecture, but whether the secret becomes visible in a form malware can read at the moment of use. That distinction matters for NHI and human identity programmes alike because it changes the control target from persistent storage to transient exposure. Teams should evaluate tools on exposure windows, not just vault design.

From our research library:

• The average user manages 70 to 100 passwords, many of them outside centralised identity platforms.

What this signals

Runtime credential visibility will become the decisive control boundary. Browser password managers that keep secrets available in process memory are effectively extending trust to every endpoint that can run the browser. Identity programmes should start measuring where secrets become visible, not just where they are stored.

Browser vaults are increasingly misaligned with privileged access governance. The more important the account, the less defensible it becomes to leave that secret inside a browser profile that can be scraped by local malware. That pushes high-value credentials toward controlled issuance models rather than persistent local reuse.

For practitioners

• Audit browser-stored privileged credentials Inventory cloud admin, production, developer, and SaaS credentials currently saved in browser-native vaults, then classify them by blast radius and business criticality.
• Remove high-risk accounts from browser autofill Block browser-based storage for administrative and production access, especially where a compromised endpoint would expose more than one sensitive system.
• Shorten credential exposure with JIT access Use just-in-time access for sensitive accounts so credentials are issued only when needed and not left resident in browser memory after use.
• Separate shared-endpoint identities Treat VDI, Citrix, and other shared environments as high-risk for browser password storage and keep privileged users off shared browser profiles.

Key takeaways

• Browser password managers can still expose credentials at the moment of use, even when the stored secret is encrypted.
• The main risk is runtime memory exposure, which infostealers and local compromise can exploit without breaking encryption.
• Teams should remove privileged accounts from browser vaults and move sensitive access toward just-in-time issuance and tighter compartmentalisation.

Key terms

• Plaintext RAM Exposure: Plaintext RAM exposure is the condition where a secret is decrypted into process memory long enough for malware or local attackers to read it. For browser password managers, the risk is not storage encryption failure but the moment credentials exist in usable form on the endpoint.
• Exposure Window: The period in which a credential, session, or privilege grant can be exploited before it is revoked or expires. Shorter windows help, but they do not solve the deeper question of whether the access remains justified for the full time it is active.
• Credential Compartmentalisation: Credential compartmentalisation is the separation of secrets by function, team, or system so that access in one area does not automatically expose others. It is a practical control for reducing unintended sharing, limiting lateral misuse, and making ownership clearer across complex or collaborative environments.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.

What's in the full article

Akeyless's full article covers the operational detail this post intentionally leaves for the source:

• The Microsoft Edge plaintext-RAM disclosure and the specific browser memory behaviour described
• The named infostealer families the article cites as real-world harvesters of exposed browser secrets
• The vendor's recommended response steps for users, browsers, and enterprise environments
• The details of Akeyless Password Manager 2.0 and how it claims to reduce in-memory exposure

👉 Akeyless's full post covers the Edge disclosure, infostealer risk, and the browser credential response model.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.