The NHI inventory problem
You cannot monitor what you don't know exists. Most enterprises have no complete inventory of their non-human identities — the service accounts were created by different teams at different times with different naming conventions, and they live in Okta, Entra ID, AWS IAM, GCP service accounts, GitHub Actions secrets, and a dozen SaaS applications simultaneously.
The first step in any NHI programme is discovery. ManySignal's entity graph populates NHI nodes automatically as connectors ingest events — any principal that appears in an audit log and is not matched to a human identity in the IdP is tagged as a non-human identity. This passive discovery is the baseline; augment it with active enumeration via cloud provider APIs.
For each discovered NHI, capture: owning team, purpose, permission scope, last used date, rotation policy, and associated secrets store. NHIs with no owning team, no stated purpose, or no activity in 90 days are orphaned credentials — they are the highest-risk category.
- Cloud IAM NHI enumeration: AWS (list-users, list-roles), GCP (service accounts), Azure (service principals)
- IdP service account enumeration: Okta API tokens, Entra ID app registrations
- GitHub Actions secrets and environments inventory
- Orphaned NHI identification: no owner, no activity in 90 days
- Permission scope audit: NHIs with admin or owner-level permissions
NHI classification and risk scoring
Classify NHIs by blast radius: Tier 1 (can create or modify other identities, can access sensitive data stores, can modify security controls), Tier 2 (can read sensitive data, can modify application configuration), Tier 3 (read-only, narrow scope). Tier 1 NHIs should have the same monitoring intensity as privileged human accounts.
Risk score each NHI on four dimensions: permission breadth (scoped vs broad), rotation status (rotating vs long-lived), usage recency (active vs stale), and owner accountability (known owner vs orphaned). The risk score drives monitoring priority and remediation sequencing.
NHI behavioural baselining
Non-human identities have narrower acceptable behaviour spaces than human identities — which makes them excellent anomaly detection targets. A service account that calls three specific API endpoints during business hours has a behaviour space of roughly 6 dimensions. Any deviation — new endpoint, new hour, new source IP, elevated volume — is high-signal.
ManySignal builds NHI baselines the same way as human identity baselines: 90-day rolling window, per-entity dimensions. The difference is the anomaly threshold: a human identity might need a 3-sigma deviation to trigger; an NHI with a narrow baseline might trigger at 2-sigma because the acceptable variance is smaller.
# detections/nhi/service_account_new_api_call.yaml
key: nhi.service_account_new_api_call
domain: identity
severity: high
type: behavioural
where:
identity_type: service_account
behavioural:
dimensions: [api_operation, target_resource_type, source_ip_asn]
baseline_days: 90
min_anomaly_score: 70
require_new_dimension_value: true
attck:
tactic: TA0008
techniques: [T1078.004]
stage: activeDetection patterns for NHI abuse
Three categories cover the majority of NHI abuse: (1) credential theft and misuse — an NHI credential being used from a new source IP or in a new geographic region; (2) permission escalation — an NHI assuming a role or acquiring permissions beyond its historical scope; (3) lateral movement — an NHI calling APIs in services or accounts it has never touched.
A particularly dangerous pattern is NHI-to-human-identity bridging: a service account that creates a new IAM user or adds a user to a privileged group. This is a persistence technique (T1136) that transforms a stolen service account credential into a durable human-facing backdoor.
NHI lifecycle management
Establish a machine identity lifecycle process: creation requires an owner and purpose, provisioned permissions must be justified, rotation policy must be set at creation time, and decommission triggers automatic credential revocation. Without a lifecycle process, the NHI inventory grows indefinitely and orphaned credentials accumulate.
Integrate the secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) as an entity graph source. When ManySignal detects that an NHI credential is being used and the credential is not registered in the secrets manager, that is a shadow credential — a high-severity finding warranting immediate investigation.
Key takeaways
- NHIs outnumber human identities 10:1 — they are under-monitored and over-permissioned.
- Discovery is the first step: passive entity graph population plus active cloud API enumeration.
- Classify by blast radius; Tier 1 NHIs get the same monitoring intensity as privileged humans.
- NHIs have narrower acceptable behaviour — anomaly thresholds should be tighter than for humans.
- NHI-to-human bridging (service account creates IAM user) is a critical persistence pattern.
- Long-lived credentials over 90 days without rotation are the highest-probability attack vector.