Under certain conditions, it is possible for a browser to get enrolled in Push as the wrong user. This can happen if you use shared credentials when logging into SaaS apps observed by the Push browser extension in a browser profile that has not yet been enrolled.
Description of issue
If you deploy the Push browser extension using a device management tool, the token that links browsers to your Push tenant is a single identifier. Once installed, the browser extension then uses the following techniques to link the browser to a specific employee:
Checks if there is a user logged into the browser where the extension is installed.
Looks for an email address from an open Google Workspace or Outlook tab in the browser.
Waits for an email login into one of the SaaS apps that Push supports and observes the email address of the user that way.
In cases where User A is not logged into their browser, or browser login is not supported (such as with Brave), and they also log into a SaaS app using User B’s credentials on a browser profile that has not yet been enrolled, the extension will incorrectly identify them as User B, because that is the username observed by the extension.
This issue does not occur with browser self-enrollment completed by the employee via email or ChatOps. In those cases, the enrollment link is uniquely tied to that individual.
This issue also does not occur if a browser profile is already enrolled in Push. Enrollment is a one-time action unless the extension is deleted.
To remove the mistaken enrollment, you can unlicense the employee (User B in this case) in the admin console and then re-license them.
To prevent this issue from occurring, you can:
Require users to log into their browsers, if supported.
Avoid using shared SaaS credentials.
If you must use shared credentials in certain situations, be sure you are logging into the app with the shared credentials in a browser profile already correctly enrolled to you.