What Is GCPW? - Handling Windows Logon with Google Authentication

In consultations about consolidating Windows endpoint logon around Google, the following questions get tangled together with remarkable frequency.

• Does GCPW “just show the Google login screen”, or more?
• What happens to existing local profiles and AD profiles?
• Can it also take care of Windows administrator rights, BitLocker, and update management?
• How do first logon, offline use, 2-step verification, and password changes behave?
• Can it coexist with Active Directory, or does it replace it?

Lump these together carelessly and pre-rollout expectations drift, which is exactly when migration and initial setup start to break.

GCPW is neither a mere “Google sign-in screen” nor a complete replacement for a Windows domain. In practice, the picture becomes much clearer when you separate Google sign-in to Windows, mapping to existing profiles, Google-side password / session operations, and combined use with Windows device management.

This article lays out, for practical use and with plenty of Mermaid diagrams, what happens when you use Google Credential Provider for Windows (GCPW) in a Windows 10 / 11 environment: which configurations it suits, the rollout steps, and the pitfalls. The content is primarily based on Google Workspace official documentation verifiable as of March 2026.

The diagrams are conceptual. They render as diagrams in Mermaid-capable Markdown environments.

1. The Conclusion First

Putting the conclusions up front:

• GCPW is a mechanism for signing in to Windows 10 / 11 with a managed Google account.
• What GCPW alone drives is Windows sign-in and the Chrome Browser SSO experience.
• If you also want Windows updates, BitLocker, local administrator rights, custom settings, and wipe, it is more practical to assume combined use with Windows device management.
• In environments with existing local / AD profiles, you will get stuck in migration unless you first decide “associate the existing profile, or create a new one?”.
• The first sign-in assumes being online. Moreover, on an AD-joined device that does not yet have an existing AD-backed profile, being able to reach AD at first sign-in also matters.
• Offline sign-in is possible, but unless you decide how many days to allow, operations will wobble.
• 2-step verification works, but USB security keys are not supported by GCPW.
• Decide password operations first, or mismatches between the Google side and the Windows side will break logon. In particular, resetting only on the AD / Entra ID side first is dangerous.
• GCPW treats Google as the only identity provider, so design the configuration on that premise to avoid misalignment.

In short, GCPW is “a mechanism for entering Windows with Google” - and if you want to own the whole Windows endpoint operation, the sound approach is to design it together with Windows device management.

Terms Used in This Article

Google-side and Windows-side vocabulary get mixed together here, so let us line them up first.

First, See the Positioning on One Page

flowchart TD
    A["Want to use Google accounts on Windows devices"] --> B{"What do you want to achieve"}
    B --> C["Google sign-in to Windows"]
    B --> D["Centralized management of Windows settings"]
    B --> E["Migrating existing profiles"]

    C --> F["GCPW"]
    D --> G["Windows device management"]
    E --> H["Mapping design for existing local / AD profiles"]

    F --> I["Windows logon"]
    F --> J["Chrome Browser SSO"]
    F --> K["Google password sync"]

    G --> L["BitLocker"]
    G --> M["Windows Update"]
    G --> N["Local administrator rights"]
    G --> O["Custom settings / wipe / auditing"]

    H --> P["Create a new profile?"]
    H --> Q["Reuse the existing profile?"]

