Browser Saved Credential Check: Find, Measure and Remove Corporate Passwords in Browsers

Corporate passwords saved in a browser's built-in password manager are one of the first things an infostealer collects, and most organisations cannot say how many of their managed devices hold them. This guide is a method for finding those credentials on managed Windows and macOS devices without reading the secrets themselves, stopping new ones being saved, cleaning up what is already there and proving the exposure is falling. It covers the policy, endpoint and identity signals that reveal saved corporate credentials, how to roll out restrictions without breaking users, and how to measure progress. It is written for endpoint, identity and security operations teams who manage Google Chrome, Microsoft Edge and Mozilla Firefox fleets. Browsers are listed alphabetically throughout, and the order is not a ranking. For the wider browser baseline, read the Browser Security Hardening Guide; for the home user view of the same settings, see the Browser Privacy and Security Settings Guide.

Key takeaways

• Turning off password saving does not remove saved passwords. Chrome and Edge both document that when PasswordManagerEnabled is disabled, previously saved passwords still work, so every policy change needs a discovery and clean-up campaign behind it.
• Find the stores, not the secrets. Inventory which profiles hold a saved-login database and which sites they cover from metadata, and never extract password values as part of discovery.
• Sync is the multiplier. A corporate password saved in a browser signed in to a personal account leaves your control entirely; restrict browser sign-in and password sync on managed devices before anything else.
• Password reuse detection turns the browser into a sensor. Chrome and Edge can warn, and Chrome can report, when a user types the protected corporate password into a site that is not on your list.
• Every hit means rotation. A corporate credential found in a browser store on a device later infected, or in an infostealer log, is compromised: reset it, revoke sessions and check for new MFA methods.

Why saved browser credentials matter on managed devices

Browsers save usernames and passwords in a per-profile database. In Chromium-based browsers the profile sits under the user data directory (on Windows %LOCALAPPDATA%\Google\Chrome\User Data for Chrome, on macOS ~/Library/Application Support/Google/Chrome), and the password manager writes to files named Login Data and, for passwords held in the signed-in account store, Login Data For Account. Microsoft Edge uses the same Chromium file names under its own User Data folder. Firefox keeps saved logins in logins.json in the profile folder, with the encryption key material in key4.db.

These stores are encrypted at rest, but the encryption is designed to let the logged-in user's processes decrypt them, which is exactly the position an infostealer running as that user is in. MITRE ATT&CK tracks this as T1555.003 Credentials from Web Browsers, a sub-technique of T1555 Credentials from Password Stores, and the stolen credentials are then used as T1078 Valid Accounts. The Infostealer Threat Guide covers how the malware works; this guide covers the defender's side of the browser store.

The exposure is wider than staff personal logins. Saved entries frequently include the single sign-on password, VPN portal credentials, admin consoles for network and storage devices, shared team accounts and API or service passwords that someone typed into a web console once and let the browser remember. Those last ones are non-human identity secrets living in a human's browser, with no owner, no rotation and no audit trail.

The browser policies that control saving, sync and reuse

Each browser exposes enterprise policies for its password manager. The table lists each browser's own policy names, taken from the vendors' policy documentation; all three can be set through Group Policy ADMX templates, Microsoft Intune or a macOS configuration profile.

Google Chrome

• PasswordManagerEnabled: Google's policy definition states that disabling it means users cannot save new passwords, "but previously saved passwords will still work", and that it does not change the contents of passwords already saved and possibly synchronised to the Google account. The same applies to PasswordManagerPasskeysEnabled for passkeys.
• Sign-in and sync: BrowserSignin set to 0 disables browser sign-in (local profile passwords are preserved and usable); RestrictSigninToPattern takes a regular expression such as .*@example\.com so only corporate accounts can become the browser primary account; SyncTypesListDisabled can exclude the "passwords" data type from sync; SyncDisabled turns Chrome Sync off.
• Password reuse detection: PasswordProtectionLoginURLs lists your enterprise sign-in pages, where the password protection service captures salted hashes of the password typed; PasswordProtectionWarningTrigger then warns when that password is reused on a non-allowed site (value 1) or on a phishing site (value 2). Unset, the service protects only Google passwords.
• Leak checks and sharing: PasswordLeakDetectionEnabled controls checks of entered credentials against known leaks; PasswordSharingEnabled controls family password sharing, which Google notes managed accounts cannot use.

