Upgrade user accounts on devices

AI-generated Key Takeaways

outlined_flag

• Upgrading a user account migrates it from a device-centric managed Google Play Account to a corporate managed Google Account for improved integration with all Google services.

• Key benefits of upgrading include seamless access to all Google services via single sign-on, enhanced user management, and direct control over identity lifecycle.

• The upgrade process involves an IT admin updating a device's policy to require a managed Google Account, potentially with a specific email address.

• New API fields and non-compliance reasons are introduced to support user account upgrades within device policies.

• Different user upgrade scenarios exist, ranging from prompted logins to silent upgrades, depending on policy configuration and whether the required account is already present on the device.

• Non-compliance during the upgrade process can lead to policy enforcement actions such as device blocking or wiping.

Upgrading a user account on a device involves migrating it from a managed Google Play Account to a managed Google Account. This process shifts the user's identity from a device-centric, non-personal account to their corporate Google identity, which is the foundation for a more integrated user experience across all Google services.

Overview

The primary goal of this upgrade is to provide customers with enhanced features, such as improved user management through the Google Admin console, stronger security, and access to Google services and AI capabilities like Gemini.

Key benefits of upgrading user accounts:

• Works with all Google services: Unlike managed Google Play Accounts, this new identity works seamlessly with all Google services, including Google Drive, Docs, and Meet. It also supports device backup when enabled by the IT admin.

• Seamless user experience: Through single sign-on (SSO) integration, users are automatically signed in to their corporate environment and all their Google services, such as Gmail.

• Direct identity control: The organization can directly control the identity lifecycle through manual, automated, or sync-based methods.

• Familiar user identifier: For better visibility, the new account uses the same email address that the user already knows and uses.

Prerequisites

1. The customer's Google Workspace Domain must be domain verified. It simplifies user management for the IT admin and also allows them to sync directory.

2. Managed Google Accounts for each of the users in the intended account upgrade must exist prior within the admin console.

API changes

This section outlines the key API changes within the policy and non-compliance flow to support user upgrade. User upgrade adds a new field within enterprises.policies, and adds new enums in enterprises.devices to support new non-compliance reasons.

• New fields and enums in the policy workAccountSetupConfig.
• New enums added to specificNonComplianceReason.

Account upgrade process

To upgrade an account, an IT admin updates a device's policy to require a managed Google Account for authentication. This is done using the workAccountSetupConfig and setting the authentication type to GOOGLE_AUTHENTICATED.

The optional requiredAccountEmail parameter allows the IT admin to specify the exact account the user must use to successfully complete the setup.

Depending on the configuration and whether the required account already exists on the device, the user will be prompted to add either a specific managed Google Account or any valid managed Google Account or the upgrade happens automatically in the background.

Upon completion, the new managed Google Account becomes the primary one for device management, replacing the old managed Google Play Account.

New non-Compliance reasons

New non-compliance reasons have been added to allow the IT admin to trigger policy enforcement based on different scenarios encountered during the user's login.

• If the account entered by the user does not match the requiredAccountEmail, an error message is immediately shown on the screen.

• If the IT admin accidentally specifies a required email address that is not part of the enterprise domain, the non-compliance reason REQUIRED_ACCOUNT_NOT_IN_ENTERPRISE is returned.

• If no requiredAccountEmail is specified and the user tries to enter an account which is not part of the enterprise, the non-compliance reason NEW_ACCOUNT_NOT_IN_ENTERPRISE is returned.

User upgrade scenarios

These user journeys illustrate common scenarios and outcomes when implementing and using the user upgrade feature. They cover experiences from both the IT admin and end-user perspectives. All scenarios assume the device is initially enrolled with a managed Google Play Account.

We recommend that you familiarize yourself with these journeys to better support your customers and validate them with your solution.

Successful upgrade with a specific managed Google Account required

When a device's policy is configured with authenticationType set to GOOGLE_AUTHENTICATED and a specific requiredAccountEmail, the user is prompted to add that managed Google Account. After the user logs in, the device syncs the new policy and becomes compliant. As a result, the old managed Google Play enterprise account is removed, and the device is now primarily managed by the specified managed Google Account.

Successful upgrade with no specific managed Google Account required

When a device's policy is configured with authenticationType set to GOOGLE_AUTHENTICATED but does not specify a requiredAccountEmail, the user is prompted to add a managed Google Account. The Google login screen does not pre-populate an account, so the user adds any valid managed Google Account for their enterprise. The device then becomes compliant, managed by the new managed Google Account. As a result, the old managed Google Play enterprise account is removed, and the device is now primarily managed by the specified managed Google Account.

Silent upgrade when required managed Google Account already exists

If a device's policy is configured with authenticationType set to GOOGLE_AUTHENTICATED and a specific requiredAccountEmail, and that specified managed Google Account already exists on the device, the upgrade occurs silently without the user being prompted. The managed Google Play enterprise account is removed, and the pre-existing managed Google Account becomes the primary account for the device's management.

Prompted upgrade with user selection (pre-existing account, no specific account required)

When a device's policy is configured with authenticationType set to GOOGLE_AUTHENTICATED without a specific requiredAccountEmail, and a valid managed Google Account already exists on the device, Android Device Policy will prompt the user to select or add an account. The user may be presented with an account picker and must select or add the chosen managed Google Account, as this is not a silent upgrade. The device then becomes compliant, with the selected managed Google Account serving as the primary account for the device's management.

Upgrade triggered immediately post-enrollment

When a device's policy is configured with authenticationType as GOOGLE_AUTHENTICATED and a requiredAccountEmail before enrollment, it initially gets a managed Google Play Account. Immediately after enrollment, Android Device Policy prompts the user to add the required managed Google Account. The user adds the account through a Google login screen, causing the device to sync, become compliant, and remove the managed Google Play Account.

Policy enforcement and compliance

Android Device Policy includes built-in compliance actions that help guide users through required upgrades and other policy updates. These actions also provide IT administrators with the tools to manage remediation for non-compliant devices.

Non-compliance leading to device block or wipe

When a device's policy requires a managed Google Account (for example, with authenticationType as GOOGLE_AUTHENTICATED and a requiredAccountEmail) and is also configured with policyEnforcementRules that specify a block or wipe, Android Device Policy will display warnings if the user remains non-compliant. If non-compliance persists beyond the set days for a block, device usage is blocked. If it persists beyond the days for a wipe, the device is factory reset. This is similar to the existing non-compliance flow.

Attempted Sign-In with an Unauthorized Account (blocked at login)

If a device policy requires a specific managed Google Account using requiredAccountEmail, but the user attempts to sign in with a different managed Google Account, an error message is displayed directly on the Google login screen. This prevents the unauthorized sign-in. An example message is, "Work policy requires the specified work account."

Attempted sign-in with an account outside the enterprise (account removed)

When a device's policy requires a managed Google Account but no requiredAccountEmail is set, and the user signs in with an account that is not part of the EMM-linked enterprise, the unauthorized account is automatically removed. The user is then prompted to sign in again with a valid account. The device status report reflects a nonComplianceReason of USER_ACTION and a specific reason of NEW_ACCOUNT_NOT_IN_ENTERPRISE.

Admin misconfiguration: required account not part of enterprise

If an admin misconfigures the policy by setting a requiredAccountEmail that is not part of the enterprise, Android Device Policy will display an error message, possibly titled "Contact IT admin." The device will remain non-compliant, and the device status report reflects a nonComplianceReason of USER_ACTION with the specific reason REQUIRED_ACCOUNT_NOT_IN_ENTERPRISE. The user can only proceed with the upgrade after the admin corrects the policy with a valid primary account.