This diagram is for looking up the tool from the goal. Reading left to right, choosing what you want to achieve determines which mechanism owns it (GCPW / Windows device management / profile design). There is only one thing to take away here: device-level management such as BitLocker and Windows Update never appears in the GCPW column.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (25 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. GCPW Is Easier to Understand Split into 4 Layers

GCPW discussions get complicated because “sign-in”, “profile migration”, and “device management” tend to be treated as the same box. In practice, splitting it into these four layers is the fast route.

Viewed this way, the causes of misalignments like “we installed GCPW but BitLocker isn’t enforced” or “I got in with Google but my existing user data is gone” become much easier to see.

The Layer Structure

flowchart LR
    subgraph Id["Identity / session"]
        A["Google account"]
        B["2-step verification"]
    end

    subgraph SignIn["Sign-in layer"]
        C["GCPW"]
    end

    subgraph Profile["Windows profile layer"]
        D["Existing local profile"]
        E["Existing AD-backed profile"]
        F["New Windows profile"]
    end

    subgraph Mgmt["Management layer"]
        G["Windows device management"]
        H["BitLocker / updates / local admin rights"]
        I["Custom settings / wipe / auditing"]
    end

    subgraph Config["Configuration layer"]
        J["Admin console"]
        K["Registry settings"]
    end

    A --> C
    B --> C
    C --> D
    C --> E
    C --> F
    J --> C
    K --> C
    G --> H
    G --> I
    C --> G

Where the diagram in chapter 1 went from goal to tool, this one rearranges the same elements by which layer they belong to and what depends on what. Two things to read from it: every arrow passes through GCPW (the sign-in layer), and the arrows leaving GCPW toward the profile layer fan out into three. That fan-out is exactly the “associate the existing profile, or create a new one” design covered in chapter 4.

3. How It Behaves in a Windows Environment

3.1 Pin Down the Support Requirements First

In a Windows environment, the first priority is not tripping over the requirements.

Edition Differences (the First Gate in the Rollout Decision)

“GCPW alone” and “GCPW with Windows device management” require different editions. The supported editions listed in Google’s official documentation (Overview: Enhanced desktop security for Windows) are as follows.

Read it like this. If all you need is sign-in through GCPW, almost every edition can do it. But if you want to manage BitLocker, Windows Update, and local administrator rights, you need one of the supported editions: Business Plus, Enterprise Standard or above, Cloud Identity Premium, and so on. In particular, Business Starter / Business Standard and Cloud Identity Free can use GCPW but not Windows device management. Some “we installed GCPW but cannot manage BitLocker” questions come down to exactly this.

Edition lineups change, so always check the latest support matrix in the official documentation before signing a contract.

The easily overlooked items here are Chrome and the lack of ARM support. Because this is a Windows-endpoint topic, people tend to look only at the OS, but GCPW also depends on Chrome to launch the Google sign-in screen - so a missing or misplaced Chrome can also make logon fail.

3.2 From First Sign-In to Everyday Logon

Simplifying the flow after GCPW is installed:

1. GCPW is installed on the device
2. The user signs in with their Google account for the first time
3. GCPW either associates an existing profile or creates a new Windows profile
4. After that, the user enters via the normal Windows logon screen
5. However, on security events such as a Google password change or session expiry, the Google sign-in screen is required again

The important point here is that it is not the case that “you always enter through the Google dialog every time”. At first logon and on certain security events the Google-side authentication comes to the front, but normally sign-in happens at the Windows logon screen.

The First Sign-In Flow

sequenceDiagram
    participant U as User
    participant W as Windows sign-in screen
    participant G as Google sign-in
    participant P as GCPW
    participant R as Existing / new profile
    participant C as Chrome Browser

    U->>W: Choose Add Work Account or an existing account
    W->>G: Launch the Google authentication screen
    G->>U: Email / password / 2SV
    U->>G: Enter credentials
    G->>P: Authentication succeeded

    alt Associate an existing profile
        P->>R: Find and associate the existing local / AD profile
    else Create new
        P->>R: Create a new Windows profile
    end

    P->>C: Carry over the Google sign-in state
    P->>W: Start the Windows session

The thing to notice in this diagram is that there is only one branch: associate an existing profile, or create a new one. It is settled in the instant of the first sign-in, and going back later to say “actually, use the existing profile” means rework. That is why the association design in chapter 4 has to be finished before the installer goes out.

3.3 Password Sync, Offline, and 2-Step Verification

If you want to operate GCPW stably in a Windows environment, the very first thing to look at is actually password operations.

Google’s official guidance also presumes that, on devices using GCPW, the Google password and the Windows password are kept in sync - and that users primarily manage the Google-side password. That makes it a poor match for designs that rely on changing the Windows password via Ctrl + Alt + Delete.

How to Think About Password Sync

flowchart LR
    A["Google password changed"] --> B{"Is the device online"}
    B -- Yes --> C["GCPW syncs the Windows-side password"]
    C --> D["Next logon succeeds"]

    B -- No --> E["Sync is deferred"]
    E --> F["Re-syncs next time online"]

    G["Password changed only on the AD / Entra ID side"] --> H["Google and Windows mismatch"]
    H --> I["Password incorrect / sync error"]

This diagram splits into two flows. The upper flow (changed on the Google side) syncs when online, and catches up the next time the device comes online if it was offline. The lower flow (changed only on the AD / Entra ID side) never syncs, no matter how long you wait. When you write the password reset runbook, it is worth spelling out that lower flow as a prohibited procedure.

What comes up most often in practice:

• The password was changed on the Google side, but the device was offline and has not yet synced with the Windows side
• Conversely, a reset was done only on the AD / Entra ID side first, creating a mismatch with Google
• The Google-side password complexity was weaker than Windows / AD, and the user changed to a string that fails the Windows-side requirements

So before rollout, you must decide at least this much:

• Does Google hold the ownership of passwords?
• Or are passwords synced into Google from AD / Entra ID / another tool?
• Will password complexity be aligned to at least the Windows-side requirements?

That third item, complexity, is configured per organizational unit under Security > Authentication > Password management in the Google Admin console. What you can specify there, though, is limited to an “Enforce strong password” checkbox, the minimum and maximum length (8 to 100 characters), whether reuse is allowed, and expiration. You cannot specify character classes the way an Active Directory password policy does - “must contain at least N of uppercase, lowercase, digits, and symbols”. The Google side evaluates overall password strength rather than the breakdown of character classes.

So in practice the alignment ends up being: set the Google-side minimum length equal to or greater than the AD side, and turn on “Enforce strong password”. If the AD-side character class requirements are strict, a password accepted on the Google side may still be rejected on the Windows side, so always verify that combination in the pilot.

Offline and 2-Step Verification

GCPW does support offline sign-in. However, you can configure how many days are allowed since the last online sign-in. Roll it out without deciding this, and you tend to land on one of two bad places: too strict and the field suffers, or too loose and the risk on device loss rises.

Also, 2-step verification works, but it is safer to tell the field these points in advance:

• USB security keys are not supported by GCPW
• Instead, assume methods such as the Google prompt, Google Authenticator, and backup codes
• In configurations that allow only security keys, users may be locked out of Windows

4. How to Handle Existing Local / AD Profiles

This is where GCPW migrations break most often.

When a device already has a working Windows profile, whether GCPW associates and reuses it or creates a new Windows profile changes both the user experience and the migration difficulty dramatically.

The Three Representative Patterns

Google’s guidance likewise has you map Windows account names or AD accounts via custom attributes on the Directory side when associating existing profiles, or use SID-based registry settings on the device. In other words, this is a migration task that requires advance design - not an operation where “the user picks something on the spot after install”.

Even more important is the behavior when you do not associate:

• Users of existing local profiles may retain a path into the old profile
• For existing AD users, once a new Google sign-in profile is created, they may not land cleanly in the work profile they expected

Decision Diagram for Handling Existing Profiles

flowchart TD
    A["Device has an existing work Windows profile"] --> B{"Want to keep using its data / settings?"}
    B -- Yes --> C["Design the existing-profile association"]
    B -- No --> D["Let GCPW create a new Windows profile"]

    C --> E{"Type of existing profile"}
    E -- Local --> F["Map via Local Windows accounts, etc."]
    E -- AD-backed --> G["Map via AD accounts, etc."]

    G --> H["Verify AD connectivity at first sign-in"]
    F --> I["Sort out Windows user names / per-device restrictions"]
    D --> J["Run existing-data migration as a separate plan"]

This is a decision you only have to walk through once per fleet of devices. Settle the first branch - do you want to keep using the existing data - at the fleet level, and everything after that converges on either writing the mapping definitions or writing the data migration plan. Leave it to be judged device by device in the field and you end up with new profiles and associations mixed within the same fleet, which makes support load impossible to predict.

5. GCPW Alone vs. GCPW + Windows Device Management

When discussing GCPW, separating these two is extremely important in practice.

Comparison Table

Google officially recommends, for company-issued devices, the configuration that uses GCPW and Windows device management together. Conversely, if you already have another management platform and only want the Google logon experience, GCPW alone is the way to think about it.

A Quietly Important Constraint in Combined Use

When combining with Windows device management, it is safer to understand up front that only one user can be enrolled per device.

Google’s official documentation presents this as a constraint on the Windows 10 / 11 side. Even if multiple users can enter the device via GCPW, only the first user is enrolled into Windows device management. And device-level settings such as BitLocker, updates, and local administrator rights affect the other users of that device as well.

The First-User Problem

flowchart TD
    A["Set up the device"] --> B["First user to sign in via GCPW"]
    B --> C["Enrolled into Windows device management"]
    C --> D["Device-level settings applied"]
    D --> E["BitLocker / updates / local admin rights / custom settings"]

    F["Another user signing in via GCPW later"] --> G["Windows sign-in itself is possible"]
    G --> H["But no additional users get enrolled"]
    H --> I["Device-level settings operate based on the first enrollment"]

Where this bites is the problem of the provisioning technician signing in via GCPW first. If the setup person’s account - rather than the employee who will actually use the device - gets enrolled, the intended settings never land later.

6. What to Decide Before Rollout

What pays off later in a GCPW rollout is the advance design, more than running the installer itself. Translating the official guide into practical terms, you want at least these six decided in advance.

flowchart LR
    A["Decide before rollout"] --> B["Password ownership"]
    B --> C["Complexity requirements"]
    C --> D["Permitted domains"]
    D --> E["Existing-profile handling"]
    E --> F["Admin rights for support"]
    F --> G["Staging policy for auto-enrollment"]
    G --> H["Allowed offline days"]

The order in this diagram carries meaning. Left to right, each item has to be settled before the next one can be. Complexity, for instance, cannot be decided until you know whether password ownership sits with Google or with AD. Put the other way round: skip any link in this chain and ship the installer anyway, and the device count grows while every downstream decision stays open.

Bad Approaches vs. Practical Approaches

Three Especially Easy-to-Miss Points

1. Permitted domains are mandatory

With GCPW, users cannot log on until you decide which domains’ accounts are permitted to log on. You can configure this in the Admin console or via the domains_allowed_to_login registry value - but either way, it is mandatory.

2. Give the Admin console and the registry separate roles

Older write-ups center on registry configuration, but today Admin console management is the baseline. That said, when you want finer granularity - e.g., different permitted domains per device - the registry can be the better fit.

3. Admin console settings are not applied instantly

GCPW settings sync to devices roughly on an hourly cadence. “I entered the setting but it hasn’t applied yet” is common, so during the pilot it is safer to evaluate with this lag in mind.

7. A Practical Rollout Procedure

Here is the flow for rolling out GCPW practically in a Windows environment, kept as short as possible.

Rollout Flow

flowchart TD
    A["1. Verify subscription plan / OS / Chrome requirements"] --> B["2. Decide password strategy and complexity"]
    B --> C["3. Decide permitted domains and other settings"]
    C --> D["4. Decide whether to associate existing profiles"]
    D --> E["5. Enable Windows device management if using it"]
    E --> F["6. Obtain the installer from the Admin console"]
    F --> G["7. Distribute to devices / install with admin rights"]
    G --> H["8. User performs the first online sign-in"]
    H --> I["9. Verify device details / enrollment / logs"]

7.1 First, Decide the Configuration

Decide this first.

• Use GCPW alone?
• Use GCPW + Windows device management?
• Associate existing profiles?
• Or switch over with new profiles?

This decision comes first. Distribute the installer without deciding this, and you end up later with “we can’t manage the devices the way we thought” or “the existing user data didn’t carry over”.

7.2 Decide Permitted Domains and Options

There are two configuration methods.

• Admin console Suited to distributing the same settings organization-wide. This is the baseline today.
• Device registry Suited to fine-grained, per-device differentiation.

If you use the registry, you need at least domains_allowed_to_login. If you combine GCPW with Windows device management, enable_dm_enrollment and validity_period_in_days become decision points; for shared-device-style operations, so does enable_multi_user_login.

7.3 Obtain and Distribute the Installer

Obtain the 32bit / 64bit GCPW installer from the Admin console and distribute it to the devices. The screen you download it from is at this path.

Google Admin console
  -> Menu
  -> Devices
  -> Mobile & endpoints
  -> Settings
  -> Windows
  -> "Google Credential Provider for Windows setup"
  -> "Download GCPW"

This action requires signing in as a super administrator. From there you download the 64bit or 32bit build and distribute it.

What matters in the current management model is that an installer downloaded from the Admin console has that organization’s token embedded in it automatically. Whether the token is there or not shows up later.

If you have already distributed a Chrome Enterprise Core enrollment token to the devices, that token also lets you manage GCPW settings from the Admin console. When “I set the permitted domains in the Admin console but they aren’t reaching the devices”, the first thing to suspect is that a token-less installer went out. Applying a setting also takes up to about an hour, so wait that long before drawing conclusions.

7.4 Install

For a manual install, for example:

# 64bit version
gcpwstandaloneenterprise64.exe /silent /install

# 32bit version
gcpwstandaloneenterprise.exe /silent /install

7.5 Example of Per-Device Registry Configuration

An example of entering, per device, values not configured in the Admin console.

Note: when the same setting exists in both the Admin console and the registry, the Admin console side wins.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Google\GCPW]
"domains_allowed_to_login"="example.com"
"enable_dm_enrollment"=dword:00000001
"validity_period_in_days"=dword:00000007
"enable_multi_user_login"=dword:00000000

