Creating an Adaptive Access policy

You can create an Adaptive Access policy from the IBM® Security Verify administrative console.


  1. Log in to the IBM Security Verify administration console as an Administrator.
  2. From the navigation menu, click Security > Access policies.
    A table lists the available policies by name and description. The icons indicate whether the policy can be deleted Delete. A lock icon Lock indicates that the policy is preset and can't be modified or deleted.
  3. Click Add policy.
  4. Provide the policy name and optionally, a policy description.
  5. Click Next.
  6. Enable the Adaptive Access toggle button.
  7. Optional: Change the actions for each risk level.
    Table 1. Risk levels and remediation actions
    Risk level Description Default actions Available remediation actions
    Very High A user that is assessed as a very high risk must be considered as a critical risk to the business. Either the user was acting in a suspicious way or the device that they are using is unknown, not trusted, or contains malware. Block
    Block (Override)
    The block action overrides all other decisions in the policy.
    MFA (Override)
    The MFA action overrides all other decisions in the policy.
    Allow (Override)
    The allow action overrides all other decisions in the policy.
    The user is denied access.
    MFA always
    Always require MFA, even in the same session.
    MFA per session
    If not already done, force MFA.
    The user is granted access.
    For more information about remediation actions, see Adaptive Access User Actions.
    MFA options
    You can select one or more methods that can be used for multifactor authentication.
    • Email OTP
    • FIDO2
    • SMS OTP
    • Time-based OTP
    • IBM Verify
    • Voice OTP
    High A user that is assessed as a high risk must confirm their identity back to the business each time they attempt to access an adaptive access enabled application. This multi-factor authentication ensures that the business can trust that the user who is accessing the application is in fact the expected user. MFA Always
    Medium A user that is assessed as a medium risk must confirm their identity once per session. This multi-factor authentication ensures that during the initial application authentication the user is actually who they are logging in as. Subsequent authentication requests do not require a second-level authentication. When the session expires, the user is required to provide more authentication. MFA per session
    Low A user that is assessed as a low risk does not need to provide any additional insights into who they are beyond their initial authentication. All subsequent accesses to the application are allowed. When the current Verify session expires, the users are required to reconfirm their identity. Access to applications is granted. Allow
  8. Optional: Enable the user notification toggle to notify the user when access is challenged or denied.
    Table 2. Email information
    Attribute Description User action
    Location If available, the name of the city and country from where the request originated. Validates that this location is a known location from where the user authenticated in the past.
    Browser The name and version of the browser from which the request originated. Validates that this browser is a known browser that the user used for authentication to the application.
    IP address The IP address that the request came in from. If possible, validates whether the IP address is known.
  9. Click Next.
  10. Optional: Add a rule.
  11. Optional: Change the action for the Default Rule.
    Click the Edit for the Default rule and select an action from the menu. Then, click Save.
  12. Click Save.
    The policy is added to the list of available policies and can be selected when you set the access policy for the administration console and home page.

What to do next

Manage the policy rules. See Managing Adaptive Access policy rules.