Oasis Security’s first year shows why NHI governance needs new controls

At a glance

What this is: Oasis Security’s first-year review argues that fragmented cloud and DevSecOps environments have expanded NHI sprawl and made centralized human-centric governance insufficient.

Why it matters: It matters because IAM, PAM, and NHI programmes now need lifecycle control, ownership, and continuous visibility across service accounts, tokens, keys, and automated workloads.

By the numbers:

• NHIs are everywhere, they outnumber human identities by a factor 20x on average, are highly privileged, and often unmanaged.
• 100% of identities mapped and every secret discovered is the stated visibility target in the post’s first-year summary.

👉 Read Oasis Security’s first-year review of NHI Security Cloud capabilities

Context

Cloud and SaaS adoption has fragmented the identity perimeter, which means each service can behave like its own identity provider. That breaks the old assumption that access can be centrally understood, reviewed, and governed through human-centric identity models alone. For NHI programmes, the problem is not just scale, but the loss of visibility into what each workload identity can reach and who owns it.

The post is really about governance debt in machine identity estates. Service accounts, API keys, access tokens, database users, and automation scripts accumulate faster than teams can inventory them, and DevSecOps often moves the control point out of the legacy IAM stack. For teams already building NHI lifecycle controls, the relevant baseline remains the Ultimate Guide to NHIs and the broader NHI governance model.

Key questions

Q: How should security teams govern service accounts and API keys across cloud platforms?

A: Treat them as lifecycle-managed identities, not static credentials. Centralise ownership, track where each identity is used, and require revocation paths for stale access. The goal is not just rotation, but visibility into who or what depends on each credential so decommissioning does not break production.

Q: Why do NHIs complicate zero trust architecture?

A: Zero trust assumes every access request can be evaluated continuously, but NHIs often spread across pipelines, vaults, applications, and cloud services with incomplete context. Without reliable ownership and usage data, least privilege becomes hard to prove and harder to enforce across the full machine identity estate.

Q: What breaks when NHI visibility is limited to inventory alone?

A: Teams can count identities without understanding their permissions, consumers, or business purpose. That creates a false sense of control, because attestation, remediation, and risk prioritisation all depend on context. Inventory without context is enough for reporting, but not enough for governance.

Q: How can teams reduce risk from stale non-human identities?

A: Use automated detection, verification, and safe decommissioning workflows for accounts and secrets that are no longer in use. Pair that with ownership reassignment and revocation evidence so the leaver process is visible, auditable, and repeatable across infrastructure and platform teams.

How it works in practice

Fragmented identity perimeters in cloud and SaaS

Modern cloud and SaaS estates often create separate identity control planes for each platform, vault, and pipeline. That makes a workload identity harder to govern because the subject, the secret, the permissions, and the consumer may live in different systems. When DevSecOps shifts control left, access can be created and used before central governance has a complete picture. The result is not just sprawl, but incomplete identity context that weakens ownership, attestation, and remediation.

Practical implication: map every NHI to its source system, downstream consumers, and owner before you can claim governance coverage.

Context reconstruction for NHI visibility

Visibility is not just inventory. Context reconstruction means correlating logs, IdP data, vault events, DSPM findings, and application telemetry to answer what an identity is, what it can access, and whether that usage matches intent. In NHI programmes, this matters because a secret or service account can be technically present but operationally opaque. The governance risk is that teams can count identities without understanding their actual blast radius.

Practical implication: build correlation across identity, secret, and usage telemetry so attestation is based on real behaviour, not static records.

Automated lifecycle controls for secrets and stale accounts

The post ties lifecycle management to two controls that matter most in machine identity estates: stale account decommissioning and secret rotation. Stale identities are dangerous because unused access tends to survive in tooling, code, and pipeline dependencies, while rotation reduces the persistence window for exposed credentials. The important detail is that the post frames both as governed automation, not one-off cleanup. That is the right architectural direction for high-churn NHI environments.

Practical implication: automate detection, verification, and safe decommissioning of stale NHIs and secrets before they become hidden standing privilege.

NHI Mgmt Group analysis

Identity perimeter fragmentation is now a governance problem, not an inventory problem. Once each cloud and SaaS service behaves like a separate identity provider, centralized review loses line of sight over machine identities. That means the programme cannot rely on a single authoritative directory to tell it what exists or who owns it. Practitioners should treat cross-platform identity correlation as the new baseline for NHI governance.

Context is the control gap that separates NHI visibility from real oversight. Counting identities is not the same as knowing their permissions, consumers, and business purpose. The post’s emphasis on context reconstruction is directionally correct because governance fails when teams know a secret exists but cannot tell what it touches or whether anyone is accountable for it. Practitioners should prioritize contextual ownership and usage mapping over raw inventory completeness.

