Browser-saved passwords are a security risk: here is what to do instead

Chrome asks whether you want to save the password. You click Save. Next time the login form fills itself in and you never think about it again. Nobody trained anyone to do this, nobody approved it, and no line item on any invoice pays for it. By sheer accident, the browser is the most widely deployed password manager in most small businesses, holding more business credentials than any tool the business actually bought.

For a personal Netflix login, that is fine. For the account that reaches your accounting system, your vendor portal, and your payroll provider, it is a different proposition, and not because browser encryption is weak. The encryption is genuinely decent. The problem is what the encryption is tied to, what happens to those credentials once they sync, and the fact that the most common piece of commodity malware on the internet has exactly one job, which is emptying browser credential stores in the first ten seconds after it lands.

This article covers how browser password saving actually works under the hood, where it falls short for business use, how to turn it off across Chrome, Edge, Firefox, and Safari through policy rather than instruction, how to migrate what is already saved without creating a worse problem in the process, and how to announce the change without generating a week of support tickets. It assumes a business of roughly 20 to 50 people with either Intune, Group Policy, or neither.

Short answer

Browser-saved passwords are a security risk for business use because the vault is unlocked whenever the user is signed in to the computer, because the credentials sync to whatever account the browser profile belongs to (often a personal Google or Microsoft account that leaves with the employee), because you as the business have no visibility, no sharing controls, and no way to revoke them, and because infostealer malware targets browser credential stores specifically and steals session cookies alongside the passwords, which lets an attacker skip your MFA entirely. The fix is a four-step sequence and the order matters: migrate everyone’s saved credentials into a business password manager first, delete them from the browser and verify, then disable password saving centrally through Group Policy, Intune, or Chrome Browser Cloud Management, and finally block sign-in to personal browser profiles so the habit cannot quietly restart. Doing the policy step first, before migration, is the single most common way this project turns into a helpdesk incident.

Browser-saved passwords at a glance

Question	Short version
Is browser encryption weak?	No. The key is tied to your OS login, so anything running as you can use it.
What is the actual threat?	Infostealer malware. It targets browser stores first and takes cookies too.
Do stolen cookies bypass MFA?	Yes. A valid session cookie is a session already past the MFA prompt.
Can I see what my staff have saved?	No. There is no admin console and no audit trail.
Where do the passwords go?	To whatever account the profile is signed in to, including personal ones.
Can I revoke them when someone leaves?	Not if they synced to a personal account. That copy is gone.
How do I turn it off?	PasswordManagerEnabled in Chrome and Edge, OfferToSaveLogins in Firefox, allowPasswordAutoFill on Apple devices.
Does the policy delete existing saved passwords?	No. It only blocks new saves. You have to remove the old ones.
What is the riskiest step of the migration?	The exported CSV. It is plaintext and people leave it in Downloads.
Does this affect passkeys?	No. Passkeys are a separate mechanism and you should keep them.

How browser password saving actually works

Browsers do not store passwords in plain text. They keep an encrypted database on disk, and the interesting question is what protects the key to that database.

On Windows, Chromium browsers historically wrapped the encryption key using the Data Protection API, which binds it to the Windows user account. That design is sound against someone who steals the laptop and pulls the drive, because the credentials cannot be decrypted without the user’s Windows session. It is not sound against a process already running as that user, which can simply ask Windows to unwrap the key. That is the whole vulnerability in one sentence: your Windows login is the lock, so any code running as you is already holding the key.

Google addressed this in Chrome 127 in July 2024 with app-bound encryption, which moves the master key behind an elevation service running as SYSTEM that verifies which application is asking before releasing it. It was a real improvement and it raised the cost of the attack. It did not end it. Within months, infostealer families were bypassing it by driving the browser’s own remote debugging interface, scraping memory, abusing COM interfaces, and injecting into a hidden browser process. The bypass is now standard equipment in commodity malware sold as a service.

On macOS the equivalent is the login keychain, which is unlocked as part of signing in. Same principle, same practical result.

The consequence that matters day to day is subtler than the malware story. Autofill requires no re-authentication. Chrome and Edge will ask for your Windows PIN before displaying a saved password in the settings page, but they will happily type it into a login form without asking for anything. An unlocked laptop, left alone for two minutes, is a working session on every site whose password is saved. A dedicated password manager behaves differently by design: it has its own master secret, its own lock timer, and it re-locks whether or not the operating system session is still open.

