Day 0 provisioning is the initial creation of access, accounts, or policy bindings before a system enters routine operation. In identity governance, it is only the starting point. For infrastructure-managed identities, it must be followed by continuous review as deployments, connectors, and privileges change.
Expanded Definition
Day 0 provisioning is the first binding of identity, access, and policy before a workload, service account, API client, or agent enters production use. In Non-Human Identity operations, it establishes the baseline from which lifecycle controls should continue, as described in the NHI Lifecycle Management Guide.
Usage in the industry is still evolving because some teams treat Day 0 as a one-time onboarding event, while others treat it as the start of governed identity state. The distinction matters: a Day 0 process may create the initial credential, role, vault binding, or trust relationship, but it does not by itself prove the identity remains appropriate after deployment drift, connector changes, or privilege expansion. That is why NHI governance should connect initial provisioning to continuous review, and why the broader lifecycle model in Ultimate Guide to NHIs is more useful than a static joiner-only view.
From a control perspective, Day 0 provisioning overlaps with zero trust ideas in NIST Cybersecurity Framework 2.0, but it should not be mistaken for ongoing assurance. The most common misapplication is treating the initial account or secret issuance as full lifecycle governance, which occurs when deployment teams stop after creation and never revalidate scope, ownership, or revocation paths.
Examples and Use Cases
Implementing Day 0 provisioning rigorously often introduces coordination overhead, requiring organisations to balance deployment speed against the cost of tighter approvals, stronger identity bindings, and later rework if the initial setup is too permissive.
- A CI/CD pipeline creates a service account, assigns an RBAC role, and stores the secret in a vault before the first release, then hands the identity into continuous review under the practices described in the Top 10 NHI Issues.
- An AI Agent is provisioned with narrowly scoped tool access on launch day so it can call approved APIs, while later policy changes are tracked against Zero Standing Privilege expectations and reviewed with NIST Cybersecurity Framework 2.0.
- A temporary integration partner receives an API key and certificate at onboarding, but the initial trust relationship is paired with expiry, rotation, and offboarding requirements to prevent long-lived access from becoming normalised.
- A platform team provisions Kubernetes workload identities at deployment time, then links them to namespace policies so that later environment changes do not silently widen permissions.
- A secrets management workflow issues a short-lived credential at first run, but the owner also documents the revocation path so the identity can be shut down cleanly after testing or migration.
These examples align with the lifecycle emphasis in the NHI Lifecycle Management Guide, where creation is only one checkpoint in a longer operational chain.
Why It Matters in NHI Security
Day 0 provisioning matters because the first privileges assigned to an NHI often become the baseline everyone forgets to revisit. If that baseline is too broad, mis-scoped, or unowned, the organisation inherits unnecessary risk from the beginning. NHIMG research shows that 97% of NHIs carry excessive privileges, which makes early provisioning decisions especially consequential when identities are created faster than they are reviewed.
This is also where NIST-aligned governance becomes practical: initial provisioning should support least privilege, traceable ownership, and revocation-ready design rather than permanent trust. If teams only optimise for speed at launch, they often create service accounts, tokens, or agent credentials that remain active long after the original need has changed. The result is not just configuration debt, but exposure that can persist through connectors, automation jobs, and inherited permissions.
Practitioners typically encounter the true cost of Day 0 mistakes only after a breach review, failed audit, or emergency rotation, at which point the provisioning record 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 | Day 0 provisioning sets the initial NHI identity and access scope OWASP expects to be controlled. |
| NIST CSF 2.0 | PR.AC-1 | Initial access assignment must be controlled and traceable within identity and access management. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero Trust requires each newly provisioned identity to start with minimal implicit trust. |
Define and review initial NHI creation rules, ownership, and least-privilege scope before go-live.
