Provisioning is the creation of access and de-provisioning is the removal of it. The control value lies in how reliably those actions propagate across connected systems, because partial removal leaves residual access and audit gaps.
Expanded Definition
Provisioning and de-provisioning are lifecycle controls for Non-Human Identity access: creating the access an agent, service account, workload, or integration needs, then removing that access when it is no longer required. In NHI operations, the term covers more than account creation and deletion. It includes entitlement assignment, secret issuance, key distribution, dependency updates, revocation, and confirmation that every connected system has actually processed the change. That end-to-end propagation is what separates a clean lifecycle from a fragile one. The NIST Cybersecurity Framework 2.0 treats access control and asset governance as ongoing functions, which aligns with how NHI lifecycle work must be continuously verified rather than assumed complete.
Definitions vary across vendors on whether de-provisioning means immediate revocation, queued revocation, or eventual cleanup after token expiry, so governance teams should document the required latency and evidence of completion. In practice, provisioning is often tied to identity onboarding and approval workflows, while de-provisioning must account for cached credentials, replicated secrets, CI/CD variables, and delegated access paths. The most common misapplication is treating account disablement as full de-provisioning, which occurs when tokens, certificates, and downstream entitlements remain active after the primary account is removed.
Examples and Use Cases
Implementing provisioning and de-provisioning rigorously often introduces orchestration overhead, requiring organisations to weigh faster deployment against stronger access hygiene and auditability.
- A deployment pipeline provisions a short-lived service account for a new microservice, then revokes its tokens and vault access when the service is retired, following the lifecycle principles in the NHI Lifecycle Management Guide.
- A cloud workload receives just enough API permissions to publish events, and those permissions are removed automatically when the workload is scaled down or replaced.
- A third-party integration is approved with scoped secrets, then de-provisioned across the identity provider, secrets manager, and downstream SaaS application during vendor offboarding, a pattern highlighted in the Ultimate Guide to NHIs.
- An expired certificate is replaced before cutover, while the old certificate is explicitly revoked so the prior trust path cannot be reused.
- An API key is removed from code, but also invalidated in the vault and in every environment variable store to prevent lingering access paths, a failure mode often discussed in Top 10 NHI Issues.
Lifecycle automation should preserve an audit trail showing who approved the change, where it propagated, and whether any dependent systems reported failure or delay.
Why It Matters in NHI Security
Weak provisioning and de-provisioning is one of the fastest ways to create residual access, and residual access is especially dangerous for NHIs because machine credentials are often copied, cached, or embedded in automation. When de-provisioning is incomplete, orphaned secrets and over-retained entitlements can survive long after the owning application, team, or vendor relationship has changed. NHIMG reports that only 20% of organisations have formal processes for offboarding and revoking API keys, which means most environments are likely to retain at least some stale machine access after business or technical changes.
That gap undermines least privilege, inflates audit scope, and creates blind spots during incident response. It also makes Zero Trust implementation brittle, because trust decisions continue to rely on identities that should already have been removed. The operational issue is not simply whether an account exists, but whether every token, key, certificate, and delegated permission tied to it has been invalidated. Organisationally, this becomes visible only after a breach review, SaaS offboarding, or failed rotation exposes that access was never fully withdrawn, at which point provisioning and de-provisioning become 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 | Lifecycle provisioning and revocation are core NHI hygiene controls. |
| NIST CSF 2.0 | PR.AC-1 | Access management guidance covers authorisation, review, and removal of privileges. |
| NIST Zero Trust (SP 800-207) | PR.AC | Zero Trust requires continuous verification of identity and access state. |
Revalidate machine access continuously and revoke trust immediately when the identity is no longer needed.
