Icite vs NHI Point Tools: Non-Human Identity Inside a Converged Identity Platform

NHI point tools manage service accounts and API tokens in isolation. Icite treats non-human and human identities as one graph — because attackers do.

Hero summary

Non-human identities — service accounts, API tokens, OAuth apps, service principals, IAM roles, federated identities, managed identities, machine certificates — now outnumber human identities by roughly 45 to 1 in most enterprises. Incumbent NHI security platforms emerged to address what human-IAM tools could not: the sprawl, rotation, lineage, and blast radius of non-human credentials. Icite is not an NHI-only tool. Icite is an identity intelligence platform that treats human and non-human identities as one graph — because the access paths between them are how real attacks unfold.

For executives: Standalone NHI platforms answer part of the question. Icite answers all of it: human and machine identities in one graph, one posture score, one detection surface, one response path. Organizations that already run an NHI point tool typically keep it for deep credential lifecycle operations and layer Icite on top for unified identity intelligence. Organizations starting fresh often adopt Icite alone.

What NHI platforms do

NHI platforms treat non-human credentials as first-class citizens of the identity stack. Core capability set:

  • Discovery — scan cloud providers, SaaS apps, secret managers, and code repositories to find every service account, API token, OAuth client, and machine credential in the environment

  • Inventory and classification — categorize by credential type, owner, age, permissions, and usage patterns

  • Secret rotation and hygiene — flag stale credentials, over-privileged tokens, secrets committed to code, unrotated keys past policy

  • Ownership and lineage — map credentials to the human or system that created them, the application that uses them, and the resources they can reach

  • Just-in-time provisioning — issue short-lived credentials on demand, reduce standing privilege

  • Compliance reporting — evidence for SOC 2, ISO 27001, and other frameworks that require NHI governance

Incumbent NHI platforms vary in focus:

  • Some emphasize broad category coverage — AI agent and third-party integration discovery, OAuth and SaaS-app NHI

  • Some emphasize cloud-native NHI lifecycle — strong in AWS and Azure credential management

  • Some emphasize secret sprawl and credential exposure — strong code-repo scanning

  • Some emphasize just-in-time privileged access — strong on cloud entitlements

These are real products solving a real problem. What they share is that they reason about non-human identities in isolation from human identities, even though the two are deeply interconnected.

The architectural gap in NHI-only tools

Most NHI platforms are built on a credential-centric data model: the thing being tracked is a token, a key, or an OAuth app. Surrounding metadata — owner, permissions, usage — is attached to the credential.

This works for credential lifecycle operations. It breaks down the moment the question shifts from "is this token rotated" to "how did this token get into this environment, who deployed it, and what human identity can reach the resources it protects."

That broader question requires:

  1. Unified identity graph — human and non-human identities as nodes in the same graph, with edges representing create-relationships, impersonation paths, and access overlaps

  2. Configuration history across both identity types — SCD tracking that records when a human created a service principal, when an OAuth app was granted a scope, when an IAM role's trust policy changed

  3. Event correlation across both — authentication events from humans and service-account API calls in the same timeline, so attacks that pivot between the two (compromised human credential → create service account → exfiltrate data) show up as one continuous story

  4. Cross-provider NHI resolution — the same deploy-bot service account may exist in GitHub Actions, AWS IAM (as a federated identity), and Okta (as an OAuth client). Resolving these to one logical NHI is a graph problem, not a credential-inventory problem.

NHI point tools generally don't hold all four. Icite was built around them.

How Icite covers NHI

Icite's NHI coverage is not a bolt-on module. It uses the same three-database architecture that powers the rest of the platform.

Per-provider NHI detection:

  • Okta — app-user assignments, API tokens, OAuth service apps, system log actor types that identify non-human callers

  • Microsoft Entra ID — service principals, app role assignments, OAuth permission grants, credential metadata (when created, by whom, expiration), federated identity credentials, managed identities

  • AWS — CloudTrail actor types (Root, IAMUser, AssumedRole, FederatedUser, AWSAccount, AWSService), access key metadata, IAM role trust policies

  • Google Workspace and Google Cloud — service account email patterns (*.iam.gserviceaccount.com), admin API metadata, domain-wide delegation scopes

  • GitHub — personal access tokens, fine-grained PATs, GitHub Apps, deploy keys, OAuth apps, machine users

  • Salesforce — connected apps, named credentials, external client apps

  • Zoom, Slack, Atlassian, and others — OAuth apps, bot tokens, workspace integrations

Every NHI lands in the same data model as a human identity: a node in the graph, records in the SCD tables, events in the time-series store. The identity resolution layer links NHIs across providers where lineage is derivable (e.g., an AWS IAM role assumed from an Okta identity with federation configured).

What this enables:

  • Blast radius for a compromised service account — one graph query returns every resource the NHI can reach, every human who can assume or rotate it, and every application that depends on it

  • Lineage of "mystery" tokens — "who created this API token, when, and what does it access?" is a single SCD + graph query

  • Cross-provider NHI drift detection — a service account that exists in one provider without the corresponding record in the system of record for NHI deployment (e.g., an AWS IAM role without a matching Terraform/Crossplane definition)

  • Correlated detections — human compromised at 09:00, service principal created by that human at 09:05, exfiltration via the service principal at 09:15 — is one continuous detection in Icite, not three separate alerts in three separate tools

  • Posture scoring for NHIs — stale service accounts, over-privileged machine identities, OAuth apps with unused scopes, service principals with no recent activity, expired-but-not-revoked credentials

