Multifactor authentication (MFA) is an additional layer of security that helps verify the identity of a user who is attempting to access a resource protected by Okta Privileged Access. By enabling MFA, orgs can add a more robust layer of protection to safeguard privileged access to resources, in addition to the Okta Sign-On (SSO) and Okta Privileged Access-specific SSO policies used by your organization.
Okta Privileged Access security admins can enable the MFA in the policy rule. It can be enabled for both Okta Identity Engine and Okta Classic Engine orgs. After MFA authentication is enabled, each time a user tries to connect to a server with SSH or RDP, Okta Privileged Access will validate that authentication meets the MFA condition.
To enable MFA, see Security policy.
Things to consider when you configure MFA
- Okta recommends that you avoid setting up security policies that overlap with each other. A security policy may overlap when a user belongs to multiple groups used in different security policies, or when the same resource is included in the security rules of two different policies. However, if you do decide to implement such policies, consider the following:
- When creating security policies that allow access to a resource, it's important to avoid overlapping policies with different MFA settings. If such policies exist, the system enforces the most restrictive MFA requirement when accessing the resource. Therefore, Okta advises against creating overlapping security policies.
- If an existing MFA setting is modified in a security policy rule, any MFA challenges that users have completed to access resources governed by the security policy will no longer be valid. As a result, users are required to complete another MFA challenge before being granted access to the resource. This, however, doesn't impact any active sessions.
If there are multiple policy rules, either in the same or different policies, phishing resistance takes higher precedence. For example, if a policy has MFA enabled with the following rules:
- Rule 1: Phishing resistant
- Rule 2: Any two factor types
In this scenario, the system selects Rule 1.
If there are multiple phishing resistant type MFA conditions, the system selects the one with the lowest re-authentication frequency. For example, if a policy has MFA enabled and re-authentication frequency configured with the following rules:
- Rule 1: Phishing resistant with re-authentication frequency set to 3600 minutes
- Rule 2: Phishing resistant with re-authentication frequency set to 600 minutes
- Rule 3: Any two factory types with re-authentication frequency set to 4200
In this scenario, the system selects Rule 2.
- If security policies have short MFA durations, end users who delay choosing their connection method and account may receive a "server not found" error when attempting to connect to a server. This is because their MFA authentication may have expired. To resolve this issue, users can reconnect to the server and complete the MFA challenge again. After that, they'll be able to connect to the server.
- Before making an MFA policy active with a phishing resistant authenticator type, ensure that Okta org-level admin has allowed users to enroll devices such FastPass, YubiKeys, or WebAuthn to prevent phishing attacks.