Make Chrome Autofill Safer with Windows Hello

An employee steps away from their Windows laptop for a few minutes. The screen is still unlocked. Chrome is already signed in. Someone else sits down — a colleague, a visitor, or someone who should not be there at all.

Inside that browser may be saved passwords, payment cards, addresses and contact details. Without additional verification, some of that information may be easier to access than the business expects.

The browser knows which information is saved. Windows Hello can help confirm who is trying to use it.

Google provides two device-level verification settings in Chrome on Windows that can help here. They are not enabled by default. They are worth knowing about.

Last checked: 16 August 2026.

What is Windows Hello?

Windows Hello is Microsoft's local sign-in system. Depending on the device, it can use a PIN, fingerprint, or facial recognition. The credentials are tied to the device — they are not simply another online account password you type in.

Windows Hello gives applications a way to ask Windows to verify the person sitting at the device. When Chrome asks Windows Hello to confirm your identity, it is asking the operating system to check that you are the authorised user of that specific machine.

A Windows Hello PIN is associated with the device rather than being a reusable account password. Windows Hello also supports biometric verification where the hardware allows. For detail on how Windows Hello works at a technical level, Microsoft's own documentation is the correct reference.

Windows Hello for saved passwords

Google Password Manager, which is built into Chrome, includes a setting called Use Windows Hello when filling passwords. When this is on, Chrome requires Windows Hello verification before it will:

• fill a saved password into a login field
• reveal a saved password
• copy a saved password
• edit a saved password

According to current Google documentation, this setting is off by default.

To find it in Chrome: open Chrome, go to Passwords and autofill, then Google Password Manager, then Settings. The Use Windows Hello when filling passwords toggle is listed there.

If your business stores passwords in Chrome, this is a setting worth reviewing rather than assuming it is already enabled.

Autofill should save you typing — not remove the need to prove you are the person using the computer.

Windows Hello for saved payment cards

Chrome's payment-method autofill also has a verification option, separately from the password setting. Google calls it Verify it's you to autofill payment methods.

When this setting is on, Chrome requires device-level verification — including Windows Hello where supported — before saved payment information is used. A screen lock must be configured on the device for this setting to function.

To find it in Chrome: go to Chrome Settings, then Autofill and passwords, then Payment methods. The Verify it's you to autofill payment methods toggle is listed there.

This is a device-level setting. It applies to the current device and may need configuring separately on each machine where Chrome is used.

A saved card should be convenient for the account owner, not convenient for whoever happens to be using the PC.

These are two separate settings — both may need configuring

This is important enough to state clearly: enabling Windows Hello for passwords does not automatically protect payment cards, and enabling payment verification does not protect passwords. They are different controls in different parts of Chrome's settings.

Turn on one and you have not necessarily turned on the other.

Both settings are device-level and both are off by default. A user — or IT — needs to enable each one deliberately.

What about saved addresses and other autofill data?

Chrome can also store names, addresses, phone numbers, email addresses, and in some circumstances identity and travel information. Google currently documents stronger verification specifically for passwords and payment methods.

Whether Windows Hello verification applies to other categories of autofill data — such as addresses — should be verified against current Google documentation before drawing conclusions. Do not assume every piece of saved autofill data gets the same protection.

Windows Hello PIN is not just a PIN

Some people assume a PIN is inherently weaker than a password. In the context of Windows Hello, that comparison is not straightforward.

A Windows Hello PIN is associated with the specific device rather than with an online account. It cannot be used on a different machine the way a reusable password potentially can. Windows Hello also supports biometric verification where the hardware supports it.

This does not mean every Windows Hello configuration is equivalent in strength. But it does mean the phrase 'it's just a PIN' underestimates what Windows Hello provides. For a full technical explanation of Windows Hello credentials, Microsoft's documentation is the correct source.

Shared PCs and individual user accounts

Windows Hello cannot create individual accountability if everybody shares the same Windows account.

If more than one person routinely uses a device, each person should normally have their own Windows user account. Browser security — including Windows Hello verification — depends heavily on knowing which user owns the browser profile, the saved passwords, the payment information, the browsing history and the active sessions.

A shared Windows login is a shared identity. Verification built on top of that shared identity does not tell you who actually approved the action.

