Detects accounts that have not been accessed for a specified period. Because the account owner isn’t logging in, they will be less likely to notice if the account is compromised. They will also not have received password expiration notifications or prompts to change their password. As a result, the account might have an old password that predates newer requirements for password length and complexity.

By default, the threshold SSPM uses for detecting dormant accounts is 30 days. In the upper section of the Identity page, you can click on the current threshold value to reset it.

Detects accounts whose credentials will expire within a set number of days. By default, the threshold SSPM uses for detecting expiring credentials is 30 days. In the upper section of the Identity page, you can click on the current threshold value to reset it.

Detects accounts that have not had their credentials rotated within a set number of days. Account credentials include user ID and password combinations, as well as credentials for accessing APIs, such as API keys and OAuth tokens. Failure to rotate these account credentials can represent a significant risk to your organization.

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 a bad actor to continue to obtain valid access tokens.

By default, the threshold SSPM uses for detecting non-rotated credentials is 30 days. In the upper section of the Identity page, you can click on the current threshold value to reset it.

A guest account is an account designed to provide external users, such as a partner or contractor, limited or temporary access to the SaaS application. Guest accounts 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.

Local accounts 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 component identifies these risky local accounts by comparing account information from the SaaS app instance with account information from the identity provider. For this reason, the Identity component displays local account information only if you have onboarded an instance of either the Microsoft Azure or the Okta identity provider. If the Identity component isn’t displaying this local account information, you can Add Provider and follow the steps to onboard Okta or Microsoft 365.

In the upper section of the Identity page, the Identity Provider field shows the identity provider that the Identity component uses to detect local accounts. If more than one identity provider was onboarded, you can select a different one from this list. Selecting a different identity provider does not immediately refresh the information displayed on the Identity pages. The displayed information will be refreshed after the next identity scan completes.

Multi-factor authentication (MFA) misconfigurations are users with no MFA or with weak MFA.

If MFA enforcement policies are not configured for the identify provider, a user 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.

Weak MFA refers to 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.

Overprivileged accounts are accounts that have elevated, administrator-level access to the SaaS app. For some administrators, this level of access might be legitimate. However, for other accounts, the elevated privileges are not needed for the human or non-human entity to complete their tasks. To follow the principle of least privilege, you should investigate accounts with elevated permissions to verify that they have only the permissions necessary to complete their work.