A provisioning path is the mechanism that creates, updates, or removes access for an identity. It may use SCIM, connectors, directory sync, or embedded automation. If the path is hard to maintain or weakly audited, entitlements drift away from policy and access becomes durable by accident.
Expanded Definition
A provisioning path is the operational route that creates, modifies, or removes access for an identity, including service accounts, workload identities, and human users when those identities are governed through the same control plane. In NHI programs, the term usually covers SCIM-based provisioning, directory synchronization, connector-driven workflows, and embedded automation that writes entitlements into downstream systems. The distinction matters because the path is not the entitlement itself; it is the mechanism that enforces policy, timing, and auditability across the identity lifecycle.
Definitions vary across vendors when orchestration, lifecycle management, and entitlement provisioning are bundled into one product story, so practitioners should separate the policy decision from the delivery mechanism. That separation aligns with lifecycle guidance in the NHI Lifecycle Management Guide and with the access governance model in the NIST Cybersecurity Framework 2.0. A strong provisioning path is observable, reversible, and mapped to approval logic, while a weak one quietly accumulates exceptions, stale grants, and orphaned identities.
The most common misapplication is treating a one-time account creation workflow as a complete provisioning path, which occurs when teams ignore updates, revocation, and downstream synchronization.
Examples and Use Cases
Implementing provisioning paths rigorously often introduces integration and governance overhead, requiring organisations to weigh faster access delivery against tighter audit, review, and change-control requirements.
- SCIM automatically creates and revokes SaaS access when a service account is onboarded or decommissioned, reducing manual ticket handling.
- A directory sync updates group membership for an application role, but only if the target app accepts mapped attributes without custom code.
- A connector-based workflow provisions cloud API keys after approval, then records the event for later review in identity governance tooling.
- Embedded automation in CI/CD grants a build agent temporary access to a registry, then removes it after the pipeline completes.
- A manual exception path creates persistent access for a legacy system, which should be documented because it often becomes a drift source.
In practice, the most useful patterns are those that can be traced from source of truth to target system and back again. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs describes why lifecycle steps must remain explicit, while the same pattern is reflected in NIST Cybersecurity Framework 2.0 guidance on controlled access management.
Why It Matters in NHI Security
Provisioning paths matter because they determine whether entitlements are short-lived, reviewable, and policy-driven, or durable by accident. In NHI environments, a broken path can leave service accounts overprivileged, keep expired secrets active, or fail to remove access after a workload is retired. That creates attack surface far beyond the original request because access drift becomes distributed across directories, apps, cloud control planes, and pipelines. The NHIMG research data shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which makes weak provisioning paths a direct contributor to persistent NHI exposure.
Good governance requires visibility into where the path starts, who approves it, what system of record it follows, and how revocation is confirmed. The Top 10 NHI Issues highlights how lifecycle gaps and weak control points turn routine access changes into security defects. Practitioners should also recognize that a path can be technically functional while still being insecure if it bypasses policy checks, logs too little, or leaves no evidence of removal. Organisations typically encounter the consequences only after an account review, incident response, or audit finds that access was never fully removed, at which point the provisioning path becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers lifecycle and access governance issues where provisioning paths create or remove NHI access. |
| NIST CSF 2.0 | PR.AC | Access control outcomes depend on provisioning paths that enforce least privilege and timely revocation. |
| NIST Zero Trust (SP 800-207) | Zero Trust depends on continuous, policy-based access enforcement rather than static provisioning. |
Tie provisioning workflows to access control objectives and review them for drift, delay, and orphaned access.
Related resources from NHI Mgmt Group
- Why do leaked secrets need a different reporting path than ordinary software bugs?
- What is the difference between just-in-time provisioning and just-in-time access?
- What is the difference between access certification and provisioning?
- What is the difference between onboarding access and NHI provisioning?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
