Governing Non-Human Identities: New Certification Offers Needed Help
9:53
author photo
By Cam Sivesind
Wed | Sep 17, 2025 | 11:33 AM PDT

Machines don't sleep. APIs don't negotiate. Scripted agents don't take coffee breaks. Non-human identities (NHIs) are everywhere in modern organizations—from service accounts, bots, and credentials to AI agents, machine identities, certificates, and keys. As these take on increasingly critical roles, the lack of governance, visibility, and ownership becomes a serious liability.

Recently, Oasis Security introduced a Non-Human Identity Management (NHIM) Fundamentals Certification, aiming to give security professionals a framework to govern NHIs in the age of agentic AI. This move reflects growing recognition across the industry that NHIs need as much attention, if not more, than human identities. Let's unpack what NHIM entails, the risks, where industry experts stand, and how the new Oasis certification fits in.

Non-Human Identity Management refers to how organizations discover, track, govern, secure, and retire identities that are not tied to individual humans but are critical for machine-to-machine interaction or AI/automation services. According to CrowdStrike: "NHIs are digital identities for applications, services, or devices… often falling outside traditional IAM controls, making them particularly vulnerable when left unmanaged."

These identities include:

  • Service accounts

  • Automated APIs / tokens

  • AI agents / bots

  • Machine identities (containers, fleet apps)

  • Certificates and secrets

They are essential, but because they often don't interact via user login UI flows, they tend to bypass many human-centric security practices.

There are challenges and risk vectors that make poorly managed NHIs a major threat, including:

  1. Volume, sprawl, and poor visibility: Many organizations don't have a full inventory of their non-human identities. Secrets, tokens, API keys may be embedded in code, spread across vaults, cloud configs, or messaged between systems.

  2. Over-privileged access and misconfiguration: NHIs often have broad access (for convenience or due to legacy permissions) and aren't always subjected to least privilege policies. Misconfigured permissions can lead to powerful backdoors for attackers.

  3. Lack of ownership / auditability / accountability: Without clear ownership or attestation (who is responsible for each NHI, its permissions, lifecycle), orphaned or forgotten identities accumulate. That means nobody is verifying if they are needed, safe, or being misused.

  4. Security control gaps: Traditional IAM tools, MFA, and user-centric identity governance don't always cover NHIs. Monitoring, alerting, and enforcing policies for NHIs are often inconsistent. Token usage across third-party apps, usage from unexpected locations, or unrotated secrets are common attack vectors.

  5. Fear of disruption / operational challenges: Teams are cautious about rotating or disabling credentials because doing so could break automation, CI/CD pipelines, or critical services. Because of that, insecure identities are allowed to persist.

While NHIM is challenging, several trends and initiatives create opportunities for improvement:

  • Zero trust and least privilege models applied to NHIs. Grant only what is needed; enforce strong controls over machine identities.

  • Behavioral monitoring and anomaly detection for NHIs. Since many operate non-interactively, deviations from baseline behavior are key signals.

  • Automation of lifecycle management: provisioning, rotating, decommissioning, and auditing of NHIs via tools and policies to avoid manual errors.

  • Clear ownership and attestation processes: defining who is responsible, who approves, and who audits each non-human identity.

  • Industry frameworks and certifications to standardize NHI security best practices.

To address the gap, Oasis Security has launched the Non-Human Identity Management Fundamentals Certification. This training and certification proceeds from real-world patterns, scenario-driven exercises, and competency assessments intended for both practitioners and leaders—CISOs, identity teams, DevSecOps, compliance officers, etc.

According to an Oasis press release, the certification:

  • Helps integrate NHI governance into enterprise workflows

  • Unlocks secure adoption of agentic AI systems

  • Provides a common playbook for managing NHIs securely and at scale 

This is especially timely as agentic AI adoption grows, and enterprises increasingly rely on machine identities, automated workflows, and automated credentials.