The malware problem is the part that changed

Infostealers are the most successful category of commodity malware in circulation. They are cheap, sold as a subscription service to people with no technical skill, and they are usually delivered through the ordinary channels: a fake software download, a cracked application, a malicious browser extension, a phishing attachment, or one of the increasingly convincing lures covered in AI-powered phishing.

What makes them relevant here is what they collect. An infostealer is not looking for your documents. In its first seconds on a machine it takes browser-saved passwords, browser cookies, autofill data, and any credentials sitting in files with obvious names. Then it exits. The whole intrusion can be over before an alert fires, and the stolen data is on a criminal marketplace within hours.

Two details make this worse than it sounds.

Session cookies come with the passwords, and cookies defeat MFA. A stolen session cookie represents an authentication that already happened. Replaying it puts the attacker inside the account without a password prompt and without an MFA challenge, because from the application’s point of view the challenge was passed. This is the mechanism behind a large share of business email compromise cases, and it is why MFA and strong passwords are two layers rather than substitutes. Every credential in the browser store is exposed to the same theft as the cookies sitting beside it.

One infected machine exposes everything that user ever saved. Not one account. The whole store, including the credentials from three jobs ago, the ones for systems the business retired, and the personal banking login the employee saved on the work laptop. Credential theft from a single workstation is one of the standard routes into a network, which is worth reading alongside how ransomware gets into small business networks and the signs that a network has already been compromised.

None of this makes browser encryption bad engineering. It makes the browser the wrong place to keep credentials that matter to a business, because the browser is the single most targeted application on the endpoint and it is holding the keys in a store the attacker knows exactly how to find.

Where browser password managers fall short for business

Set malware aside for a moment. Even on a machine that is never compromised, the browser is missing everything that makes credential management a business function rather than a personal convenience.

You cannot see anything. There is no admin console, no report of who saved what, no list of reused or breached passwords across the team, no way to answer the question a cyber insurance form or a client security questionnaire will eventually ask. A password audit simply cannot reach credentials that live in fifty separate browser profiles.

They sync to whichever account owns the profile, and that account is often personal. This is the gap most owners have never considered. If an employee signs into Chrome with their personal Gmail, or into Edge with a personal Microsoft account, every business password they save replicates to that account and onto their home computer and personal phone. It is not a policy violation anyone notices, it is the default behavior of a browser that was signed in once. Those credentials are now outside your control permanently.

There is no way to share, so people share badly. Two staff need the same vendor portal login. The browser has no shared vault, so the password gets pasted into a chat message or an email, which is the exact behavior the shared credentials problem exists to solve.

Offboarding does not reach them. You disable the user’s account, you collect the laptop, and you feel done. But the passwords they saved to a personal profile still work, because they are credentials to third-party systems that have no idea your directory exists. This is a large part of what actually happens to your passwords when an employee leaves, and it is invisible in every offboarding checklist that only covers your own systems.

They save indiscriminately and never clean up. The browser saves whatever gets typed into a form, including the wrong password entered on the wrong site, test credentials, and logins for services cancelled two years ago. Nothing ever expires or gets reviewed.

They only cover websites. Wi-Fi keys, RDP credentials, the NAS admin login, SSH keys, software licence keys, MFA recovery codes, bank PINs, and the service account credentials nobody rotates have no home in a browser. So the business ends up with a browser for web logins and a spreadsheet for everything else, which is the worst of both.

What browser password managers are genuinely fine for

Being fair about this matters, because employees who use browser saving at home will otherwise assume the whole message is exaggerated.

For a personal account on a personal device, a browser password manager is a real improvement over reusing the same password everywhere. It generates strong values, it flags credentials that appeared in known breaches, it costs nothing, and the encryption is competent. If a family member asks whether they should use Chrome’s password manager, the answer is yes, that is better than what they are doing now.

The business argument is not that browser storage is worthless. It is that business credentials need administrative visibility, controlled sharing, revocation on departure, coverage beyond the browser, and separation from the most heavily targeted application on the endpoint. A browser cannot provide any of those, which is the whole reason businesses buy a dedicated password manager instead of relying on the free tool already installed.

The one rule worth stating plainly to staff: keep personal credentials wherever you like, keep business credentials in the company vault, and never sign a work browser profile into a personal account.

