CID Checks
On the Verify Privileged Identity Platform, Continuous Identity Discovery (CID) leverages a subset of checks designed to discover and secure privileged cloud identities that pose potential security risks. These include checks that are specific to vaulting in Secret Server as well as checks that are not specific to vaulting.
CID Checks results will be returned only if you use the built-in password changer for the application, because the checks require a strong identifier that includes both username and application.
See also the complete list of available ITP/PCCE Checks
General Checks (not Vaulting-specific)
This section describes CID checks that are not specific to vaulting.
Admins without MFA
Detects admin user accounts without multi-factor authentication enabled.
The Platform searches for any user account with the MFA property set to false. To ensure that the user has a chance to set up MFA before being detected, the Platform ignores any account that was never activated (staged) and any account that never performed an initial login (has a login date that is empty or set to 1970).
App registrations with almost expired stale credentials
Detects Microsoft Entra ID app registrations with credentials expiring within 30 days. Credentials that have already expired, or that have no expiry date, are not flagged. Expiring credentials that are not rotated in time can disrupt services, and static credentials remain vulnerable to theft even before they expire.
Rotate the app registration's credentials before they expire.
Supported only for Entra
App registrations with stale credentials
Identifies App registrations with non-rotated credentials, ensuring adherence to organizational key rotation policies. Use the policy definition step to specify the number of days before a key must be rotated, as per your organizational policy.
Supported only for Entra
Excessive number of non-human administrators
Detects non-human accounts (service accounts, workloads, and similar identities) that hold administrative privileges. The check fails when the number of non-human administrators reaches the configured threshold (default: 5); every non-human administrator is listed regardless of the threshold. Non-human admin accounts can indicate attacker persistence or lateral movement; validate the source and business justification for each one.
The threshold is configurable per application.
Limit number of administrators
Limit the number of administrative accounts to ease audit efforts and reduce the potential impact of credential compromise.
You can set a threshold to define the expected number of admins for them, so the check won't fail.
Limit number of administrators [federated access]
Detects federated admin accounts, as a new federated administrative account might be an indication of persistence or later movement achieved by an attacker. Validate that the user should be an admin; otherwise remove admin privileges.
Supported for apps that are not IdPs.
You can set a threshold to define the expected number of admins for them, so the check won't fail.
Limit number of Domain Admins
Domain Admins group should contain only the minimum number of necessary users. Excessive membership increases risk and management complexity.
You can set a threshold to define the expected number of admins for them, so the check won't fail.
Limit number of external administrators
Detects admin accounts, as a new administrative account might be an indication of persistence or later movement achieved by an attacker. Validate that the user should be an admin; otherwise remove admin privileges.
Limit number of global admins
Application-level admin roles grant users the highest scope of permission in the application, and increase the blast radius in the organization. We recommend keeping their number as small as possible.
You can set a threshold to define the expected number of admins for them, so the check won't fail.
Limit number of organization admins
Application-level admin roles grant users the highest scope of permission in the application, and increase the blast radius in the organization. We recommend keeping their number as small as possible.
You can set a threshold to define the expected number of admins for them, so the check won't fail.
Limit number of super admins
Application-level admin roles grant users the highest scope of permission in the application, and increase the blast radius in the organization. We recommend keeping their number as small as possible. Super admin is the most privileged type of role in Okta.
You can set a threshold to define the expected number of admins for them, so the check won't fail.
Remove shadow admins
Detects accounts with shadow admin entitlements. A shadow admin is a user that does not have full administrative privileges but has sensitive privileges that grant them control over other users or sensitive administrative tasks. The policy logic tracks both local and federated accounts. The full list of shadow admin permissions that are evaluated and their combinations can be found here.
Supported for Active Directory, AWS, Azure, GCP.
Shadow admin non-human identities
Detects non-human identities — service accounts, workloads, secrets, and keys — that hold sensitive administrative privileges without full administrative rights. Shadow admin non-human identities are especially risky because they often carry long-lived credentials and operate with less oversight than human accounts. The full list of shadow admin permissions that are evaluated can be found here.
Supported for AWS, Microsoft Azure, Google Cloud Platform, and Active Directory (on-premises).
Vaulting-Specific Checks
This section describes CID checks that are specific to vaulting.
Checks in this section that require Secret Server are still created on tenants without the Secret Server entitlement. Until Secret Server is enabled, they are evaluated against zero alerts and display as Passed with 0 affected entities.
Unvaulted app registrations
Detects app registration with unvaulted in Secret Server. All log-in credentials and similarly sensitive information should be managed as vaulted secrets in Secret Server.
Supported only for Entra
Unvaulted human admin access keys
Detects human admins which their access keys are not in Secret Server. Creating secrets for users that are currently not managed by the Secret Server can help increase organization security.
Supported for AWS only
Unvaulted human admin credentials
Detects human admins which their credentials are not in Secret Server. Creating secrets for users that are currently not managed by the Secret Server can help increase organization security.
Unvaulted human shadow admin access keys
Detects human shadow admins which their access keys are not in Secret Server. Creating secrets for users that are currently not managed by the Secret Server can help increase organization security.
Supported for AWS only
Unvaulted human shadow admin credentials
Detects human shadow admins which their credentials are not in Secret Server. Creating secrets for users that are currently not managed by the Secret Server can help increase organization security.
Supported for Active Directory, AWS, Azure, GCP.
Unvaulted local admin on Windows computers
Detects enabled, human, local Windows user accounts that hold local administrator rights and are not vaulted in Secret Server as a Windows secret matching the computer. Domain accounts with local administrator rights and non-human accounts are not flagged. Unvaulted local administrator accounts increase the risk of credential theft and lateral movement.
Vault the affected accounts' credentials, enable regular rotation, and enable session recording.
Supported only for Active Directory
Unvaulted PAM bypassing using access keys
Detects privileged accounts that bypass Secret Server by using access keys that are not stored as vaulted secrets, based on observed account activity.
Create new access keys and store them as vaulted secrets in Secret Server, and require privileged users to access cloud applications only through Secret Server.
Supported for AWS only.
Based on activities we collect.
This check includes all privileged accounts (admins, shadow admins, privileged accounts).
Unvaulted PAM bypassing using credentials
Identify privileged accounts (e.g., admins, shadow admins) that bypass Secret Server by using unvaulted credentials for logging in. This check analyzes account activities to detect whether a user accessed a cloud application without using vaulted credentials, and triggers alerts if the account has vaulted access but chooses non-vaulted access instead.
Ensure that privileged users can only access cloud applications through Secret Server using vaulted login credentials.
Based on activities we collect.
This check includes all privileged accounts (admins, shadow admins, privileged accounts).
Unvaulted privileged human account access keys
Detects privileged human accounts which their access keys are not in Secret Server. Creating secrets for users that are currently not managed by the Secret Server can help increase organization security.
Supported for AWS only.
You can configure privileged account definitions on the Collections page.
Unvaulted privileged human account credentials
Detects privileged human accounts which their credentials are not in Secret Server. Creating secrets for users that are currently not managed by the Secret Server can help increase organization security.
You can configure privileged account definitions on the Collections page.
Unvaulted service account access keys
Detects privileged, admin and shadow admin service accounts whose access keys are not stored in Secret Server. Creating secrets for NHIs that are currently not managed by the Secret Server can help increase organization security.
Supported for AWS and GCP
Unvaulted service account credentials
Detects privileged, admin and shadow admin service accounts whose credentials are not stored in Secret Server. Creating secrets for NHIs that are currently not managed by the Secret Server can help increase organization security.
Supported for AWS only
Vaulted PAM bypassing using access keys
Detects vaulted privileged accounts whose vaulted access key is used without a corresponding Secret Server view or checkout in the preceding 15 minutes, indicating that the key is being used from a copy held outside the vault.
Disable the account's access keys or terminate the session, then rotate the secret.
Supported for AWS only.
Based on activities we collect.
This check includes all privileged accounts (admins, shadow admins, privileged accounts).
Vaulted PAM bypassing using credentials
Identify vaulted privileged accounts (e.g., admins, shadow admins) that bypass Secret Server by storing credentials locally. This check analyzes account activities to detect whether a user accessed a cloud application, not through Secret Server despite having vaulted access. Ensure privileged users follow security best practices.
Access cloud applications through Secret Server using vaulted login credentials. Do not store credentials locally.
Based on activities we collect.
This check includes all privileged accounts (admins, shadow admins, privileged accounts).
See also: