Thank you to everyone who participated in our AMA on Access Management Policies! 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 experts by reading the complete discussion thread.

Here are the key takeaways:

Optional MFA Enrollment 

A few participants were interested in enforcing MFA enrollment only when an application explicitly demands it. This is easily achieved by setting the authenticator as optional in the Authenticator enrollment policy and specifying that the authenticator is a required authenticator when accessing an app in the Application Sign On Policy. Users will be prompted to enroll in the authenticator only when they access this app. 

Tailoring Policies for Granular Security and User Experience

A significant area of interest focused on the flexibility and power of Okta Access policies. Our experts highlight how they can be tailored to enforce conditional access and meet specific organizational needs, like requiring phishing-resistant MFA, limiting factor enrollment within the corporate network, and leveraging Device Assurance Policies to ensure access is granted only from specific trusted devices. The unique capabilities of Okta’s policies lie in its flexibility to be powerful, adaptable to various device platforms, management solutions, and meet security requirements.

When and Why to Prompt Reauthentication

“When and why do users need to reauthenticate?” was a question asked during our AMA. Access Management Policies provide the mechanisms to enforce reauthentication based on specific security requirements or sensitive actions. Policies consider various conditions such as device posture, network zones, and the strength of authentication factors to determine when a reauthentication prompt is needed. The frequency of prompting is controlled within the app sign on policy and can be set to one of the following 3

• Every sign-in - This means whenever the user attempts to SSO to the app, they will be prompted
• When it has been over a specified length of time - This means that the user is prompted only if it was longer than the specified length since this user last verified an allowed authenticator, when SSOing into an app.
• When an Okta global session does not exist - This means that the user is prompted only if the user had never verified this allowed authenticator in this session

Tailoring Policies for FastPass Rollout

To smoothly roll out FastPass, ensuring both enrolled and unenrolled users have a seamless experience is easy, and there are two options. First, create a higher priority option rule in the application sign-on policy for users required to use FastPass, forcing inline enrollment if they aren’t already enrolled. A lower priority rule can accommodate other users, allowing them to authenticate with different enabled authentication. This approach minimizes friction during Fastpass adoption.

Identifying and Restricting Access from Non-Corporate Devices (BYOD)

A customer inquired about leveraging existing signals from corporate devices to identify non-corporate devices and prevent them from logging into Okta. Administrators can configure application sign-on policies to grant access only for registered and managed devices to achieve this goal

What’s Next

Check back soon for details on our next Ask Me Anything. To view past AMA topics, search in the Okta Community.