How to turn off browser password saving

An instruction to stop saving passwords in the browser holds for about a week. Policy holds indefinitely. Here is what to set.

Browser	Setting	Where to apply it
Chrome	PasswordManagerEnabled = Disabled	GPO under Google Chrome, Password manager. Registry HKLM\SOFTWARE\Policies\Google\Chrome\PasswordManagerEnabled = DWORD 0. Intune via ingested Chrome ADMX, or Chrome Browser Cloud Management
Edge	PasswordManagerEnabled = Disabled	GPO under Microsoft Edge, Password manager and protection. Registry HKLM\SOFTWARE\Policies\Microsoft\Edge\PasswordManagerEnabled = DWORD 0. Intune settings catalog
Firefox	OfferToSaveLogins = false, plus PasswordManagerEnabled = false	Firefox ADMX templates, or policies.json on the endpoint
Safari, iOS, iPadOS, macOS	allowPasswordAutoFill = false	A com.apple.applicationaccess restriction payload in an MDM configuration profile

Three things about this that surprise people.

The policy only blocks new saves. This is the detail that catches almost everyone. Setting PasswordManagerEnabled to Disabled stops the browser offering to save anything new, but credentials saved before the policy applied remain in the store and remain autofillable. If you set the policy and declare the project finished, every existing browser-saved password is still sitting there, still syncing, and still the first thing an infostealer collects. Deletion is a separate step and it has to actually happen.

Sync is a separate control from saving. Turn off both. Chrome’s SyncTypesListDisabled lets you disable password sync specifically while leaving bookmarks alone, and both browsers support SyncDisabled to switch it off entirely. Pair that with BrowserSignin and RestrictSigninToPattern, which restricts browser sign-in to accounts matching your domain pattern. That last one is what actually prevents a work browser profile from being signed into a personal Gmail or a personal Microsoft account, and it closes the leak that policy on password saving alone leaves open.

This does not affect passkeys, and it should not. Passkeys are a different mechanism: a private key generated on the device, hardware-protected, non-exportable, and useless to malware that copies files. Disabling the browser password manager does not disable passkeys, and you want the opposite of disabling them. Passkeys are the direction credential security is heading, and every login you move to one is a login with no password left to steal.

If you have neither Group Policy nor Intune, you are not stuck. Chrome Browser Cloud Management is free and applies Chrome policy to enrolled browsers over the internet with no domain required, which suits a business running all-cloud with unmanaged-but-company-owned laptops. Edge policy applies through Intune, and if you are already licensed for Microsoft 365 Business Premium you have Intune whether or not you have configured it. For personally owned devices, policy is not available to you and the answer is a written rule plus a managed browser profile, which is the same boundary a BYOD policy has to draw for everything else.

Whichever route you take, sequence it correctly. Enforce after a department has migrated, never before. Applying the policy first locks people out of credentials they have not moved yet, floods the helpdesk in an afternoon, and gives every skeptic a story about how the new system broke their day.

How to migrate what is already saved

The migration itself is straightforward. There is exactly one dangerous step in it, and it is not the one people expect.

1. Export from the browser. In Chrome, chrome://password-manager/settings and Download file. In Edge, the passwords section of edge://wallet/passwords and Export. In Firefox, about:logins and Export logins. Safari exports through Passwords in Settings on macOS.

1. Treat that export file as a live credential dump, because it is one. Every browser exports to plaintext CSV. Every password the person has ever saved, readable, in a file that lands in the Downloads folder by default, which on a lot of machines is a folder that syncs to OneDrive. This one file is the single largest risk in the entire project. Import it into the vault immediately, delete it from disk, empty the recycle bin, and confirm it did not replicate to cloud storage or a backup. Never send it by email or chat, not even to yourself.

1. Audit while you migrate, do not import blindly. Migration is the only moment when someone looks at all of their credentials at once, so use it. Drop entries for services the business no longer uses, flag anything reused across accounts, and reset anything the vault reports as breached. Importing 200 rows of accumulated debris produces a vault that looks organized and is not, and this is where a proper password audit pays for itself.

1. Delete from the browser and turn the offer off locally. Clear the saved passwords, then switch off “Offer to save passwords” in the browser’s own settings before the central policy lands. Then verify rather than trust, because this setting has a habit of still being enabled somewhere.

