There is a particular kind of security request that sounds trivial and turns out to have edges. “Stop Chrome from saving passwords” is one of them. A client rolls out a real password manager — 1Password, Bitwarden, whatever the standard becomes — and the last thing they want is users quietly stashing credentials in the browser at the same time, outside the system that’s supposed to hold them. So the ask lands on your desk: turn off Chrome’s password manager everywhere. In Intune, the mechanics of that are genuinely a minute of work. What’s worth slowing down for is what the setting does and doesn’t do, because both of those shape the tickets you’ll get afterward.

The Setting Itself

The control lives in the Intune settings catalog, which is the modern home for granular, GPO-style configuration on Windows. You create a Settings Catalog policy for Windows 10 and later, open the settings picker, and search for the password manager setting under the Google Chrome category — the one named “Enable saving passwords to the password manager.” You set it to Disabled, assign it to the right group, and you’re done. Under the hood this maps to the long-standing Chrome Enterprise policy PasswordManagerEnabled, the same lever administrators used to pull through on-prem Group Policy. Intune has simply surfaced it as a built-in setting, so there’s no custom OMA-URI or ADMX ingestion to wrestle with anymore.

When it applies, Chrome stops offering to save passwords and blocks access to the vault of ones already stored. The “Save password?” prompt disappears. That’s the behavior the client asked for, and it works.

What “Disabled” Doesn’t Mean

Here’s where the edges are, and both of them are the kind of thing that generates a confused follow-up if you don’t say it out loud up front.

The first: disabling the password manager does not delete anything. The setting hides the saved passwords and blocks access while it’s active — it doesn’t wipe them. Remove the policy and they come back. This is reassuring from a data-loss standpoint, but it’s also a subtle security caveat worth naming to a client who assumes “disabled” means “gone.” The credentials still exist on the machine; they’re gated, not erased. If the actual requirement is that browser-stored passwords must not persist at all, this setting alone doesn’t satisfy it.

The second is the one that undoes the whole exercise if you miss it: Chrome Sync routes around the policy entirely. If a user is signed into Chrome with a personal Google account and sync is on, their passwords live in that Google account, and this setting has nothing to say about them. You can dutifully disable the local password manager and still have credentials flowing in and out of a browser profile through the user’s own Google identity. If keeping passwords out of the browser is the real goal — and for most clients deploying a managed password manager, it is — then you have to think about restricting Chrome sign-in or sync as a companion control. Otherwise you’ve locked the front door and left the side gate open.

That pairing is the actual lesson here. The visible setting handles the visible behavior. The thing that quietly defeats it is a second, independent system — sync tied to a personal account — that the first setting never touches. It’s the same shape that shows up all over Microsoft 365 administration: the control you configured is real, but it isn’t the only thing governing the outcome.

Roll It Out Like It Can Break Things

Because this setting reaches into something users touch every day, it’s worth the discipline of a pilot group before it goes tenant-wide. Anyone who has been leaning on Chrome to remember their logins is going to feel it the moment the policy lands — not as data loss, but as a sudden wall between them and credentials they used yesterday. Rolling it out to a small ring first lets you get ahead of that with communication instead of behind it with a queue of tickets. The change is easy to make and easy to reverse; the surprise it causes is the part that costs you.

The Full Version

The step-by-step — exact policy name, platform, the setting path in the picker, assignment, and the notes on what it does and doesn’t affect — lives in my knowledge base as a copy-pasteable runbook, so I’m not rebuilding it from memory the next time a client standardizes on a password manager:

→ Intune: Disable Google Chrome’s Password Manager — part of my open MSP Microsoft 365 knowledge base on GitHub.

The runbook gets you the deployment. The two caveats — it hides rather than deletes, and sync ignores it entirely — are what turn a one-minute setting into an actual solution to the problem the client was trying to solve.