Notifications
Clear all
Topic starter
06/06/2026 1:57 am
TL;DR: Ungoverned credentials, fragmented workflows, and late-stage remediation leave NHI risk baked in before teams can react, according to Oasis Security, whose NHI provisioning capability creates and governs non-human identities from the start, with policy enforcement, ownership assignment, vaulting, rotation, and deprovisioning set during request approval and applied through the lifecycle.
NHIMG editorial — what this means for NHI practitioners
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.
Questions worth separating out
Q: What breaks when NHI provisioning happens without ownership and policy at creation time?
A: The identity enters production already outside governance.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full announcement
Oasis Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The request-to-approval workflow across Terraform, ServiceNow, API triggers, and the Oasis UI for provisioning NHIs.
- The step-by-step identity generation flow for Azure service principals and how the platform tags created identities.
- The secret generation and vaulting path, including how the Oasis Outpost keeps sensitive operations inside the customer perimeter.
- The notification and lifecycle events that follow provisioning, including ownership assignment, success alerts, and error handling.
👉 Read Oasis Security's blog on NHI provisioning from day one →
Oasis NHI provisioning and the governance gap teams still miss?
Explore further
06/06/2026 3:20 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Oasis NHI provisioning shifts identity governance left from day one
