The Ultimate Guide To Non-Human Identities
Introduction
A year ago, I wrote my first white paper on Managing Non-Human Identity Risks, where I shared a hands-on practitioner's view on understanding, assessing, and managing NHI risks based on over 20 years of experience establishing and running global NHI programs at various investment banks. This white paper received significant recognition from the industry and is still considered the go-to resource for helping organizations understand the core foundational principles necessary for managing NHI risks. It outlines the key capabilities needed to manage these risks effectively and sustainably.
Writing this white paper was the catalyst for forming the NHI Mgmt Group, which is now established as the number one authority on research, education, guidance and advice on NHI risks.
Given the growing buzz around NHIs coming into 2025, I decided my first major contribution of the year would be to produce "The Ultimate Guide to Non-Human Identities".
In this guide, we will cover:
1 - What are Non-Human Identities
3 - Why Now – Why Should You Be Concerned
4- Key Research and Survey Results
5 - Lifecycle Processes for Managing NHIs
6 - Static vs. Dynamic Secrets
7 - Regulatory and Audit Perspectives
8 - Standards
9 - The NHI Market
10 - 2025 Outlook and Predictions
Initially, my intention was to also include sections on:
How to Evaluate Your Current Risk Posture and Maturity Level
How to Start an NHI Program
How to Tackle the "Elephant in the Room" Using a Risk-Based Approach
While I began drafting these sections, I ultimately decided that a 70 page report was already too extensive. Therefore, I will leave those topics for my next major paper, "The Practitioner's Guide to Managing NHI Risks", which will coincide with several keynote talks I will be giving at major conferences this year. In the meantime, please read my white paper on Managing Non-Human Identity Risks for additional insights.
Biography of the Author
Known in the industry as ‘Mr. NHI,’ Lalit Choda is the founder of the NHI Mgmt Group (https://nhimg.org). Through this initiative, he evangelises and educates the industry and organisations on the risks associated with Non-Human Identities (NHI) and strategies to address them effectively.
A sought-after keynote speaker on the subject, Mr. Choda has managed some of the largest global regulatory NHI programs within the investment banking sector for over 20 years. He has also authored widely recognised white papers and research articles on NHIs, earning him the reputation as the leading voice and NHI Evangelist in the industry.
In 2024, Lalit further expanded his impact by forming the thriving LinkedIn Non-Human Identity Management Community Group, with over 1,500 members, encouraging collaboration and awareness around this critical topic across the industry.
1 - What are Non-Human Identities
A Non-Human Identity (NHI) is a digital entity or credential that represents machines, applications, automated processes or services used IT Infrastructure. NHIs enable machines and software workloads to securely authenticate, operate and perform tasks automatically (including access other machines, processes or services) without direct human interaction.
Examples of NHIs include API Keys, Tokens, Service Accounts, Secrets, Technical Accounts, Certificates, Admin Accounts, System Accounts.
NHIs are found in Containers, Microservices, 3rd Party Application Integrations, OT Equipment, CI/CD Pipelines, IOT Devices, AI LLMs, Databases, Robotic Process Automation (RPA), Sensors ...
Machine Identities – These relate to the identities linked directly to machines or devices to allow them to operate or authenticate with other machines, devices, and software workloads/processes. They typically have a Device MAC address, Serial Number, and GUID/UUID to identify the device. From a credential management standpoint, they use access tokens, certificates, root/admin accounts, etc., to operate and authenticate with other machines, devices, and software workloads/processes.
Workload Identities – These relate to the identities used by software workloads to operate automatically, authenticate, and access other machines, devices, and software workloads/processes. From a credential management standpoint, they use tokens, API keys, service accounts, certificates, secrets, passwords, etc., to operate and authenticate with other machines, devices, and software workloads/processes.
The Non-Human Identity vs Machine Identity Debate
Let's address one of the "elephants in the room" right at the start of this report.
There are two main camps in the industry:
Non-Human Identity
The term "Non-Human Identity" is generally better understood by the average person, especially when discussed in the context of Human and Non-Human Identities. The majority of vendors and groups use the NHI term, although some prefer not to use a term defined by being the opposite of "human". Some might argue there is a venture capital play here.
Some feel that describing something by what it is not, is not the best way to define a term. For example, a non-human could be an animal, but on the other hand, a machine could be a drill or a tractor as well.
Machine/Workload Identity
Organizations like Gartner, Microsoft, and Venafi are in the Machine Identity camp, which can be further broken down into:
Workloads
Devices
My personal view, and the reason I used the NHI Mgmt Group name, is that while Gartner's model is good, it is not quite right. Apologies to the Machine Identity camp - hope you'll still talk to me!
Machines and devices, to me, fall under one category, while software workloads fall under another, as they need to be managed very differently. Grouping everything under "Machine Identity" does not feel right.
In my LinkedIn post, I argued that a machine (e.g., a server, desktop) can also have human identities. So, if a machine can have both human and non-human identities, how can we classify this entire category as Machine Identity if it includes humans?
I hope I have convinced people that "Machine Identity" is not the right term and that a higher-level classification, "Non-Human Identity," is probably more appropriate. Machines/devices would be one bucket, and software workloads would be another.
Our survey at the NHI Management Group found that "Non-Human Identity" was clearly the preferred term.
Are we ever going to converge on a common term? Very unlikely, but I think the industry needs to converge.
The main thing is that we all need to focus on helping customers solve their Non-Human / Machine / Workload Identity risks.
2 - Key Challenges and Risks
The NHI Challenge
Whilst the management of Human Identities is fairly mature, including the solutions to manage them, Non-Human Identities (NHIs) are very difficult to manage. As per my white paper, I believe this is probably the hardest challenge an organisation will face in terms of risk exposure.
Addressing NHI risks touches on all aspects of IT processes and controls, from IAM Lifecycle Processes (JML), SDLC (CI/CD, DevSecOps), Secrets Vaulting, Secrets Scanning, Prevent Controls, Detect and Response—many of which will require significant strategic investments to deliver the required infrastructure capabilities to support risk reduction and sustainable controls to “stop the bleeding."
Unless an organisation already has mature controls and capabilities for managing NHIs, they are likely to uncover thousands of unmanaged hardcoded credentials in the environment (both internally and externally) that can be easily discovered or are already known. There are likely to be many credentials that have not been cycled and a sizeable percentage of legacy/inactive accounts, increasing the surface area of risk. It is also highly likely that these credentials are being used by humans to bypass Human PAM controls, potentially posing risks to the integrity of a firm's books and records.
Unfortunately, at the moment, there is no ‘magic bullet’ here. You cannot simply buy a product that will take care of this completely for medium to large organisations with a hybrid environment. You cannot hire a few key SMEs/Consultants to quickly fix this—for many large global organisations, this could be at least a 2-3 year program and upwards of a $10-20M investment, based on my experience running some of the largest NHI programs in the industry.
The key challenges of NHIs:
NHIs are typically unmanaged with very weak controls.
They have high privileges and access to critical data.
They are a key attack vector to compromise systems/data.
It is very challenging to remediate the risks.
NHIs outnumber Human Identities 25x – 50x.
There is a huge secrets sprawl problem with Cloud/SaaS integrations, microservices, containers, etc.
Significant use of NHIs by humans poses a huge internal threat that is often overlooked.
Monitoring controls are very challenging to implement and it is very hard to see “the wood from the trees.”
There have been significant breaches including third-party supply chain attacks.
GenAI is going to increase the use of NHIs significantly and create bigger risks.
The Key Risks
Below is a summary of the Top 10 NHI Issues our NHI Mgmt group highlighted in an earlier article.
Plain-Text / Unencrypted Credentials – Organisations often find that many NHIs have been hard-coded into source code repositories (and other places) and can therefore be easily discovered by both external and internal threat actors. Addressing these issues is a major undertaking for most organizations today.
Full Inventory of Accounts – Obtaining an inventory of all NHIs is very challenging, as there could be many platforms, endpoints, directory services, and cloud integrations where these NHIs exist.
Stale / Inactive Accounts – Due to weak lifecycle processes and a lack of visibility into account usage information, many NHIs end up inactive, increasing the attack surface area.
Lack of Account Ownership – NHIs in most organizations lack ownership information. It is critical to identify an owner for each NHI to help drive hygiene and remediation activities.
Humans Using Non-Human Accounts – Humans using NHIs has always been a problem. It is very easy for users to bypass human access controls and use an NHI account instead. This leads to repudiation issues and, in many cases, the activities go undetected.
Excessive Privileges – NHIs are generally highly privileged accounts, but we see in many cases NHIs are given excessive privileges when much lower permissions would suffice.
Lack of Credential Cycling/Rotation – Cycling/rotating NHIs is very challenging for a number of reasons, such as lack of password change information, unknown dependencies that could cause operational impacts, changes required to application code/configuration, lack of secret vaulting capabilities, and lack of endpoint cycling capabilities.
Lack of Environment Segregation – In many cases, the same NHI is used in both production and non-production environments, or the same logical NHI has the same password across each environment, increasing the risk of lateral movement.
Sharing of Credentials – Sharing NHIs across applications is a major issue, breaking the principles of need-to-have and least-privilege. This makes things like password cycling much more complex, as you don’t know all the dependencies of where a credential is being used.
Non-Complex Passwords – NHI passwords have been found to be non-complex and therefore prone to password guessing attacks.
3 - Why Now – Why Should You Be Concerned?
At the Gartner IAM summit in Dec 2024, Non-Human / Machine Identities were called out as one of the Top Trends for 2025.
A staggering 80% of identity-related breaches relate to compromised NHIs, such as service accounts and API keys, as highlighted in our 40 NHI Breaches report.
At the 1st NHI Security Conference, hosted by Astrix Security and the Cloud Security Alliance (CSA) last September in NY, several CISOs talked about NHI risks always being present, but previously there were bigger fish to fry, e.g., Human IAM, PAM, and Cyber defenses. NHIs are now viewed as a top 3 risk for CISOs.
Based on my personal experience running global NHI programs over the last 20+ years, historically, the typical driver for starting an NHI program has been internal incidents (including accidents using NHIs), regulatory requirements, or, more recently, breaches.
Secrets Sprawl
We have a major secrets-sprawl problem in the industry, which has worsened significantly in recent years for several reasons:
Source – Clutch Security
Hybrid-Cloud Environments
Cloud-Native Adoption
Legacy On-Prem Environments
SaaS Services and associated 3rd Party Supply Chain Risks
API-Based Service Architecture
Multiple Identity Providers and Directory Services
Containerisation and Microservices
CI/CD Automation and Distribution
GenAI & LLMs
This has led to an exponential increase in NHIs, hyper-fragmentation, making it very hard to implement controls over this very complex landscape.
Source – Oasis Security
Non-Human Identities outnumber Human Identities by a factor of 25x – 50x.
I have dealt with 500k+ NHIs as part of running some of the largest global NHI programs within the financial industry.
Most NHIs are typically static in nature, leading to huge issues and risks that we shared earlier.
There are multiple identity providers and directory services providers that all have to be factored in across your Hybrid-Cloud and On-Prem environments.
Particularly with legacy On-Prem environments, NHIs also exist locally on multiple endpoints (e.g., Operating Systems and Databases) that require endpoint connectivity to get visibility, etc.
You also have to consider all your environments (e.g., Production and Non-Production) as there are issues around the lack of environment segregation, allowing lateral movement.
A typical organisation has over 300 3rd Party SaaS integrations with limited visibility and a lack of controls on how they are managed internally as well as on the SaaS 3rd Party supplier side.
NHIs Are Very Easy to Discover and Compromise
In our view, the biggest risk around NHIs is that they are hardcoded everywhere, e.g., in source code repositories (public and internal), webpages, Confluence, SharePoint, file systems, etc., making them very easy to discover and compromise.
In preparing this report, I asked our security research intern to find out how easy it is for NHIs to be discovered in public GitHub repositories.
Dorking
We focused on a specific technique called Dorking, which exploits specialized search capabilities in tools such as application source code repositories (e.g., GitHub) or even search engines to uncover exposed secrets. These queries can help locate API keys, passwords, tokens, and more.
Dorking Query Examples – Below are some of the queries you can run to look for API keys, passwords, AWS credentials, GitHub tokens:
What Did We Find – We ended up finding a .env file in a public repository with leaked GitHub and Docker Hub secrets that were still valid and could allow the following to occur:
The GIT_ACCESS_TOKEN can grant unauthorized access to a GitHub account, allowing an attacker to perform various actions including creating, modifying, or deleting repositories.
The DOCKERHUB_USERNAME and DOCKERHUB_PASSWORD can allow unauthorized access to the DockerHub account, enabling attackers to pull, push, or delete images.
With the NGROK_TOKEN, an attacker could set up tunnels to access internal services, exposing sensitive internal applications to the internet. This could be used to exploit services that are not intended to be publicly accessible.
Leaked Secrets Are Growing Rapidly
In a recent "The State of Secrets Sprawl" report by GitGuardian, a staggering 12.8 million occurrences were detected on GitHub.com in the last year alone—a 28% increase from 2022.
Attackers Are Monitoring for Secrets in Real-Time
A recent Secret Debunking research report by Clutch Security demonstrated that attackers operate at lightning speed, often compromising secrets within minutes of exposure. They simulated the exposure of 38 AWS Access Keys across 14 destinations:
66% were exploited, some in under a minute!
GitHub: Secrets were exploited within an average of 6.6 minutes. Alerts from AWS arrived quickly (average 1.4 minutes), but exploitation often occurred faster. Scenarios like embedding secrets in .env files or Terraform state files saw rapid compromise.
GitLab: Keys took significantly longer to exploit (average of 3 days) or went unnoticed. However, GitLab lacks integration with AWS’s secret scanning, making it less equipped to provide alerts.
Cloud API Keys For Sale
In one of our earlier articles, we reported that API keys for AWS, Azure, MongoDB, GitHub, DockerHub, and GCP were available for sale, starting from $100!
This was the message from the hackers:
"If you can think of API Key, we have it. All working. Will get new keys everyday. Have tons of working AWS, GCP, Azure, Alibaba keys. You can compromise whole companies with keys with high permissions. Whole cloud infra is in your access". We have Openai, Notion, Dockerhub, SQL, Mongodb, Telegrambot and around 200 different services APIs. All fresh and working. Message me here to buy anything. Starting from $100. Minimum purchase $100"
NHI Breaches
2024 has seen an unprecedented number of breaches involving NHIs, either to initiate the breach or discovered during the breach to cause further damage. Once a hacker is in, they typically target NHI accounts, given the high level of privileges they have to critical systems and data.
We recently published a major report on 40 NHI breaches that have occurred over the last 2-3 years, with a clear uptick in reported breaches in 2024. Below, we highlight over 15 key breaches from 2024.
BeyondTrust Breach Causes Major Incident at US Treasury – In December 2024, BeyondTrust, a leading cybersecurity solutions provider, identified anomalous activities against instances of its Remote Support Software-as-a-Service (SaaS) platform as a result of a compromised API key being exploited. Later that month, the US Treasury announced a “major incident” as its systems were hacked as a result of this breach, with employee workstations being accessed, including some unclassified documents.
Schneider Electric Breach – In November 2024, Schneider Electric confirmed a significant cybersecurity incident involving unauthorized access to its internal project management system. The attacker exploited exposed credentials to gain access to Schneider Electric’s Jira server and extract 40GB of sensitive data.
AI LLM Hijack Breach – In October 2024, Permiso Security reported attackers hijacking LLM models on cloud infrastructure to run rogue chatbot services. Threat actors leveraged AWS access keys to hijack Anthropic models provided by AWS Bedrock for Dark Roleplaying.
Emerald Whale Breach – In October 2024, a significant cybersecurity incident known as Emerald Whale shocked the DevOps community. This incident revolved around exposed Git configuration files, an apparently simple misconfiguration that resulted in the theft of over 15,000 sensitive data items and unauthorized access to over 10,000 private repositories.
The Internet Archive Breach – In October 2024, the Internet Archive fell victim to a major data breach affecting 31 million user accounts. Unsecured authentication tokens in their GitLab repository, which were left accessible for almost two years, were the cause of this incident. Threat actors exploited these tokens to gain access to critical systems, databases, and user data.
Cisco Breach – In October 2024, Cisco experienced a significant cybersecurity breach related to Non-Human Identities (NHIs). The threat actor ‘IntelBroker’ exploited exposed credentials, API tokens, and keys located in DevHub, Cisco’s public development environment.
CI/CD Pipeline Exploitation – In September 2024, a security researcher demonstrated how a series of flaws in a CI/CD environment resulted in a full server takeover. The attack started with an exposed .git directory, progressed through mismanaged CI/CD pipeline configurations, and ended up with unauthorized server access.
230 Million AWS Cloud Environments Compromised – In August 2024, many organizations fell victim to a large-scale extortion campaign targeting improperly configured cloud environments. Attackers exploited insecure environment variable files (.env) in these environments.
Hugging Face Breach – In June 2024, Hugging Face, considered a leading company and AI platform, announced a security breach targeting its Spaces Platform. The incident included unauthorized access to authentication secrets (API keys and tokens), which could lead to the compromise of sensitive data and disrupt workflows.
The New York Times Breach – In June 2024, the New York Times (NYT), a media powerhouse known for its reporting excellence, became the subject of headlines for an entirely different reason: a significant cybersecurity breach.
GitLocker Breach – In June 2024, GitHub users fell victim to an extortion campaign targeting their repositories. The threat actor gained unauthorized access to GitHub accounts using stolen credentials that seemed to be acquired from previous breaches.
Snowflake Breach – In May 2024, Snowflake fell victim to a major cybersecurity breach. The breach compromised data from major organizations, including Ticketmaster and Santander Bank, highlighting the weaknesses in cloud environments when lacking efficient security measures.
Dropbox Sign Breach – In May 2024, Dropbox Sign experienced a significant security breach. Attackers exploited a compromised backend service account, which granted them the ability to access the customer database, leading to the exposure of sensitive user data, including email addresses, usernames, hashed passwords, and account authentication details like API keys and OAuth tokens.
JetBrains Breach – In May 2024, a critical vulnerability (CVE-2024-37051) with a CVSS score of 9.3, was reported in JetBrains’ GitHub plugin for IntelliJ-based IDEs. This vulnerability exposed GitHub access tokens to malicious third parties.
Sisense Breach – In April 2024, Sisense reported a security breach from unauthorized access to Sisense’s self-managed GitLab instance, which led to the exfiltration of large amounts of data, including access tokens, API keys, passwords, and certificates.
Google Firebase Breach – In March 2024, security researchers discovered that misconfigurations in Google Firebase instances had exposed over 19.8 million secrets. Google Firebase is a popular Backend-as-a-Service (BaaS) platform used by developers to manage databases, storage, and authentication for their applications.
Microsoft Midnight Blizzard Breach – In January 2024, Microsoft detected a cyberattack planned by the Russian state-sponsored group Midnight Blizzard (also known as Nobelium or APT29). The attacker exploited a legacy, non-production test tenant account without multi-factor authentication (MFA).
Breach Deep Dive – NHIs and AI Intersections
Whilst there were many significant breaches in 2024 e.g. Snowflake, BeyondTrust etc, the one that particularly stood out for me was the AI LLM Hijack Breach given it used a breached AWS access key to hijack an AI LLM model to run rogue chatbot services for Dark Roleplaying. It shows what’s coming and why everyone is so concerned about AI security.
Overview
Whilst there were many significant breaches in 2024 (e.g., Snowflake, BeyondTrust), the one that particularly stood out for me was the AI LLM Hijack Breach. This breach used a compromised AWS access key to hijack an AI LLM model to run rogue chatbot services for Dark Roleplaying. It shows what’s coming and why everyone is so concerned about AI security.
In October 2024, Permiso Security reported a sophisticated cyberattack that revealed critical vulnerabilities in the infrastructure of cloud-hosted large language models (LLMs), such as AWS Bedrock, Anthropic, and Google Vertex AI. "LLMjacking," this emerging threat targets AI applications hosted on major cloud platforms, exploiting their inherent scalability and computational power for malicious purposes.
In this incident, the attackers used compromised AWS cloud access keys, often obtained through framework vulnerabilities or phishing schemes, to gain unauthorized control of these advanced AI systems. Using these credentials, they bypassed traditional security measures, invoking APIs such as InvokeModel and InvokeModelWithResponseStream to discreetly hijack AI resources.
The Rise of Hosted AI Models
Hosted AI models, like OpenAI’s GPT or similar platforms, are designed to respond to user prompts in natural and creative ways. Whether it’s helping someone write a story, debug code, or answer questions, these systems are versatile and accessible. However, their open-ended design is both a strength and a weakness. AI doesn’t understand morality or intent; it responds to inputs based on patterns it’s learned during training. This neutrality makes it vulnerable to exploitation by users seeking to push ethical boundaries.
What Is Dark Roleplaying?
Dark roleplaying occurs when users co-opt AI for scenarios that simulate harmful or unethical behavior. Think of it as a twisted form of storytelling where users prompt the AI to act out scenarios involving violence, abuse, or other morally questionable activities.
Examples of Dark Roleplaying
Simulating criminal activities, such as planning a heist or creating phishing schemes.
Generating graphic or violent narratives for entertainment or experimentation.
Creating fake conversations or scenarios used to harass or blackmail individuals.
What is LLMHijacking?
Imagine renting a car for a road trip, only to find someone else secretly using it for joyrides at your expense. This analogy reflects LLMHijacking, the exploitation of hosted Large Language Models (LLMs) like GPT or Bard by unauthorized users for malicious purposes. Attackers identify vulnerabilities in public or cloud-hosted LLMs, like misconfigured APIs or leaked credentials, and hijack access. Once inside, they exploit the stolen resources to generate phishing emails, obfuscated malware code, or even monetize it as underground AI services. Beyond financial theft, LLMHijacking empowers cybercriminals to scale attacks like never before.
Why do hackers perform LLM Hijacking?
Attackers hijack Large Language Models (LLMs) for several reasons, primarily centered around exploiting their computational power, bypassing security protocols, and generating malicious content.
Monetizing Hijacked AI Models
Once attackers gain control of a cloud-hosted LLM, they can resell access to the hijacked resources. This practice allows cybercriminals to monetize their stolen access. They can offer malicious services to other bad actors, such as automated content generation for phishing campaigns, crafting fake news or deepfakes, or even providing illegal material through the AI models, all without bearing the cost of operating the infrastructure themselves.
What Happened?
Initial Compromise: Credential Theft
Access Key Exploitation: Attackers acquired AWS access keys through techniques like phishing, credential stuffing, or exploiting publicly exposed keys in GitHub repositories.
Cloud Enumeration: Using stolen credentials, they identified accessible services, including AWS Bedrock. API queries like GetCallerIdentity helped attackers validate account access.
Probing Cloud Services
Validation of Permissions: Attackers employed unusual parameters in the InvokeModel API to probe AI model access without triggering outright denial errors. This method confirmed the existence of active AI models without raising alarms in conventional logging mechanisms.
Region-Specific Targeting: Knowing Bedrock was only available in specific regions, attackers tested operations selectively in us-east-1, us-west-2, and other supported regions, ensuring efficient use of their resources.
API Invocation and Reverse Proxy Setup
InvokeModel Usage: Attackers invoked the InvokeModel and InvokeModelWithResponseStream APIs to interact with and control AI models. Streaming responses enabled token-by-token real-time data extraction, optimizing their malicious workflows.
OAI Reverse Proxy Deployment: A reverse proxy server was established to route traffic through compromised credentials. This layer obfuscated attacker origins while efficiently managing multi-model deployments.
Model Jailbreaking
Jailbreaking Techniques: Exploiting vulnerabilities in model prompt design, attackers bypassed AI safeguards. They used prompt injection techniques sourced from underground forums, enabling LLMs to generate explicit or harmful content despite content filters.
Concurrent Requests: Custom scripts, often generated by the hijacked LLMs themselves, allowed attackers to automate interactions with multiple AI models, ensuring continuous content generation and extraction.
Monetization and Payload Delivery
Service Resale: Attackers monetized their access by selling unauthorized LLM usage to other cybercriminals. For example, generating synthetic scripts or creative outputs tailored for malicious intent.
Mass Invocations: Over 75,000 invocations were logged in a short period, almost all of a sexual nature, demonstrating industrial-scale misuse. Data was likely saved and organized for resale or direct criminal application.
Can This Be Prevented?
Enhanced Credential Management
API Key Protection: Secure storage of access keys is paramount. Environment variables should be used to store API keys instead of hardcoding them into the codebase. Furthermore, access keys should be rotated regularly, and the least privilege access policies should be enforced to limit the potential damage if keys are compromised.
Multi-Factor Authentication (MFA): MFA should be enabled for all cloud services to add an extra layer of security, ensuring that even if an access key is compromised, unauthorized users cannot gain full access.
Zero Standing Privileges (Ephemeral Secrets): Move away from static secrets to JIT secrets and transition to a Zero Trust model.
Advanced Access Controls and Monitoring
Role-Based Access Control (RBAC): Organizations should implement granular access control based on roles. Only authorized users should be granted permission to invoke models or access sensitive AI resources.
Real-Time Monitoring and Anomaly Detection: Tools that track and analyze the usage of cloud services can alert administrators to suspicious activities, such as unusual API requests or excessive invocation patterns. Advanced anomaly detection mechanisms should be deployed to flag potential hijacking attempts.
Logging and Auditing: Ensure that all actions performed by AI models and their interactions with cloud services are logged. Use services like AWS CloudTrail or Google Cloud Logging to monitor API calls, track access, and investigate suspicious events.
Secure API Design
Rate Limiting: Cloud providers should impose rate limiting on API calls to prevent abuse through rapid, large-scale requests that might strain resources or go undetected. If a service is invoked excessively in a short period, automated defenses should kick in to prevent further access.
Endpoint Security: Ensure all API endpoints are secured and properly authenticated, using protocols like OAuth2 or JWT tokens. This ensures that only authorized users or services can invoke models, mitigating the risk of external attackers using stolen keys.
Education and Awareness
Employee Training: Training teams to recognize phishing and credential theft techniques will reduce the risk of initial compromises. By building awareness of social engineering tactics and common attack methods, the organization can prevent attackers from gaining access in the first place.
Threat Intelligence Sharing: Organizations can collaborate with industry peers and share insights into new attack vectors, ensuring that they stay ahead of evolving LLM hijacking techniques.
Stronger AI Safeguards
Prompt Engineering: AI providers should enhance prompt engineering to detect and block attempts to bypass content moderation rules. By analyzing common bypass techniques and training models to recognize them, AI systems can be made more resistant to exploitation.
Conclusion
The LLM hijacking incident highlights a critical vulnerability in cloud-hosted AI systems. Cybercriminals exploiting stolen access keys and bypassing security safeguards, like jailbreaking AI models, have shown how easily these powerful tools can be weaponized for malicious purposes. This breach underscores the urgent need for enhanced security measures in AI and cloud environments. As AI continues to play a pivotal role in various sectors, securing these technologies is crucial to prevent further exploitation and maintain trust in their use.
To sum up, based on what we have shared in this Breaches section, we hope you walk away with a clear understanding of the huge risks and exposures around NHIs and why this is something you need to address now. It is very easy for both external and internal threat actors to discover, access, and compromise your systems or those of your integrated 3rd Party Supply Chains using NHIs, the number one threat vector from an identity standpoint, with over 80% of attacks involving NHIs.
4 - Key Research and Survey Results from 2024
Our NHI Mgmt Group and a number of other organisations have conducted major research and surveys that provide a stark view of the challenges and risks around NHIs. These findings align with the view we have held for many years, that this is probably the hardest security challenge organisations will face, given that it has become the number one identity security risk in the industry.
A key summary of the findings:
High Prevalence of NHIs – They outnumber human identities by 25x-50x. Organisations expect them to increase due to AI, etc., with 12.8 million occurrences detected on GitHub.com.
NHI Leaks & Attacks – 80% of identity breaches involved NHIs, and 79% reported secrets leaks. Compromised NHIs lead to successful cyber-attacks.
Defenses Lagging – There is a lack of rotation in a timely manner, over-privileged accounts, inadequate monitoring and logging, slow responses to secret leak exposure, and an inability to stop lateral movement.
Service Accounts – Managing service accounts is a significant challenge and the biggest concern. Most organisations rely on them and are seeing increased use.
3rd Party Exposure – Most organisations expose NHIs to 3rd parties, raising concerns that their security practices may not align. The majority say supply chain attacks are a clear and present danger.
Fragmented Approaches – Existing tools are not designed to address NHI challenges. Most organisations have multiple solutions and secrets managers but struggle with a unified approach to DevSecOps strategy.
Mismanaged NHIs – There is a large number of static credentials in code, often shared via email and messaging apps. Most have excessive privileges, weak encryption, are overused/shared, and vaults are misconfigured.
Addressing NHI Risks – Two-thirds don’t know how to fully address risks, and only 15% are confident in their ability to secure NHIs. Key challenges include discovering, assessing, auditing/monitoring NHIs. Only 6% have full visibility of their service accounts, and 20% have formal processes for offboarding API keys. Fewer have processes for rotating them, which is viewed as the most significant threat to NHI security.
Investment – Enterprises are investing disproportionately in NHI security. NHI spending is primed to increase significantly in many organisations, including investments in threat detection and response solutions.
Other – Breaches are getting board-level attention. AI poisoning attacks will become a new supply chain attack. IoT connections are projected to hit 83 billion by 2024 (70% in the industrial sector). Many different technology teams are involved in the NHI space, but normally security personas are the most common budget holders. Managing NHIs is essential for a successful zero-trust model.
The Full Details
High Prevalence of NHIs
A staggering 12.8 million occurrences detected on GitHub.com in the last year alone - a 28% increase from 2022. [4]
Half of the organisations expect the total number of NHIs to increase by more than 20% over the next 12 months. [5]
NHIs often outnumber human identities by a factor of 25x - 50x. [1]
NHI Leaks & Attacks
69% of organizations express moderate to high concern about NHIs as an attack vector. [3]
79% of organizations reported experiencing secrets leaks, with 77% of these incidents resulting in tangible damage to either the company, its employees, or both. [4]
Compromised NHI accounts frequently lead to successful cyberattacks, with approximately 66% of enterprises enduring a successful cyberattack from compromised NHIs and 25% of enterprises encountering multiple attacks. [5]
Defences Lagging
The most common causes of NHI-related attacks were lack of credential rotation (45%); inadequate monitoring and logging (37%); and over-privileged accounts/identities (37%). [3]
Zombie Leaks - A huge 91.6% of secrets remain valid five days after the targeted organization is notified, showing a significant gap in remediation procedures. [4]
The average estimated time to remediate a leaked secret stands at 27 days. [4]
78% of organizations aren’t confident they can stop an attacker performing lateral movement with compromised credentials. [8]
71% of non-human identities are not rotated within the recommended time frames, increasing the risk of compromise over time. [2]
Service Accounts
Managing service accounts is a significant challenge, with 32% of organizations highlighting it as a major pain point. [3]
57% of respondents were most concerned about service accounts, followed by 28% for API keys/tokens, 8% for Robotic RPA bots, and 7% for IoT devices. [1]
99% of teams rely on service accounts, but 83% find managing multiple service accounts adds complexity. [9]
45% of teams increased their use of service accounts and diversified their cloud providers. [9]
3rd Party Exposure
92% of organizations are exposing NHIs to third parties, risking unauthorized access if third-party security practices are not aligned with organizational standards. [2]
84% of teams say software supply chain attacks continue to be a clear and present danger. [9]
Visibility into third-party vendors connected by OAuth apps is limited, with 38% of organizations reporting no or low visibility. [3]
Fragmented Approaches
Existing tools are not specifically designed to address NHI security challenges. [3]
58% use Identity and Access Management (IAM) systems.
54% use Privileged Access Management (PAM).
40% use API security measures.
38% employ Zero Trust/least privilege strategies.
36% use Secrets Management tools.
Most enterprises invest in multiple solutions for various aspects of non-human identity management, revealing a lack of motion toward platform unification at this point. [5]
Organizations maintain an average of 6 distinct secrets manager instances. [4]
52% of teams struggle to find a unified approach to effectively embrace a DevSecOps strategy. [9]
While 51% of respondents use cloud provider IAM tools for non-human identities, 38.9% still rely on less secure methods like secrets managers. [6]
Mismanaged NHIs
97% of NHIs have excessive privileges, increasing unauthorized access and broadening the attack surface. [2]
At least 25% of organizations cited weak encryption algorithms, exposed keys or secrets, and/or loosely managed service accounts. [5]
46% of service accounts regularly use weak authentication protocols (NTLM), leaving them open to credential theft and abuse. [8]
60% of NHIs are being overused, with the same NHI being utilized by more than one application, increasing the risk of a single point of failure and widespread compromise if exposed. [2]
73% of vaults are misconfigured, leading to unauthorized access and exposure of sensitive data and compromised systems. [2]
Alarmingly, 30.9% of organizations store long-term credentials directly in code, 23.7% share secrets by copying and pasting via email or messaging apps, and 15.5% use manual spreadsheets to store secrets. [6]
Addressing NHI Risks
68% of respondents said they don’t know how to fully address NHI risks. [1]
There is a significant gap in organizations' security methods, with only 1.5 out of 10 organizations highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities. [3]
Key challenges in managing the risks: 25% flagged auditing and monitoring, 25% flagged understanding access and privileges, and 24% flagged discovering NHIs. [3]
Only 5.7% of organizations have full visibility into their service accounts, leaving a huge percentage of organizations with unknown NHIs. [8]
89% of organizations faced challenges managing secrets at scale in cloud-native environments. [9]
83% believe failing to secure operations at the workload level renders other security measures obsolete. [9]
Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. [3]
IAM Maturity Gap: A significant 88.5% of organizations admit their non-human Identity and Access Management (IAM) practices lag behind or are merely on par with their user IAM efforts. [6]
Only 19.6% of respondents express strong confidence in their non-human IAM practices, while 23.7% report little to no confidence. [6]
The lack of regular key rotation is the most significant threat to non-human identity security, identified by 29.6% of respondents. [6]
Investment
Enterprises are investing disproportionately to solve non-human identity security. [5]
24% of organizations plan to invest within the next six months, and 36% within the next 12 months. [3]
Non-human identity security spending is primed to increase—a notable 83% of organizations expect to spend relatively more on non-human identity security, with nearly one in five expecting to spend significantly more. [5]
40% of organizations expect to increase spending on identity threat detection and response solutions. [5]
39% will prioritize investments in technologies designed to address visibility, monitoring, and remediation for non-human identities. [5]
Other Findings
Policies/Standards: Only 44% of developers are reported to follow security best practices. [4]
Organisational Management of NHIs Controls/Processes: Security personas (32%) are the most common budget holders. A diverse set of constituents across technology teams from DevOps, Cloud Security, SecOps, and cloud applications contribute to evaluating, recommending, and purchasing solutions. [5]
Board Level Attention: 57% of non-human identity compromises definitively got board-level attention, with 37% of respondents indicating their organization’s board may have delved into the details of the incident. [5]
Operational Technology: IoT connections are projected to hit 83 billion by 2024, with over 70% in the industrial sector. [7]
Artificial Intelligence: 77% of IT security leaders believe AI poisoning attacks will become the new software supply chain attack. [9]
Zero Trust: Approximately 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
References:
1 – NHI Mgmt Group - Non-Human Identity - Industry Polls
2 – Entro Security – 2025 State of Non-Human Identities and Secrets in Cybersecurity
3 – CSA & Astrix Security - The State of Non-Human Identity Security
4 – GitGuardian – The State of Secrets Sprawl in 2024 and The State of Secrets in App Sec
5 – ESG and Oasis Security – 2024 ESG Report: Managing Non-Human Identities
6 – Aembit – 2024 Non-Human Identity Security Report
7 – Corsha – Challenges & Solutions in OT to IT Security – White Paper
8 – Silverfort – Identity Underground Report March 2024
9 – Venafi – The Impact of Machine Identities on the State of Cloud Security Native Security in 2024
5 - Lifecycle Processes for Managing NHIs
So what are the key lifecycle processes required to manage NHIs? Based on my original white paper, below I describe the key lifecycle processes involved in managing and securing NHI risks.
1 - Provisioning and Decommissioning
JML processes are typically quite weak in most organisations when it comes to NHIs. Static NHIs are created through many different and disparate provisioning processes, and in many cases, the credentials (e.g., passwords) are shared directly with the requestor of the NHI (i.e., a human), leading to broader issues around the inappropriate use of NHIs by humans.
Provisioning – You will need to think about provisioning NHIs in a secure way:
For static NHIs, these should ideally be fed directly into a secrets vault, without any human intervention or visibility.
For dynamic NHIs, these are typically secure by design as they are provisioned just in time.
Decommissioning – For static secrets, it’s important to have clear decommissioning/offboarding processes. For example, if the account is no longer used or when people have left/transferred, they may still know the credentials (passwords, keys, tokens), which could be compromised either in their new role or externally in Cloud/SaaS environments.
Recertification – In particular for static secrets, recertification processes are also critical to ensure NHIs are still valid and required. This is further covered in the Hygiene – Posture management section.
2- Discovery & Inventory
This is probably the most important thing to focus on, especially when you are starting out a NHI program, as it allows you to understand the size of the problem and then help drive remediation activities.
This can, however, be one of the biggest challenges, as NHIs typically don’t exist in a centralised Identity Management system with a full inventory of identities/accounts. You will typically need to deal with multiple identity providers, directory services, and local accounts across Hybrid-Cloud, SaaS, and On-Prem environments.
NHIs defined in a Directory Service like Active Directory are much easier to inventory and manage compared to local accounts defined directly on a platform (e.g., on an operating system or database). Locally defined NHIs will typically require custom feeds to be built, which can take a significant amount of time and effort to develop.
Scanning – Another important aspect is to scan for plain-text/unencrypted credentials in source code repositories as well as other repositories like SharePoint, Confluence, file systems, etc. Any credentials exposed in these repositories can be easily discovered by both external and internal threat actors.
While you may be able to identify plain-text/unencrypted credentials, understanding their content can be challenging. Typically, scanning solutions will let you know a credential has been found, but it won’t tell you the context of that credential, such as what is the identity of that account (name) and where it is used (e.g., a local account on a database).
3 - Classification
Another key step is to fully classify NHIs in terms of key attributes and metadata. Once you have this metadata, you can understand the overall risk associated with the NHI based on the level of privilege and breadth of access.
Ownership – Assigning an owner is critical to ensure there is clear accountability for the NHIs, especially when driving risk reduction and remediation activities. An organisation should not underestimate the effort associated with claiming ownership for NHIs. Many accounts may not be known to the current incumbents or could be used by other teams (e.g., upstream and downstream components). We have seen many global programs where it has taken multiple years to fully claim ownership for NHIs.
Note – I see many folks in the industry talk about mapping a human owner to an NHI, but I would argue you need to map an NHI to an application/service (which indirectly has owners) as this ensures ownership of the NHI does not need to change due to personnel changes in a team.
Levels of Privilege – Understanding the level of privileges granted to an NHI is very important, i.e., does it have full admin, write, or read access, etc. Understanding the levels of privilege can be very challenging as you may need to understand the entitlement model.
Breadth of Access – What is the breadth of access for the account? Is the account entitled to just one asset/component, or is it entitled to hundreds/thousands of assets/components? Clearly, the more assets it has access to, the higher the risk of the account.
Account Usage – If an organisation can determine whether the account is in use, this can drive hygiene activities to remove legacy/inactive accounts and achieve quick wins in driving down the surface area of risk. For some platforms/account types, this is straightforward as account usage data is readily available (but needs to be extracted), but for others, it is quite complex (needs to be extracted from endpoints) or does not exist.
4 - Hygiene - Posture Management
A key part of any NHI program is to drive hygiene activities, known in the industry as Posture Management.
Excessive Permissions – While NHIs are often highly privileged, many end up being over-privileged and should follow the principles of least privilege.
Inactive Accounts – Given NHIs typically have very weak lifecycle processes, many remain inactive and should be removed to reduce the surface area of risk. We have worked at various financial institutions where over 50% of the
Shared Accounts – Another big issue is NHIs being shared across applications, which breaks principles of Segregation of Duties (SoD) and least privilege. Sharing causes many issues when NHIs need to be secured and cycled or hygiene activities are being performed, as you could cause operational impact by not fully understanding all the dependencies.
Environment Segregation – Another key issue we see across organisations is the same NHI being used across production and non-production environments, leading to lateral movement risks, etc.
5 - Securing / Protecting Credentials
Remediation of NHI risks can take a number of forms.
Encryption – Migrating away from plain-text credentials to encrypted credentials with encryption keys being securely managed.
Passwordless Credentials – Moving away from password authentication to passwordless credentials like certificates can be another way to address security risks.
By far the most common method to secure credential risks is to migrate plain-text/unencrypted passwords to a secrets vault.
Vaulting – A critical strategy for securing credentials is to migrate any plain-text/unencrypted credentials from source code repositories into a secrets vault. This is no small undertaking and will need to handle global scale, high volumes, and provide a resilient/fault-tolerant capability.
There are various integration patterns that need to be supported given an organisation will have both strategic and legacy applications, i.e., Runtime, Agent-Based, Build/Deploy Time patterns, etc., each with pros and cons from a control effectiveness and cost/effort standpoint. Other key considerations include how credentials are onboarded onto the vault, i.e., via centralised account inventory feeds or manually by application teams.
Account namespace definitions will need to be established to appropriately describe the credential type/instance being onboarded, to support future processes like managed password cycling, reporting, etc.
Cycling / Rotation – There are many benefits to passwords being cycled as it reduces risks around transfers, leavers, mitigates/removes credential exposure in legacy code/scripts (including version history), helps uncover unknown dependencies and sharing of credentials, etc.
Password cycling is incredibly challenging given the above risks—if the dependencies are not known in advance, i.e., all scripts/code that use the credential (including sharing of the credentials by other applications), there is an elevated risk of operational impact of applications breaking when a password is cycled.
Cycling cannot be considered in isolation—there needs to be a sustainable solution for automating the cycling activities (manual cycling does not scale or is repeatable) and tightly coupled to an organisation's Secrets Vault capability that needs to support cycling.
6 - Monitoring Controls – ITDR
This is one of the most challenging areas to deliver a strong and effective control, but one of the most critical, given an external/internal threat actor will always find a way to discover and misuse an NHI credential.
Unfortunately, there is no one-size-fits-all product that you can just onboard and deploy to your environment. There are challenges around the sheer volume of events, the multitude of platforms/NHIs you need to monitor, each with their own maturity/availability of metadata, and the biggest challenge by far is “seeing the wood from the trees” and dealing with false positives.
Organisations should consider Intelligence and Behaviour Analytics capabilities (i.e., UEBA tools) to develop a scalable and sustainable solution, as it is not possible or practical to look at every single event that could be a violation and instead look at outliers/anomalies as a more effective way to manage the risk.
There will be more fundamental challenges an organisation will need to deal with around why humans are using NHIs, e.g., cases deemed by teams to be valid/BAU which need to be understood, rooted out/stopped; otherwise, it becomes an impossible task to see the wood from the trees.
7 - Prevent Controls
As you mature your capabilities and controls around managing NHIs, you need to target more strategic preventative controls, including moving towards a zero-trust model. Note that many of these areas are in the early stages of maturity, but are areas you should consider as part of your overall strategy to “stop the bleeding.”
Stop Check-In of NHIs – A key preventative control as part of a DevSecOps shift-left strategy is to ensure at code check-in time, the code is scanned for secrets and if found, the check-in is blocked.
JIT - Ephemeral Secrets – Migrating away from static to dynamic secrets, e.g., Just-In-Time (Ephemeral Secrets) as part of workload identity management, will stop threat actors from taking advantage of NHIs.
Real-Time Threat Protection – While many Detect and Response solutions are more reactive in nature (i.e., post-event), there is a clear direction in the industry to move towards a real-time threat protection model. Using a combination of anomaly detection and policy enforcement rules against, for example, a control plane or transport layer, they can in real-time detect and block inappropriate access. Some examples include:
Identity Control Plane – Monitoring, controlling, and preventing policy violations on a Domain Controller in Active Directory – as used in the Silverfort platform.
Workload Attack Surface Protection – Another emerging technique that can be considered is to leverage Mutual TLS (mTLS), a security protocol typically used to authenticate between processes/workloads. This combined with actual NHI tracking/usage/discovery, anomaly detection techniques, and policy enforcement rules can help detect and block unknown or inappropriate access – as used in the TrustFour platform.
6 - Static vs. Dynamic Secrets
As we have stated earlier in our research report, the main root cause of the issues and risks associated with NHIs is due to the fact that the vast majority today are static in nature. There is a lot of talk in the industry at the moment around Zero Standing Privileges (ZSP), Ephemeral Just-In-Time (JIT) Secrets, and Zero Trust.
Static Secrets – Long-lived credentials that remain unchanged for extended periods.
Advantages: Simple to implement and integrate, compatible with legacy systems, and require minimal computational resources.
Issues: High security risks due to long-term exposure. If compromised, attackers can gain indefinite access. Difficult to audit and track due to widespread distribution.
Mitigation: Remove hard-coded credentials from source code; use centralized secrets vaults; rotate secrets regularly; remove inactive accounts to reduce the surface area of risk.
Dynamic Secrets – Short-lived, automatically generated credentials that provide temporary access to resources.
Advantages: Enhanced security due to short lifespan, reducing the risk of unauthorized access. Supports zero-trust principles through zero-standing privileges (ZSP).
Issues: More complex and costly to implement and manage compared to static secrets; outage risks given high availability dependency on identity issuing systems; maturing space; many legacy systems cannot support dynamic secrets.
Mitigation: Use automated tools and platforms for generating and managing dynamic secrets.
Whilst everyone will agree that moving to dynamic ephemeral secrets is where we need to be heading as an industry, in practice, it is not that simple for a number of reasons:
The approach, standards, and solutions around a zero-trust model for NHIs are maturing.
For most organisations, this is likely to be a massive undertaking and investment.
Given the huge secrets sprawl problem, hyper fragmentation, legacy platforms, products, and many 3rd party external dependencies, this is not something that can be implemented enterprise-wide, given the differing levels of maturity across the industry.
Organisations will need to take a balanced approach, focusing on getting control of their current risk exposure using a risk-based approach, while looking at strategic solutions and capabilities to stop the bleeding.
7 - Regulatory and Audit Perspective
Having worked in the Financial Industry for over 30 years, I have been at the coalface, engaging and dealing with all the major regulators and external auditors (PWC, Deloitte, EY, and KPMG) around the world in the NHI/IAM/PAM areas.
US – Federal Reserve (FED)
HK – Hong Kong Monetary Authority (HKMA)
SG – Monetary Authority of Singapore (MAS)
UK – Prudential Regulation Authority (PRA) and Financial Conduct Authority (FCA)
IN – Reserve Bank of India (RBI)
CH – Swiss Financial Market Supervision Authority (FINMA)
With respect to regulatory and audit focus on NHIs, I can say the focus has increased substantially over the last 2-3 years. In particular, if you are in the financial industry and don't have a program to manage NHI risks at the moment, you could get caught out very soon. We strongly urge you to get in front of this, as dealing with a regulatory program around NHIs will hit you very hard indeed from an investment and risk mitigation standpoint.
Previously, regulators and auditors focused on human controls, looking at things like Privileged Access Management (PAM), Developer Access to Production, and Segregation of Duties (SoD).
In recent years, I have personally seen that both regulators and auditors have started asking very specific questions around the controls you have in place for NHIs. A number of them, as part of broader industry-wide cyber threat assessment exercises, perform red-team exercises that regularly end up identifying NHI risks, particularly around hardcoded/unencrypted credentials in source code.
At a high level, the key controls they have been asking about are:
Plain-text/unencrypted credentials in source code and other repositories.
Cycling/rotation of credentials.
Monitoring controls, e.g., detecting inappropriate access, particularly humans using NHIs.
Most organisations are likely to have very weak or no controls around these areas, and it is very easy for regulators and auditors to identify these security weaknesses, particularly around hardcoded / unencrypted credentials, as these are very easy to discover and likely exist in every organisation.
Key Regulations and their NHI Impact
Below are some of the key regulations that exist in the industry today, which have significant implications for managing NHIs within an organisation:
The Sarbanes-Oxley Act (SOX) – Requires publicly traded companies to implement internal controls to ensure the accuracy and integrity of financial reporting. This includes testing and documenting evidence of these controls regularly, in some cases every quarter.
The Payment Card Industry Data Security Standard (PCI DSS) – Has long served as the foundation for organizations handling payment card data, ensuring robust security measures are in place to protect sensitive information. The release of PCI DSS version 4.0 on March 31, 2022, marked a significant evolution in the standard, introducing requirements and emphasizing areas that were previously under-addressed.
The Digital Operational Resilience Act (DORA) – A regulation introduced by the European Union to strengthen IT security frameworks across the financial sector. With the introduction of DORA, financial institutions are now required to follow stringent guidelines for safeguarding against Information and Communication Technology (ICT) related incidents. These include measures for protection, detection, containment, recovery, and repair. DORA explicitly targets ICT risks, introducing clear rules for ICT risk management, incident reporting, operational resilience testing, and oversight of ICT third-party risks.
ISO/IEC 27001 – This international standard provides a framework for information security management systems (ISMS). It helps organizations manage the security of assets such as financial information, intellectual property, employee details, and information entrusted by third parties. Non-human identities, such as digital certificates and API keys, fall under the scope of this standard.
The General Data Protection Regulation (GDPR) – Applies to the European Union and has significant implications for non-human identities. While it primarily focuses on personal data protection, it also impacts how organizations manage data generated by automated systems, such as AI and IoT devices. Organizations must ensure transparency and accountability in their data processing activities, regardless of whether the data pertains to human or non-human identities.
SOC 2 (System and Organization Controls 2) – A cybersecurity framework developed by the American Institute of Certified Public Accountants (AICPA). It focuses on protecting customer data and ensuring that organizations follow best practices in information security. SOC 2 compliance is achieved through an audit that evaluates an organization's controls based on five Trust Service Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. Non-human identities need to be properly secured and monitored to ensure processing integrity and prevent unauthorized access to sensitive and personal data.
Regulatory Deep Dives
Deep Dive 1 – SOX
Non-human identities (NHIs), such as service accounts, bots, and automated processes, play a crucial role in these controls. Given SOX is concerned about the impact on books and records, based on my experience, the focus is typically on NHIs with “write” privileges.
Whilst I don’t believe there is a formal set of requirements specifically on NHIs, they are covered in a broader set of IT controls. The key ones relevant to NHIs are listed below, with my interpretation of what I believe they mean from an NHI standpoint:
Access Management Controls
Strong password policies, including cycling/rotation for NHIs
JML processes, including access reviews and revocation processes for NHIs
Segregation of Duties (SoD) & Least Privilege
Segregation of NHIs across environments to prevent lateral movement
Separate NHIs for each application
Ensuring NHIs only have the permissions required to perform their duties
Audit Logs and Monitoring
Ability to monitor the inappropriate use of NHIs to impact books and records
Privilege Access
Ensure humans are not using NHIs to bypass human PAM controls
Change Management Controls
Ensure NHIs are not used to bypass change management controls
SoX is probably one of the oldest regulations in the industry and something I have had to deal with on numerous occasions at various global investment banks. Below, I share two real-life examples of dealing with SOX/Audit control requirements over 20 years ago and how they are still very relevant today.
Example 1: My first exposure to SOX was over 25 years ago at an investment bank within the Equities division, dealing with the opposite of the secrets sprawl problem, as you can see in my article Who Says We Have a Secrets Sprawl Problem.
Within the Equities division, we had just one Solaris Technical Account (NHI) that was used to run the entire equities infrastructure and applications, including production and non-production (covering approximately 1,000 applications), and approximately 1,000 staff had sudo (su) impersonation access rights to this technical account. This was flagged as a major Segregation of Duties (SoD) issue, so what did we do?
Each application ended up having its own set of NHIs.
We segregated NHIs—one per environment to prevent lateral movement between environments.
Each account had an environment postfix, e.g., trading_prod, trading_qa, trading_dev.
Unfortunately, 25 years on, the world has not changed much and has instead gotten worse with the huge secrets sprawl problem we now see:
Many NHI credentials are still shared across environments.
Many NHI credentials are still shared across applications.
Many plain-text/unencrypted credentials are found in source code repositories.
Organisations are still struggling to rotate/cycle NHI credentials.
Example 2: My second exposure to SOX was over 20 years ago at the same investment bank, where there was a key SOX control requirement around ensuring production database technical accounts (NHIs) with “write” privileges had their passwords cycled every 180 days.
This ended up becoming a major challenge for a number of reasons:
Passwords were hardcoded in application source code.
Cycling a password would require coordinating updates in many scripts, with a huge risk of operational impact if all the dependencies were not understood.
Credentials were shared across applications, making cycling more challenging.
No password vault solutions really existed in those days.
As a result, application teams struggled to meet this control requirement on a quarterly basis, and it became a major SOX control issue for the organisation. I was lucky (or unlucky) enough to end up having to run a huge global program to mitigate the risk exposure.
One of my claims to fame many years ago was that I built a rudimentary password vault-type solution that allowed teams to remove hardcoded passwords from their scripts and deal with complex challenges of resiliency, dealing with staggered password changes through retry logic to first try the new password then the old password, etc. It’s scary to see that 20 years on, some of the major vault solutions don’t even offer some of these capabilities!
Given the SOX focus was on database technical accounts with “write” privileges, we decided to focus on over-privileged accounts. By leveraging usage metadata available on Sybase databases, we found that over 80% of the database accounts that had “write” privileges were actually only performing “read” actions and were therefore over-privileged. I ended up devising a common “read” and “write” metadata model on all of our databases, and our team went on to migrate thousands of NHI accounts from “write” to “read” privileges. By doing this huge hygiene exercise, we were able to massively reduce the surface area of risk and the requirement to cycle passwords of DB technical accounts with “write” privileges.
A number of years later, a huge Regulatory audit flagged major issues with environment segregation, which also covered control issues around NHIs. The cycling/rotation problem now manifested itself company-wide. I ended up running a huge global IT regulatory program, including dealing with the password cycling challenge. Based on what we had done a few years earlier within the Equities division, I educated our C-Level execs on the huge challenges with rotating passwords regularly on databases.
We did a rinse and repeat exercise, looking for over-privileged “write” accounts and converted many to “read” thus reducing the surface area of risk and cycling requirements significantly.
We also looked at “inactive” accounts on our Sybase databases. After developing a global solution to collect and assess millions of database accounts on thousands of databases across production and non-production, we identified over 1 million accounts (yes, one million accounts, both human and non-human) that appeared inactive. Over 18 months, we drove a huge hygiene program to delete these accounts, which also massively reduced the surface area of risk and requirements to cycle passwords.
The final recommendation I made was to move away from password authentication and instead use passwordless Kerberos authentication to connect to Sybase DBs. This again became a massive global undertaking, with millions of dollars spent upgrading, migrating, and deploying application code to support Kerberos authentication. The earlier work we did to remove inactive accounts not only reduced the surface area of risk but also significantly reduced the number of accounts we had to move to Kerberos authentication.
It is scary to see that 20 years on, we still have all these issues, but now the challenge is significantly worse due to the huge secrets sprawl problem we have described earlier.
Deep Dive 2 - PCI-DSS
The release of PCI DSS version 4.0 on March 31, 2022, marked a significant evolution in the standard, introducing requirements and emphasizing areas that were previously under-addressed. One such critical area is the management of Non-Human Identities—service accounts, application accounts, APIs, and automated scripts that interact with cardholder data environments (CDE) or critical systems.
In a conversation with Vincenzo Iozzo, CEO at SlashID, he delves into the specific challenges companies face regarding non-human identities in PCI DSS v4.0 and explores strategies to overcome them. Full details can be found in his blog post.
PCI DSS v4.0 introduces several new mandates aimed at enhancing the security of non-human identities:
Unique Identification: Each non-human entity must have a unique ID to ensure accountability (Requirement 8.2.2).
Secure Authentication: Strong authentication methods must be implemented, avoiding hard-coded passwords (Requirement 8.6).
Credential Management: Authentication credentials must be securely managed and rotated regularly (Requirement 8.3.5).
Least Privilege Access: Access rights should be limited to the minimum necessary (Requirement 7.1).
Regular Review and Deprovisioning: Access rights must be periodically reviewed, and unnecessary accounts removed (Requirements 7.2.5 and 8.1.4).
Monitoring and Logging: Activities of non-human accounts must be logged and monitored (Requirement 10.2.1).
Secure Transmission: Credentials must be transmitted using strong cryptography (Requirement 8.5.1).
Cryptographic Key Protection: Cryptographic keys must be securely managed (Requirement 3.5).
Avoid Hard-Coded Credentials: Hard-coded passwords in code or scripts are prohibited (Requirement 8.6.1).
Segregation of Duties: Non-human accounts must not have conflicting responsibilities (Requirement 10.4.1).
The Challenges Companies Are Facing meeting PCI DSS requirements:
Identifying and Managing Non-Human Accounts – Many organizations lack a comprehensive inventory of non-human accounts, which proliferate in complex IT environments. Without unique identification, accountability and traceability are difficult, increasing risks of unauthorized access and non-compliance.
Eliminating Hard-Coded Credentials – Hard-coded credentials in scripts and applications are commonly used for convenience but pose significant security risks. Embedded credentials are prone to exposure, violating PCI DSS requirements.
Implementing Strong Authentication Methods – Legacy systems may not support modern authentication mechanisms like API tokens or certificates. Outdated methods weaken security and hinder compliance.
Secure Credential Management and Rotation – Manual credential management is time-consuming and error-prone. Infrequent rotation and insecure storage increase breach risks.
Enforcing Least Privilege Access – Non-human accounts often have broad permissions for operational ease. Over-privileged access increases risk and violates the principle of least privilege.
Regular Review and Deprovisioning of Accounts – Tracking access rights for all non-human accounts is difficult without automation. Orphaned or unnecessary accounts create vulnerabilities.
Comprehensive Monitoring and Logging – Existing logging systems may not capture non-human account activities across platforms. Insufficient monitoring delays incident detection and response.
Secure Transmission of Credentials – Ensuring secure credential transmission in mixed legacy and modern environments is challenging. Unsecured transmission can result in breaches and compliance failures.
Protecting Cryptographic Keys – Securely managing cryptographic keys throughout their lifecycle requires specialized tools. Compromised keys can lead to unauthorized decryption of sensitive data.
Conclusion
Meeting PCI DSS v4.0 requirements for Non-Human Identities is complex but essential. A strategic approach, combining audits, automated tools, and robust policies bridges the technology gaps and strengthens security. By prioritizing these efforts, organizations can achieve compliance and bolster their overall security posture.
8 - Standards
One thing that is very clear and evident from our report is that managing NHIs is not a mature discipline. Given the complexity of dealing with Non-Human / Machine / Workload Identities, a number of standards have evolved or are starting to evolve, primarily in the space of Zero Trust, covering Just-In-Time (JIT) ephemeral credentials for Workload Identity Management. These standards collectively aim to enhance the security, efficiency, and interoperability of Non-Human Identities.
Below we share a number of the key standards that exist or are evolving:
SPIFFE/SPIRE - spiffe.io
SPIFFE (Secure Production Identity Framework for Everyone) and SPIRE (SPIFFE Runtime Environment) is a set of open-source standards for providing secure, cryptographic identities to workloads across various platforms.
SPIFFE: Defines a framework and set of standards for identifying and securing communications between application services. It aims to provide strongly attested, cryptographic identities to workloads.
SPIRE: A production-ready implementation of the SPIFFE APIs. It performs node and workload attestation to securely issue SPIFFE IDs (SVIDs) to workloads and verify the SVIDs of other workloads.
Use Cases: SPIFFE and SPIRE are used for secure microservices communication, cross-service authentication, and bridging the gap between different platforms like Kubernetes.
Benefits: They enable defense in depth, reduce operational complexity, and ensure consistent, automated management of identity.
WIMSE (Web Infrastructure Machine Security Ecosystem, IETF) - ietf.org
WIMSE is an emerging standard being developed by an IETF working group that enhances the security of machine identities and communications over the web. It aims to standardize protocols for secure machine authentication and communication, ensuring that machine identities are managed and verified securely in web-based environments. WIMSE focuses on fine-grained access control across platforms in public and private clouds.
The WIMSE working group focuses on:
Propagation, representation, and processing of workload identities.
Authentication and authorization for software workloads in various runtime environments.
Managing complex contexts, such as user identity, software origin, and hardware-based attestation.
SPICE (Simple Protocol for Independent Computing Environments, IETF) - ietf.org
SPICE is an IETF initiative to simplify and secure communication between isolated computing environments. It facilitates secure machine-to-machine communication in multi-tenant and cloud-native architectures by providing a protocol for remote access to virtual environments. SPICE ensures that data channels are encrypted and authenticated, enhancing the security of remote interactions.
OpenID Connect Adaptations for M2M Authentication (OpenID Foundation) - cncf.io
OpenID Connect for M2M Authentication extends the OpenID Connect protocol to support authentication between machines, devices, or applications without human intervention. Here are some key points:
Secure Authentication: Ensures that machines can securely authenticate each other using tokens and credentials, reducing the risk of unauthorized access.
Interoperability: Promotes interoperability between different systems and applications, making it easier to integrate and manage M2M authentication.
Use Cases: Common use cases include automated processes, IoT devices, microservices, and cloud-native applications that need to securely communicate and access resources without human involvement.
FDO (FIDO Device Onboarding) - fidoalliance.org
FIDO Device Onboarding (FDO) is an automatic onboarding protocol developed by the FIDO Alliance for edge nodes and IoT devices. Here are some key points:
Automatic Onboarding: FDO automates the process of installing secrets and configuration data into a device, enabling it to securely connect and interact with cloud and edge management platforms.
Zero-Touch Provisioning: FDO supports zero-touch provisioning, meaning devices can be onboarded without manual intervention.
Late Binding: Devices can be manufactured identically and then "late bound" to a specific management platform using a digital proof of ownership called an "Ownership Voucher."
Security: FDO ensures secure onboarding by cryptographically verifying device ownership and authenticating devices.
Flexibility: The protocol supports a wide range of processors and operating systems, making it versatile for various applications.
FDO is designed to simplify and secure the deployment of edge and IoT devices at scale, providing a robust solution for managing device lifecycles.
SPIFFE/SPIRE - Deep Dive
The SPIFFE/SPIRE framework is probably one of the most mature frameworks for workload identity management, and a number of vendors and organisations have started to adopt this framework.
The SPIFFE (Secure Production Identity Framework for Everyone) and SPIRE (SPIFFE Runtime Environment) open-source projects provide a comprehensive framework and runtime environment for managing identities in a cloud-native ecosystem.
What is SPIFFE?
SPIFFE, short for Secure Production Identity Framework for Everyone, is an open standard for securely authenticating software services in dynamic and heterogeneous environments. It provides a set of specifications for identifying and verifying workloads in a standardized manner.
Key Features of SPIFFE:
Universal Identity Management: SPIFFE provides a consistent identity format across different environments, such as on-premises, cloud, or hybrid setups.
Workload Authentication: By using SPIFFE IDs, workloads can authenticate each other without relying on IP addresses or DNS names, which can be mutable and insecure.
Interoperability: SPIFFE ensures interoperability across various platforms and technologies, promoting a unified approach to identity management.
How SPIFFE Works:
At the heart of SPIFFE is the SPIFFE ID, a unique identifier assigned to each workload. These IDs are presented as URIs (Uniform Resource Identifiers), which follow a standard format, making them universally recognizable. Workloads use SPIFFE IDs to establish mutual TLS (mTLS) connections, ensuring secure and encrypted communications.
Introducing SPIRE:
SPIRE, or SPIFFE Runtime Environment, is the reference implementation of SPIFFE. It provides the necessary infrastructure and runtime components to implement SPIFFE specifications in real-world environments.
Key Features of SPIRE:
Dynamic Registration: SPIRE supports the dynamic registration of workloads, making it suitable for environments where services are constantly scaling up or down.
Pluggable Architecture: SPIRE’s architecture is highly extensible, allowing it to integrate with various authentication backends and data stores.
Workload Attestation: SPIRE ensures that only verified workloads are assigned SPIFFE IDs through an attestation process, which can include factors such as workload identity, hardware security modules (HSMs), and cloud provider metadata.
How SPIRE Works:
SPIRE consists of two main components:
SPIRE Server: This is the control plane, responsible for issuing and managing SPIFFE IDs. It handles workload registrations, policies, and attestation mechanisms.
SPIRE Agent: This is the data plane, deployed alongside workloads. It fetches and renews SPIFFE IDs and handles the local attestation of workloads.
The interaction between SPIRE Server and SPIRE Agent ensures that workloads are dynamically identified and authenticated, maintaining a secure and scalable identity management system.
Benefits of SPIFFE and SPIRE:
Enhanced Security: By decoupling identity from underlying infrastructure, SPIFFE and SPIRE reduce the risk of identity spoofing and other attacks.
Scalability: Suitable for cloud-native environments, they support dynamic scaling and microservices architectures.
Interoperability: Ensures consistent identity management across diverse environments and technologies.
Reduced Complexity: Simplifies identity management by providing a standardized approach, reducing the need for custom solutions.
Real-World Applications:
Microservices Security: Ensuring secure communication between microservices in a Kubernetes environment.
Zero Trust Architectures: Implementing zero trust principles by verifying and authenticating every workload and service request.
Hybrid Cloud Environments: Managing identities across hybrid cloud setups seamlessly, ensuring consistent security policies.
Getting Started with SPIFFE and SPIRE:
To begin with SPIFFE and SPIRE, start by exploring the official SPIFFE and SPIRE documentation.
Conclusion:
SPIFFE and SPIRE offer a robust framework for managing identities in modern IT infrastructures. By providing standardized and secure identity management, they help organizations enhance security, streamline operations, and adapt to the dynamic nature of cloud-native environments. As the digital landscape continues to evolve, adopting solutions like SPIFFE and SPIRE will be crucial for maintaining secure and resilient IT systems.
9 - The NHI Market
Investment and Growth in the Non-Human Identity Market Have Exploded in the Last 12-18 Months
The first main batch of NHI vendors started to appear in the market approximately 3 years ago (although a few appeared even earlier).
The last 18 months have seen an explosion in vendors entering this space, given the recognition in the industry of NHI risks and the lack of available solutions to solve this hugely complex problem.
Why the Huge Growth in NHI Products in Recent Years?
Based on what we have stated in our report, managing NHI risks is probably the most complex challenge in the industry today, and the current set of solutions are not fit for purpose to handle the complex set of requirements for managing NHI risks.
Source: Oasis Security original diagram, overlaid by Francis Odum to include key Vendors and further overlaid by our NHI Mgmt Group to include a missing piece around Secret Scanning solutions
As stated by Francis Odum in his "The Complete Guide to the Growing Impact of NHIs in Cybersecurity" report, some organizations have tried to utilize some form of CIEM, PAM, Secrets Manager, and PKI/Cert Mgmt integrations to manage aspects of their NHI challenge. This results in custom in-house solutions and processes to deal with the issue. Based on the current fragmented identity ecosystem, where no one solution solves the problem, it is clear that the industry requires a comprehensive set of solutions.
A Practitioner's View
Having run one of the largest NHI programs in the financial industry recently, I can fully attest to this. When starting the program a few years ago, NHI products did not exist in the market, so we had to build our own in-house capabilities, covering:
Inventory Management – In-house built.
Ownership/Claiming Processes – In-house built.
Secrets Scanning – Vendor solution with in-house extensions and processes, e.g., to deal with the challenges of false positives and being able to apply context to the scan results.
Secrets Vault Solution – Vendor solution with in-house extensions and processes and guidelines to deal with all the different use cases.
Prevent Controls – Vendor solution to stop the check-in of secrets into source code.
CI/CD Integration – In-house built with secrets vault integration and source code prevent controls.
Cycling Capabilities – In-house built, very challenging to build as it needed to integrate cycling capabilities into each endpoint platform into the vault solution, etc.
Hygiene Processes – In-house built to deal with inactive accounts, environment segregation issues, etc.
User Entity Behavior Analytics (UEBA) Detect and Response – In-house built, using a vendor UEBA product, but very challenging to implement given the number of endpoints, sheer volume of events, and false positives.
Make no mistake, this was a massive undertaking, spanning multiple years and tens of millions in investment and remediation activities.
Question: If NHI products existed when you started the program, would you have used them?
Answer: Absolutely.
Question: Would they have solved all your requirements?
Answer: No.
Why - While the NHI products have matured significantly in recent years, they still need to mature further to meet the full set of requirements, particularly for large multinational organisations that have hyper-fragmented environments, especially their legacy On-Prem footprint.
Question: Would they help fix the issues quickly?
Answer: No.
Why - While the NHI products can help significantly accelerate your understanding of the current exposure with inventory management and help reduce risk exposure through posture management, remediating the risks identified, such as plain-text/unencrypted credentials in source code and cycling/rotation, is still a massive undertaking.
What types of NHI solutions have emerged:
Pure Non-Human Identity products
Core Lifecycle Capabilities: Focus mainly on dealing with static secrets, the core lifecycle processes of discovery and inventory management, including scanning, classification/ownership, posture management (hygiene), remediation (vaulting, cycling), and ITDR (detect and response).
Advanced Lifecycle Capabilities: Support prevnenting check-in of secrets, the zero-trust model of Zero Standing Privileges (ZSP) using Just-In-Time ephemeral secrets, real-time threat detection and prevention.
In addition, we have seen:
Combined Human/Non-Human Identity products
Existing IGA/PAM solutions that are now adding broader NHI lifecycle capabilities.
Cloud-focused solutions.
SaaS-focused solutions.
Solutions that perform a specific function, e.g., secrets scanning, detect and response.
Over time, it is very clear we will see convergence of these capabilities within the solutions.
Who Will Be The Winners? – The vendors who can provide these combined capabilities, support a zero-trust model, deal with the huge challenge around on-prem environments, and offer significantly faster ways to remediate and get the risks under control, e.g., through real-time threat detection and prevention, will likely be the winners in the market.
Market Activity – There were some major acquisitions in 2024 showing the importance of the Non-Human / Machine Identity market overall.
In May 2024, privileged access management (PAM) vendor CyberArk signed an agreement to acquire machine identity management company Venafi for $1.54 billion.
In November 2024, Silverfort acquired Resonate with the goal of consolidating the offerings to protect identities across all on-prem assets, cloud identity providers, cloud infrastructure, and SaaS applications.
We also expect more of the heavyweights in the identity market to enter the NHI space (some already are), including possibly:
Identity Providers (Microsoft, Google, IBM, Okta, ...)
PAM/Secrets Vault Providers (HashiCorp, BeyondTrust, Delinea, CyberArk, ...)
IGA Providers (Saviynt, SailPoint, Veza, ...)
PKI/Cert Providers (Venafi, KeyFactor, ...)
CIAM/SSPM Providers (Wiz, Axonius, Zscaler, Netskope, Obsidian, ...)
Expect major acquisitions and consolidation, including within the existing NHI product companies themselves, during 2025 and beyond.
Our NHI Mgmt Group is strategically placed to provide deep insights into the market and the vendors, given our experience in running some of the largest NHI programs in the industry and having strategic partnerships with close to 20 vendors in the NHI space, all helping support our mission statement to educate and evangelize around the huge NHI risks and support organizations in their journey to get these huge exposures under control.
Expected Growth in the Non-Human Identity Market
While the NHI market is difficult to assess at the moment, here are some key data points indicating where the NHI market is heading:
According to PrecisionReports, the global machine identity management market size was valued at USD 1.2 billion in 2021 and is expected to expand at a CAGR of 12.25% during the forecast period, reaching USD 2.4 billion by 2027.
According to Verified Market Reports, the machine identity and credential management market size was valued at USD 1.5 billion in 2022 and is projected to reach USD 5.8 billion by 2030, growing at a CAGR of 18.7% from 2024 to 2030. Clearly, this is a broader scope than just Non-Human / Machine Identities.
In our view, the Non-Human / Machine Identity market is likely to be somewhere in the middle of these two numbers in the next few years. The huge surge in adoption of GenAI would not have been factored in, and the fact that over 80% of breaches are now identity-related, with identity security becoming the new cybersecurity perimeter.
As noted in the next section on VC investment, it is very evident the NHI market is exploding, and we expect the market to grow massively in the next few years, far exceeding the earlier projections.
VC Investment
Overall, in 2024 there has been approximately $400 million in VC funding for a large number of start-ups developing NHI capabilities and close to $900 million overall, which is a staggering amount of growth and investment in this space.
Note: For our analysis, we used the following companies: Akeyless, Aembit, Andromeda, Anetac, Astrix, Britive, Clutch, Corsha, Entro, GitGuardian, Oasis, Oleria, Opal, Permiso, P0 Security, SlashID, Silverfort, Spirl, Token, TrustFour, Veza.
This list is not exhaustive companies with NHI capabilities, and we have not included many of the IGA/PAM products that are getting into this space or have been in the space for a while, including CyberArk/Venafi, Saviynt, KeyFactor, Delinea, HashiCorp, BeyondTrust, and SailPoint.
Note: We have sourced the funding data from a number of third-party providers, so it's possible there could be small inaccuracies in the actual numbers, but it shows the overall trend in growth and investment.
Source – Non-Human Identity Management Group
The Need for Specialist NHI Focused Programs and Products
Below is a piece I originally wrote in Francis Odum’s “The Complete Guide to the Growing Impact of NHIs in Cybersecurity” report, which I have updated slightly.
Based on the current fragmented identity ecosystem, where no one solution solves the problem, it is clear that the industry requires a comprehensive solution.
Our NHI Mgmt Group conducted a big industry survey involving close to 330 security practitioners on whether non-human identity products and human identity products should be kept separate or converge. While the result was close, 55% to 45% in favor of keeping non-human identity products separate from human identity products, the reality is that some of the folks who voted for convergence see it as an ideal end-state view, but clearly understand there is a valid case for keeping the focus on NHI risks separate for now.
The challenges and approaches to addressing non-human identity risks versus human identity risks are very different. For example, addressing hardcoded passwords in source code requires discovery through scanning tools, and then remediation requires shift-left DevSecOps CI/CD processes integrated into a secrets vault.
While there may be overlapping identity lifecycle processes for non-human and human identities, there is a clear need to manage NHI identity risk programs separately from human identity risk programs. Specialized NHI products are more vertically focused on discovering and managing NHI risks.
In the longer term, as the industry moves towards a zero-trust model and we move away from static secrets to more of a JIT model, we may see more convergence, as it then becomes a more generic problem of identity management and security.
Some vendors have already made a play to cover both Non-Human and Human Identities in one product. Karen Crowley from Andromeda Security writes a nice piece, "Human Identity and NHI Must Be Addressed Together".
The Vendors
Below are a number of vendors that have NHI capabilities. Some of them:
Are pure NHI products and some cover Human Identities also.
Cover the Core Lifecycle Processes (focused more on Static Secrets) and/or the Advanced Prevent Lifecycle Processes (Dynamic Secrets, etc.) we talked about earlier.
Cover a mixture of Cloud, Hybrid-Cloud, SaaS, and On-Prem.
Note this is not an exhaustive list; there are many more that we will look to add to the report in due course.
Note the descriptions below on each vendor and their product capabilities have been provided directly by the vendors and do not in any way represent the opinions of the NHI Mgmt Group.
The vendors have been listed in alphabetical order.
Aembit is the Workload Identity and Access Management Platform that secures access between non-human identities. With Aembit, businesses can fully automate secretless, policy-based, and Zero Trust workload access.
You can think of Aembit as Okta for workloads. Aembit does this via an identity broker that grants secretless access, just-in-time, based on the workload’s identity and posture. Leveraging native identities and sophisticated automation via a no-code approach, Aembit eliminates the need for developers to store sensitive secrets within applications or vaults. And DevOps no longer needs to manually manage service accounts or rotate credentials.
With Aembit, companies can:
Secure access to sensitive resources by discovering, validating, and enforcing access rights in real-time using the native identity of the workload and an access policy, instead of a long-lived secret.
Reduce risk by providing zero trust conditional access for NHIs
Automate DevOps by minimizing secrets rotation, reducing key sprawl, and the need for secrets scanning.
Remove the burden of auth from developers through no-code auth-as-a-service.
Akeyless is redefining identity security for the modern enterprise, delivering a unified Secrets & Non-Human Identity platform designed to prevent the #1 cause of breaches - compromised machine identities and secrets.
Akeyless Security delivers a cloud-native SaaS platform that integrates Vaultless Secrets Management with Certificate Lifecycle Management, Next Gen Privileged Access (Secure Remote Access), and Encryption Key Management to manage the lifecycle of all machine identities and secrets across all environments.
Akeyless Unified Secrets & Non-Human Identity Platform has been adopted by several large enterprises across healthcare, financial, technology, and retail organizations delivering:
Improved Visibility across all secrets and machine identities / non-human identities
Enhanced Efficiency of a SaaS platform, including multi-product consolidation
Complete Control across the full lifecycle of credentials, certificates and keys
Proactive Security with DFC™ Zero-Knowledge and modern “Secretless” authentication
Comprehensive Human + Non-Human Identity Security
Andromeda Security combats the mounting challenges in Cloud and SaaS arising from identity sprawl, excessive privileges, and manual processes. We take a data-centric approach, correlated with AI models, to provide risk-based actionable insights and gain control over your human users, non-human identities (NHI), and applications.
We treat NHI as part of a unified identity security strategy and leverage rich context from risk, usage, and behavioral analytics to address all aspects of NHI (and human identities). Our approach goes beyond discovery and credential management to include activities and permissions management.
Andromeda Security offers the following capabilities to enable both security and productivity:
Discover human and non-human identities
Assign risk scores based on posture, behavior, and privileges
Track activities and remove unused and inactive identities
Gain fine-grained visibility into permissions usage
Reduce attack surface by right-sizing roles
Implement frictionless just-in-time (JIT) privileged access
Simplify compliance with automated user access reviews (UARs)
Automate identity lifecycle and governance
Secure and manage the lifecycle of NHIs such as service accounts, API keys, secrets, and OAuth tokens across SaaS, Cloud, and On-Prem environments.
Inventory: Real-time discovery of NHIs.
Posture Management: Prioritize NHI risks and improve security posture.
Non-Human ITDR: Detect and respond to anomalous activity and third-party breaches.
NHI Lifecycle Management: Control and manage NHIs from creation to expiry.
Auto-Remediation: Automate remediation with integrations and playbooks.
Next-Gen Secret Scanning: Map exposed secrets and easily rotate them.
AxisNow provides a simple yet powerful Non-Human Access Hub for the AI and automation world.
The non-human (applications, scripts, and services) identity infra and traffic hub. Identity-centric security, secure non-human access across environments. Providing the necessary speed, scalability, and reliability for production.
Key Features：
Edge: Trusted combination of machine identity and egress gateway.
Endpoint: Cross-environment connection of all non-human client endpoints and server endpoints.
Policy: The central identity and traffic orchestration layer.
Insight: Full-stack logs and observability.
Platform: Multi-tenant, developer friendly and ecosystem integration.
Britive is a cloud-native privileged access management (PAM) platform purpose-built to secure and manage access for both human and non-human identities across multi-cloud and hybrid on-prem environments. Everything we do at Britive is designed to address the unique challenges of managing identities in modern, complex infrastructures.
With our agentless, cross-functionally aligned PAM solution, Britive empowers development teams, platform engineers, and security professionals to securely and seamlessly manage dynamic access without compromising security, innovation, or operational efficiency.
Key Features and Capabilities:
Proactively Mitigate Identity & Access Risks with Zero Trust
Patented Just-in-Time (JIT) Access
Unified Access Management
Simplified Compliance & Audit Readiness
Self-Service Access with Access Builder
DevOps & Automation Workflow Support with PyBritive
Secrets Management & Credential Vaulting
Rapid Scalability
Corsha’s platform embodies zero trust principles anchored in identity security to protect lifecycles, authenticate and govern the identities securing operational systems. The platform delivers innovative machine-to-machine authentication and secure communications.
Next Generation Machine Identity - Focus on Identity and Access Management, Not Static Credentials like Certificates, API Keys, or Attributes that are easily spoofed.
From Anywhere to Anywhere - Monitor and control all Machine communication. Securely connect across hybrid clouds, legacy systems, and even shop floors.
A Centralized View - Corsha Console provides a unified view of your Non-human Identities, ensuring trusted machine access with configurable trust levels and a deny-first API security approach.
Entro securely manages the full lifecycle of Non-Human Identities and the secrets that create them.
Discovery & Inventory – Discover all NHIs at creation locations, vaults, and exposure locations for a full inventory.
Classification – Enrich each NHI and secret to understand owners, permissions, usage, enablement, rotation time, and more.
Posture Management – Right-size permissions and avoid misconfigurations.
NHIDR – Monitor all secrets, NHIs, and vaults for any abnormal behavior.
Rotation & Vaulting – Streamline rotation and ensure secrets are vaulted.
Decommission – Remove stale and unused NHIs to reduce the attack surface.
GitGuardian has a comprehensive approach to tackling your Non-Human Identity challenges, focusing on two key areas :
1. NHI Governance - Objective: Ensuring all identities and secrets are fully managed and secured.
Discover and maintain a centralized inventory of all secrets.
Get detailed context and scopes around each secret.
Remove the pain of managing multiple secrets managers.
Manage secrets continuously across their entire lifecycle.
Assess secrets security posture and improve IAM hygiene.
2. Secrets Security - Objective: Detecting, remediating, and preventing secrets leaks, aiming for 0% leaked secrets.
Detect and remediate company-related leaked secrets on public GitHub to secure your organization’s attack surface.
Identify and address secrets sprawl across the internal tech stack to prevent insider and external threats.
Use decoy secrets to detect unauthorized access and respond swiftly to mitigate secrets-related breaches.
Natoma is on a mission to safeguard NHIs and empower enterprises to securely connect any technology. The comprehensive platform allows customers to secure and manage all NHIs, including service accounts, access tokens, API keys, workloads, bots, and more.
Natoma automatically discovers NHIs across your ecosystem and surfaces intelligent context regarding ownership, downstream dependencies, and permissions. The platform goes beyond a surface-level view of NHIs – we feature deep contextual data and graphs to illustrate the relationship between NHIs and systems. Natoma then continuously monitors NHIs to surface issues or anomalies.
The platform also provides automated lifecycle management with on-demand & policy-based rotations and seamless governance. Natoma automates every step of the NHI lifecycle including:
Rotation, ensuring credentials are regularly updated and secure
Revocation, safely deactivating unused NHIs
Rightsizing permissions based on usage data
Reassignment, ensuring smooth transitions when owners leave or change roles
Reviewing, certifying that NHIs are still relevant and required
Oasis NHI Security Cloud is an enterprise cloud service for managing and securing NHIs across the hybrid cloud.
Powered by purpose-built AI/ML intelligence engines, Oasis combines NHI auto-discovery, vulnerability detection, rapid remediation, policy-based lifecycle orchestration, and compliance management in a single integrated, easy-to-use solution.
Unique Capabilities:
NHI auto-discovery and classification across hybrid cloud
Context Reconstruction
Ownership discovery
Risk posture analysis
Threat detection
Remediation
Policy-driven lifecycle orchestration
Identity Lifecycle management workflows
P0 Security is a unified IGA and PAM platform for the cloud that governs and secures all forms of access for both human and non-human machine identities.
Inventory all cloud identities and owners.
Identify risks, including over-privileged access and unused identities.
View resources at risk due to vulnerable identities.
Assign owners for each service account and NHI.
Manage the complete lifecycle from creation to deactivation.
Enforce policy-based controls to achieve least-privilege access.
Secure access at scale with automated workflows.
Automate regular access reviews, credential management, and secret rotations.
SlashID is a comprehensive identity security platform designed to protect both human and non-human identities across cloud, on-premises, and SaaS environments. It provides a unified solution to streamline compliance and enhance security posture through a graph-based approach augmented with runtime data.
Key Features:
Unified Identity Graph: Gain visibility across all environments with comprehensive inventory tracking, toxic combination detection, custom tagging for Separation of Duties (SoD) mapping, and attack path discovery.
Threat Detection: Identify posture issues and actively detect threats, including malicious OAuth 2.0 apps, fake delegated Identity Providers (IdPs), and forged tokens.
Compliance Framework Mapping: Effortlessly generate compliance reports, reducing the manual effort required for assessments and ensuring faster adherence to industry standards.
Automated Remediation: Automatically enforce corrective actions such as blocking, suspending accounts, rotating credentials, applying conditional access, or enforcing MFA to mitigate the impact of attacks and simplify compliance management.
Identity Lifecycle Management: Ensure proper attestation and provisioning of non-human identities (NHIs) and detect and remediate onboarding and offboarding processes.
TrustFour secures workload and AI attack surfaces, ensuring all interactions are authenticated and authorized. TrustFour protects against unauthorized lateral movement by enabling standards compliance, interaction mapping, non-human/machine identity discovery, connectivity telemetry, observability, and deterrence against unauthorized access.
Key Features:
Data-in-Transit Observability
Advanced Deterrence Telemetry
NHI & Service Account Tracking
Workload Authorization Map & Notable Alerting
Workload Attack Surface/Lateral Movement Control
TLS and Post-Quantum Compliance and Cryptographic Agility
Unosecur is a cutting-edge cloud identity security platform that safeguards human and non-human identities in real-time.
Full contextual inventory of Non-Human Identities, such as keys and secrets, while quantifying risks and enforcing 'ruthless' least privilege policies.
Real-time threat detection - halts attacks like privilege escalation and lateral movement as they happen, using AI-powered insights and no-code IAM workflows for rapid, seamless remediation.
Out-of-the-box integrations with IDPs and incident management tools ensure top-tier security without disrupting productivity in multi-cloud environments.
Whiteswan Security provides full lifecycle management for service accounts with automated discovery, granular access controls, and visibility into anomalous threat activity.
Automated Access Control - Eliminate manual intervention with real-time controls.
Time-Bound Permissions - Limit access to key infrastructure and data.
Comprehensive Visibility - 360-degree visibility across all access events.
Identity-Based Micro-Perimeters - Secure users and devices with dynamic, identity-centric boundaries to prevent unauthorized access.
Granular Access Policies - Enforce least-privilege principles.
Real-Time Threat Protection - Neutralize threats instantly with advanced analytics.
10 - 2025 Outlook – Predictions
I expect 2025 to be a pivotal year in the Non-Human Identity Management space for a number of reasons (see my festive 12 Days of NHIs post).
MrNHI and the NHI Mgmt Group - As I take on my new full-time role as Mr NHI, our goal at the NHI Mgmt Group will be to help lead the charge in educating and evangelising about NHI risks.
We hope this research report becomes a defining moment in the history of the Non-Human Identity space, helping to accelerate progress in the industry.
Non-Human/Machine Identities will be the hottest topic in the identity management/security space, as seen and talked about at Gartner IAM in December. We expect significant events in 2025 that will massively amplify the noise levels around NHIs – more news on that to be announced shortly.
Organisations start investing in NHI programs - We expect to see organisations increasingly seeking guidance on NHI risk management, given the increased visibility and understanding of the exposures. We expect they will no longer be driven into starting a NHI program based on an incident or breach.
However, they will face a huge dilemma: How do you tackle the “huge elephant in the room” and take a risk-based approach to get the biggest bang for your investment?
This is something our NHI Mgmt Group has a very deep understanding of, as highlighted in this report. We can provide you with independent guidance and advice on the options that are the right fit for your organisation.
Growth in NHI Advisory/Consultancy space - While we expect huge growth on the vendor/product side, we also predict significant growth in the consultancy, reseller, and system integrator space. Professional services organisations, which historically focused on the Human Identity space, will start vying for a slice of the huge NHI pie.
Buying a product is part of the answer but not the whole answer. Many larger organisations will need to set up dedicated NHI programs and teams, using a combination of their existing IAM resources as well as professional services organisations.
Regulators and Auditors are coming - You better watch out, as they are now shifting focus away from Human Identity, PAM, Developer Access to Production controls, and towards NHI risks. There is so much low-hanging fruit for them to find, such as plain-text/unencrypted credentials in source code, etc.
Note that while most people worry about cyber risks/attacks with NHIs, don’t forget the internal actors within your organisations who may maliciously or accidentally cause impact using NHIs. Humans using NHIs within an organisation is a huge problem and one that regulators and auditors will definitely hone in on, so don’t think this is just a cyber risk.
Industry continues to mature towards Zero Trust architectures - Standards like SPIFFE, WIMSE, and SPICE will help drive the big push towards Zero-Trust and Just-In-Time Ephemeral Secrets.
Real-Time Threat Detection and Prevention - In speaking to a number of CISOs last year, they all realised the huge challenges around NHIs. In some cases, they have said it’s not practical, or they don’t have the budgets to focus on the huge efforts required to remediate NHI risks, given all their other security priorities. They see preventative controls, i.e., stopping threats in real-time, as a key capability that needs to be delivered by the industry so they can quickly get control of the risks, while strategically moving towards a target state Zero-Trust model.
Over 50-100 major NHI breaches in 2025, as a result of increased AI-driven attacks.
AI tips NHI risks over the edge - From a security risk/posture management standpoint, AI is weaponised for NHI attacks.
AI may also help massively with the NHI challenge. As we have clearly articulated in this research report, this is probably the most complex security challenge facing the industry. The sheer scale of what is required to deal with the huge secrets sprawl challenge, hyper-fragmentation, etc., requires something more radical. Using AI may help deal with massively streamlining, automating, and managing the lifecycle process for NHIs.
Could we, for example, see AI models that can identify hard-coded credentials in source code, apply context, understand all the dependencies, set up the credentials in a vault, automatically remove the hard-coded credentials from source code, deploy the updated code in a staggered manner to reduce operational impact, and then cycle the credentials on a regular basis, without any human intervention?
AI folks, have I just given you the perfect recipe for transforming NHI Management? 😉
Quantum Computing Threats continue to remain a big concern for the industry, with a clear impact on NHIs.
Huge Acquisitions and Consolidation in the Market - Industry heavyweights will make their play, given the huge growth potential around the NHI market. Existing players will merge and combine their capabilities to help accelerate greater innovation in the market.
Given our NHI Mgmt Group probably has the deepest understanding of the NHI market, we have seen many NHI companies emerge in the last 12-18 months, and existing identity players getting into the NHI space. I personally feel we are getting very close to saturation point with the number of players in the market, and there will need to be some consolidation and clearer differentiating products/capabilities to survive in this highly competitive market.
Could AI newcomers also disrupt the NHI market? - We have already seen a number enter the broader identity market (like Twine Security and RedBlock AI) that could be disruptive to the industry.
Existing NHI companies will need to invest heavily in AI capabilities to continue having a differentiating offering, as Astrix Security is planning with their recent $45M Series B fund raise announcement.
I would say the NHI market has matured at a rapid pace in the last 12 months, but based on my deep understanding of the problem space, there is a long way to go to reach the maturity level seen in the Human Identity or PAM space.
Closing Remarks
I personally can’t wait to see what 2025 brings in the Non-Human / Machine / Workload Identity space. Exciting times ahead! Fasten your seatbelts; it’s going to be a crazy ride, and our NHI Mgmt Group is right at the front, leading the way 😉
With this report my goal was to create the most definitive research report ever produced on NHIs (including a hands-on practitioner's view) that I hope will stand the test of time and achieve the primary goal: to help educate everyone in the industry and help move the needle on this massive challenge the industry and organisations are facing.
Let’s stop the rise of Non-Human and Machine Identities and get them under control!
Acknowledgements
Firstly, given the huge magnitude of this report and the many weeks of effort put into it (including many late nights), there may be some inaccuracies or errors. Please let us know if anything needs correcting.
Thanks to my team at the NHI Mgmt Group, in particular Abdou and Seb, who helped with the Dorking and NHI Breach content and Anita and Anika reviewing this monster 70 page document.
I would like to thank all our strategic partners who supported us in our journey at the NHI Mgmt Group last year, helping educate and evangelise about the NHI challenges, and building a great community that can work and collaborate to protect organisations from these huge risks around NHIs.
I would also like to thank Francis Odum for giving me the opportunity to contribute to and review his comprehensive NHI report published earlier last year. This inspired me to produce this report, which I hope is worthy of the amazing work Francis produces. I hope this report takes things to the next level in terms of depth and breadth, based on 25+ years of hands-on practitioner experience and the work we do at the NHI Mgmt Group.
I would also like to thank everyone I have interacted with, worked with, supported me, provided guidance and advice, as we established our NHI Mgmt Group as the number one authority in the Non-Human Identity space. I look forward to continuing to work with you all, making a huge impact through our NHI community to tackle one of the most challenging problems in the industry.
Who are the NHI Mgmt Group: Your Premier Partner in Non-Human Identity Management
The NHI Mgmt Group, is the market-leading research and advisory firm in the Non-Human Identity (NHI) space. We are your trusted partner for independent guidance and advice, helping you manage the complex risks associated with Non-Human Identities.
Why Choose Us?
Unmatched Expertise: Our team boasts over 25 years of experience advising, establishing, and managing global regulatory IAM/NHI programs at major financial institutions.
Comprehensive Knowledge Centre: Dive into our extensive resources, including foundational articles on NHIs, industry white papers, major breach analysis, research reports, blogs, educational videos, industry surveys, newsletters, and detailed product information to support NHI risk management.
Industry Leadership: Founded by an IAM industry veteran, our group has pioneered global regulatory NHI programs, authored major white papers and research on NHIs and established the thriving NHI LinkedIn Community Group. Recognised as the #1 NHI evangelist and voice in the industry, we are at the forefront of NHI innovation and advocacy.
Our Commitment to You:
At the NHI Mgmt Group, we are dedicated to advancing the NHI landscape through cutting-edge research, strategic partnerships, and unparalleled expertise. Join us in navigating the future of Non-Human Identity Management and stay ahead in this rapidly evolving field.
Let us help you turn the tide on NHI risks and achieve greater security and efficiency in your organisation. Together, we can conquer the challenges and seize the opportunities presented by the ever-expanding world of NHIs.
Ready to Tackle Non-Human Identity Risks?
Reach out to us for expert, independent guidance and advice. Together, we can create a robust strategy to manage and mitigate NHI risks. Let's transform challenges into opportunities!