1. Check every browser and every profile. People run two browsers and forget one. Chrome profiles are the usual hiding place: a work profile and a personal profile on the same machine, with business credentials in the personal one. Check both. Check the phone as well, since iOS and Android autofill from the platform’s own store, and a personal phone signed into a personal Google account is holding a synced copy of everything.

1. Apply the policy, then verify from the admin console. Your password manager’s admin console shows how many items each person has stored. A department that migrated should show credentials per person in the dozens. Anyone still showing three items did not migrate, they just stopped saving new ones, and they are now storing passwords somewhere you cannot see at all.

The whole sequence takes about twenty minutes per person, and it works far better in a guided session than as an email with instructions. This is the same reason a password manager rollout schedules migration as a room full of people doing it together rather than as a task assigned to everyone individually.

How to announce it without a revolt

The technical work is the easy half. The change everybody actually notices is that a convenience they used every day has been taken away, so lead with what replaces it rather than with what is being removed.

Open with the benefit, not the threat. The new tool fills passwords on the phone as well as the laptop, works in every browser instead of one, generates passwords so nobody has to invent them, shares a vendor login with a colleague without emailing it, and ends the reset-my-password ticket. That is a better pitch than a lecture about malware, and it is all true.

Then give one concrete reason, once. A single sentence lands harder than a security memo: malware that steals browser-saved passwords is the most common malware on the internet, it takes everything saved in the browser in seconds, and it takes the session cookies with it, so multi-factor authentication does not stop it. Say it once, move on, do not repeat it weekly.

Be honest that the first week is slower. It is. After that it is faster than typing passwords from memory and resetting the ones you forgot. Promising a seamless transition guarantees that everything else you say gets discounted by Tuesday.

Give a real deadline and a named person to ask. “Browser saving is turned off on the 14th, migration help is available Tuesday and Thursday afternoon, ask Sarah” beats any amount of policy language.

Have leadership go first. Adoption is a management problem wearing a technical costume. If the owner still autofills from Chrome, everyone knows the deadline is decorative.

Common browser password mistakes

1. Applying the policy before migrating. It locks people out of credentials they still need and turns a security improvement into an outage story.
2. Assuming the policy deleted the old saved passwords. It did not. It only blocked new saves, and everything already stored is still there and still syncing.
3. Leaving the exported CSV in the Downloads folder. Plaintext, complete, and frequently synced to cloud storage. Import it, delete it, verify it is gone.
4. Turning off saving but leaving sync and browser sign-in alone. Personal profiles keep the credentials, and the habit restarts within a month.
5. Checking one browser and one profile. The second profile is where the business credentials usually are.
6. Forgetting phones entirely. A personal phone signed into a personal Google account holds a synced copy of everything saved on the laptop.
7. Treating this as a training issue rather than a policy issue. Instructions are followed for about a week.
8. Migrating everything without auditing. Dead credentials and former vendors get carried into a system that now looks clean and is not.
9. Not verifying adoption in the admin console. People stop saving new passwords, never migrate the old ones, and quietly move to a notes app instead.
10. Disabling passkeys along with password saving. They are unrelated mechanisms, and passkeys are the one credential type malware cannot copy.

How this fits the rest of your credential security

Browser-saved passwords are the loophole that quietly cancels the rest of a credential program. Your password policy needs an explicit rule about them or the policy simply does not reach them. Your password manager rollout is not finished until browser saving is off, because credentials living in two places make the vault non-authoritative and leave you with the weaknesses of both. Your offboarding process misses them completely when they synced to a personal account. And your password audit is measuring only the credentials it can see, which makes the result look better than reality.

The work itself is small. A guided migration session per department, a policy object or an Intune profile, a few sync and sign-in settings, and one verification pass in the admin console. Call it a couple of weeks of light effort for a business of fifty people. What it buys is the difference between a vault that holds most of your credentials and a vault that holds all of them, which is the point at which everything else you built on top of it starts being true.

What is next in this series

The next article covers what to do when it has already happened: the immediate steps when business credentials turn up in a breach dump or an account starts behaving strangely, how to work out which accounts are affected, why revoking active sessions matters as much as resetting passwords, and when a credential compromise crosses into a reportable breach.

How Sequentur can help

If you want help turning off browser password saving across your fleet, migrating what is already saved without leaving credential files scattered around, or building the policy and monitoring that keeps it that way, schedule a call.