Non-Human Identity (NHI) Security: Managing Machine, Service and AI Agent Identities

Table of contents

• What is a non-human identity?
• NHI vs machine identity vs workload identity
• Why NHIs are the blind spot mid-market IT teams inherit
• The four NHI risks that actually hit companies with 50 to 500 employees
• What NIS2 and ISO 27001 require for non-human identities
• A five-step NHI governance framework
• How to add non-human identities to your next access review
• How Corma governs non-human identities
• Frequently asked questions

Most identity security programmes are built around people: onboarding, SSO, MFA, offboarding, an annual access review. Meanwhile, a second population has quietly grown inside every SaaS stack, and nobody put it on the org chart. Service accounts, API keys, OAuth grants between two SaaS tools, Zapier and Make automations, and now AI agents with their own connectors.

Vendor estimates for how far these identities outnumber employees range from 25 times to more than 100 times, depending on who is counting and what they count. The direction of travel is not disputed. What matters for an IT team of two or three people in a 200-person company is different: these identities were never provisioned through your identity provider, they do not appear in your leaver checklist, and most of them have no owner.

This guide covers what a non-human identity is, how the terminology actually breaks down, the four risks that genuinely materialise in mid-market environments, what NIS2 and ISO 27001:2022 expect from you, and a five-step governance framework you can run with the tools you already have. No secrets-management platform required.

What is a non-human identity?

A non-human identity (NHI) is a digital identity used by software rather than a person to authenticate and access systems, covering service accounts, API keys, OAuth tokens, certificates, workloads and AI agents.

Unlike a human identity, which is protected by a password plus a second factor and tied to a named employee, an NHI authenticates with a secret: a token, a key or a certificate. That difference has three consequences that drive everything else in this article.

• No MFA. A machine cannot approve a push notification, so the single credential is the whole security boundary.
• No working hours. An NHI has no normal behaviour pattern to deviate from, which makes anomaly detection harder.
• No leaving date. Humans get offboarded. Secrets tend to stay valid until someone actively revokes them.

The five families of non-human identity

Most NHI inventories in a mid-market SaaS environment fall into five buckets. The distinction matters because each family is created differently, and therefore discovered differently.

The important observation for a company between 50 and 500 employees: the volume is not in Kubernetes workloads or mutual TLS certificates. It is in OAuth grants and SaaS-side service accounts, created by employees connecting one tool to another.

NHI vs machine identity vs workload identity

The three terms are used interchangeably by vendors, which creates real confusion during audits. They are not synonyms, and the distinction is practical rather than academic.

• Non-human identity is the umbrella term. It covers every identity that is not a person.
• Machine identity is narrower and historically PKI-centric: it usually refers to the cryptographic credentials (X.509 certificates, TLS, SSH keys) that let devices and services trust each other. This is the vocabulary of certificate lifecycle vendors.
• Workload identity is narrower still: an identity assigned to a running piece of compute (a container, a pod, a serverless function) that is typically short-lived and issued dynamically by the cloud platform.

Which term should appear in your policy?

Use non-human identity in governance documents and audit evidence, because it is the only term broad enough to cover the OAuth grant your marketing team created last quarter. Reserve machine identity for certificate and key rotation procedures, and workload identity for anything cloud-native. Mixing them in a single policy is how service accounts end up outside scope.

If your team is still clarifying the surrounding vocabulary, the Corma identity and access management glossary covers the adjacent terms, and identity governance versus identity management explains where governance responsibilities sit.

Why NHIs are the blind spot mid-market IT teams inherit

Non-human identities are a blind spot because they are created outside the identity provider, by people who are not in IT, for reasons that are entirely legitimate.

How many NHIs are there, really?

Published ratios vary widely and are worth reading with their source and date attached, because they measure different populations. Certificate vendors count certificates. SaaS security vendors count integrations. Cloud vendors count workloads.

Treat these numbers as an order of magnitude, not a benchmark. The useful exercise is counting your own, which is step one of the framework below.

How NHIs get created without anyone deciding

Nobody submits a ticket to create a non-human identity. The usual paths:

• A marketing manager connects the CRM to the email platform and clicks Allow on an OAuth consent screen requesting read and write access to contacts.
• A developer generates a personal API token to build a quick internal dashboard, then leaves the company.
• A finance analyst automates an export with Zapier, using their own credentials as the connection.
• Someone enables an AI assistant inside a SaaS tool, and the assistant inherits a connector with broad scopes.

Every one of those creates a durable, MFA-free access path. None of them appear in your identity provider. This is the same discovery problem as shadow IT, and it responds to the same solution: continuous discovery across the SaaS estate rather than a static asset register.

Why SSO, MFA and your JML process miss them

Your three main identity controls are structurally blind to NHIs.

