Direct provisioning means writing accounts, entitlements, or permissions straight into a target application rather than routing every change through an intermediary identity provider. It can reduce friction, but it also concentrates trust, audit, and rollback requirements into the connector itself.
Expanded Definition
Direct provisioning is the practice of writing accounts, entitlements, or permissions straight into a target application or platform instead of sending every change through an intermediary identity provider or orchestration layer. In NHI operations, this usually appears when service accounts, API clients, or application roles are created locally in the system they protect, then updated by connector logic rather than central policy alone.
Definitions vary across vendors because some teams use the term for any local account creation, while others reserve it for fully autonomous write operations that bypass standard identity workflows. The operational distinction matters: direct provisioning can be a legitimate design choice for systems with limited federation support, but it also increases the number of places where trust, audit evidence, and revocation logic must be maintained. That makes it especially relevant to lifecycle control, connector reliability, and rollback planning, as discussed in the NHI Lifecycle Management Guide and the NIST Cybersecurity Framework 2.0.
The most common misapplication is treating direct provisioning as harmless convenience, which occurs when teams add accounts locally without a documented source of truth or deprovisioning path.
Examples and Use Cases
Implementing direct provisioning rigorously often introduces connector complexity, requiring organisations to weigh faster application onboarding against weaker central visibility and more difficult rollback.
- A legacy SaaS platform cannot federate with an enterprise directory, so an automation job writes a service account directly into the app and stores the mapping in a change log.
- A CI/CD tool creates short-lived deployer credentials in a target environment through an API, then later removes them when the pipeline ends, rather than depending on a separate identity broker.
- An internal database plugin assigns local roles to an application account because the platform does not support external group claims, creating a need for careful review of entitlements and expiry.
- A merger integration team temporarily uses direct provisioning to bridge two identity stacks while building a longer-term federation model, a pattern that should be documented and time-boxed.
- Teams studying local account sprawl often begin with the attack patterns summarized in Top 10 NHI Issues and then compare their provisioning model to guidance in NIST Cybersecurity Framework 2.0.
In practice, direct provisioning is most defensible when the target system lacks safe federation, but it should still be constrained by approval, expiry, and reconciliation controls.
Why It Matters in NHI Security
Direct provisioning matters because it shifts the security burden from a central identity layer into the connector, target system, and surrounding operational process. That creates a larger attack surface for mis-scoped permissions, stale service accounts, and broken revocation, especially where changes are made quickly to keep automation running. NHI Management Group research shows that 97% of NHIs carry excessive privileges, and direct provisioning can make that problem harder to detect when entitlements are written locally and reviewed only after an incident.
It also affects governance. If the provisioner cannot reliably prove what was created, when it was removed, and under whose authority, audit and incident response become fragmented. The issue is not that direct provisioning is always wrong, but that it demands stronger reconciliation, stricter ownership, and better lifecycle controls than many teams initially build. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is especially relevant here because lifecycle discipline becomes the control plane when provisioning is local. Organisations typically encounter the true cost of direct provisioning only after a stale account, leaked key, or privilege escalation forces emergency offboarding, at which point the model 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 | Direct provisioning can create unmanaged account paths and weak lifecycle oversight. |
| NIST CSF 2.0 | PR.AC-4 | Local entitlement writes must still enforce least privilege and access review discipline. |
| NIST Zero Trust (SP 800-207) | Zero Trust favors continuous verification over implicit trust in connector-written access. |
Treat directly provisioned access as continuously verified and remove it when policy or context changes.
Related resources from NHI Mgmt Group
- What is the difference between direct access and effective access in Active Directory?
- What is the difference between IAM roles and direct API keys for AI workloads?
- What is the difference between direct account compromise and SaaS supply chain compromise?
- What is the difference between just-in-time provisioning and just-in-time access?
