HealthInsight audits an organization’s security settings and suggests recommended tasks to improve security posture. These security recommendations are intended primarily for admins that manage employees within their organization.

See Security tasks and recommendations below for more details.


Partial list of HealthInsight security tasks


With HealthInsight, certain admins can:

  • View a list of complete, incomplete, or dismissed tasks applicable to your orgThe Okta container that represents a real-world organization..
  • Review detailed recommendations from Okta based on your org’s existing security settings.
  • Navigate to various settings to update your existing configuration.
  • Dismiss tasks so they do not appear Incomplete.

Tasks are marked as complete automatically by HealthInsight when addressed in its respective section in the adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. console.


Access this feature

  • From the HealthInsight prompt on the admin console dashboard.
  • From the Shortcuts list on the admin console dashboard, click HealthInsight.
  • From the admin console menu, click Security and navigate to HealthInsight.


Before you begin

Note the following about admin roles and permissions:

Admin Permission Super Admin Org Admin Read-Only Admin
View HealthInsight status
Dismiss security tasks and recommendations  


Security tasks and recommendations


Security Task Why is this recommended? Security Impact End- User Impact
Enable MFA for Okta Administration access To reduce the risk of admin account compromise if credentials are obtained maliciously by a third party. Critical None
Limit the number of super admin roles To ensure that org admins are not assigned more permissions than necessary. Most orgs require only a few super admins. Critical None
Enable ThreatInsight to block suspicious IP addresses To detect suspicious IP addresses from credential-based attacks. Critical Low
Enable strong MFA factors in factor enrollment policies To improve resistance to phishing and man-in-the-middle attacks. High High
Enforce a limited session lifetime for all policies To reduce the risk of malicious third party access to an end user's applications (when an end-user session is active). High Moderate
Enable Suspicious Activity Reporting To give end usersEnd users are people in your org without administrative control. They can authenticate into apps from the icons on their My Applications home page, but they are provisioned, deprovisioned, assigned, and managed by admins. the option to report unrecognized activity from an account activity email. High Low
Enable new sign-on email notifications To inform end users by email of any unrecognized activity from a new or unknown device or browser. High Low
Enable factor enrollment notifications To inform end users by email of new MFA enrollment activity on their account. High Low
Enable factor reset notifications To inform end users by email that MFA factors for their account have been reset. High Low
Use SAML or OIDC authentication for app access To leverage SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. and OIDCOpenID Connect (OIDC) is an authentication layer on top of OAuth 2.0, an authorization framework. The standard is controlled by the OpenID Foundation. authentication protocols, which reduce reliance on password-based authentication. High None
Blacklist network zones to deny access to your Okta tenant To deny access from known suspicious IP addresses or locations from your Okta tenant. Moderate Low
Enable strong password policy settings To enforce strict password policies that define settings for password lockout, history, minimum age, and minimum length. Low Moderate
Set a required factor for MFA enrollment policies To ensure that end users assigned to a given policy are enrolled in multifactor authentication. Low High




HealthInsight and any recommendations about your security practices is not legal, security, or business advice. The HealthInsight features is intended for general informational purposes only and may not reflect the most current market and legal developments nor all relevant business or legal issues. You are responsible for obtaining legal, security, or business advice from your own lawyer or other professional advisor and should not rely on HealthInsight. Okta is not liable to you for any loss or damages that may result from your implementation of the recommendations in HealthInsight except as otherwise explicitly agreed to in the signed Master Subscription Agreement (or other such agreement addressing the same subject matter), between you and Okta.


Related topics