7.6 If Reusing Existing Profiles, Build the Mapping Definitions First

If you want to reuse existing local / AD profiles, prepare the mapping between users’ Google accounts and Windows accounts in advance, using custom attributes on the Directory side. Defer this and let users log on first, and you will likely be rolling back after new profiles have already been created. This is the single most breakage-prone step in the whole article, so here it is in concrete terms.

Step 1: Create the custom attributes

Add them from the Admin console under Directory > Users > “More” at the top > Manage custom attributes. Enter the values exactly as below, including capitalization (get them wrong and you cannot rename them later - you have to recreate them).

If you create them through the Directory API, register them with schema name Enhanced_desktop_security and field names AD_accounts / Local_Windows_accounts. To populate the values from an existing AD, Google Cloud Directory Sync is one option.

Step 2: Fill in the value for each user

An “Enhanced desktop security” section appears under User information on the user detail page; enter the Windows-side account name there. The format is fixed.

There are three constraints worth remembering.

• Only one AD account per user. Enter several and GCPW uses only the first.
• If both AD and local values are set, GCPW looks for the AD account first.
• If the attribute is unset, or no matching Windows profile is found, a new Windows profile is created. Most reports of “I associated it, but the existing data is gone” trace back to this.

On an AD-joined device, a user who does not yet have an AD-backed profile on that device (someone entering via “Other user” on the sign-in screen) needs the device to be able to reach AD at first sign-in. Have that user do their first sign-in on a device that is out working remotely and it fails right here.

