NHIs (non-human identities) have become a top risk as enterprises adopt Cloud and SaaS, and breaches involving NHIs rise, driving this vulnerability to the top of CISO priority lists. 

An NHI is a digital identity linked to an application or service, empowering it to execute actions on target systems or resources. Developers, systems, and applications rapidly generate NHIs to enable automated interactions during cloud adoption, software development, and integration of third-party services. These identities are pivotal in driving automation and facilitating seamless integration across cloud services, SaaS platforms, and on-premises applications. 

NHI challenges for security

With the rising prevalence of NHIs in modern ecosystems, implementing robust management and security is vital to protecting against unauthorized access and mitigating risks. The main challenges that have increased the need for greater security include:

• Lack of NHI visibility: NHIs' dynamic and ephemeral nature impacts visibility and traceability. It is challenging to know how many NHIs have been created or where they live across multiple platforms, directory services, and cloud integrations. Many NHIs operate in the shadows, making tracking their numbers, usage, and access permissions extremely difficult.
• Excessive and Uncontrolled Permissions: NHIs are granted more privileges than necessary, creating significant security risks through potential privilege escalation.
• Ineffective Lifecycle Management: NHIs often become stale or inactive, with some accounts remaining unused for years, dramatically increasing the potential attack surface. In addition, human lifecycles are tied to NHI and must be addressed simultaneously. 

In this blog post, we discuss three core elements that play a role in NHI security: entitlements, credentials, and client security. We outline how their use dictates your security plan, explain why entitlements are critical, and offer best practices for securing credentials and clients. 

Note: the term ‘credential’ in this article refers to authentication secrets such as API keys, access keys, certificates, etc., and the term ‘provider’ refers to a public cloud or SaaS provider.

The Elements of NHI for Security

When an NHI is created, three elements must be managed and secured: its credentials, entitlements, and the client that uses it.

A client (an application or a workload) uses an NHI to perform actions on one or more resources using a set of entitlements (permissions). In this process, the client application authenticates using a credential to establish its identity.

1. Credentials
   ‍
   ‍Non-Human Identities (NHIs) must use one of the supported authentication methods (username/password, access keys, API keys, key pairs, certificates) to authenticate and establish their identity.
   ‍
   Advanced authentication methods like multi-factor authentication and passwordless solutions are not supported for NHIs.
   ‍
   Credential management is crucial to reduce the risk of a compromise, and it may be owned by the enterprise or the cloud provider.
   ‍
   Best Practice: Utilize short-lived credentials wherever possible to limit the chance of a compromise.
   ‍‍
2. Entitlements
   ‍
   ‍NHIs are assigned specific privileges that define the actions they can perform on a target system or resource.
   ‍
   If an NHI is compromised, the attacker gains access to these privileges, determining the scope of the potential attack surface.
   The enterprise is responsible for ensuring that only the necessary privileges are assigned.
   ‍
   Sometimes, the entity requiring the NHI may provide a predefined role with the necessary privileges. In other cases, the enterprise must determine and assign the appropriate privileges.
   ‍
   Best Practice: Ensure the least privilege for entitlements as it is the enterprise's final line of defense and is under its control.
   ‍‍
3. Client Using the NHI
   ‍
   ‍The client application or workload using the NHI must be secured against unauthorized access.
   ‍
   Responsibility for the security of the workload or the client application lies with the cloud provider, the enterprise, or a third party, depending on who controls it.

The key takeaway is that entitlements control your attack surface. While securing all three elements is essential, if entitlements are rightsized to least privilege, even if a credential or client is compromised, the business impact is greatly reduced. The attacker is severely constrained. 

NHI Security Implications

An NHI can be used in four ways, depending on who is responsible for credential management, who is responsible for entitlement management, and where the client workload is located. Below, we discuss these use cases and their security implications.

• Provider-managed NHI
• Shared ownership NHI
• Enterprise-managed NHI
• External Client NHI

Provider-managed NHI

In this case, the enterprise creates an NHI for a required cloud service, which the cloud provider completely manages.

The three aspects of NHI security discussed above apply in this case:

• Credentials: The enterprise has no explicit credentials to manage. The provider creates short-lived credentials within the workload and is responsible for the credentials' lifecycle (periodic rekey). 
• Entitlements: The provider also manages entitlements for the NHI.
• Client: The ​​workload/application where the NHI is used. The provider owns and manages the client and is responsible for its security.

