After upgrading to Okta Identity Engine (OIE), some applications might unexpectedly be assigned to the "Any two factors" authentication policy, especially if Terraform is being used to manage the Okta configuration. This results in an unexpected Multi-Factor Authentication (MFA) prompt for users, which can disrupt access to critical applications. This article explains why this happens and how to resolve it.

• Okta Identity Engine (OIE)
• Terraform Okta Provider
• Application Sign-On Policies
• Multi-Factor Authentication (MFA)
• okta_app_saml
• okta_app_oauth

The root cause of this behavior lies in the nuance between the Okta Identity Engine (OIE) upgrade process and how the Terraform Okta provider handles authentication policies.

1. OIE Default Policy Change: During the migration from Okta Classic Engine to OIE, the tenant's default sign-on policy is updated. Before OIE, a less restrictive policy (for example, password only or 1FA) might have been the default as part of classic tenant. Post-OIE, the default policy becomes "Any two factors." 
2. Terraform Provider Behavior: The Terraform Okta provider is designed to associate the tenant's current default sign-on policy with an application if the authentication_policy argument is not explicitly specified in the Terraform configuration for that application. This behavior is consistent across Terraform versions.
3. Application of New Default: When you run a Terraform apply on applications that previously did not have an explicit authentication_policy in their configuration, Terraform now sees the new OIE default ("Any two factors") and implicitly assigns it to these applications. This can happen even if no changes were made to the authentication_policy attribute in the Terraform code, as the terraform plan phase might not always perfectly predict implicit server-side default changes.

To prevent applications from unexpectedly defaulting to the "Any two factors" policy after an OIE upgrade when also using Terraform, explicitly define the authentication_policy id for all the applications in the Terraform configurations.

1. Identify Affected Applications: Review the Okta applications and their assigned authentication policies. Cross-reference this with the Terraform configurations to identify applications where authentication_policy is not explicitly set.

2. Match Terraform Configurations: For each affected application, add or update the authentication_policy argument in the Terraform resource definition (okta_app_saml, okta_app_oauth, etc.) to explicitly specify the desired authentication policy ID. This ensures that the policy remains consistent regardless of changes to the tenant's default.

Refer to this example:

resource "okta_app_saml" "my_saml_app" {
  label              = "My SAML Application"
  sign_on_mode       = "SAML_2_0"
  # ... other application settings ...

  # Explicitly define the authentication policy to prevent defaulting
  authentication_policy = "00pabcdefghijklmnopqrst" # Replace with desired policy ID
}

• Test Changes: Before applying changes to production, test the updated Terraform configurations in a lower environment (for example, staging or UAT) that closely mirrors the production setup. This allows for verification that applications are assigned the correct policies and that no unexpected MFA prompts occur.

• Monitor System Logs: After applying changes, monitor Okta System Logs using the query eventType eq "policy.mapping.create" to track policy assignment events and confirm the desired outcome.