General Security

Configure various global org security settings such as user notification emails, user enumeration prevention, and Okta ThreatInsight.

To access these settings in the Admin Console, go to SecurityGeneral.

Security Notification Emails

Configure notification emails for end users by going to SecurityGeneralSecurity Notification Emails. If a notification email doesn't reach its recipient, an event that indicates the cause of the delivery failure (deferred, dropped, or bounced) appears in the System Log.

If your org has multiple brands, these settings apply to the default brand only. To change email recipients for a specific brand, go to CustomizationsBrands. Choose the brand that you want, and then click Emails. Select a template, and then click Edit next to Audience. For more information about email notifications and template customization, see Customize an email template.

New sign-on notification email	End users receive an email notification if they sign in from a new or unrecognized client. This email contains user sign-on details such as the web browser and operating system used to sign in, in addition to the time and location of authentication. See New sign-on notification emails for more information about the limitations for identifying new clients. Note: This feature is disabled by default for new orgs. For more information, see Sign-on notifications for end users.
Authenticator enrolled notification email	End users are sent a confirmation email if they or an admin enroll in a new authenticator for their account. Note: This feature is enabled by default for new orgs. For more information, refer to Authenticator enrolled notification email for end users.
Authenticator reset notification email	End users are sent an email if they or an admin reset an authenticator for their account. Note: This feature is enabled by default for new orgs. For more information, see Authenticator reset notifications for end users .
Password changed notification email	End users receive an email notification if they change or reset the password for their account. This email contains password reset details such as the time and location of the password reset. Note: If an admin sets a temporary password, the end user receives an email notification only after they've changed their password from the temporary password. End-user notifications for passwords reset using delegated authentication (DelAuth) isn't supported. An email notification isn't sent to end users if the user is inactive. For more information, refer to Password changed notification for end users.

New sign-on notification emails

New sign-on notification emails complement other security features such as authenticators and shouldn't act as a replacement. In most scenarios, clients are easily and accurately identified but there are some limitations.

Notification emails for a new device sign-in are triggered when a new client is identified based on an end user's browser cookies or fingerprint.

A client can be considered new in one or more of the following scenarios:

New browser type or version.
New operating system type or version.
New or updated app.
Unrecognized browser or operating system (appears as Unknown in the notification email).

A client isn't considered new when end users sign in to Okta using any browser type and with Okta FastPass.

New Device Behavior Detection requires the following:

Improved New Device Behavior Detection is enabled.
Global Session Policies configured with the primary factor set as Password / IdP / or any factor allowed by authentication policy rules.

If the authentication isn't recognized, end users should contact their admin immediately to investigate their account activity. The admin can perform actions such as terminating a user's sessions, locking the user's account, and adding authenticators to improve security.

Limitations

There are some limitations that present a challenge for identification. Enabling email notifications in addition to other identifiers such as a new IP address or new location provides improved accuracy when identifying suspicious activity on an end user's account.

The current limitations for identifying new clients are as follows:

Device fingerprints are captured after a successful sign-in.
New device notifications may be generated when there's a change to the user's operating system or browser.
New device notifications aren't generated for a sign-in initiated by non-Okta Identity Providers.
The device fingerprint is based on the browser in use. The end user receives a new device notification email if they sign in with a new browser type.
For mobile sign-in flows, new device notification emails are sent based on the detection of a new mobile app and not the device used to sign in.
New device detection isn't always fully guaranteed.
End users may receive an unexpected new or unknown device notification email if they have not signed-in to their accounts within 40 days.

For more information about end-user notifications, see Customize an email template.

CAPTCHA integration

As an option to increase org security, Okta supports CAPTCHA to prevent automated sign-in attempts. You can integrate either of two services: hCaptcha or reCAPTCHA v2.

The vendor implementations supported by Okta are both invisible. They each run risk-analysis software in the background during sign-in to determine the likelihood that the user is a bot. This risk analysis is based on the settings that you configure for the service.

Before you configure your org to use CAPTCHA, sign in to the vendor of your choice or sign up for an account, and then follow the instructions:

For hCaptcha, see https://docs.hcaptcha.com/api/#getting-your-api-key.
For reCAPTCHA v2, see https://developers.google.com/recaptcha/intro#overview.

For reCAPTCHA v2, select Invisible reCAPTCHA badge.

During your configuration of either service, you need to obtain a site key and secret key for your org configuration.

After creating a reCAPTCHA or hCAPTCHA service, be sure to specify your domains on the vendor's service configuration page. For example:

If your web app is based on the customized domains myapp.com and testapp.com, you must specify each domain for your CAPTCHA service.
If your Sign-In Widget is Okta-based, you must add okta.com into the CAPTCHA service domain list.

To configure a CAPTCHA service in Okta:

