Use the MFA Policies page to create, update, or delete multi-factor authentication (MFA) policies. Once a policy has been created, you can refer to it in authentication or registration flows designed in PingOne, PingOne DaVinci, or the PingOne MFA API.
When you create a new environment, the MFA Policies page contains a default MFA policy. You can make changes to this policy, or create additional MFA policies of your own. If you have created additional MFA policies, you can set any one of them to serve as the default MFA policy. The default policy serves the following purposes:
- When defining an authentication policy in PingOne, you can add an MFA step and select the Use Default Policy option. This means that the authentication policy will use whatever MFA policy is currently set to be the default MFA policy for the environment.
- The DaVinci PingOne MFA connector includes a policy ID in its configuration. If you do not specify an MFA policy, the connector will use whatever MFA policy is currently set to be the default MFA policy for the environment.
- In the PingOne MFA API, there are calls that allow you to specify a particular MFA policy to use. In these situations, if you do not specify an MFA policy, the flow will use whatever MFA policy is currently set to be the default MFA policy for the environment.
When you create a new MFA policy, specify the following information:
- name for the MFA policy
- the authentication methods that the policy allows
- the method-specific settings, such as how many failed passcode attempts are allowed, and how
long users should be blocked after passcode failureNote: In authentication flows that implement "onetime authentication" with the PingOne MFA API, users are not blocked after passcode failure even if you specify a blocking period in the MFA policy.
- how to determine the method to use for MFA, from among these options:
Note: The Method Selection setting is not applied if you have enabled device authorization and the user is accessing an application from a trusted mobile device. It is also not applied if the user is trying to access the application with a browser that they have used for FIDO2 authentication in the past. In such cases, FIDO2 is used.
- use the method that the user set as their default (User selected default)
- always have the user select the method to use if there is more than one method available (Prompt user to select)
- always have the user select the method to use even if there is only one method available (Always display devices)
If you have enabled Mobile Applications as an authentication method, you must click +Application and provide the following details for the mobile application:
- The name of the mobile application to use (from among those you have defined for the environment)
- The mechanism that should be used to allow the user to authenticate:
- Push - use only the standard push mechanism
- OTP - use only one-time passcodes
- Push & OTP - use the standard push mechanism, and allow OTP as a backup mechanism
- How much time a user should have to respond to a push notification before it expires (Push Notification Timeout)
- The number of consecutive push notifications that can be ignored or rejected by a user within a defined period before push notifications are blocked for the application (Limit Push Notifications). The purpose of this feature is to help you prevent attacks based on repeated push notifications that lead users to eventually accept the request. You can specify the number of notifications (1-50), the time period (1-120 minutes), and the block duration (1-120 minutes).
- Whether the application should allow Auto Enrollment. This means that the user can authenticate for the first time from an unpaired device, and the successful authentication will result in the pairing of the device for MFA.
- How much time an issued pairing key can be used until it expires (Pairing Key Lifetime)
- Whether to allow Device Authorization. If this option is
enabled, the trusted device handles the authentication automatically, and no user
involvement is required. This automatic mechanism is used only if the user is
requesting access from the same device. If you are enabling Device
Authorization, choose one of the following options for
- Disabled - do not use an extra verification step
- Permissive - a push is sent to the device to be handled automatically. If the push is not received, access is granted nonetheless.
- Restrictive - a push is sent to the device to be handled automatically. If the push is not received, access is not granted.
- How authentication and registration attempts should proceed in the event that a device
integrity check yields inconclusive results. Select
Permissive if you want to allow the process to continue.
Select Restrictive if you want to block the user in such
The Permissive/Restrictive buttons are displayed only if device integrity checking has been enabled for the application on the Authenticator tab of the Applications definition page.