⚙️🪟💻CP - Google Chrome - Disable Password Manager
The browser is not a vault. This policy stops Chrome from offering to remember corporate passwords, so credentials live where you actually manage them.
What this policy is about 🔐
Chrome loves to offer "Save password?" on every login, and users say yes. Now corporate credentials sit in a browser profile, synced to whatever personal Google account happens to be signed in, protected by nothing more than the Windows session. This policy turns that off: no saving to the built-in manager, and leak detection off alongside it because the manager it feeds is gone.
This is the default baseline. It goes to everyone, and the one team that genuinely needs Chrome's manager gets it back through the paired inverse and its exception group, not by loosening this.
The goal is not to make life harder. It is to stop the browser from quietly becoming the password vault. With saving off, passwords go where you can actually govern them: SSO, or the managed password manager the customer standardized on.
Why this matters 🕵️
Passwords saved in Chrome ride along with the browser profile. Sign into a personal Google account, and those saved logins can sync out to a device you do not manage. Hand the laptop to the next employee without a wipe, and the credentials are still sitting there behind an unlocked session. It is a vault with the door propped open and a sticky note that says "back in five".
Keeping credentials out of the browser and inside a real password manager means one governed store, one set of controls, and no corporate logins quietly replicating to someone's home PC.
🛠️ Configuration
Where: Intune admin center → Devices → Configuration → Create → Windows → Settings catalog → Google \ Google Chrome \ Password manager.
| Setting | Value |
|---|---|
| Enable saving passwords to the password manager | Disabled |
| Enable leak detection for entered credentials | Disabled |
| Assignment, include | All devices |
| Assignment, exclude | 🛡️🪟💻👈🔓⚙️Group - Chrome Password Manager Allowed |
Caveats ⚠️
Exclusion is not the same as re-enabling. This writes to a policy value that can persist on a device that already received it. Pulling a device out of this policy stops new enforcement; it does not necessarily switch the manager back on. That is precisely why the Enable inverse exists and is assigned to the exception group.
Give users somewhere to put passwords first. Disabling the browser manager only works if there is a sanctioned alternative already in place. Turn this on into a vacuum and users invent their own vault, and it is usually a spreadsheet named passwords_final_v2.
Leak detection goes off too. That is deliberate: it belongs to the manager you are switching off. A tenant that genuinely keeps Chrome as its password manager wants leak detection on, which is exactly what the Enable inverse restores.
License and reversibility. Included in Business Premium. Clean-revert on its own, though the exception path is the paired inverse rather than plain unassignment.
🔗 Related
- ⚙️🪟💻🔓CP - Google Chrome - Enable Password Manager: the paired inverse that switches the manager back on for the approved exception group.
- 🛡️🪟💻👈🔓⚙️Group - Chrome Password Manager Allowed: the documented group the inverse is assigned to.
One does not simply store corporate passwords in the browser. Send them to the vault you manage, and keep this the default for everyone else. 🔐