Create an API token, required to authenticate requests to Okta APIs. See Create an API token.
In the Admin Console, go to SecurityGeneral.
Configure the following settings in the CAPTCHA Integration section:
- Type: Select the CAPTCHA service that you're using.
- Site key: Copy in the site key from your service configuration.
- Secret key: Copy in the secret key from your service configuration.
Enable CAPTCHA for – Select one or more types of authentication for which you want to use CAPTCHA.
- Sign Up: Users are prompted to pass CAPTCHA when first registering and signing in.
- Password Reset: Users are prompted to pass CAPTCHA when resetting their password.
- Sign On: Users are prompted to pass CAPTCHA when signing in.
Currently, CAPTCHA isn't supported for Password Reset in identifier-first authentication flows. That is, when users enter passwords on a second sign-in page.
You can change the authentication flow so that users see the username and the password on the same page in the Sign-In Widget:
- Ensure that your org doesn't use any Identity Providers for authentication. You may use the Okta option for AND Identity provider is in your Global Session Policy rules, but not the Specific IdP option.
- All of your Global Session Policy rules have the Establish the user session with option set to A password.
See Add a global session policy rule and Sign-in flows for instructions.
Click Save.

Troubleshoot the CAPTCHA connection

If you entered an incorrect service site key in the Okta configuration, users lose access to the Okta org. To reconfigure, first submit the following instructions to the CAPTCHA management public API.

Copy

1
2
3
4
5
6
curl -v -X PUT \ -H "Accept: application/json" \
                -H "Content-Type: application/json" \
                -H "Authorization: SSWS ${api_token}" \
                -d '{"captchaId": null,
                "enabledPages": null}'
            "https://${yourOktaDomain}/api/v1/org/captcha"

Organization Security

Configure global organization settings by going to SecurityGeneralOrganization Security.

IP binding for Admin Console	This setting associates admins with the IP address that they signed in from. If the IP changes during a session, the admin is signed out of Okta, and an event appears in the System Log.
Remember user on sign in	This setting pre-populates the Username field on the Sign-In Widget. The end user is still required to authenticate. It doesn't remember recent MFA authenticators or previous sessions.
Stay signed in	This setting lets users establish an Okta session that continues after they close and reopen their browser. Users who choose to stay signed in aren't prompted again for MFA for the amount of time defined in your global session policy. See Keep me signed in.
Show option to stay signed in before users sign in	Early Access release. This setting displays the Keep me signed in option to users on the Sign-In Widget before they enter their credentials. Post-authentication prompts are now configured in authentication policies. See Keep me signed in.
Activation emails are valid for	Sets the link expiry in the account activation email sent to end users. For more information about email notifications, see Customize an email template.
Enforce device matching for creating sessions	By default, Okta ensures that authentication redirects stay within the browser in which they were initiated. Okta compares the device identifiers provided in the requests. If they don't match, Okta denies access to the app and doesn't create an Identity Provider session. Keep this setting enabled unless Okta Support instructs you to disable it.
Username match criteria on sign in	This setting determines how a user profile is matched when they sign in. If you select Match entire username, users can't sign in unless they enter their full username including the domain. If you select Allow short match, users can sign in without their domain.
Users can view Recent Activity	This setting enables the Recent Activity page for users. This page displays a user's recent sign-in activity and security events for their accounts.

Protect against password-based attacks

Require possession factor before password during MFA

When this feature is enabled, users are required to verify their identity with a possession factor before verifying with a password or other knowledge factor. This helps protect your org against password guessing or spray attacks.

When this feature is enabled, a user's preference for remembering their password as the last-used factor is overridden.

In the Admin Console, go to SecurityGeneral.
In the Protect against password based attacks section, click Edit.
Select Enabled from the Require possession factor before password during MFA dropdown menu to enable this feature, or Disabled to disable it.
Click Save.

Requiring a possession factor before a password doesn't take effect in the following scenarios:

When MFA isn't required
When user enumeration prevention is triggered, the user is prompted for the email or password first.
When Classic Engine authentication endpoints are used

Block suspicious password attempts from unknown devices

When this feature is enabled, your org blocks suspicious password attempts from unknown devices. Users who sign in to Okta with devices they've used before aren't locked out if another device that is unknown to Okta causes a lockout.

In the Admin Console, go to SecurityGeneral.
In the Protect against password-based attacks section, click Edit.
Select Enabled from the Block suspicious password attempts from unknown devices dropdown menu to enable this feature, or Disabled to disable it.
Click Save.

See Add a password policy for more information.

You can allow individual users to sign in using an unknown device. When a user has lost their device, this helps them sign in with a new, unknown device for the first time. See Allow unknown devices to sign in.

User enumeration prevention

When this feature is enabled, your org is protected against attackers who attempt to identify user accounts and authenticator enrollments. If the user doesn't exist or can't sign in, they receive an authenticator verification error. Okta doesn't verify that the account exists.

This feature is disabled by default. For information on end user sign-in attempts to Okta, see New sign-in experience.

In the Admin Console, go to SecurityGeneral.
In the User Enumeration Prevention section, click Edit.
Preview Only: Select one or both of these options to enable user enumeration prevention:
- Authentication: Enable or disable user enumeration prevention for user authentication attempts.
- Recovery: Enable or disable user enumeration prevention for recovery scenarios.
To disable user enumeration prevention, clear the checkboxes for Authentication and Recovery.
Click Save.

User Enumeration Prevention doesn't take effect if either of the following conditions are allowed:

Self-Service Registration
JIT flows with email authentication

See User management for more information.

Okta ThreatInsight settings

Okta ThreatInsight aggregates data across the Okta customer base and uses this data to detect malicious IP addresses that attempt credential-based attacks.

To prevent abuse, Okta ThreatInsight is working in limited capacity for free trial editions. Contact OktaSupport if fully functional Okta ThreatInsight is required.

See Okta ThreatInsight for more details about this feature.