<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Logs Event "Access has been denied because the policy requirements could not be satisfied"
Multi-Factor Authentication
Okta Identity Engine
Overview

The article provides the troubleshooting steps for a scenario in which a user is unable to access Okta or an application due to policy requirements.

This can be determined by the following event in System Logs:

 

 Access has been denied because the policy requirements could not be satisfied by the users’ current set of available authenticator enrollments



System Logs Event 

Applies To
  • Okta Identity Engine (OIE)
  • Enrollment policy
  • Authentication Policy
Cause

At every login, the enrollment policy is evaluated to determine what authenticator the user is allowed to use to satisfy the authentication policy requirements, such as being able to use 2 factors or satisfying any possession factor constraints.

  • The common cause is that the user is not allowed to use the factor requested in the authentication policy.
    Authentication methods          Allowed Authenticators 

  • The second cause can be if the possession factor constraints can not be satisfied by the factor in its current form. This is mostly regarding "Phishing resistant" since not all forms of a factor are "Phishing resistant."
    "Phishing resistant" constraint  
    For Okta Verify, only FastPass is phishing-resistant. 

    Okta Verify 

 

NOTE: WebAuthn (FIDO 2) and Okta FastPass (which comes with Okta Verify) are phishing-resistant authenticators. For more information about Phishing-resistant authenticator enrollment.

 

  • Another common cause is that if the user verification settings in Okta Verify are out of sync with the device settings, the policy requirements cannot be satisfied. Users are denied access with the same error.

Enrollment is set to Preferred, and the user can skip enabling either the PIN or Biometrics. However, the authentication policy requires the user to verify with either the PIN or Biometrics:

Enrollment is Preferred Possession factor constraints   

Solution

To allow the user to access Okta or the Application, an Admin will need to compare the authentication policy and enrollment policy to ensure that at least one required factor is set as required or optional.

NOTE: The enrollment policies are evaluated based on priority, so a user can be evaluated using a different enrollment policy than the intended one.

To check the Authentication PolicyTo check the MFA Enrollment Policy
Go to Security > Authentication Policy > search for the app's Authentication Policy Name > edit an existing policy or create a new one > check the Authentication methodsGo to Security > Authenticators > Enrollment tab > select the name of the Authenticator Policy > Authenticators.

Authentication methods

Authenticators

 

 

The second cause requests the user to enroll in the required factor or reset the factor. The most common scenario is migrated users from Okta Classic who have set Okta Verify with only the One-Time Password (OTP) code, Push, and FastPass are not set, and they do not have Okta Verify on the desktop device.

Also, to ensure that there are no out-of-sync settings. If PIN or Biometrics are required for user verification, it is recommended to set Okta Verify to Required in the authentication policy. Please note that this feature, once enabled, has a global effect.

Loading
System Logs Event "Access has been denied because the policy requirements could not be satisfied"