User Sign-In/Authentication
Q: If the device loses network connectivity, can users still sign into the device?
Network connectivity is not required for the user to sign into the device, with the exception of SSO authentication. Since the idP manages SSO, it necessitates a network connection. The device itself handles the comparison and logic for barcode, facial recognition, and passcode entry.
Q: What action should be taken if an "Open external app" prompt appears during SSO sign-in?
Depending on the Microsoft Edge version installed on the device, tap Open or Open external app. This is a standard confirmation from Microsoft Edge required to return control to Identity Guardian and complete the sign-in process. Caution: Do not tap Cancel, as that action aborts the authentication process.
This prompt typically appears in the following scenarios:
- PingID: Appears on every sign-in if Microsoft Edge is the default browser and Google Chrome is disabled or not installed.
- Okta SSO: Appears on every sign-in and may also appear during sign-out when Identity Guardian returns from Okta, if Microsoft Edge is the default browser and Google Chrome is disabled or not installed.
- Initial Microsoft Entra Sign-In: Appears once per user during initial enrollment on Edge-default devices lacking Microsoft Authenticator and Company Portal, before Multi-Factor Authentication (MFA) is completed. It does not repeat on subsequent sign-ins.
- Tenant-Side Policy Changes: Appears once following a policy change (e.g., new MFA requirement, password reset, or security info re-confirmation) after a brief redirection through an additional Microsoft page. It does not repeat afterward.
If the prompt appears on every Microsoft Entra sign-in (not just during initial enrollment), or if tapping Open fails to complete the sign-in process, contact Zebra Technical Support to open a support case.
Q: Is a barcode required for user authentication?
Shared devices require a barcode to store user data for authentication. The only exception is when single sign-on (SSO) is implemented, eliminating the need for a barcode. However, for personally assigned devices, barcodes are not utilized. Instead, user data is securely stored within the isolated storage of Identity Guardian on the Android platform.
Q: What if the shared device user loses their barcode?
If the user of a shared device loses their barcode, the only way to recover is to retrieve the barcode from the designated folder on the device: /enterprise/usr/Profiles
Q: If the device is shared among multiple users in a single shift – for example, one nurse grabs another nurse’s device to assist with a patient – how do I know that handoff has occurred?
To ensure a smooth device handoff, a policy incorporating user authentication via barcode and biometric scan (or passcode entry) should be implemented to ensure accountability. This facilitates an automatic profile transition, granting users access to their unique profiles and apps. However, this is only possible if the device screen is locked. Thus, new users receiving a device with an unlocked screen must lock and authenticate themselves. Clear communication of this procedure through the organization's policy is essential for adherence to proper handoff protocol.
Q: Why does the "Scan to Unlock" button still appear on the Identity Guardian sign-in screen after configuring Cloud Passcode as the primary authentication?
This occurs when the On Device Manual Checkin lock-screen event is configured without a verification method. Identity Guardian requires a valid Verification Setup to display the sign-in screen when a user signs out. If this setting is set to NONE, the lock screen defaults to barcode scanning (Scan to Unlock) rather than displaying Cloud Passcode when the application is upgraded or redeployed.
Q: If an admin bypass code is used, how is user accountability tracked?
If the primary and/or secondary authentication methods fail, and an admin bypass code is implemented as a fallback, user accountability is not possible because no user is logged in during this process.
Q: What are the PIN/passcode character entry restrictions?
This is defined by the administrator when setting up the passcode rules in the Enrollment Configuration.
Q: How does Identity Guardian support roles?
Since Identity Guardian can include a user’s role, a unique launcher experience can be created based on different user roles through the Zebra Enterprise Home Screen (EHS) application. Administrators can define multiple layouts tailored to specific roles, ensuring a personalized experience upon device login.
Facial Biometrics
Q: Is facial biometrics required?
Your administrator can opt to enforce other forms of authentication other than facial biometrics, for example passcode or SSO. This applies to both shared or personally assigned devices.
Q: Are device users informed they are opting into biometrics?
Yes, Identity Guardian provides a Terms and Conditions disclaimer to the user that they must accept to use the biometric portion of the solution.
Q: Can I customize the terms a user agrees to when using Biometric?
Yes, an organization can include their own custom Terms and Conditions alongside Zebra’s.
Data Security
Q: Where is device user data stored?
For shared Zebra Android devices, the user data is stored in an encrypted barcode that the user holds and manages. For personally assigned devices, user data is encrypted and stored in the Identity Guardian app’s sandbox within the Android framework, which is protected and only accessible by the app.
Q: How do we ensure the barcode encryption is unique?
Organizations can use their own key to encrypt the data, ensuring only their devices can read the barcode data.
Device Usage Visibility
Q: What visibility does Zebra DNA Cloud provide into device usage via Identity Guardian?
The Zebra DNA Cloud has visibility into which users have device access profiles, including information on when these profiles were created, last used, and the specific device(s) they were utilized on, among other data points.
Secure NFC
Q: We are migrating from old NDEF cards to the new Secure Layer format. What is the most important setting?
When migrating from NDEF to Secure Layer, the most critical setting is to set the User Data Operation in zCreator's NFC Configuration to Wipe card and write. This ensures that the old, unencrypted NDEF data is destroyed before the new, secure data is written, preventing any data persistence risks.
Q: What happens if I leave the security key fields blank in the EMM configuration?
The system is secure by default. If the key fields are left blank, the application automatically falls back to using a set of default, proprietary factory keys. Only custom keys need to be defined if the organization's security policy requires it.
Q: How do I change my organization's security keys without locking out all my users?
Follow the Key Rotation strategy. In the EMM configuration for both IG and zCreator, move the current (old) keys into the Secondary Key fields and enter the new keys into the Primary Key fields. The system then attempts to read cards with the new primary key and, if that fails, will automatically fall back to the old secondary key, ensuring users with older cards can still log in without disruption.
Q: A user's card is not being read by Identity Guardian. What should I check first?
First, ensure the user's device has the correct Identity Guardian policy from your EMM. If using Secure Layer, verify that the Primary and Secondary Read Keys in the Identity Guardian NFC Configuration match the keys that were used to write the card via the zCreator policy. Also, confirm the IG Data Identifier matches between both policies.
Q: Can I prevent an operator from overwriting a card that belongs to someone else?
Yes. In the zCreator Managed Configuration for NFC Configuration, set the Allow Different User Overwrite option to false. With this policy, zCreator first checks if a card contains data from a different user ID. If it does, the write operation is blocked.