Chrome profiles

Chrome supports multiple profiles within the browser. A user might have a work profile and a personal profile, or be signed into different Google accounts. Saved passwords, payment information and browsing history can vary between profiles.

Businesses should understand whether staff are signed into Chrome with a personal Google account, a work account, or both — and whether passwords and payment cards from those accounts are syncing.

A Chrome profile helps separate browser data. A separate Windows user account provides the stronger device-level separation.

Chrome profile separation is not a security boundary equivalent to separate Windows user accounts. Do not rely on profile separation as the primary protection for sensitive business credentials.

Should businesses save passwords in Chrome?

This is worth considering deliberately rather than letting it happen by default.

Google Password Manager provides password generation, saved credentials, synchronisation across devices, security checks and — with the setting enabled — Windows Hello protection. For many business users it is materially better than reusing passwords, writing them down or storing them in spreadsheets.

Larger organisations may prefer enterprise password managers, centrally managed identity, passkeys or SSO depending on their requirements. These are legitimate choices.

The important question is not whether the password manager lives in the browser. It is whether the organisation manages credentials deliberately.

Password manager and autofill are related but separate

It helps to understand the distinction. A password manager stores and manages credentials. Autofill inserts those credentials into login fields when you need them. The Windows Hello verification setting is controlling when saved information can be used — the point where stored credentials become active.

Saving a password and filling a password are related but separate actions.

Passkeys and the longer-term direction

Passkeys reduce reliance on reusable passwords and provide phishing-resistant authentication in services that support them. Windows Hello itself can be used as part of passkey authentication — it provides the local verification step that unlocks a passkey stored on the device.

The long-term direction is fewer reusable passwords, not better ways of repeatedly typing them.

IT Club has separate guides on setting up passkeys for Microsoft and Google accounts. If your business has not reviewed passkey options, that is a worthwhile next step alongside the settings covered in this article.

Payment details on business PCs — challenge the requirement

Before enabling payment verification, it is worth asking a more fundamental question: which members of staff actually need business payment card details saved in their browser?

Someone who handles purchasing, pays invoices or manages subscriptions may legitimately need those details accessible. A general staff member may have no business reason to store company payment cards at all.

The safest saved payment card is the one the user genuinely needs to have access to.

Card security codes

Chrome currently supports saving card security codes (CVV or CVV2 numbers) in some circumstances. Users can save, edit, remove or disable saving of security codes depending on the configuration.

Businesses should consider whether saving card security codes alongside card numbers is appropriate for their situation. The combination of card number, expiry date and security code is what most online payment forms require.

Convenience settings deserve more scrutiny when the information being saved can spend money.

Whether saving card security codes in Chrome affects PCI DSS obligations is a question for a qualified assessor familiar with your specific setup — IT Club does not make compliance conclusions here.

Google Account sync

When users sign into Chrome with their Google Account, certain saved information can synchronise across devices. Passwords, payment methods and addresses may be associated with Chrome, the Google Account, or Google Wallet depending on configuration.

Windows Hello verification applies to the device where the check is performed. If a saved password syncs to another device and that device does not have Windows Hello verification enabled, the protection on the first device does not carry over.

If users sync sensitive information, account security becomes important too. Protecting the PC matters. Protecting the cloud account holding or syncing the data matters too.

• Use strong Google Account authentication
• Enable MFA or passkeys on the Google Account
• Review recovery methods
• Monitor account activity

What Windows Hello autofill verification does not protect against

It is worth being clear about limitations. Windows Hello autofill verification does not by itself prevent:

• phishing where the user willingly approves access
• malware already running as the user on the device
• account compromise that happens outside the device
• session-cookie theft — an attacker with a valid session cookie may not need the password
• malicious browser extensions with appropriate permissions
• weak or absent MFA on the account itself
• shared Windows accounts where individual accountability cannot exist
• an already compromised device

Good local authentication reduces one risk. It does not turn a compromised PC into a safe PC.

Browser extensions and what they can see

Browser extensions can request permissions that allow them to read content on the pages a user visits. Depending on those permissions and their design, extensions may potentially access information that appears in the browser — including saved credentials in some circumstances.

