The number of users who are not enrolled in any additional factors for MFA. If MFA enforcement policy rules are not configured for the identify provider, these users can access SaaS apps through the identity provider by using only one factor. If those credentials are compromised, there is no additional layer of security to prevent unauthorized access to their account. These users should enroll in a strong second factor for MFA.

The number of users who are enrolled in one or more additional factors for MFA, but whose factors are not resistant to phishing, social engineering, or interception attacks. The weak MFA factors include factors such as email verification and short message service (SMS) verification. Weak second factors offer less protection than stronger factors, such as biometric login or a hardware key.

If MFA enforcement policy rules on the identity provider are not configured to prevent sign-ins using only weak factors, then the account can be more easily compromised. These users should enroll in a strong second factor for MFA.

The number of users who signed into SaaS apps by using only weak factors, which are not resistant to phishing, social engineering, or interception attacks.

Although the users might have registered a strong second factor, such as biometric login or a hardware key, they used only a weak factors, such as email verification and short message service (SMS) verification, to sign in.

Administrators should create or modify policy rules in the identity provider to require these users to sign in using a strong second factor for MFA.

The number of sign-ins with no MFA or weak MFA, organized by SaaS app.

The number of human accounts that have not been accessed for the specified period. These might be accounts that weren’t deleted after the account owner left the organization, and were forgotten. Or a user might have set up a new account without deleting, or continuing to access, the older one. Dormant accounts represent a signification security risk because bad actors can use them to gain access. Accounts that have remained dormant for a significant period can represent the greatest risk, because they might predate enforced requirements for MFA and for password length and complexity.

You can display the number of accounts that have been dormant over 30, 60, or 180 days, and can click the number of dormant accounts to filter the table of Human Accounts in the lower section of the page. The table provides more information about each dormant account. It shows when the account was created, when the account was last accessed, and when the account password was last updated.

The number of non-human accounts that have not had their credentials rotated for the period specified.

Non-human account credentials include service account passwords, as well as credentials for accessing APIs, such as API keys and OAuth tokens. Failure to rotate these non-human account credentials can represent a significant risk to your organization.

Service account passwords that are not rotated are more vulnerable to brute-force attacks, especially if the password predates enforced requirements for password length, complexity, and reuse.

API keys that are not rotated increase the window of opportunity for bad actors to exploit leaked or compromised keys. Similarly, if the client secret of an OAuth app isn’t rotated, a compromised refresh token will enable to a bad actor to continue to obtain valid access tokens.

You can display the number of non-human accounts with credentials that have not been rotated in 30, 60, or 180 days. You can click the number of accounts to filter the table of Non-Human Accounts in the lower section of the page. The table provides more information about each account, such as when the account was created, and when the account credentials were last updated.

The number of human accounts that are local accounts, which are accounts that weren’t created through your identity provider. Local accounts are a security risk because the identity provider isn’t managing access for them. Because they have bypassed the identity provider, it's difficult to enforce security policy rules for them.

The Identity Security component identifies these risky local accounts by comparing account information from the app instance with account information from the identity provider. For this reason, the dashboard will display the local account information only if the Identity Security component is integrated with an instance of either the Microsoft Azure or the Okta identity provider. If the dashboard isn’t displaying this information, you can Add Provider and follow the steps to onboard Okta or Microsoft 365.

The identity provider that the Identity Security component uses for this comparison is the identity provider that is currently selected in the Identity Providers list. If more than one identity provider instance is connected to SSPM, you can select a different identity provider from the list.

You can click the number of accounts that are missing in the identity provider to filter the table of Human Accounts in the lower section of the page. From the table you can gain additional insights about the local accounts, such as the email address that is associated with the account.

This information applies to Salesforce instances only. The number of human accounts that have excessive permissions, which are probably not required for the user to do their job. Overpriviledged accounts are ordinary user accounts that have administrator permissions. For Salesforce, the overprivileged accounts are accounts that have Modify All Data permissions.

You can click the number of overprivileged accounts that are missing in the identity provider to filter the table of Human Accounts in the lower section of the page. From the table, you can gain additional insights about the local accounts, such as the email address that is associated with the account.

This information applies to Office 365 instances only. Guest accounts in Office 365 enable you to collaborate with people who are outside of your organization. Although guest accounts are designed to give outside users access to your resources for legitimate purposes, they can represent a risk if their access isn’t properly restricted. For example, an external collaboration setting in Azure Active Directory might grant guest users the same access as members. Another Azure Active Directory setting might allow anyone in the organization to invite guest users, including guests and non-administrators.