Capability

Threat protection

What it does: Watches live sessions for risk signals and ends the ones that go wrong.

WIC

In short

Threat protection keeps checking a session after the user has signed in. When risk signals change, it can trigger a response such as ending the session, so a stolen session does not have to stay valid until it expires.15

Book a callHow Okta does it ↓
5
attack types it helps against

What it is, and the attacks it stops

A sign-in check happens once. After that, a session can run for hours, and the account, the device or the network around it can change in that time.

Threat protection continues to evaluate risk while the session is active. Okta describes Identity Threat Protection as assessing risk signals continuously and responding to changes, for example through Universal Logout.15

That ongoing check helps against situations such as:

1

Session cookie theft

Malware copies the session token after a legitimate sign-in, and the attacker reuses it from another machine.

2

Adversary-in-the-middle phishing

A proxy captures the session after MFA is complete, so the attacker uses the session without signing in again.

3

A device that is compromised during the session

Malware lands on a device after the user signed in, and the session is still trusted.

4

A sudden change of network or location

The same session suddenly appears from a different network or country.

5

Slow response to an incident

Security finds a problem, but access in other apps stays open until each session expires.

Before and after rollout

Without
With
WithoutA session stays trusted until it expires.
WithRisk is evaluated while the session is active, not only at sign-in.1
WithoutA suspicious session is found through a manual review, if at all.
WithRisk signals can trigger a response automatically, such as ending the session.15
WithoutClosing access means visiting each app one by one.
WithUniversal Logout lets Okta send a logout request to connected apps that support it.5
WithoutSecurity tools and the identity provider work separately.
WithWhere integrated, signals from other security tools can feed the same decision.1

How Okta does it

Identity Threat Protection works on the session, after the sign-in policy has done its job.12

1

The user signs in

The user passes the sign-in policy of an app protected by Okta.2

2

Okta keeps evaluating the session

Identity Threat Protection continues to assess risk signals while the session is active.1

3

The risk level changes

A signal, such as a change in the user's context or an alert from an integrated security tool, raises the risk level.1

4

A response runs

Based on the configured policy, Okta can respond - for example by ending the session with Universal Logout in apps that support it.15

WIC
Who it protectsStaff, contractors, admins
Identity Threat ProtectionEvaluates risk during a session and can run configurable responses when the risk changes.1
Universal LogoutLets Okta request a logout in connected apps that support it.5
Behavior detectionOkta can compare a sign-in with the user's usual behavior, for example location or device, and use the result in a policy.3
Okta ThreatInsightOkta ThreatInsight can help identify requests from suspicious IP addresses.4

How Zelto implements it

Okta supplies the signals and the response mechanism - Zelto decides with you which signals matter in your environment and what should happen for each. We start with responses that are easy to reverse and add stricter ones as your team gains confidence, to minimize risk/impact for users.

Typical rollout

  1. Map sessions, apps and signals

    We list your apps, how long sessions last, and which security tools could send signals.

  2. Check which apps support a logout request

    We confirm with your admins which apps can act on a logout request, because that decides what a response can reach.

  3. Choose a response for each risk level

    With your security team we agree what happens at each level, from a notification to ending the session, and who is told.

  4. Pilot with admins and IT

    We start with admins and IT, review every response that triggers, and tune it before it reaches other groups.

  5. Extend group by group and review

    We extend to more groups step by step, and we review triggered responses and exceptions on a schedule.

Pitfalls we plan for

A risk signal fires for a user who is traveling.

−End every session at once, so users lose work and learn to ignore the alert.

+Start with a notification or an extra check for medium risk, and end the session only for high risk.

An app does not support a logout request.

−Assume the session ends everywhere when Okta ends it.

+Check app by app which ones support it, and cover the rest with shorter sessions or a manual step in the incident plan.

Alerts arrive but nobody owns them.

−Turn on detection and leave the alerts in a shared inbox.

+Name an owner on your side for each response, and agree how fast the alert must be handled.

A security tool is connected as a new signal source.

−Connect it to production at once and let its signals end sessions.

+Test the signal with a pilot group first and compare it with what your team actually sees.

Want to end risky sessions instead of waiting for them to expire?

We review how long your sessions run and what could trigger a response. Then we tell you where to start.

Book a call30 minutes, no slides. We look at your sessions and security signals today.

Related blog posts

Notes from rollouts

Z Is For Zero Trust: Revalidate Access ContinuouslyRead on the blog →

Sources

Official Okta and Auth0 documentation and primary legal sources.

  1. 1Okta Identity Threat Protectionokta.com product page
  2. 2About app sign-in policiesOkta Help Center
  3. 3About behavior detectionOkta Help Center
  4. 4About Okta ThreatInsightOkta Help Center
  5. 5Universal LogoutOkta Help Center