What is the difference between onboarding access and NHI provisioning?

Why This Matters for Security Teams

Teams often use “onboarding” and “provisioning” interchangeably, but the difference changes how access should be approved, monitored, and revoked. Human onboarding is tied to employment, manager sponsorship, and a predictable life cycle. NHI provisioning is tied to a workload, integration, or automation that can outlive a person and act continuously. That makes the security concern less about welcome flows and more about standing authority, ownership, and secret handling.

The practical risk is that human processes are often reused for machine access, which leaves long-lived credentials in place after the original business need has faded. NHI guidance in the Ultimate Guide to NHIs and the Top 10 NHI Issues shows why this matters: NHIs outnumber humans by a wide margin, and only 20% of organisations have formal offboarding and API key revocation processes. Current guidance from the OWASP Non-Human Identity Top 10 treats lifecycle control as a first-class security problem, not an admin task.

In practice, many security teams encounter overexposed service access only after a workload has already been repurposed, duplicated, or forgotten.

How It Works in Practice

Human onboarding usually starts with identity proofing, role assignment, and a manager or HR signal that justifies access. NHI provisioning starts with a workload need: an app, pipeline, bot, agent, integration, or device must prove what it is, what it may do, and how long that authority lasts. That is why NHI provisioning should be treated as cryptographic and operational setup, not employee administration.

In mature environments, the access path includes workload identity, least privilege, and short-lived secrets. A service account, API key, certificate, or token should be issued for a specific purpose, tied to an owner, and rotated or revoked on a schedule that matches operational risk. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the NHI Lifecycle Management Guide are useful references for defining those stages. OWASP also advises that NHI controls should emphasise rotation, secret storage discipline, and revocation readiness rather than one-time approval.

• Assign an accountable system owner, not just a request approver.
• Use just-in-time access or ephemeral secrets where the task allows it.
• Store secrets in a managed vault, not in code, tickets, or chat.
• Set explicit expiry and revocation triggers for every credential.
• Review whether the workload still needs its current privileges after each release or integration change.

The distinction also affects governance tooling: HR systems can trigger onboarding, but they cannot reliably govern machine-to-machine authority. These controls tend to break down when shared service accounts are reused across multiple applications because ownership, logging, and revocation become ambiguous.

Common Variations and Edge Cases

Tighter provisioning often increases operational overhead, requiring organisations to balance speed against control. That tradeoff is most visible in CI/CD, ephemeral jobs, and agentic systems, where access needs to appear quickly and disappear just as quickly. For those cases, best practice is evolving toward intent-based approval and policy evaluation at request time, rather than broad pre-issued entitlements. The exact model is not universal yet.

Shared service accounts are a common exception, but they should be treated as temporary technical debt rather than a stable design pattern. Another edge case is third-party automation, where the requester, operator, and beneficiary may all be different. In that environment, the question is not “who was onboarded?” but “which workload is authorised, under what conditions, and for how long?” The 52 NHI Breaches Analysis and Ultimate Guide to NHIs — Key Challenges and Risks both underline how quickly poor lifecycle boundaries turn into exposure. One useful data point from NHI Mgmt Group is that 91.6% of secrets remain valid five days after notification, which shows how slowly many revocation processes still move. The right operational response is to design for fast ownership transfer, fast expiry, and immediate revocation when the workload changes or disappears.

Where environments rely on legacy apps without workload identity or secret automation, this guidance breaks down because manual provisioning cannot keep pace with machine-speed access changes.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between human IAM controls and NHI governance?