In Okta Classic Engine environments, administrators attempting to modify sensitive configurations, such as Okta Sign-On Policy rules, may find they are unable to save their changes. Investigation of the Okta System Log may reveal corresponding events with the outcome reason "Protected action attempted CHALLENGE".

This indicates Okta's "Protected Actions" security feature has been triggered. This behavior is intended and results from security enhancements requiring administrator step-up authentication for designated critical tasks. The specific protection for updating Okta Sign-On policies became Generally Available for Classic Engine in April 2025.  

• Active Directory
• AD-sourced Admins
• Okta Admins
• Okta Classic Engine

The inability to save the policy change, often correlated with the "Protected action attempted CHALLENGE" log event, occurs in Okta Classic Engine due to a specific platform characteristic:

1. Protected Action Triggered: Modifying the sign-on policy correctly initiates the Protected Actions flow, requiring administrator re-authentication as a security measure. This is logged in the System Log.
2. Limitation for AD-Sourced Administrators in Classic Engine: The core issue arises when the administrator performing the action uses an account sourced from Active Directory (AD). Okta Classic Engine explicitly does not support the completion of the Protected Actions step-up authentication flow for these administrators.  
    
3. Inability to Complete Step-Up: Consequently, although the security requirement is triggered (and logged), the Classic Engine platform lacks the mechanism for the AD-sourced administrator to successfully re-authenticate and satisfy the requirement. This prevents the policy modification from being saved

Identifying the Event in System Log

You can query the Okta System Log to find these events using the following query:

eventType eq "security.protected_action.attempt" and outcome.result eq "CHALLENGE"

To manage this situation within Okta Classic Engine, consider the following approaches:

1. Verify Administrator Account Type: First, confirm whether the administrator account encountering the issue is sourced from Active Directory (AD) or is Okta-sourced.
2. Use an Okta-Sourced Admin Account: The most direct resolution is to perform the policy modification using an Okta-sourced administrator account with sufficient privileges.
   • Ensure this administrator has appropriate Multi-Factor Authentication (MFA) factors enrolled.
   • Confirm browser pop-ups are enabled for the Okta domain, as these might be needed if a step-up prompt were supported and presented.
3. API Workaround (Advanced): Utilize the Okta API to modify the policy rule programmatically, bypassing the UI-based step-up challenge.
   • Obtain Token: Generate an Okta API token with sufficient permissions.
   • Identify IDs: Find the specific policyId of the Okta Sign-On Policy and the ruleId of the rule you need to modify. These can be found by employing a tool like Postman, curl, or a custom script to send an HTTP GET request on the following endpoints:

     1. Policy ID: /api/v1/policies/{{policyId}}
     2. Rule ID, using Policy ID: /api/v1/policies/{{policyId}}/rules/{{ruleId}}

      
   • Prepare Request: Prepare an HTTP PUT request to the endpoint: 

     /api/v1/policies/{policyId}/rules/{ruleId}

      

   • Construct Payload: Create the correct JSON body for the PUT request, containing the complete desired configuration for the rule, including the modified settings.
   • Execute: Send the authenticated API request to update the rule.
4. Plan for Okta Identity Engine (OIE) Migration: Consider the long-term benefits of migrating to Okta Identity Engine (OIE). OIE includes native support for administrators sourced from external directories (including AD) completing protected action step-up authentications, resolving this specific limitation found in Classic Engine.

Related References

• Okta Policies API - Replace a policy rule
• Okta Classic Engine release notes (Production) - Step-up authentication for updating policies
• Protected actions in the Admin Console.