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, navigate to Security > General.

Security Notification Emails

Configure notification emails for end users by going to Security > General > Security Notification Emails.

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 enrollment notifications 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, refer to 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 have changed their password from the temporary password.
  • End user notifications for passwords reset using delegated authentication (DelAuth) is not supported.
  • An email notification is not 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 should not 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 application
  • Unrecognized browser or operating system (appears as Unknown in the notification email)

A client is not considered new when end users sign-in to Okta using any browser type and with Okta FastPass.

If your org has Improved New Device Behavior Detection the email notifications won't be sent if the sign-on behavior evaluation determines that a device is known. New Device Behavior Detection requires the following:

If the authentication is not 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 is a change to the user's operating system or browser.
  • New device notifications are not 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 ins, new device notification emails are sent based on the detection of a new mobile application and not the device used to sign in.
  • New device detection are not 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 reCAPCHA v2, select Invisible reCAPTCHA badge.

During your configuration of either service, you will 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 application 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:

  1. Create an API token, required to authenticate requests to Okta APIs. See Create an API token.
  2. In the Admin Console, go to Security > General.
  3. Configure the following settings in the CAPTCHA Integration section:
  • Type – Select the CAPTCHA service 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 to work around this limitation; see Add a global session policy rule.

  1. Click Save.

Troubleshooting

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

Copy
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 Settings

Configure global organization settings by going to Security > General > Organization.

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.
Show option for "Keep me signed in" This setting displays or hides the Keep me signed in checkbox for end users at the sign-in screen. If an end user selects this feature and signs in, their session is remembered and authentication may not be required based on Global Session Policy settings.
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 binding for creating sessions Device binding ensures that redirect requests are used only in the browser where they were generated. You can disable this feature for compatibility with Classic Engine, but Okta recommends against it. If you disable this feature, Okta will bypass the checks that ensure state tokens are redeemed only by the actor who initiated the authentication flow.

User Enumeration Prevention

When this feature is enabled, your org is protected against attackers who attempt to identify user accounts and authenticator enrollments. Every new sign-in attempt from a device will show the password and email if authentication is allowed in the org.

If the user doesn't exist or can't sign in, they will receive an authenticator verification error, but no verification of the existence of the account will be provided.

This feature is disabled by default. See Enable User Enumeration Prevention for instructions on how to enable this feature. See Disable User Enumeration Prevention for instructions on how to disable this feature.

Enable User Enumeration Prevention

  1. In the Admin Console, go to Security > General.
  2. In the User Enumeration Prevention section, click Edit.
  3. Select the Enabled option from the User enumeration prevention drop-down list.
  4. Click Save.

Disable User Enumeration Prevention

  1. In the Admin Console, go to Security > General.
  2. In the User Enumeration Prevention section, click Edit.
  3. Select the Disabled option from the User enumeration prevention drop-down list.
  4. Click Save.

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

  • Self-service registration
  • JIT flows with email authentication

For information on end-user sign-in attempts to Okta, see New user registration, activation, and sign-in experience.

Okta ThreatInsight

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

In order to prevent abuse, Okta ThreatInsight is working in limited capacity for free trial editions. Please contact Okta Support if fully functional Okta ThreatInsight is required.

See Okta ThreatInsight for more details about this feature.

Related topics

Global session policies

HealthInsight

Okta ThreatInsight