Example: 

In AWS, the AWSServiceRoleForBackup is an example of Provider-Managed NHI. It helps backup resources in AWS and has entitlements to list/read resources and copy them to the S3 bucket/EBS volume for backup.

The Enterprise is only responsible for creating the NHI when they require the backup service. The AWS cloud provider is responsible for defining NHI and its short-lived credentials. AWS also defines the NHI’s entitlement and is accountable for the security of the workload (AWS Backup Service) where the NHI is used.

Shared ownership NHI

In shared ownership,  the provider and the enterprise jointly manage the NHI:

• Credentials: The enterprise has no explicit credentials to manage. The provider creates short-lived credentials within the workload and is responsible for the credentials' lifecycle (periodic rekey). 
• Entitlements: The enterprise controls entitlement management. It decides what permissions are required for the NHI. 
• Client: While the workload/application runs within the cloud provider, the enterprise is responsible for securing access to the workload.

Example: 

In AWS, an EC2 instance with an instance profile or a Lambda service can be linked to an IAM Role with a list of permissions. An Azure-managed Identity with role assignment would also fall into this category. The application runs in the cloud provider's VM service, which manages the lifecycle and injection of temporary credentials. The enterprise is responsible for defining the permissions required for the application and the security of the client VM, and AWS is responsible for managing the short-lived credentials. 

Enterprise-managed NHI

 When the NHI is entirely managed by the enterprise, the security looks like: 

• Credentials: The NHI requires explicit credentials, which the enterprise manages.
• Entitlements: The enterprise controls entitlement management. The enterprise decides which permissions the NHI requires.
• Client: Two scenarios exist:
  
  • The application/workload runs within the enterprise's network boundary, and the enterprise is responsible for injecting the credentials into the workload/application and securing the workload where the application is running.
  • The application/workload runs externally in a third-party application. The enterprise shares the credentials with the third party, who is responsible for injecting the credentials into the workload/application and securing the workload where the application is running.

Example:

An AWS IAM User with an Access Key and Role assignment or Entra/Azure Service Principal with Key and Role assignment falls into this category. The NHI can be used from anywhere: inside the enterprise network (case 1 below) or externally (case 2 below) to perform actions on the target system or resource.

Case 1:

Case 2:

External (Third-party) Client NHI

In this case, a third party (external entity) creates and manages the NHI credentials. The enterprise trusts the NHI and manages the entitlements. The NHI is used by the third-party entity to perform actions in the enterprise’s cloud environment. 

• Credentials: No explicit credential is created in the enterprise. Instead, a cross-organization trust is established between the enterprise and the third-party entity. The external third party creates and manages the NHI credentials.
• Entitlements: The enterprise controls entitlement management. The enterprise decides which permissions are required for the NHI.
• Client: The third-party entity owns the workload/application and, in collaboration with the enterprise, is responsible for its security. 

Example: 

An example of an NHI in this category is a role-to-role trust established between a third-party entity’s AWS account and a role in the target enterprise’s AWS Account. In Azure, the Service Principal in the customer's Entra domain trusts a registered Application in a third-party Entra domain, and the Service Principal has assigned roles in the target enterprise’s Azure environment.

Summary

Credentials, entitlements, and clients/workloads must all be managed to secure your NHIs. Credential and client compromises will happen; in many cases, they are outside the enterprise's control. To maximize security, the two best practices an enterprise can follow are

1. Whenever possible, use the NHIs with short-lived credentials. This will reduce the need to manage and secure credentials and the chance of a credential compromise.
2. Entitlements are the most important aspect. Maintain least privilege on the entitlements, which guarantees a limited attack surface even in case of a breach.

How Andromeda Security Can Help

Andromeda Security discovers all NHI credentials, entitlements, and workloads and helps customers manage and secure them through:

• Full discovery of NHIs and all credentials and details of clients using these NHIs
• Complete lifecycle management of NHI credentials
• AI-driven insights into NHI behavior patterns with recommendations and remediation steps to remove unused credentials and inactive NHIs
• Least privilege Entitlement management, including access and usage visibility at the fine-grained permissions level, with recommendations and remediation steps to remove all unused permissions
• Identification of shared NHIs across multiple applications with permissions rightsizing recommendations for each application
• Behavior analytics and anomaly alerts on client NHI usage