Microsoft Edge

• PasswordManagerEnabled: Microsoft states that when disabled, users cannot save or add new passwords but can still use previously saved passwords. Supported from version 77 on Windows and macOS.
• PasswordManagerBlocklist: a list of domains (for example your identity provider sign-in host) where Edge will neither save nor fill passwords, and users cannot override it. Supported from version 99. This lets you keep the password manager for low-risk sites while keeping the corporate password out of it.
• Password protection: PasswordProtectionWarningTrigger (0 off, 1 warn on reuse) with PasswordProtectionLoginURLs and PasswordProtectionChangePasswordURL to define the protected password. Sites in those policies and in SmartScreenAllowListDomains do not trigger a warning.
• Password Monitor: PasswordMonitorAllowed controls whether Edge checks saved passwords and alerts users when one is found to be unsafe, shown under Settings, Passwords, Password Monitor.

Mozilla Firefox

• PasswordManagerEnabled: removes access to the password manager in preferences and blocks about:logins; it sets signon.rememberSignons. OfferToSaveLogins controls only whether Firefox offers to save.
• PasswordManagerExceptions: a list of origins Firefox will not save passwords for, available from Firefox 101, for example https://login.example.com.
• PrimaryPassword: true requires a primary password protecting the saved logins; false removes the feature.
• DisableFirefoxAccounts: disables Firefox Accounts integration, which is how Firefox syncs saved logins.

How to find saved corporate credentials without reading them

Discovery has to answer three questions: which devices and profiles hold saved logins, which of those logins are for corporate or privileged sites, and which users are sending corporate passwords to places they should not. Use several signals, because each one misses something.

Endpoint inventory, step by step

1. Enumerate browsers and profiles: use your endpoint management or EDR inventory to list installed browsers per device, then every profile folder under each user's User Data directory (Default, Profile 1, Profile 2 and so on) and every Firefox profile. Include Chrome Beta and Canary channels, which use separate folders.
2. Record store presence and size: for each profile collect whether Login Data, Login Data For Account or logins.json exists, the file size and last write time. Treat a store larger than an empty database, written after your policy date, as a policy failure to investigate.
3. Classify by site, not secret: where your legal and privacy teams approve it, run a read-only query that returns only the site origin and, optionally, whether the username matches a corporate pattern. Match origins against a list of your identity provider, VPN, admin console and SaaS admin domains. Never collect the password field, and keep results in the security tooling's access-controlled store.
4. Join to identity: map each hit to the device owner and to the account behind the username. A hit on a privileged or shared account goes straight to remediation; a hit on a service or API password becomes a non-human identity finding with an owner assigned.
5. Repeat on a schedule: run the inventory weekly during the campaign, then monthly, and trend the counts.

Give employees notice through your acceptable use policy before inspecting browser profile metadata, and check works council or local labour law requirements where they apply. The point is to find corporate credentials, not to monitor personal browsing.

Turn the browser into a reuse sensor

Configure PasswordProtectionLoginURLs in Chrome and Edge with every corporate sign-in page, set PasswordProtectionWarningTrigger to warn on reuse, and in Chrome send password reuse, password changed and password breach events to your SIEM through the reporting connector. Each passwordReuseEvent is a lead: either a user is reusing the corporate password on a personal site, or they were phished. Both mean a reset. The event does not contain the password.

Choosing a remediation approach

There is no single right setting; the choice depends on whether you have an enterprise password manager and how much of the estate is on passkeys or phishing-resistant MFA.

See the Password manager (enterprise) migration playbook for moving credentials into a managed vault, and the Passkey Rollout Guide for removing the password altogether.

How to implement

1. Baseline first: run the endpoint inventory and the sync state report before changing any policy, so you have a starting count of profiles with saved corporate logins.
2. Close the sync path: restrict browser sign-in to corporate accounts (RestrictSigninToPattern, BrowserSignin in Chrome), exclude passwords from sync or disable it (SyncTypesListDisabled, SyncDisabled, DisableFirefoxAccounts), and disable password sharing.
3. Turn on reuse detection: configure the password protection policies with your login URLs and route Chrome reporting events to the SIEM. Do this before blocking, so you can see the scale of reuse.
4. Pilot the save restriction: apply PasswordManagerEnabled disabled (or the per-domain block lists) to an IT and security pilot ring for two weeks; collect help desk tickets about lost autofill and broken sign-in pages.
5. Communicate and migrate: tell users what is changing, why, and how to move entries into the enterprise password manager, then ask them to delete corporate entries from the browser. Provide a deadline.
6. Expand in rings: roll out to departments in waves, re-running the inventory after each wave.
7. Rotate exposed credentials: for every privileged, shared or service credential found in a browser store, rotate the password, revoke sessions and confirm no new MFA methods were registered.
8. Rollback plan: removing the policy assignment restores saving once each browser has picked up the policy change (Firefox may need a restart). Keep the pilot group assignment as the fast rollback target and document which business applications needed an exception.

