okta · thomascavanagh-okta · May 5, 2026 · May 7, 2026 · May 8, 2026 · May 13, 2026
@@ -109,6 +109,32 @@ Use the [App sign-in policies page](https://help.okta.com/okta_help.htm?type=oie
 
 > **Note:** API service apps aren't automatically assigned a default app sign-in policy. You must explicitly assign an app sign-in policy to each API service app.
 
+##### Staged policy branches
+
+<ApiLifecycle access="ea" /><ApiLifecycle access="ie" />
+
+> **Note:** This functionality is available as a self-service Early Access (EA) feature for Identity Engine orgs. To use it, enable the Change management for app sign-in policies feature. See [Self-service features](/docs/concepts/feature-lifecycle-management/#self-service-features).
+
+App sign-in policies support branching, which lets you draft, test, and deploy policy changes without affecting end users until you're ready to promote them.
+
+A policy can have at most one draft or staged branch at a time, alongside the live branch.
+
+An app sign-in policy branch can have one of the following states:
+
+* **Draft branch:** A new branch that's created as a copy of the live policy. Rules are inherited and can be edited. You can promote draft branches directly to live, but you can't monitor them.
+* **Staged branch:** A draft branch that has been staged. Rules can be added, updated, or deleted. You can enable monitoring on a staged branch to evaluate its rules against real user traffic without enforcing them.
+* **Live branch:** The set of policy rules that are currently enforced. This is the standard branch state for an app sign-in policy.
+
+Enable monitoring on a staged branch to evaluate its rules against real user traffic without enforcing them. This lets you assess the impact of your changes before you deploy them.
+
+To enable this, set a monitoring expiry date when you stage the branch. The maximum monitoring period is 28 days. Monitoring stops automatically when you promote the brach to live, revert it to draft, or the expiry passes. To view monitoring data, see [Use the Policy Insights Dashboard](https://help.okta.com/okta_help.htm?type=oie&id=policy-insights-dashboard).
+
+Previously live branches are stored in a branch history. You can restore a branch from history to make it live again. Restored branches are still included in the branch history. Okta makes an identical copy of the branch in the branch history and promotes the copy as the live branch.
+
+To configure staged branches for an app sign-in policy, see [Manage staged app sign-in policy branches](https://help.okta.com/okta_help.htm?type=oie&id=ext-staged-policy-branches).
+
+The Policy Branching API exposes branch operations under `/api/v1/policies/{policyId}/branches`. The `okta.policies.manage` scope is required to perform these operations. See [Policy Branching](https://developer.okta.com/docs/api/openapi/okta-management/management/tags/policybranch).
+
 #### Okta account management policy
 
 <ApiLifecycle access="ie" />

@@ -50,13 +50,19 @@ You can specify any number of global session policies and the order in which the
 
 In addition to the global session policy, you can configure app sign-in policies for each app for extra levels of authentication. You can also [share app sign-in policies across multiple apps](https://help.okta.com/okta_help.htm?type=oie&id=ext-share-auth-policy).
 
-When you add an app, a shared default policy is automatically assigned to it. This policy has a single catch-all rule that allows a user access with two factors. You can add as many rules to the default policy as you need. However, remember that the changes are applied to both new and existing apps that are assigned to the shared default policy.
+When you add an app, a shared default policy is automatically assigned to it. This policy has a single catch-all rule that allows a user access with two factors. You can add as many rules to the default policy as you need. But there can be only one app sign-in policy per app.
+
+Remember that any changes to the default app sign-in policy are applied to both new and existing apps that are assigned to the shared default policy.
+
+You don’t have to use the default app sign-in policy. You can create a policy specifically for an app, or you can [add an app to another existing shared policy](https://help.okta.com/okta_help.htm?type=oie&id=ext-share-auth-policy). If you change an app’s sign-in requirements, you can modify its policy or switch to a different shared policy. You can do this by using the [App sign-in policies page](https://help.okta.com/okta_help.htm?type=oie&id=ext-create-auth-policy).
 
 > **Note:** API service apps aren't automatically assigned a default app sign-in policy. You must explicitly assign an app sign-in policy to each API service app.
 
-You don’t have to use the default app sign-in policy. You can create a policy specifically for an app, or you can [add an app to another existing shared policy](https://help.okta.com/okta_help.htm?type=oie&id=ext-share-auth-policy). If you change an app’s sign-on requirements, you can modify its policy or switch to a different shared policy. You can do this by using the [App sign-in policies page](https://help.okta.com/okta_help.htm?type=oie&id=ext-create-auth-policy).
+#### Policy branching
+
+<ApiLifecycle access="ea" /><ApiLifecycle access="ie" />
 
-> **Note:** There can be only one app sign-in policy per app.
+App sign-in policies support branching. You can create and promote staged branches, which lets you draft, test, and deploy policy changes without affecting end users until you're ready. See [Staged policy branches](/docs/concepts/policies/#staged-policy-branches).
 
 ## Configure sign-on policies for common scenarios
 

@@ -28,11 +28,13 @@ If you need a simple app for testing, see [Sign users in to your SPA using the r
 
 You can use the Policy API to simulate real-world user requests to access an app. In the Admin Console, these simulations are run using the Access Testing Tool available from **Reports** > **Access testing tool**. See [Access Testing Tool](https://help.okta.com/okta_help.htm?type=oie&id=ext-access-test-tool). The API endpoint that underpins this tool is also available for developers to simulate policy configurations and to test app access. For full details on the API endpoint, see the [Policy API reference](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicySimulation).
 
-The policy simulations run access tests based on existing policy configurations and which rules and settings are matched to create the authentication and enrollment requirements. Results of the tests determine individual or group access to an app. You can simulate matches for the following types of policies and rules:
+The policy simulations run access tests based on existing policy configurations and which rules and settings are matched to create the authentication and enrollment requirements. Results of the tests determine individual or group access to an app.
+
+You can simulate matches for the following types of policies and rules:
 
 * App sign-in policies
 * Authenticator enrollment policies
-* Global Session Policies
+* Global session policies
 * User enrollment policies for apps
 
 For background information on policies, see [Policies](/docs/concepts/policies) and [Global session and app sign-in policies](/docs/guides/configure-signon-policy/main/).