What are non-human identities

With the rise of automated workflows, cloud-native development and interconnected systems, non-human identities (NHI) are becoming a key part of modern IT environments. These identities help systems communicate and operate without human involvement.

However, their proliferation comes at a cost. As the number of NHIs increases, it broadens the attack surface, creating critical, yet often overlooked, security vulnerabilities that require careful management and specialized security controls.

NHI security best practices

Here are some best practices you can follow to reduce common NHI risks:

• Assign only the minimum permissions needed for NHIs to function.
• Log and alert on anomalous NHI behavior (e.g., a CI/CD bot accessing production data at 3 a.m.) via SIEM (Security Information and Event Management) rules.
• Automate credential rotation and management for all NHIs.
• Schedule quarterly NHI reviews to deprovision unused identities (e.g., deprecated API keys of certain microservices).
• Categorize NHIs based on risk and apply corresponding security controls.

Common threats targeting non-human identities

Your NHI security policy should implement protective measures for the following threats:

1. Credential theft - Attackers steal API keys, service account credentials or certificates to gain unauthorized access to systems. This can happen through misconfigured repositories or exposed environment variables.
2. Privilege escalation - If NHIs are granted excessive permissions, and hackers are able to compromise them, they can then exploit those permissions to execute privilege escalation attacks.
3. Token hijacking - Compromised tokens or session IDs allow attackers to impersonate services and execute unauthorized actions. If these tokens are not properly rotated, attackers may get to use them for extended periods without detection.
4. Supply chain attacks - Third-party services and integrations often rely on NHIs. If a provider’s credentials are compromised, attackers can use them to infiltrate connected systems.
5. Orphaned (unmonitored) NHIs - NHIs that are no longer in use but still have active credentials pose a security risk. Without proper tracking, these accounts can be easily exploited.

If your organization uses automation, cloud services or any kind of system-to-system communication, you almost certainly have non-human identities (NHIs) in your environment. Even if their number is low right now, you should start developing a scalable NHI management system immediately.

As your infrastructure grows, the number of NHIs can increase exponentially, which would make it harder to track and secure them later. A structured management framework helps prevent security gaps and ensures that NHIs are properly controlled from the start.

Non-human identity management lifecycle explained

Here’s an overview of a typical NHI lifecycle:

1. Discovery & inventory - Identify all NHIs (API keys, service accounts, IoT credentials, etc.) across cloud, on-prem and third-party systems.
2. Classification & risk assessment - Tag NHIs by criticality (e.g., "high-risk" if they are accessing sensitive data). Check for excessive permissions, hardcoded secrets or unused identities.
3. Secure provisioning - Create NHIs with the bare-minimum privileges they need to perform their actions. Automate credential issuance via secrets managers like HashiCorp Vault or AWS Secrets Manager.
4. Continuous monitoring - Set up continuous monitoring of NHI activity and logging for audit trails and threat detection.
5. Rotation & deprovisioning - Automate credential rotation using short-lived tokens or SPIFFE/SPIRE certificates. Formulate a process to proactively remove orphaned NHIs.
6. Auditing - Analyze NHI activity logs to detect anomalous behavior and potential security breaches. Ensure that NHI management practices continue to comply with relevant regulatory requirements.

Next, let’s look at two examples of how NHIs work in real life:

An automation script

Consider a script that fetches some data from a sensitive database. Here’s how it could work:

1. A developer creates a service account specifically for the script. It’s granted only the bare-minimum permissions to access the database.
2. The script uses a secure API key or service account credentials to authenticate itself with the database.
3. Each database request made by the script is logged to track activity and detect anomalies.
4. The API key or service account password is rotated periodically to prevent long-term exposure.
5. When the script is no longer needed, its access is revoked and its credentials are deleted.

An EC2 VM

Our next example is an EC2 instance that needs to interact with other cloud services.

1. An IAM role is created with specific permissions (e.g., read/write access to S3 and DynamoDB).
2. The EC2 instance automatically receives temporary security credentials via the instance metadata service.
3. The VM uses its temporary credentials to make signed API requests to S3 or DynamoDB.
4. AWS automatically rotates the temporary credentials to reduce the attack surface.
5. CloudTrail and CloudWatch log API requests to detect unauthorized access attempts.
6. When the VM is terminated, its associated IAM role access is also revoked.

Modern frameworks like NIST CSF 2.0, PCI DSS 4.0.1 and ISO 27001:2022 place greater emphasis on dedicated NHI management. Organizations must take heed of these guidelines, not only to ensure compliance, but also to proactively mitigate security vulnerabilities.