• SSO covers applications, not the machine-to-machine links between them. An OAuth grant between two apps does not traverse your identity provider on each call.
• MFA cannot apply to a token. This is the single biggest asymmetry: an attacker holding a valid API key faces no second factor.
• The Joiner-Mover-Leaver process deprovisions the human account. The tokens that human created, and the automations running under their name, usually survive the offboarding. Our guide on managing identity lifecycle and offboarding for apps that do not support SCIM, SAML or SSO covers the manual side of this gap.

The four NHI risks that actually hit companies with 50 to 500 employees

Enterprise NHI content tends to focus on CI/CD pipeline compromise and lateral movement in Kubernetes. Those are real risks, but they are not what breaks in a 200-person company. These four are.

1. Orphaned identities that outlive their creator

When an employee leaves, their user account is disabled. The service account they set up, the API token in their name and the Zapier connection they built keep working. An orphaned NHI is a non-human identity whose owner has left the organisation or whose purpose no longer exists, but whose credentials remain valid. It is the cleanest example of an access path that no review catches, because no review looks at it.

2. Over-privileged OAuth grants

OAuth consent screens are optimised for the app developer, not the security team. A tool that only needs to read calendar availability frequently asks for full mailbox access, because the coarse scope is easier to ship. Obsidian Security reported in 2026 that organisations average 40 to 60 third-party integrations per core SaaS application, and that 15 to 25 percent of them had been inactive for more than 90 days while still holding their full permissions.

3. Static secrets that were never rotated

Human passwords have expiry policies. API keys usually do not. A key generated in 2022 for a one-off migration, pasted into a spreadsheet and never revoked, is functionally a permanent skeleton key. There is no alert when it is used, because there was no baseline to compare against.

4. AI agent connectors with no accountable owner

This is the fastest-growing category and the least governed. An AI agent authenticates like any other NHI, but it acts with far more autonomy: it decides which systems to call and which data to read. If your agent inventory does not answer "who approved this, and what can it reach", you have a governance gap that will be examined at your next audit. We covered the operating side of this in the governance of AI agents and the practical management challenges in navigating the challenges of AI agent management for IT teams. The unsanctioned variant is covered in the rise of shadow AI.

What NIS2 and ISO 27001 require for non-human identities

Neither framework contains the phrase "non-human identity". Both apply to them anyway, because both are written in terms of identities, accounts and access rights rather than in terms of humans. This is where European mid-market companies have a concrete, dated obligation rather than a best practice.

NIS2

Article 21(2) of the NIS2 Directive lists the minimum risk-management measures in-scope entities must implement. Three of them land directly on non-human identities:

• Access control policies must cover all access to systems, and an API key is access.
• Asset management requires knowing what exists, which includes credentials.
• Human resources security connects to the leaver process, which is precisely where orphaned NHIs are created.

Article 21 also requires multi-factor authentication or continuous authentication solutions where appropriate. Since MFA cannot be applied to a token, the compensating control expected of you is lifecycle governance: scoped permissions, rotation and revocation. For the broader picture, see our guide on what the NIS2 directive means for your business.

ISO/IEC 27001:2022

Annex A is more explicit. Four controls apply to NHIs without ambiguity:

• A.5.16 Identity management: the full life cycle of identities must be managed, and the standard is explicit that identities can be assigned to non-human entities.
• A.5.17 Authentication information: allocation and management of secrets, which is your API key and token handling.
• A.5.18 Access rights: provisioning, review and removal of access rights.
• A.8.2 Privileged access rights: restriction and control of elevated access, which most service accounts hold.

In practice, an auditor asking about A.5.16 will accept a user list from your identity provider. An auditor who has read the 2022 revision will ask for the service account inventory too, with an owner per line. Our ISO 27001 and IAM implementation guide maps the wider control set, and Corma itself is ISO/IEC 27001:2022 certified.

A five-step NHI governance framework

You do not need a secrets-management platform to start. You need an inventory, an owner per line, and a recurring review. Here is the sequence.

Step 1: Discover

Build one list of every non-human identity across your estate. Pull from four sources: your identity provider's service account list, the OAuth application inventory in Google Workspace or Microsoft Entra ID, the connected-app screen of each of your top 20 SaaS tools, and your automation platforms. A SaaS management platform does this continuously instead of quarterly, which matters because the population changes weekly.

Step 2: Assign a human owner to every line

This is the highest-return step and it costs nothing but persistence. Every NHI gets a named person accountable for whether it should still exist. An identity with no owner is a decision waiting to happen, and the default decision should be revocation. If the owner has left the company, the line is by definition an orphan.

Step 3: Enforce least privilege

For each identity, ask what it actually needs, not what it was granted. Downgrade write access to read where the use case allows. Replace shared admin service accounts with scoped ones. Consistent scoping is easier when the underlying access model is clean, which is what role-based and attribute-based access control are for.

Step 4: Review on a schedule

