User16370330549592969269 (Customer Support Online Experience) asked a question.
Our next Ask Me Anything (AMA) will focus on Access Management Policies in Identity Engine, covering Authentication Policies, Global Session Policies, and Account Management Policies.
These policies help admins manage onboarding, access, and recovery operations while balancing security and user experience. Whether you're looking to block factor enrollment outside your network, prompt reauthentication at key moments, or apply phishing-resistant MFA, now’s your chance to ask the experts.
Submit your questions by clicking the ‘Answer’ button below anytime between now and Tuesday, May 6.
Then join us in this thread on Wednesday, May 7, from 9 to 11 a.m. PDT as Okta product experts post detailed, written responses.
Need ideas on what to ask?
✅ How to tailor Authentication, Session, and Account Management Policies
✅ When and why to prompt reauthentication
✅ How Okta Expression Language works in policies
✅ Using Device Assurance to restrict access to trusted devices
We want to hear your questions - drop them below now and get expert insight!
Want to learn more? Check out the blog post -> https://support.okta.com/help/s/blog/a67KZ000000oLpVYAU/may-7-ask-me-anything-access-management-policies?language=en_US
This is great news. Thanks for the update!
How do you restrict the Okta Admin Dashboard to only Admins with Okta Verify registered devices?
Hi @JamesH.28411 (Customer), Thanks for your question. In the Admin Sign on policy, you can create a top level rule where device state is registered and allow access only on this rule. For all other rules, you can deny access. More information on this can be found here.
Below is a sample screen capture detailing this configuration.
1) In OIE, how can we enforce optional multi-factor authentication (MFA) enrollment only when a user accesses an application that requires MFA or an optional factor they have not yet enrolled in?
2) How should we approach a scenario with different verification requirements for various types of authenticators? For instance, I can use Push authentication to reset my password, but to enroll in stronger authentication factors like WebAuthn, I need to use a higher level of authentication.
3) Is there a recommended method for identifying login traffic from Virtual Desktop Infrastructures (VDI) within Authentication Policies, so that we can implement a separate policy set?
Hello @Sandeep KumarN.69621 (Customer) . Thank you for your questions.
I have answers for #1 and #2 below. For #3, I don't think we have a good way to do that yet. But I am investigating and will let you know once we find a way.
1. In enrollment policy keep all the MFA authenticators as Optional Enrollment and in the Application's sign on policy, specify the required authenticators via granular controls[allow specific authentication methods] or Authentication Method chains and this should only prompt the user when they are not enrolled in that specific authenticator in the App sign on policy. [If global sign-on policy requires MFA, user will be prompted even when an app did not specify additional authenticators in App sign on policy]
2. Use the Okta Account Management Policy. By default, password reset relies on legacy verifications, you can change it to use Okta Account Management Policy . Note that the changes to Okta account management policy also applies during authenticator enrollments unless restricted to password reset. See here for more details
Thank you, Bhagya, for your input. I have a follow-up question: Does the custom expression below specifically target AD Password Recovery, or is it applicable to any factor? Additionally, is there a cheat sheet available that lists all supported custom expressions or at least the request elements we can use in custom expressions?
accessRequest.operation == 'recover'
Please ignore my second comment, I was able to find this information on the Okta Docs portal. Please clarify on the first question -
It is applicable for all authenticator enrollment and unenrollment operations. Again, this can be limited to some authenticators only with custom EL expression
Question regarding restricting Okta access for non-corporate devices, specifically BYOD (Bring Your Own Device). Our corporate devices are Windows-based, managed by System Center (SCCM), joined to the Active Directory domain, and equipped with the CrowdStrike EDR agent.
Is it possible to leverage any of these signals to identify whether a device is non-corporate and subsequently prevent it from logging into Okta? . How?