Oasis NHI provisioning shifts identity governance left from day one

At a glance

What this is: This is an analysis of Oasis Security's NHI provisioning capability and its claim that governing identities from day one reduces sprawl, misconfiguration, and audit friction.

Why it matters: It matters because IAM teams have to design provisioning, ownership, and lifecycle controls for NHIs and human identities before access is created, not after exceptions accumulate.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps - 38% have no or low visibility, and a further 47% have only partial visibility.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Oasis Security's blog on NHI provisioning from day one

Context

NHI provisioning is the control point where a service account, token, certificate, or federated identity first enters the environment. If provisioning happens outside policy, later rotation or review can only clean up after exposure has already been created, which is why day-one governance is the real boundary that matters for NHI security.

Oasis Security's announcement is about moving that boundary earlier in the lifecycle by tying approval, identity creation, ownership, vaulting, rotation, and deprovisioning together. That framing is relevant to cloud, DevSecOps, and audit teams because it treats identity creation as a governed event, not a technical side effect, and it aligns closely with the lifecycle emphasis in the NHI Lifecycle Management Guide.

Key questions

Q: What breaks when NHI provisioning happens without ownership and policy at creation time?

A: The identity enters production already outside governance. Ownership, rotation, and decommissioning then become reactive clean-up tasks instead of built-in controls, which increases the chance of orphaned credentials, inconsistent vaulting, and delayed audit response. Provisioning is the moment when intent should be fixed, not inferred later from usage.

Q: Why do NHI provisioning mistakes create long-term security risk?

A: Because provisioning decisions define the identity's trust boundary before anyone has a chance to review behaviour. If the wrong vault, wrong secret model, or no owner is attached at creation, the resulting identity can remain valid for months while carrying avoidable exposure. That is why creation-time controls matter more than after-the-fact cleanup.

Q: How do security teams know whether NHI provisioning is actually governed?

A: Look for three signals: every identity has an owner, every secret lands in an approved storage path, and every new object appears immediately in inventory and lifecycle workflows. If any of those is missing, provisioning is still operating as a delivery process rather than a governance process.

Q: How should teams choose between credential-based and federated NHIs?

A: Use federated identity when the workload can authenticate through trust relationships instead of storing a secret. Use credential-based identities only when the use case truly requires a managed credential, and then enforce vaulting, rotation, and offboarding from day one. The decision should be driven by governance risk, not developer convenience alone.

How it works in practice

Provisioning as the first governance decision

NHI provisioning is not just account creation. It is the point where ownership, intended use, credential type, vault destination, and policy scope are fixed. If those fields are omitted, every downstream control inherits ambiguity. The technical difference between credential-based and federated identities also matters. Federated identities reduce secret handling, while credential-based identities depend on secure generation, storage, and rotation paths. When provisioning is integrated into request workflows, the identity itself becomes a governed object from the start rather than an unmanaged byproduct of deployment.

Practical implication: Treat provisioning as a policy gate, not an admin task, and require ownership and lifecycle settings before an identity is created.

Secret generation, vaulting, and perimeter control

For credential-based NHIs, the main risk is not just issuance but where the secret exists and who can reach it. A secure model generates the credential, stores it in a controlled vault, and keeps the sensitive operation inside the customer perimeter. That reduces exposure during creation and avoids creating a backdoor path between orchestration and secret material. The design also separates control messages from credentials, which matters because metadata flows are far easier to secure and monitor than secret transport.

Practical implication: Keep secret creation and storage inside controlled infrastructure, and verify that provisioning systems never transmit raw credentials across trust boundaries.

Lifecycle automation and policy enforcement

Once an NHI is created, governance only works if policy follows the identity through its lifecycle. That includes rotation cadence, ownership assignment, decommissioning rules, notification, and attestation signals. A provisioning workflow that feeds directly into inventory and policy engines can activate monitoring, cleanup, and posture checks immediately. The deeper point is that lifecycle controls lose value when they are disconnected from creation. If an identity is not born with governance metadata, teams later have to infer intent from usage patterns, which is far weaker.

Practical implication: Link provisioning to inventory, policy enforcement, and deprovisioning so governance is attached to the identity before first use.

NHI Mgmt Group analysis

Day-one governance is the real control boundary for NHIs. If ownership, vaulting, and decommissioning are not defined at creation time, the identity enters the estate already outside effective control. Later rotation or attestation can reduce exposure, but it cannot undo the fact that the trust model was established without governance. Practitioners should treat provisioning as the first and most important lifecycle decision, not a ticketing step.

