This article goes over commonly asked questions regarding Addigy Identity. If you do not see your question here, please reach out to us by emailing support@addigy.com or submitting a ticket here.
Why do I need to sign in twice to get into my device?
This behavior will occur when both FileVault and Addigy Identity are enabled on a device. Upon the device booting up the FileVault screen will appear and require a user to enter their password (the FileVault screen will look like the native macOS login screen but the device will not have an internet connection). After the user enters their password the disk unlocks which will allow the device to reach Addigy Identity. On the Addigy Identity screen the user will sign in with their email and password. We are looking to make improvements to this workflow in 2026.
How does password syncing work when FileVault is enabled?
If FileVault (FV) is enabled before Addigy Identity is deployed, users will log into the FV window with their local account password. Then the Identity window will appear. After syncing their IdP password to their local account and signing in, their FV password will now be their IdP password.
If FileVault is enabled after Identity is deployed, users will log into the FV window with their IdP password, as it would already be synced and is the same as their local password.
Why is the "Remember Me" or "Don't ask again" checkbox not working when I sign in?
You may notice that different IdPs give different variations of the following: "Don't ask again for 90 days" or "Remember me for 30 days". This feature is not supported within Addigy Identity so even if the end user checks the box they will need to verify MFA the next time they sign into the device via Addigy Identity.
Why am I not able to connect to a WiFi network with Addigy Identity, but can do so after getting into the device?
Addigy Identity only accepts 802.11 WiFi protocols (in general these will only have a WiFi network name and password) because Apple only allows these kinds of connections on the macOS login screen. To sign into the device without a WiFi connection you can enable the "Allow users to leave Addigy Identity and continue to macOS login window" or "Allow users to sign in using their macOS username and password".
What is the best practice for changing users passwords?
Addigy Identity sets the users IdP password as the local macOS password so password changes should always be started from the Identity provider. Although the password has now been changed Addigy Identity still has the old password stored locally because it has not yet been re-launched to sync the password locally.
We recommend the end user power their device off and on to launch Addigy Identity (if FileVault is enabled the end user will need to enter their previous password). Once the end user is at the Addigy Identity screen they can sign into their IdP account with their new password. Addigy Identity will automatically recognize the password needs to be updated and ask the end user for their previous password (Addigy Identity needs the old password to not break the keychain). To see this workflow visit our Addigy Identity End User Experience article.
Is it possible for a device to use both Active Directory and Addigy Identity at the same time?
It is not possible for a device that is bound to Active Directory to utilize Addigy Identity. For these devices to use Addigy Identity the device will need to be un-bound from Active Directory (it may take some time for the un-bind to be fully completed). Once the device is no longer bound we recommend verifying the type of local macOS account that Active Directory created for the end user. In most cases Active Directory creates local users as mobile accounts which may cause problems when these types of accounts try to sync with Addigy Identity. We recommend migrating mobile accounts to local macOS accounts prior to having the end user setup Addigy Identity on their device.
Why does Addigy Identity require a redirect URI (Okta)?
To follow the OpenID Connect (OIDC) standard, we need to provide a redirect URI. After a user signs in, Okta sends the authentication response (including the authorization code) to that URI. For security reasons, this URI has to be pre-registered in your Okta app so only trusted destinations can receive the response. In our setup instructions, we recommend using a structure like https://addigy-{{your-okta-domain}}. The “addigy-” part is just a naming convention we use to help avoid confusion and keep things consistent. That said, you don’t have to use “addigy” specifically. What matters is that the redirect URI is unique to Addigy Identity. You can’t reuse your default Okta domain or any redirect that’s already tied to another app as doing so could cause issues.
Is it possible for Addigy Identity to create a local user and then have Addigy Identity uninstalled from the device?
An advanced way of using Addigy Identity is by utilizing User Attributes. With policy Auto Assignments and Addigy Identity User Attributes you can have Addigy Identity create a local user and then have your policy check for a specific User Attribute via Device Facts. Once the policy detects the Device Fact the device will be added to said policy.
Can both Addigy Identity and Platform SSO function at the same time?
Addigy Identity and Platform SSO can function at the same time on a device. To learn more about Addigy Identity and Platform SSO check out our article on the topic.
Why does a black screen appear after I complete Setup Assistant?
This behavior may occur for devices enrolled into Addigy via Automated Device Enrollment. End users may see a black screen after completing setup assistant which can occur if the Block Setup Assistant While Service Is Getting Configured Addigy Identity setting is not enabled. This setting allows for Addigy to complete the install of Addigy Identity before the end user proceeds past Setup Assistant.