Side-by-side comparison

Capability

Legacy SIEM

Icite

Service account discovery

Yes (typically broader, deeper)

Yes (19+ providers)

API token and OAuth app inventory

Yes (typically deeper)

Yes

Secret rotation workflows

Yes (primary strength)

No (integrates with secret managers)

Just-in-time provisioning

Varies (dedicated JIT platforms lead)

No (integrates with JIT platforms)

Code-repo secret scanning

Varies (credential-exposure specialists lead)

No (integrates with code-scanning platforms)

NHI in unified identity graph (with humans)

No

Yes (Neo4j)

Cross-provider NHI resolution

Limited

Yes

Human + NHI correlated detection

No

Yes

Blast radius across human and NHI

No

Yes

Posture scoring (human + NHI)

NHI-only

Unified

SCD Type 2 configuration history

Limited

Full

OCSF-normalized event ingest

Partial

Full

The comparison is not "Icite replaces every NHI tool." It is "Icite unifies NHI and human identity in one platform, which is where the interesting detections live."

When you need a deep NHI tool alongside Icite

Organizations with the following patterns often run an NHI point tool alongside Icite:

  • Heavy secrets hygiene obligations — code-repo secret scanning, certificate lifecycle, deep credential rotation. Specialist NHI tools and secret-manager-integrated platforms are purpose-built for this.

  • Just-in-time privileged access as a program — dedicated JIT platforms lead this capability; Icite integrates with them rather than replacing them.

  • Specific compliance frameworks — if auditors require a dedicated NHI governance tool for a specific control (rare but happens), a point tool may be on the checklist.

In those cases, the typical architecture:

  • NHI point tool — credential lifecycle operations, rotation, JIT

  • Icite — unified identity intelligence (human + NHI in one graph), cross-provider detections, identity investigation, posture scoring, native response

NHI tool findings flow into Icite as OCSF events, where they correlate with human identity activity. The combined stack delivers what neither tool does alone: rotation hygiene and attack-surface intelligence in one operational view.

When Icite alone is sufficient

For most organizations, Icite's NHI coverage is sufficient on its own:

  • 19+ provider coverage spans the NHI sources that matter in a typical enterprise

  • Unified graph is the highest-value NHI capability for security operations

  • Posture scoring covers the common NHI findings (stale, over-privileged, unused, expired)

  • Response actions cover the common NHI incidents (rotate via integrated secret manager, revoke sessions)

Start with Icite. Add a point tool if and when specific NHI operations (deep rotation, JIT, code scanning) justify it.

The consolidation math

A typical NHI-aware stack:

  • An incumbent NHI point tool for non-human credential management

  • An incumbent ISPM tool for human identity posture

  • A traditional ITDR tool for authentication threat detection

  • A legacy SIEM for event analytics across identity sources

Icite consolidates human and NHI identity intelligence, posture, threat detection, and response into one platform. For organizations with strong NHI point-tool commitments, Icite adds the unified-graph layer above them. For organizations rationalizing their stack, Icite replaces three of the four categories outright and reduces SIEM ingest volume on identity sources.

FAQ

Does Icite replace a standalone NHI tool?
Incumbent NHI specialists excel at deep credential lifecycle operations, especially AI agent discovery and third-party OAuth governance. Icite covers NHI detection, classification, posture, and response as part of a converged identity intelligence platform. Organizations that need deep NHI lifecycle operations (rotation workflows, JIT, code-repo scanning) often run a specialist alongside Icite. Organizations that want NHI visibility as part of a unified identity security platform typically adopt Icite alone.

What types of non-human identities does Icite detect?
Service accounts (Google, on-prem), API tokens (GitHub, Okta, Salesforce, Atlassian, Slack, Zoom), OAuth apps and service principals (Entra, Okta, Google, Salesforce), AWS IAM roles and assumed roles, federated identities, managed identities, machine users, deploy keys, and connected-app credentials across 19+ integrations.

How does Icite resolve the same NHI across providers?
Where lineage is derivable — an AWS IAM role assumed by an Okta-federated identity, a service principal consented by a specific human admin, a GitHub App installed into an org by a specific user — Icite connects the records through graph edges. Pure orphan NHIs without provider-side lineage are tracked as independent nodes.

Does Icite rotate secrets?
No. Icite integrates with enterprise secret managers to trigger rotation, but Icite does not run rotation itself. This keeps the rotation responsibility in the system of record for secret lifecycle.

Can Icite detect AI agent identities?
Yes. AI agents typically appear as OAuth apps, service accounts, API tokens, or Entra service principals — all of which Icite inventories. For deeper AI-agent-specific discovery (e.g., agent-to-agent delegation chains, MCP server credentials), see the Agent Identities page.

How does Icite compare on NHI posture scoring?
Icite scores NHI posture using the same weighted methodology as human identity posture — stale accounts (no activity in N days), over-privileged tokens (scopes vs usage), expired-but-not-revoked credentials, orphaned NHIs (no derivable owner), OAuth apps with unused grants. NHIs appear in the overall tenant posture score alongside human identities.