Thank you to everyone who participated in our Ask Me Anything on Okta Device Access! For those who couldn’t join, we’ve put together the top five highlights from the session. You can also dive into the full discussion to explore detailed answers from our product expert by reading the complete discussion thread.

Here are the key takeaways:

• Relationship between Okta Device Access and Windows Hello for Business

Our expert clarified that Okta Device Access has its own credential provider. To ensure users are prompted for Desktop MFA by Okta, you should exclude Windows Hello as a credential provider on their devices using Okta. This means you’ll typically use either Okta Desktop MFA or Windows Hello, but not simultaneously for the same MFA prompt. Relevant registry keys for this configuration can be found in our documentation here.

• Streamlined implementation journey for Okta Device Access

Curious about rolling out Okta Device Access? Good news! Overall implementation is very simple and quick once the feature is enabled in your Okta tenant. The general steps involve:

• Add the Desktop MFA (DMFA) or Platform Single Sign-On (PSSO) app in your Okta tenant and assign users
• Deploy the Okta Verify App along with the necessary configurations (We recommend to start with a small pilot group and gradually extend your testing in phases).
• For more information, see our documentation

• Fortifying trust with Okta Device Access

How does Okta Device Access fit into a Zero Trust architecture? Our expert highlighted that it’s a pivotal advancement in the Zero Trust initiative. Okta Device Access is designed to provide seamless access to necessary resources while simultaneously reinforcing device security. This integration is a crucial step in maturing a Zero Trust architecture, ensuring that access is not only frictionless for users but also rigorously protected at the device level.

• Navigating mandatory vs. optional registry keys and policies

For Windows, it is suggested to create all recommended policy configurations and then disable those not needed for specific use cases, like OfflineLoginAllowed, for example. For macOS DMFA, specific policy configurations are in place, and you should pick the one that best fits your use case. You can follow our Community blog post for additional deployment insights.

• Desktop Password Sync is now platform Single Sign-On (PSSO)

If you’ve been seeing “Desktop Password Sync,” you may have noticed “Platform Single Sign-On” now mentioned in the documentation, to which our expert clarified that we simply renamed the application. You can continue using Desktop Password Sync; however, if you choose to transition to PSSO, be aware that a new ClientID will be created, requiring you to adjust your MDM profiles and re-push them to your devices.

As we continue our AMA program, we’re excited to bring you more topics and connect you with our product experts to discuss the issues that matter most to your organization. Stay tuned for upcoming sessions—we look forward to seeing you!