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: Managed Identity

• 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:

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.

In Veza, an NHI secret is a piece of private data that grants access to resources, systems, and services. Non-human identities (like applications, functions, and other workloads) use secrets to authenticate and establish their permissions. Secrets typically have a fixed lifespan and are used at scale for programmatic access, with examples including:

• Database connection strings and passwords

• API keys for service-to-service communication

• Service account credentials providing access to cloud resources

• Cloud provider access keys that authorize infrastructure changes

• SSH and TLS private keys for system access

• Infrastructure automation tokens

• Webhook signing secrets

Veza discovers and provides metadata about secrets across your cloud and application environments, enabling comprehensive visibility into security and compliance posture, including which non-human identities can access secrets, and how they are protected.

Supported Secrets

Secrets are represented in the Veza Graph as distinct entity types. When creating queries, you can select individual entity types or use top-level groupings to search for all entities of that category. For example, searching for Keys will include both AWS KMS Customer Master Keys and Azure Key Vault Keys in the results.

Secrets

Application-level secrets including credentials and sensitive configuration:

• AWS Secrets Manager Secrets

• Azure Key Vault Secrets

• HashiCorp Vault Secrets Engine Resources

Keys

Cryptographic keys used for data encryption:

• AWS KMS Customer Master Keys

• Azure Key Vault Keys

• Google Cloud KMS Keys

Access Credentials

Long-lived authentication tokens and certificates:

• Azure Key Vault Certificates

• GitHub Personal Access Tokens

Non-Human Identity (NHI) Security provides comprehensive visibility and governance for service accounts, API keys, and automated systems across your infrastructure. NHI accounts often operate with elevated privileges without regular oversight, creating security risks through credential exposure, excessive permissions, and lack of ownership accountability.

Organizations typically have 10-45 NHI accounts per human user, making visibility essential for reducing attack surface.

NHI Overview Dashboard

Access the centralized NHI dashboard through NHI Security > Overview in the main navigation. The dashboard displays priority integrations with key security metrics.

Getting Started with the NHI Overview

1. Review the Overview: Navigate to NHI Security > Overview to assess your current NHI landscape

2. Identify Priority Areas: Look for integrations with high unowned account counts

3. Establish Ownership: Begin by assigning owners to critical NHI accounts using the bulk assignment features

4. Set Up Monitoring: Create Rules and Alerts for ongoing NHI governance

5. Implement Reviews: Configure Access Reviews for regular NHI validation

6. Build Queries: Use Query Builder to create NHI-specific analysis queries

Key Metrics

• Total NHI Accounts: Count of discovered non-human identities

• Unowned Accounts: Accounts requiring ownership assignment

• High-Risk Accounts: Accounts with admin privileges or security concerns

• Keys & Secrets: Associated cryptographic keys and credentials

• Credential Status: Rotation compliance and expiration tracking

Click any integration card to filter the NHI Accounts view to that specific platform.

Discovery and Classification

Automatic Detection

Veza automatically identifies non-human identities using built-in detection rules across 40+ integrations. Learn how classification works in NHI Identity Classification Logic.

Supported NHI Types

Veza discovers NHI entities from supported integrations, including:

• Cloud Service Accounts: AWS IAM users, Azure service principals, Google Cloud service accounts

• Application Accounts: Service accounts in enterprise applications

• Workload Identities: Kubernetes service accounts, container runtime identities

• Integration Users: System accounts for API integrations and automation

• Deploy Keys: GitHub deploy keys, SSH keys for automated deployments

Custom Classification with Enrichment Rules

Administrators can add Enrichment Rules to augment automatic NHI detection:

• Naming conventions (e.g., accounts containing "svc-", "service-account-")

• Attribute patterns (missing email addresses, specific group memberships)

• Custom tags or metadata

Go to Integrations > Enrichment Rules to create and manage rules.

Keys and Secrets Management

Discovery

Veza identifies keys, secrets, and credentials across integrated systems. See NHI Secrets for supported entity types, including:

• Cryptographic Keys: AWS KMS keys, Azure Key Vault keys, Google Cloud KMS keys

• Application Secrets: Configuration secrets, API tokens, database connection strings

• Access Credentials: Long-lived authentication tokens, certificates

Governance and Ownership

Assign Owners

The Entity Owners feature enables human accountability for NHI by assigning human owners to accounts, individually or in bulk:

1. From the NHI Accounts view, select accounts needing ownership

2. Use Assign Entity Owners to link accounts to responsible teams or individuals

After assigning ownership for NHI entities, you can use filters to search for entities with no owners, assign Access Reviews to owners, and create rules and alerts when new entities are detected with no owners.

See Managers and Resourcer Owners for more about auto-assigning Access Reviews using NHI owner metadata.

Access Reviews

You can use Veza to implement governance workflows for NHI accounts:

• Create Reviews: Use Access Review Configuration to set up NHI-specific reviews

• Schedule Reviews: Establish regular review cycles with Schedule an Access Review

• Review Intelligence: Apply Review Intelligence Policies to automate NHI governance decisions

Analysis and Investigation

Use Veza's analysis capabilities to identify security risks such as unrotated or expired credentials, keys with excessive permissions, and secrets stored outside of proper vaults:

VQL Analysis

Use Veza Query Language (VQL) to create sophisticated queries for NHI analysis. These queries can be used to create Access Review Configurations, construct custom dashboards, and generate reports.

Graph Visualization

Leverage Veza Graph search interface to:

• Visualize NHI relationships and permissions

• Trace access paths from NHI accounts to sensitive resources

• Understand permission inheritance and effective access

Comparison Analysis

Use the Access Intelligence Compare functionality to:

• Compare permissions between similar NHI accounts

• Analyze differences in access patterns

• Identify permission drift or inconsistencies

Monitoring and Alerting

Rules and Alerts

Set up proactive monitoring with Rules and Alerts:

• Alert on new unowned NHI accounts

• Monitor for NHI permission escalations

• Detect inactive NHI accounts with active credentials

Risk Assessment

Use Access Intelligence Risks to assign criticality levels to NHI queries:

• Prioritize NHI security issues by risk level

• Track risk trends over time

• Focus remediation efforts on critical accounts

Activity Monitoring

Leverage Activity Monitoring to:

• Track NHI account usage patterns

• Detect unusual access behavior

• Monitor for potential credential compromise

Reporting and Dashboards

Pre-built Reports

Access NHI-focused reports through Dashboards:

• NHI inventory summaries by integration

• Ownership coverage reports

• Risk assessment dashboards

Custom Reports

Create tailored reports using Reports:

• Export NHI data for compliance audits

• Generate ownership assignment reports

• Create executive summaries of NHI security posture

Scheduled Exports

Automate report delivery with Scheduled Exports for regular compliance reporting, stakeholder updates, and integration with external systems.

Common Use Cases

Finding Unowned Service Accounts

Use Veza Query Language to find NHI accounts lacking ownership:

SHOW AwsIamUser { name, created_at, owners }
WHERE identity_type = 'NonHuman' AND owners IS NULL;

Identifying High-Risk NHI Accounts

Create queries to find NHI accounts with admin-level access:

SHOW AwsIamUser { name, risk_level, last_login_at }
WHERE identity_type = 'NonHuman' AND risk_level = 'HIGH';

Tracking Key Rotation

Monitor cryptographic key age and rotation status:

SHOW AwsAccessKey { created_at, last_used_date, age_in_days }
WHERE created_at < CURRENT_DATE - 90;

Related Documentation

• NHI Identity Classification Logic - Understanding how Veza classifies identities

• NHI Secrets Management - Keys, secrets, and credential discovery

• Access Reviews - Governance workflows for NHI accounts

• Enrichment Rules - Customize NHI detection

• Rules and Alerts - Proactive NHI monitoring