Non-human identities belong in the same recurring cycle as human accounts. Quarterly for anything with write or admin scope, annually for read-only. The review question is narrow: does this still have a purpose, and is the owner still here? Automated access reviews turn this from a spreadsheet exercise into an auditable workflow.

Step 5: Revoke by default

Build revocation into the leaver process, not into a separate project. When someone is offboarded, the checklist must include the tokens they created and the automations running under their name. Automated provisioning and deprovisioning closes the loop on the human side; the NHI side needs an explicit line in the same runbook.

How to add non-human identities to your next access review

The fastest path to coverage is not a new programme. It is three extra columns in the review you already run.

• Column 1: identity type. Human, service account, OAuth grant, API key, or AI agent. This alone reveals how much of your access surface was previously out of scope.
• Column 2: accountable owner. A person, never a team alias. Team aliases are how ownership evaporates.
• Column 3: last used. Any identity idle for more than 90 days with write scope is a revocation candidate, not a review item.

Run it once with those columns and the output is immediately useful as ISO 27001 A.5.18 evidence. It also tends to be the moment a team discovers that a third of its integrations belong to nobody. Corma customers approach this from the governance side: Satelia, a healthcare company operating under strict data-protection constraints, uses Corma for identity governance in a regulated environment, and Brevo runs SaaS management at scale across a large application estate.

How Corma governs non-human identities

Most NHI tooling was built for enterprise security teams and assumes a secrets vault, a PKI programme and dedicated headcount. Corma approaches the problem from the other direction, because the NHIs that matter in a mid-market company live in SaaS applications, not in infrastructure.

Corma is a European SaaS Management and identity governance platform that discovers, attributes and reviews both human and non-human access across your SaaS estate from a single inventory. Concretely:

• Discovery across the SaaS estate, including OAuth grants and connected applications that never touched your identity provider, through native connectors to Google Workspace, Microsoft Entra ID, Okta and JumpCloud.
• Ownership attribution, so every service account and integration has an accountable human rather than a blank field.
• Access reviews that include non-human identities in the same auditable cycle as employees, producing the evidence trail an ISO 27001 or NIS2 auditor asks for.
• Offboarding that reaches the tokens, not just the user account, via automated user provisioning and deprovisioning.
• European hosting and GDPR-native architecture, with ISO/IEC 27001:2022 certification, which matters when the identity inventory itself contains personal data.
• Recognition in the 2025 Gartner Magic Quadrant for SaaS Management Platforms, alongside a converged approach to identity and access management and identity governance that most vendors split across two products.

Security teams working under audit constraints can see the compliance angle on the Corma IAM solution for security teams page.

Want to see your own non-human identity inventory? Request a demo and we will walk through the OAuth grants and service accounts in your estate.

Frequently asked questions

What is a non-human identity?

A non-human identity is a digital identity used by software rather than a person to authenticate and access systems. It covers service accounts, API keys, OAuth tokens, certificates, cloud workloads and AI agents. The defining characteristic is that it authenticates with a secret instead of a password plus a second factor.

What is an example of a non-human identity?

The most common example in a SaaS environment is an OAuth grant: when an employee connects their CRM to an email marketing tool and approves the permission request, a durable non-human identity is created between the two applications. Other everyday examples include a service account connecting a reporting tool to a database, an API key powering an internal dashboard, and a Zapier automation running under an employee's credentials.

Are AI agents non-human identities?

Yes. An AI agent authenticates with a credential and acts without direct human input on each action, which makes it a non-human identity by definition. It differs from a classic service account in autonomy: an agent decides which systems to call and which data to read, so scope restriction and an accountable owner matter more, not less.

What is the difference between a non-human identity and a machine identity?

Non-human identity is the umbrella term for any identity that is not a person. Machine identity is a narrower, historically PKI-centric subset referring to the cryptographic credentials such as X.509 certificates, TLS and SSH keys that allow devices and services to trust each other. Every machine identity is a non-human identity, but an OAuth grant between two SaaS applications is a non-human identity that most machine identity tools do not cover.

Who is responsible for non-human identity security?

Accountability sits with whoever owns identity governance, typically the IT or security lead, but the operating model only works when each individual identity has a named human owner. Ownerless identities are the root cause of most NHI incidents, because no one is positioned to decide whether the identity should still exist.

How do non-human identities create compliance risk?

Both NIS2 Article 21(2) and ISO/IEC 27001:2022 Annex A controls A.5.16, A.5.17, A.5.18 and A.8.2 are written in terms of identities and access rights, not in terms of employees, so they apply to service accounts and API keys. An access review that covers only human accounts leaves a documented gap in your evidence.

Can you apply MFA to a non-human identity?

No. A machine cannot complete a second-factor challenge, which is why the single credential is the entire security boundary. The accepted compensating controls are scoped permissions, short-lived credentials where the platform supports them, credential rotation, and recurring review with revocation of anything unused.