Some experts provide commentary on NHIs and implications for security teams:

  • CrowdStrike reports that many NHIs are outnumbering human identities in some enterprises by large multiples, and percentages of organizations have already experienced or suspect compromise of NHI credentials.

  • Portnox and other security vendors highlight that poor visibility and difficulty enforcing consistent policies are major obstacles.

  • Cloud Security Alliance and Oasis emphasize ownership and clear accountability as foundational to reducing risk.

Case studies involving NHIs or service-account abuse

Cloudflare (Atlassian breach via Okta tokens / service account credentials)

  • Cloudflare internal Atlassian server, involving Confluence, Jira, Bitbucket; work of a nation-state attacker via compromised authentication tokens and service account credentials.

  • Attackers gained access to internal Atlassian infrastructure, potentially exposing code, tickets, internal documentation, etc. The breach leveraged existing service account credentials that were compromised during a prior Okta breach.

  • Revealed how chained breaches (Okta → downstream Atlassian via service account) can cascade. Emphasis on protecting upstream identity providers, rotating service account credentials, limiting scope of service account privileges.

Okta support account incident

  • Okta's customer support system; some customers of Okta (1Password, BeyondTrust, and Cloudflare among them) had sessions hijacked via a service account.

  • Attackers used stolen credentials from an employee's personal Google account (used on a company-managed device) to access a support service account. They used session tokens (HAR files) to impersonate staff and hijack legitimate sessions.

  • Measures included disabling personal Google account login on managed devices, implementing session token binding based on network location, forcing re-authentication when network changes detected.

ReliaQuest report on service accounts in data breaches

  • Organizations that suffered data breaches (sample of those handled by ReliaQuest Jan-July 2024)

  • Found that approximately 85% of data breaches involved compromised service accounts. These accounts provided paths for lateral movement across networks once initial access had been achieved.

  • Highlights the need for continuous service account governance: auditing, restricting over-privileged accounts, employing least-privilege principle, enforcing rotation, and monitoring unusual usage patterns.

Marks & Spencer ransomware via service desk / Active Directory compromise

  • UK retailer Marks & Spencer; all 1,049 stores were functionally affected in certain services; customer facing services (online, returns etc.) disrupted.

  • Attackers impersonated an employee, tricked a third-party contractor/service desk into resetting passwords, obtained credentials for Active Directory (via NTDS.dit), used that for lateral movement, then deployed DragonForce ransomware.

  • Resulted in large revenue loss, suspension of online sales for days, and severe stock value loss.

There are some common themes from the above breaches and teachable moments from each:

  • Service and non-human accounts are high leverage: once attackers get control of these, they can often move widely and persistently, because such accounts tend to be trusted, over-privileged, and lightly monitored.

  • Credential exposure upstream has downstream impact: breaches at identity providers, or via support/contractor accounts, often give attackers powerful tokens, or service account credentials that unlock additional systems.

  • Social engineering and human trust are recurring vectors: many incidents begin not with zero-day exploits, but with tricking people—contractors, help desk agents—into giving up or resetting access.

  • Defensive controls tend to lag: things like session-token binding, device management policies, restricting personal accounts, stricter service desk verification, and enforcing least privilege or JIT access are often missing until after a breach.

Here are practical steps for organizations that want to move from reactive to proactive with NHIM:

  • Discovery and inventory: Use tooling to find all non-human identities: service accounts, API keys, AI agents, certificates. Catalog where they are, who created them, and what privileges they have.

  • Classification and ownership: Define the business purpose. Assign ownership to teams or individuals. Map permissions & dependencies.

  • Least privilege and access controls: Grant minimal required access. Use role-based or attribute-based access. Remove or reduce credentials for unused identity types.

  • Automate rotation and credential management: Secrets management, automated rotation, vaulting, and enforcing credential hygiene.

  • Continuous monitoring and anomaly detection: Monitor usage patterns, geographic anomalies, unusual access. Trigger alerts / automated responses.

  • Governance and policy enforcement: Policies for creation, use, audit, retirement. Include NHIs in IAM policy, audits, compliance reviews.

  • Training and culture: Educate teams (DevOps, platform engineering, IAM) about NHI risk. Make sure that fear of breaking systems doesn't halt security actions.

Comments