Businesses should periodically review installed extensions, check what permissions each extension has requested and whether that access is genuinely needed, and consider central management of extension allow and block lists.

A secure browser configuration includes controlling what you add to the browser, not just what you save inside it.

The IT Club Browser Security Model

Browser security does not sit in one place. Think of it as a chain of layers, each of which needs attention:

Browser security is only one layer of account security.

Windows Hello autofill verification sits in the Browser and User layers. It depends on the Device layer being in reasonable shape first. And it does not protect the Account layer on its own — that still requires MFA.

Business browser security checklist

Work through this checklist on each device where Chrome is used for business purposes.

Windows

• □ Supported Windows version installed and up to date
• □ Automatic screen lock configured with a short timeout
• □ Windows Hello configured — PIN, fingerprint or facial recognition
• □ BitLocker or device encryption enabled where appropriate
• □ Each user has their own Windows account — no shared logins

Chrome

• □ Current supported version of Chrome installed
• □ Automatic Chrome updates enabled
• □ Use Windows Hello when filling passwords — reviewed and enabled if appropriate
• □ Verify it's you to autofill payment methods — reviewed and enabled if appropriate
• □ Saved payment cards reviewed — unnecessary cards removed
• □ Saved card security codes reviewed
• □ Unnecessary browser extensions removed
• □ Extension permissions reviewed

Account

• □ Google Account MFA or passkeys enabled
• □ Account recovery methods reviewed and current
• □ Work and personal Chrome profiles reviewed — appropriate separation in place

Passwords

• □ Unique passwords used for all accounts
• □ A password manager in use
• □ Weak or reused passwords reviewed and replaced
• □ Passkeys used where the service supports them

Business

• □ Company payment card access restricted to staff who genuinely need it
• □ Browser policies documented — staff know what is and is not permitted
• □ Shared Windows accounts avoided

What businesses should do

• 1. Lock PCs automatically — configure a short inactivity timeout on every device
• 2. Use individual Windows accounts — every person should have their own login
• 3. Configure Windows Hello — set up PIN, fingerprint or facial recognition on each device
• 4. Enable Chrome Windows Hello verification for passwords — find it in Google Password Manager settings
• 5. Review payment autofill verification — enable the Verify it's you setting where payment cards are saved
• 6. Review what payment information is actually saved — remove cards staff do not need
• 7. Use MFA or passkeys on important accounts — Windows Hello protects the credential, MFA protects the account
• 8. Review Chrome sign-in and sync — understand what is syncing and whether the Google Account is appropriately protected
• 9. Manage browsers centrally where practical — enterprise controls add consistency the user-level setting cannot
• 10. Test the settings — verify Windows Hello verification is actually being asked before trusting that it is working

Security settings only count if they are actually enabled on the devices people use.

Cyber Essentials

Windows Hello autofill verification is not specifically a Cyber Essentials requirement. Enabling it does not make a device Cyber Essentials compliant.

However, the wider controls covered in this article — individual user accounts, screen locking, software patching, access control and authentication — directly support the access control and user authentication requirements in Cyber Essentials. This setting can improve security, but turning it on does not make a device 'Cyber Essentials compliant'.

Operational Heartbeat — keep browser security current

Browser configuration changes because Chrome updates, new features appear, users add extensions, passwords accumulate, payment cards change, devices change and Google policies evolve.

Browser security needs an Operational Heartbeat: versions, extensions, saved credentials, authentication and autofill controls should be reviewed rather than assumed to remain secure.

A periodic browser review should cover Chrome version and update health, autofill settings, password manager status, browser sign-in, extension review, Windows Hello configuration, screen lock timeout, account security, passkey adoption and whether any devices have changed hands.

The IT Club View

This is a small setting. But it represents a useful security principle: convenience should require proportionate verification.

Saved passwords are useful. Autofill is useful. Saved payment information is useful. The mistake is treating convenience as the same thing as trust.

If Chrome is about to fill something valuable, asking Windows to confirm who is sitting at the keyboard is a sensible extra step.

It will not stop every attack. But it is simple, low-friction, useful, and worth enabling where appropriate.

Security does not always require another product. Sometimes it means finding the stronger setting already available in the software you use every day.