Automated rotation and safe decommissioning are lifecycle controls, not convenience features. In machine identity estates, stale access and long-lived secrets create durable exposure that human-centric workflows rarely clean up quickly enough. This aligns with OWASP-NHI and NIST-CSF thinking on lifecycle discipline, where persistence is the real risk factor. Practitioners should design NHI lifecycle management around automated expiry, ownership, and revocation rather than manual exception handling.

Compliance reporting is only credible when it reflects operational control, not post hoc evidence assembly. PCI, NIST, and SOC 2 reporting become more useful when the underlying platform can show inventory, ownership, rotation, and decommissioning status continuously. The industry should read this as a signal that NHI governance is moving from point-in-time audit support to continuous control evidence. Practitioners should align reporting with live control states instead of treating audits as a separate process.

Expanded automation will raise the bar for autonomy-aware NHI governance. The post’s mention of AI-based analytics and autonomous rotation points to a future where identity controls themselves increasingly act without human timing. That does not make the estate autonomous in the strict sense, but it does mean governance teams must be clear about which actions are policy-driven and which are truly runtime decisions. Practitioners should separate automated execution from autonomous authority before extending trust.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which explains why lifecycle control so often lags behind discovery.
• 52 NHI Breaches Analysis shows how exposed machine identities turn visibility gaps into real incidents across cloud and SaaS estates.

What this signals

Identity sprawl is becoming a lifecycle governance problem for every NHI programme. When cloud, SaaS, vaults, and CI/CD systems each create their own identity surface, the operational challenge moves beyond discovery and into accountability. Teams should expect ownership, attestation, and offboarding to become the decisive controls, especially where secrets and service accounts outlive the business process that created them.

With 71% of NHIs not rotated within recommended time frames, per the Ultimate Guide to NHIs, the programme risk is persistence, not just exposure. That means lifecycle evidence must be continuous, not annual, and remediation has to be tied to actual usage patterns rather than scheduled review cycles.

Context reconstruction will become the differentiator between compliant inventory and real governance. As AI-driven analytics enter NHI platforms, the question for practitioners is whether those systems can prove ownership, consumer mapping, and entitlement validity in one place. That is the control layer boards will increasingly expect, because raw count data no longer tells them where the exposure really sits.

For practitioners

• Inventory identities across cloud and SaaS boundaries Build a canonical map that links each service account, token, API key, and database user to its parent system, owner, and downstream consumers. Prioritise identity sources that are currently outside central IdP control, including CI/CD and secret management tools.
• Correlate usage with ownership and entitlements Join audit logs, vault events, IdP metadata, and application telemetry so every NHI can be attested against real use. Do not accept inventory completeness unless you can explain who owns the identity and what it is actually doing.
• Automate stale NHI decommissioning Detect inactive or unconsumed identities, verify they are no longer required, and remove them through a controlled decommissioning workflow. Preserve evidence of the decision so offboarding remains auditable across infrastructure teams.
• Enforce policy-driven secret rotation Set rotation rules for secrets, access tokens, and keys based on risk and dependency criticality, then execute rotation through controlled automation. Pair each rotation cycle with validation that dependent services still function and that old credentials are revoked.
• Attach attestation to live identity state Base access reviews on current usage, current ownership, and current entitlements rather than static spreadsheets. Refresh attestations whenever an identity changes hands, changes purpose, or stops showing legitimate activity.

Key takeaways

• The post’s core message is that NHI sprawl has outgrown centralized human-centric governance models.
• The strongest evidence is not just more identities, but more identities that are opaque, overprivileged, and hard to retire.
• Practitioners should respond by tightening ownership, context, rotation, and decommissioning across the full machine identity lifecycle.

Key terms

• Non-Human Identity: A non-human identity is a machine or workload credential used by software, services, scripts, or integrations to authenticate and act in an environment. In practice, it includes service accounts, API keys, tokens, certificates, and similar credentials that need lifecycle governance, ownership, and revocation controls.
• Context Reconstruction: Context reconstruction is the process of combining identity data, logs, vault events, and application telemetry to understand what a non-human identity is, what it can reach, and why it exists. It turns raw inventory into governance-relevant evidence that can support ownership, attestation, and risk prioritisation.
• Lifecycle Management: Lifecycle management is the end-to-end control of identity creation, use, review, rotation, and retirement. For non-human identities, it must account for machine speed, hidden dependencies, and automated workloads so that access can be revoked safely without leaving standing privilege behind.
• Stale Identity: A stale identity is a credential or account that remains active after its business need has ended. In non-human estates, stale identities are especially risky because they are often embedded in code, pipelines, or integrations and can persist long after the original owner has moved on.

Deepen your knowledge

NHI lifecycle management, secret rotation, and ownership attestation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is already dealing with fragmented cloud identities, it is a useful place to build a stronger baseline.

This post draws on content published by Oasis Security: Celebrating the first year of Oasis NHI Security Cloud. Read the original.