NHI Identify Classification Logic

Detect and manage both human and non-human identities across multiple integrations.

Veza automatically applies classification logic to the identities it discovers and assigns an Identity Type, indicating if the entity represents a human user or an NHI entity.

Dashboards and out-of-the-box queries are available to help monitor and manage both human and non-human entities across cloud and enterprise systems. These queries can power a range of Veza features such as Access Reviews, Rules, and Veza Actions.

This document includes a list of supported identity types and an overview of built-in and user-defined rules for NHI classification.

Non-Human Identities

These entities are assigned the “non-human” identity type:

• Active Directory: Computer

• Active Directory: Managed Service Account

• AWS EMR: Cluster

• AWS: Service Principal

• AWS IAM: Identity Provider

• AWS EC2: Instance

• AWS Lambda: Function

• AWS EKS: Cluster

• Azure AD: Enterprise Application

• Azure: Virtual Machine

• Azure AKS: Managed Cluster

• Databricks: Service Principal

• Databricks: Account Service Principal

• Dynamics 365: Application User

• Google Cloud: Service Account

• Google Cloud Compute: Virtual Machine

• Google Cloud Run: Service Instance

• Google Kubernetes Engine: Cluster

• GitHub: Deploy Key

• GitHub: App

• Kubernetes: Service Account

Human Identities

These entities have the “human” identity type by default:

• AWS SSO: User

• Azure AD: User

• Azure: Classic Administrator

• Bitbucket: User

• Box: User

• Custom HRIS (Open Authorization API): Employee

• Databricks: User

• Databricks: Account User

• Google Workspace: User

• GitHub: Personal Account

• Kubernetes: User

• MongoDB Atlas: User

• OneLogin: User

• Oracle Cloud IAM: User

• Oracle DB: User

• PingOne: User

• SAP ECC: User

• SharePoint: User

• SQL Server: Login

• Veza: User

• Workday: Worker

Entities That Can Be Human or Non-Human

The following entities can be marked “human” or “non-human” depending on Veza rules for identifying NHIs:

• Active Directory: User (Built-in Rule)

• AWS Redshift: User

• AWS RDS Postgres: User

• AWS RDS MySQL: User

• AWS RDS MySQL: User Instance

• AWS: IAM User (Built-in Rule)

• Open Authorization API: Custom User

• Open Authorization API: Custom IDP User

• Open Authorization API: Custom Principal User

• Microsoft Dynamics 365: User (Built-in Rule)

• AWS ElasticSearch: User

• Google Cloud SQL: User (Built-in Rule)

• Hashicorp Vault: Alias (Built-in Rule)

• Hashicorp Vault: Entity (Built-in Rule)

• Mongo DB User

• Mongo DB Atlas Database User

• Okta User (Built-in Rule)

• PostgreSQL User

• Salesforce User

• ServiceNow User (Built-in Rule)

• Snowflake User (Built-in Rule)

• SQL Server Database User

• Trino User

• Workday Account (Built-in Rule)

Veza has internal rules to assign some of these identity types as non-human. See the following section for rule details.

For some integrations, there is no consistent method to automatically detect non-human identities. In Veza, these are shown as “human” by default. This behavior can be changed to label certain identities based on tags, naming patterns, groups, or other conventions employed by your organization.

Determining Human vs. Non-Human Identities

Veza uses the following rules to distinguish between human and non-human accounts in supported integrations:

Integration Type	Non-Human Identity (NHI) Rule
AWS IAM User	Considered non-human if ConsoleAccess is nil/false and MfaActive is false.
Active Directory User	Non-human if User Principal Name (UPN) is absent.
Dynamics 365 User	Non-human if the user is marked as non-interactive.
Google Cloud SQL User	Identified as non-human if UserType is UserTypeCloudIAMServiceAccount, UserTypeCloudIAMGroup, or UserTypeCloudIAMGroupServiceAccount.
HashiCorp Vault Alias	Identified as non-human if the Alias’s UserType is “service account.”
HashiCorp Vault Entity	Identified as non-human if the Entity’s UserType is “service account.”
ServiceNow User	Non-human if flagged as an internal integration user or if the email is missing.
Okta User	Non-human if all conditions are met: UserType, Manager, and DisplayName are empty; MFA is false; LastLogin is nil.
Snowflake User	Non-human if any of the following conditions are met: User is configured to use RSA public key authentication without a password. User is a SNOWFLAKE user (a special user that is only used by Snowflake Support). User is a WORKSHEETS_APP_USER user (the first time Snowsight is accessed in an account, Snowflake creates this internal account to support the web interface). User's Type is one of the following Snowflake non-human account types: SERVICE, LEGACY_SERVICE, or SNOWFLAKE_SERVICE.
Workday Account	Non-human if UI sessions are not allowed; otherwise, assumed human.

Non-Human Identity (NHI) Enrichment Rules

Veza provides Non-Human Identity (NHI) Enrichment Rules to automate NHI labeling based on specific conditions. For example, you might assign users as non-human when their email contains “service-account-%”, “svc-%”, or is missing.

Administrators can add rules on the Integrations > Enrichment page:

1. Save a Query: In Query Builder, save a query that identifies the entities to mark as non-human. For example, you could query for SAP ECC Users where the Email or Name contains the text “system-”.

2. Enable Enrichment Rules: Configure the saved query as an enrichment rule. When extracting metadata, Veza will update the Identity Type attribute for any entities that match the query conditions.

Enrichment Rules will take precedence over any default identity type for specific users. To learn more, see the Enrichment Rules documentation.