Unauthorised NHI growth starts with provisioning drift, not just secret sprawl. A team can manage secret storage well and still lose control if identities are created outside standard approval and ownership flows. The important failure mode is uncontrolled identity creation with incomplete metadata, because that leaves inventory, attestation, and deprovisioning blind. The implication is that provisioning policy must be as strict as access policy.

Day-one policy enforcement is more valuable than retroactive cleanup. Once NHIs are live, cleanup work tends to chase the environment instead of shaping it. Policy attached at request time creates a stable record of intended access, ownership, and lifecycle handling that downstream controls can rely on. That is why governance teams should prioritise creation-time enforcement over post-creation remediation.

NHI Lifecycle Management Guide alignment matters because lifecycle is the discipline, not the tooling. Provisioning, rotation, ownership discovery, and offboarding are not separate problems. They are one governance chain, and weak links at creation propagate through the rest of the chain. Teams that separate these controls into disconnected workstreams will keep producing identities that are technically valid but operationally ungoverned.

Federated identity is a governance choice, not just an engineering preference. When a workload can be created without a long-lived secret, the security model changes materially. That does not eliminate governance requirements, but it changes what has to be managed and what failure modes matter most. Practitioners should evaluate identity type selection as part of control design, not as a pure developer convenience decision.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot verify whether provisioning controls are actually holding in practice.
• The NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding fit together when identity governance starts at creation.

What this signals

Day-one governance will become the default expectation for NHI programmes. As provisioning moves closer to policy and ownership, teams that still rely on post-creation review will find their control model increasingly out of step with how identities are actually deployed. The practical shift is from remediating identities after they exist to refusing to create them without lifecycle metadata.

Provisioning and lifecycle controls are converging into one operating model. That matters because the same workflow now has to satisfy developers, IAM, audit, and security operations. Teams should expect greater pressure to connect request approval, identity inventory, rotation, and offboarding into a single chain of evidence, not separate tools and queues.

A useful concept here is identity birthright risk: the exposure created when an NHI is issued without the ownership, vaulting, and policy context it needs to remain governable. Once that pattern becomes visible, the right question is no longer whether provisioning is automated. It is whether the automation creates control or simply scales the mistake. See also Top 10 NHI Issues and NIST Cybersecurity Framework 2.0.

For practitioners

• Move ownership assignment into the provisioning request Require every new NHI to have an owner or owner group before issuance, and block creation if that metadata is missing. Tie the owner to attestation and decommissioning responsibilities so cleanup does not depend on tribal knowledge.
• Make vault destination a provisioning control Force the requester to select the approved vault or federated pattern during creation, and reject identities that would place secrets in unmanaged locations. Use the NHI Lifecycle Management Guide to standardise how provisioning links to rotation and offboarding.
• Separate credential-based and federated identity decisions Choose federated identity where the use case allows it, and reserve credential-based identities for cases that truly need secrets. Document the business reason for each exception so teams can audit why a long-lived credential exists.
• Wire provisioning into inventory and policy enforcement Ensure each newly created identity is immediately visible in inventory, posture checks, and lifecycle policy workflows. That prevents identities from existing in a gap between creation and governance activation.

Key takeaways

• NHI provisioning is a governance decision, not just an operational workflow, because it sets the identity's ownership, vaulting, and lifecycle boundaries.
• The real security risk is provisioning drift, where identities are created faster than policy, inventory, and decommissioning controls can keep up.
• Teams that attach lifecycle controls at creation time reduce orphaned identities, audit gaps, and the need for retroactive cleanup.

Key terms

• Non-Human Identity Provisioning: The process of creating a machine or service identity and attaching the controls it needs before first use. In mature programmes, provisioning defines ownership, vaulting, lifecycle rules, and policy scope at the moment the identity is issued, so governance starts before exposure can accumulate.
• Federated Identity: An identity that authenticates through trust relationships instead of storing a long-lived secret directly. For NHIs, this reduces secret handling and can shrink attack surface, but it still requires ownership, policy, and lifecycle controls so the trust relationship does not become an unmanaged access path.
• Lifecycle Governance: The set of controls that manage an identity from creation through rotation, review, and deprovisioning. For NHIs, lifecycle governance is the discipline that keeps technical identities tied to business ownership and prevents valid credentials from outliving their purpose.
• Identity Inventory: The authoritative record of identities, their owners, and their current access state. For NHI programmes, inventory is essential because provisioning without immediate visibility creates blind spots that make rotation, attestation, and offboarding unreliable.

Deepen your knowledge

NHI provisioning and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme from a day-one provisioning starting point, it is worth exploring.

This post draws on content published by Oasis Security: Introducing Oasis NHI Provisioning and its day-one governance model. Read the original.