Saved passwords in the browser, a bigger risk than many think

Your staff are probably already saving passwords in the browser.

It is fast. It feels harmless. And that is often exactly how a bad practice takes hold.

A widely shared video from Tom Jøran Sønstebyseter Rønning shows why this is worth taking seriously.¹ The video shows a command window where saved passwords appear to be dumped from Microsoft Edge for multiple users. If saved passwords can be read out like this, the problem is not only technical. The same browser is often a shortcut into email, customer data, HR systems, finance, and internal tools.

Microsoft Edge loads all your saved passwords into memory in cleartext - even when you’re not using them.

— Tom Jøran Sønstebyseter Rønning (@L1v1ng0ffTh3L4N) May 4, 2026

The first question to ask is simple: could something similar happen here?

If the answer is “maybe”, you probably already have enough reason to act.

Executive overview

This is not just a Microsoft Edge issue, that is the browser. This is about how you handle passwords and other login details in the business.

When staff save passwords in the browser, you move a sensitive protection closer to everyday work, and further away from governance. When something goes wrong, the problem becomes bigger than the browser itself. It becomes access to email, customer data, HR, finance, and internal tools.

ISO 27001 does not literally say “do not save passwords in the browser”. Its risk assessment requirement does mean you need to examine what a stolen account could lead to. You then choose safeguards and compare your selection with Annex A. For browser passwords, decisions about storage, access, authentication and device settings are connected. A technical restriction offers little help, for example, if exceptions are approved without anyone assessing the risk.

My recommendation is simple: do not allow the browser to save passwords for business-critical accounts. Ideally, disable the feature for company accounts and use a dedicated password manager with clear governance, sharing, revocation, and strong authentication.

Start here

You do not need to wait for a large security project to reduce the risk.

Do this first:

1. Decide which accounts must never be saved in the browser. Start with email, admin, HR, finance, CRM, and systems with personal data.
2. Require stronger authentication for sensitive accounts. One saved password should not get an attacker very far.
3. Review which users have too much access. The more an account can reach, the bigger the damage.
4. Treat clients and browsers as security matters, not user preferences.
5. Decide how you detect, report, and correct improper local storage of logins.

This does not solve everything. But it moves you away from relying on luck.

Why this becomes a business problem

Many people think about IT first. That is too narrow.

If a user’s browser gives access to email, an attacker can reset other passwords. If the same user has also saved logins to customer systems, supplier portals, or internal tools, one account becomes a path forward.

That is why this is not just about browsers. It is about how you handle passwords and other login details in the business.

The reason is rarely stupidity. The reason is convenience. People want to log in and move on. If the organization does not have clear rules, or if the rules are never followed up, convenience wins.

How ISO 27001 would have reduced the risk

ISO 27001 would not have made you invulnerable. But good work under the standard would have done three things:

• reduced the chance that sensitive passwords are stored in the wrong place
• limited the damage if something still leaks
• made you faster at detecting and correcting the problem

In practice, that comes from four things.

1. You would have had to decide what is sensitive

ISO 27001 clause 6.1.2 requires a risk assessment that lets you compare and prioritise risks. Information classification helps you understand what the accounts can access; control 5.12 is relevant when designing that assessment.² Our advice is to distinguish the consequences of an account being compromised. A compromised email account can be used to reset other passwords. A compromised HR account can expose staff records. Assess accounts based on what an attacker could reach and decide which logins may be saved in the browser.

2. You would have had to govern authentication information

Annex A 5.17 is relevant to password handling, alongside the controls on acceptable use, identity management, and access control.³ Our advice: choose a shared password solution rather than leaving each employee to decide where passwords are saved.

That leads to real decisions, such as which accounts must never be saved locally, which roles need stronger authentication, and who may approve exceptions.

3. You would have had to protect user devices better

Controls 8.1, 8.8 and 8.9 help you review protection where the user works: on the computer and in its settings.⁴ A practical approach needs someone to maintain approved browser settings, assess new security weaknesses and follow up whether updates reach the computers. Then test a managed computer: can the user turn on password storage or install an unapproved extension? That shows whether your chosen solution holds up when a user changes something.

That is directly relevant to browsers. If you do not control whether passwords may be stored locally, which extensions may run, or how quickly clients are updated, you leave an unnecessary hole open.

4. You would have limited the damage and learned faster

Good security work does not only try to stop problems. It also limits damage when something still happens.

That is why access control, secure authentication, logging, incident handling, and regular follow-up matter here.⁵

If you have a rule that sensitive accounts must not be saved in the browser, but never check compliance, then in practice you do not have a rule at all.

When does ISO 27001 become truly relevant?

ISO 27001 becomes truly relevant when these questions keep returning, and each time are solved ad hoc.

When nobody knows which accounts are saved locally. When rules exist, but nobody follows them up. When client protection, access control, training, and incident learning live in separate boxes.

That is when a management system becomes interesting. Not as administration. As a way to get control.

If this sounds familiar, start by finding out which business-critical accounts are saved in the browser. Then decide who is responsible for changing the approach and when you will check the result.

Footnotes

1. Tom Jøran Sønstebyseter Rønning, post on X, 4 May 2026: https://x.com/i/status/2051308329880719730. ↩

2. Reference: ISO/IEC 27001:2023, clause 6.1.2 and Annex A 5.12. ↩

3. Reference: ISO/IEC 27001:2023, Annex A 5.10, 5.15, 5.16, and 5.17. ↩

4. Reference: ISO/IEC 27001:2023, Annex A 8.1, 8.8, and 8.9. ↩

5. Reference: ISO/IEC 27001:2023, Annex A 8.3, 8.5, 8.15, 8.16, and 5.24, 5.25, 5.26, 5.27, and 5.36. ↩