For the exact click-through steps and the current specification, see the official Associate Google accounts with existing Windows profiles.

7.7 Verify After the First Online Sign-In

After the first sign-in, verify the following.

• Did the user land in the expected Windows profile
• If combining with Windows device management, was enrollment done under the intended user
• Do the device details appear in the Admin console
• Has policy sync completed

8. Common Pitfalls and How to Triage Them on Windows

GCPW trouble almost always falls into one of the rows in this table.

Breaking Down What “Chrome / AV Interference” Actually Means

The vaguest entry in that table is “AV interference”. What actually causes problems is one of the following. Checking them in order speeds up triage.

Of these, traffic before logon is the one most often overlooked. Traffic that goes through fine once the user has signed in may take a different route, or run under different credentials, at the logon screen, so check whether it is stalling there.

The Troubleshooting Flow

flowchart TD
    A["Problem with GCPW"] --> B{"What is happening"}
    B -- Sign-in refused --> C["Check permitted domains"]
    B -- Google screen doesn't appear --> D["Check Chrome presence / path / AV"]
    B -- Password incorrect --> E["Check the Google / Windows sync state"]
    B -- Existing data not visible --> F["Check the profile association"]
    B -- Not entering device management --> G["Check the first enrolled user"]
    C --> H["Check Admin console / registry"]
    D --> I["Reinstall Chrome"]
    E --> J["Re-organize password operations"]
    F --> K["Re-verify custom attribute / SID mapping"]
    G --> L["Review the staging procedure"]