Where identity fits

A saved browser password is only dangerous because the account behind it accepts a password. Every service account, shared admin account and API console login found in a browser store is evidence of a non-human identity without a proper owner or secret store. Move those credentials into a secrets manager or enterprise vault, assign an owner, and set rotation. Use the discovery output to find accounts that should not be interactive at all. See the How to Find Accounts Excluded From MFA and Conditional Access guide for the identity provider side of the same problem.

Detection and measurement

• Monitor: Chrome reporting connector passwordReuseEvent, passwordBreachEvent and passwordChangedEvent; Edge and Chrome policy compliance status; EDR alerts for processes other than the browser opening Login Data, Login Data For Account, logins.json or key4.db; identity provider sign-ins for accounts flagged in the inventory from new devices or locations.
• Metric 1, saved corporate credential exposure: number of managed profiles with at least one saved login for a corporate domain, trended weekly. Target: falling to near zero.
• Metric 2, policy coverage: percentage of managed devices reporting the save restriction and sync restriction as applied, per browser.
• Metric 3, privileged exposure: count of privileged, shared or service accounts found in browser stores, and the percentage rotated within 7 days.
• Metric 4, reuse rate: passwordReuseEvent count per 1,000 users per month.
• Metric 5, stolen corporate credentials: corporate credentials appearing in infostealer log feeds per month, split by managed and unmanaged device. See the Infostealer Logs Monitoring and Response Guide.

Common failure patterns

• Policy without clean-up: disabling the password manager and declaring victory, while every password saved before the change still works and still sits on disk.
• Personal sync left open: in the Cisco Breach 2022, an employee's corporate password saved in the browser and synced to a personal Google account was taken over, then voice phishing and repeated MFA pushes produced an approval. Restricting sign-in to corporate accounts closes that path.
• Managing one browser: enforcing Edge policy while Chrome or Firefox on the same device remains unmanaged and keeps saving.
• Discovery that reads secrets: scripts that decrypt stored passwords to "check" them create a new credential store in the security team's hands and an insider risk.
• No rotation after a finding: deleting the saved entry but not changing the password, so a copy already stolen from the device remains valid.
• Incomplete domain lists: per-domain block lists that cover the identity provider but miss VPN portals, admin consoles and regional sign-in hosts.

Framework mapping

Practitioner checklist

• Inventory every browser and profile on managed devices, including beta channels and Firefox profiles.
• Record a baseline count of profiles holding saved logins for corporate domains, using site metadata only.
• Restrict browser sign-in and password sync to corporate accounts on every managed browser.
• Configure password reuse protection with every corporate login URL and send Chrome reuse events to the SIEM.
• Disable saving (or block corporate domains) after a pilot ring, with a rollback assignment ready.
• Run a user migration and deletion campaign with a deadline; re-run the inventory after each wave.
• Rotate every privileged, shared or service credential found, revoke sessions and check MFA registrations.
• Move service and API passwords into a secrets manager with a named owner.
• Report the five metrics monthly until saved corporate credentials are near zero.

Standards and references

• MITRE ATT&CK: Credentials from Web Browsers (T1555.003)
• Google: Chrome Enterprise policy list
• Microsoft Learn: Microsoft Edge PasswordManagerEnabled policy
• Microsoft Learn: Microsoft Edge PasswordManagerBlocklist policy
• Microsoft Learn: Microsoft Edge PasswordProtectionWarningTrigger policy
• Mozilla: Firefox enterprise policy templates
• Chromium: User Data Directory
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Browser Security Hardening Guide · Infostealer Threat Guide · T1555 Credentials from Password Stores Defensive Guide · Password manager (enterprise) migration playbook · Browser Privacy and Security Settings Guide