Multifactor authentication
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 policies and Okta Privileged Access-specific SSO policies used by your organization.
Okta Privileged Access security admins can enable the MFA in the policy rule to secure access to servers and secrets. It can be enabled for both Okta Identity Engine and Okta Classic Engine orgs. After MFA authentication is enabled, users are prompted to fulfill the MFA condition whenever they try to access a secret. Similarly, if MFA is enabled for server access, Okta Privileged Access ensures that authentication meets the MFA condition each time a user tries to connect to a server using SSH or RDP.
To enable MFA, see Security policy.
Learn how multiple authentication and authorization conditions affect user access. See Rule conditions.
Things to consider when you configure MFA
- Avoid setting up 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. 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 users access the resource:
- Modifying MFA setting makes existing MFA challenges invalid
- 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 are no longer valid. As a result, users are required to complete another MFA challenge before being granted access to the resource. However, this doesn't impact any active sessions.
- Phishing resistance takes higher precedence if there are multiple policy rules
-
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
- In multiple phishing-resistant conditions, the one with the lowest re-authentication frequency is selected
-
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.
- For short MFA durations, error occurs if users delay selecting the connection method
- 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 can connect to the server.
- Ensure that users are allowed to enroll devices such FastPass, YubiKeys, or WebAuthn to prevent phishing attacks
- 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 as Okta FastPass, YubiKey, or WebAuthn to prevent phishing attacks.