Getting Started with the NHI Index
Definition
A Non-Human Identity (commonly abbreviated as “NHI”) refers to any digital credential used programmatically by machines, workloads, applications, or automated processes to authenticate and perform operations on a given resource. These identities are crucial for ensuring seamless interactions across cloud services, SaaS platforms, and on-premise data centers. As NHIs proliferate in modern IT environments, their secure management becomes vital to protect against unauthorized access.
Common NHI Types
NHIs vary based on their origin and purpose within an IT environment.
They are typically categorized into several types:
Tokens
Small pieces of data, often temporary, used to authenticate and authorize access to services (e.g., OAuth tokens for API access).
What are they
Tokens are structured data used to authenticate or authorize access to systems and services. They typically consist of claims or assertions about the entity using them, encoded in formats like JWT (JSON Web Token), which is common in OAuth 2.0 and OpenID Connect. Tokens often have a defined structure: a header, payload, and signature, which together ensure integrity and authenticity.
Example structures
OAuth 2.0 (JWT): eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Application-Specific: Some applications use a specific convention for their tokens. For example, Slack Tokens begin with xoxb- for bot tokens and xoxp- for user tokens.
What risks do they pose
Because tokens encapsulate access permissions, if they are compromised, attackers can gain unauthorized access to the associated resources. The structure and scope defined within the token can make them powerful tools for accessing systems, which is why they must be carefully managed.
Secrets
Sensitive data such as passwords, encryption keys, or API tokens, used for authentication and encryption (e.g., an API key stored in a secure vault).
What are they
Often static and long-lived, Secrets are confidential data used for authentication, encryption, or securing communication between systems. Common types of secrets include passwords, API keys, and encryption keys. Unlike tokens, which are typically generated and validated dynamically, secrets are often static and need to be stored securely. They may contain a single string of text, or include both an identifier and a secret (e.g., Access Key and Secret in AWS IAM).
Example structures
Passwords: May be simple or hashed strings, e.g., P@ssw0rd! or 5f4dcc3b5aa765d61d8327deb882cf99 (MD5 hashed).
API Keys (Generic): apikey1234567890abcdef
AWS Access Keys: AKIAIOSFODNN7EXAMPLE
What risks do they pose
Secrets, especially when hardcoded or improperly stored, can be easily exposed through code repositories, logs, or misconfigurations. They provide direct access to systems and data, making them high-value targets for attackers.
API Keys
Unique identifiers that are used to authenticate to APIs and perform programmatic operations, facilitating access to specific resources and functionalities (e.g., a cloud service API key used to manage resources).
What are they
API keys are unique identifiers used to authenticate requests to APIs, often passed in HTTP headers or as query parameters. Unlike tokens, which might carry specific claims, API keys are simpler in structure and typically just represent the identity of the calling application or user.
Example structures
AWS Access Keys: AKIAIOSFODNN7EXAMPLE
Google API Key: AIzaSyBpV1Kr__ExampleKey12345
What risks do they pose
If an API key is compromised, it can be used to perform unauthorized actions within the associated service. Since API keys often have broad permissions, they can be particularly dangerous if not properly secured.
Service Accounts
Specialized accounts used by applications or automated processes to access resources and perform tasks (e.g., a service account managing backups in a cloud environment).
What are they
Service accounts are specialized non-human identities used by applications or automated processes to access resources and perform tasks. Typically, a service account will consist of a username (or service ID) and a credential, such as a password or private key. These credentials allow the service account to authenticate and interact with other systems programmatically. In many cases, service accounts are simply regular human user accounts repurposed for programmatic access, utilizing the same type of account structure but used in a different way. However, in some platforms—such as Google Cloud Platform (GCP)—service accounts represent a distinct authentication structure, designed specifically for automated systems rather than being an adaptation of human user accounts.
Example structures
GCP Service Account Key JSON: {
"type": "service_account",
"project_id": "my-project",
"private_key_id": "abcd1234abcd5678efgh91011ijklmnop",
"private_key": "-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkq...
-----END PRIVATE KEY-----
",
"client_email": "my-service-account@my-project.iam.gserviceaccount.com",
"client_id": "12345678901234567890",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/my-service-account%40my-project.iam.gserviceaccount.com"
}
Active Directory Service Account:
Username:corp\svc_backup
Password:P@ssw0rd123!
What risks do they pose
Service accounts often have elevated privileges, which, if compromised, can lead to significant security breaches. Their credentials (e.g., passwords, keys) are high-value targets and must be managed carefully to prevent unauthorized access.
Certificates
Digital certificates that verify the identity of entities and enable encrypted communications (e.g., an SSL certificate for a secure website).
What are they
Certificates are digital credentials used to authenticate entities and establish secure communications via SSL/TLS. They typically include a public key, the identity of the certificate holder, the certificate authority (CA) that issued the certificate, and a validity period. Certificates are encoded using standards like X.509.
Example structures
X.509 Certificate: -----BEGIN CERTIFICATE-----
MIIDdzCCAl+gAwIBAgIEbXhkhjANBgkqhkiG9w0BAQUFADBhMQswCQYDVQQGEwJV UzELMAkGA1UECBMCQ0ExETAPBgNVBAcTCFNhbnRhQ2xhcmExFjAUBgNVBAoTDU15 IENvbXBhbnkgTHRkMRowGAYDVQQDExFNeSBDb21wYW55IEx0ZC4gQ0EwHhcNMTEw OTA2MDIzNjUwWhcNMjEwOTA0MDIzNjUwWjBhMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCQ0ExETAPBgNVBAcTCFNhbnRhQ2xhcmExFjAUBgNVBAoTDU15IENvbXBhbnkg THRkMRowGAYDVQQDExFNeSBDb21wYW55IEx0ZC4gQ0EwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQC3BHU4FJlg1U9b4T5B2nknv4EehU7u3u8WklbwTiBe
...
-----END CERTIFICATE-----
What risks do they pose
Expired or compromised certificates can lead to significant security vulnerabilities, such as man-in-the-middle attacks. The integrity and trustworthiness of a certificate chain are critical for secure communications, making proper certificate management essential.
What’s Not an NHI?
It's important to distinguish between NHIs and IAM roles, as they serve different functions even though they may seem similar in cloud environments. NHIs—such as tokens, secrets, or service accounts—are credentials used to directly authenticate and authorize access to resources. In other words, NHIs are like digital "keys" that prove an entity's identity and allow it to access certain systems.
On the other hand, a role is not a credential; it's a set of permissions that defines what actions an authenticated identity (whether human or non-human) is allowed to perform. A role doesn’t access resources on its own. Instead, it is assumed by a trusted entity, like an EC2 instance.
For example, an EC2 instance can be set up to assume a role. The instance itself is not an NHI—it doesn’t need credentials like API keys or secrets. Instead, it is trusted by the cloud provider (e.g., AWS) to automatically take on the role, which grants it temporary credentials (like ephemeral tokens) to access resources defined by the role's permissions.
What You Need to Know and Why It Matters
Why are there different types?
NHIs are inherently fragmented across the enterprise IT landscape, spanning cloud providers, SaaS applications, and on-premise systems. This fragmentation arises due to the absence of a universal standard for authentication and authorization. Each environment—whether a cloud platform, SaaS application, or legacy on-premise system—implements its own security protocols to meet specific operational, usability, and compliance requirements.
As a result, organizations face the challenge of managing a wide variety of distinct and often incompatible NHIs, each requiring tailored security and management practices. This lack of standardization not only complicates NHI management but also introduces significant security risks, particularly in environments where NHIs must interact across different platforms.
The NHI challenge
Non-Human Identities are scattered across cloud, SaaS, and on-premises environments, leading to significant security and management challenges. This fragmentation makes it difficult to maintain consistent oversight, often resulting in NHIs accumulating excessive privileges, remaining under-monitored, or becoming stale—each of which expands the attack surface and increases risk.
The absence of centralized controls and standardized practices for NHIs, unlike those available for human identities, exacerbates these issues. NHIs are frequently spread across multiple platforms with varying security protocols, creating visibility gaps and complicating their lifecycle management. This fragmented oversight makes it challenging to detect and respond to compromises, allowing breaches to go unnoticed until substantial damage has been done.
High-profile breaches, such as those involving over-privileged service accounts or unmonitored API keys, underscore the urgent need for robust NHI security and management strategies. To effectively address these challenges, organizations must adopt a comprehensive approach that includes enhanced visibility, stringent governance, effective risk prioritization, advanced detection and response mechanisms, and proactive Zero Trust protections. These strategies are essential to securing the digital infrastructure in an increasingly complex IT landscape.
Why We Built This Website
The NHI Index was created as a comprehensive resource to assist IT and security professionals in managing and securing NHIs across various platforms. Our mission is to provide the essential tools and knowledge needed to understand and improve NHI security, whether in cloud services, SaaS applications, or on-premise systems. By reducing the risks posed by NHIs, we aim to enhance the overall security posture of digital infrastructure.
This project is more than just a catalog—it's a step towards creating a centralized knowledge base that demystifies the complexities of NHI security and management. By offering detailed guidance and practical steps, the NHI Index empowers professionals to take proactive measures in securing NHIs, ultimately contributing to a safer and more resilient enterprise environment.
We invite the community to engage with the NHI Index, share insights, and stay informed about the latest developments in NHI security. Together, we can build a more secure digital landscape.