This diagram exists to narrow a symptom down to a single first place to look. GCPW trouble lands in one of authentication, Chrome, password sync, profile association, or enrollment, so fix which column you are in before moving on to detailed logs. When the symptoms look like several at once, checking who the first user to sign in was usually collapses them into the enrollment column.

Where to Collect Logs on Windows

When chasing GCPW on Windows, start with the Event Viewer.

• Windows Logs > Application
• Event source: GCPW

That covers most of the basics. For more detail, you can enable verbose logging via the registry.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Google\GCPW]
"enable_verbose_logging"=dword:00000001
"log_file_path"="C:\\GCPW.log"
"log_file_append"=dword:00000001

If you want to look at Windows device management as well, also check, as needed:

• Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin

When You Want to Confirm Changes Quickly

After fixing permitted domains or policies, if you want to verify quickly, Google’s guidance describes running GoogleUpdateTaskMachineUA from Task Scheduler to prompt a sync. Keeping this procedure at hand during the pilot speeds up triage.

9. Which Organizations It Suits, and Which It Doesn’t

Where It Fits

Where It Doesn’t Fit

10. Summary

The trick to using GCPW well in a Windows environment is not to see the features as a monolith.

• GCPW is the mechanism for entering Windows with Google
• Existing-profile association is the migration mechanism
• Windows device management is the endpoint-operations mechanism

