Configure session protection
Early Access release. See Enable self-service features.
Configure session protection to define which context changes result in a re-evaluation of your global session and app sign-in policies.
Think about the routine actions that your users perform after they authenticate: switching VPN, testing with different devices, or changing Wi-Fi networks when traveling. In what contexts are they considered risky? If they violate your policies, what level of remediation is the most effective? Session protection is integral to ITP because they control the number of violations you see and the level of sign-in friction your users experience.
Before you begin
-
You must be a super admin or org admin to configure session protection. See Admin roles for ITP.
-
Configure a network zone.
-
Create Workflows for ITP if you want to take a custom remediation action. Only delegated Workflows are supported. See Create delegated flows for policy actions.
Set the status
-
In the Admin Console, go to .
-
Click the Detection and Response tab.
-
Go to Session Protection.
-
In the Status section, select one of the following:
-
Monitoring: Policies are re-evaluated and session violations are recorded in the System Log. No remediation actions are enforced.
-
Enforced: Policies are reevaluated, session violations are recorded in the System Log, and remediation actions are enforced.
-
Configure the session violation detection
These settings determine when to trigger re-evaluations.
-
In the Session violation detection section, click Edit.
-
Choose your Risk level.
-
High: Only high-risk sessions prompt a policy re-evaluation. This creates the least amount of friction for users but provides less security. If you don't need to re-evaluate your policies for every IP or device change, this level can help you filter them out.
-
Medium and above: Sessions that are determined to be medium risk and higher prompt a policy re-evaluation. This level provides the most balance between security and user friction.
-
Low and above: Default. All sessions prompt a policy re-evaluation. This is the most secure risk level because no change is filtered out, but it increases admin intervention and friction for users.
-
-
In the User's new IP is menu, choose which network zones initiate policy evaluations.
-
Any IP: Re-evaluate policies for all IPs. This is the most secure setting.
-
In any of the following zones: Re‑evaluate policies only if the new IP is in admin‑chosen zones (for example, EDZ/anonymizers/geo‑risk zones). This setting is useful for orgs that can confidently identify all risky zones.
-
NOT in any of the following zones: Re‑evaluate policies for every IP except the ones in admin‑chosen zones (for example, to exclude exempt HQ/VPN). DefaultExemptIPZone and the trusted proxies configured network zones are included here by default.
-
Configure enforcement settings
These settings control what happens when a session violation is recorded.
-
In the Enforcement settings section, review the Actions inherited from your global session and app sign-in policies. These actions are enforced whenever the policy is set to Enforced, and are applied to the users you specified in those policies.
-
MFA if possible: Users who are on Okta pages are prompted to re-authenticate if the global session policy or the app sign-in policy of the app they're trying to access requires MFA. If they provide the appropriate MFA, no session violation is recorded.
-
Okta logout: Users are logged out of their Okta session if your global session policy results in a DENY action, or if they don't provide the appropriate MFA. App sessions may not be affected.
-
-
To add another remediation step, select Run an additional action, and then choose one of the following.
-
App logout: If the detection violates an app sign-in policy, and the app supports Universal Logout, users are logged out of the app. Users may be logged out of associated apps at the same time if there's a concurrent violation in the global session policy.
-
Run a workflow: Okta performs a custom remediation based on your delegated workflow.
-
-
In the Groups impacted section, select the groups that your additional action (App logout or Run a workflow) applies to. Remember that users who aren't in these groups may still be affected by the MFA if possible and Okta logout actions in your global session and app sign-in policies.
-
Click Save.