Keep these three separate, and rollout decisions become much easier.

The five points that matter most in practice:

1. Decide password operations first
2. Decide permitted domains first
3. Decide whether to reuse existing profiles
4. If using Windows device management, do not get the first enrolled user wrong
5. Have a troubleshooting procedure built around the Event Viewer

GCPW is a practical tool for shifting Windows logon toward Google. But what really pays off is not the moment you run the installer - it is the design that comes before it. Nail that down first, and Google logon, continued use of existing data, and Windows endpoint management all connect cleanly.

Related Articles

• When Do You Actually Need Administrator Privileges on Windows? - UAC, Protected Areas, and How to Tell by Design
• How to Speed Up App Validation with Windows Sandbox
• What Is ClickOnce? - How It Works, How It Updates, and Where It Fits (and Doesn’t) in Practice

Related Topics

• Windows Technical Topics

Services This Topic Connects To

• Windows App Development
• Technical Consulting & Design Review
• Contact Us

References

1. Google Workspace Help - Overview: Enhanced desktop security for Windows
2. Google Workspace Help - Prepare to install GCPW
3. Google Workspace Help - Install Google Credential Provider for Windows
4. Google Workspace Help - Set up GCPW and Windows device management together
5. Google Workspace Help - Associate Google accounts with existing Windows profiles
6. Google Workspace Help - Set account privileges on Windows 10 or 11 devices
7. Google Workspace Help - FAQ for GCPW
8. Google Workspace Help - Troubleshoot GCPW
9. Google Workspace Learning Center - Sign in to Windows after GCPW installation
10. Google Workspace Help - Set token to manage GCPW from the Admin console
11. Google Workspace Help - What’s new in GCPW
12. Google Workspace Admin Help - Enforce and monitor password requirements for users

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

What is GCPW?

GCPW (Google Credential Provider for Windows) is a mechanism for signing in to Windows 10 / 11 with a managed Google account. On its own, what it drives is Windows sign-in and the Chrome Browser SSO experience; it is neither a mere Google sign-in screen nor a complete replacement for a Windows domain. The supported operating systems are Windows 10 / 11 Pro, Pro for Workstations, Enterprise, and Education. ARM-based devices are not supported, and Chrome Browser 81 or later must be installed with administrator rights.

Can GCPW alone manage BitLocker and Windows Update?

Essentially no. What GCPW alone gives you is Windows sign-in with Google, Chrome SSO, and association with existing profiles. BitLocker, Windows Update control, control of local administrator rights, custom settings distribution, and wipe all assume that Windows device management is used alongside it. In the combined configuration, only the first user can be enrolled on a given device, so watch out for the failure mode where the provisioning technician signs in first and ends up being the enrolled account.

Can users log on to Windows with GCPW while offline?

Offline sign-in itself is possible. However, the first sign-in requires internet connectivity, and on an AD-joined device with no existing AD-backed profile, the device must also be able to reach AD at that first sign-in. How many days of offline use to allow is configurable through settings such as validity_period_in_days. If you do not decide how many days past the last online sign-in are acceptable, you tend to land on one of two extremes: too strict and the field suffers, or too loose and the risk when a device is lost goes up.

Does GCPW support 2-step verification and security keys?

2-step verification works, but USB security keys are not supported by GCPW. Plan instead on methods such as the Google prompt, Google Authenticator, and backup codes. In a configuration that permits only security keys, users can end up unable to get into Windows, so it is safer to tell the field before rollout. Passwords also assume that the Google side and the Windows side stay in sync, so resetting only on the AD / Entra ID side first leads to logon failures caused by the mismatch.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.