What breaks when organisations treat provisioning as the same thing as security control?

Why This Matters for Security Teams

Provisioning is a starting action, not a control objective. It creates an identity or grants access, but it does not answer whether that access is still required, who owns it, or whether the privilege set has drifted. When teams mistake account creation for security, they leave exposed service accounts, stale API keys, and unmanaged secrets in place long after the original business need has ended.

This matters because security programs are measured on containment, traceability, and revocation, not on how quickly an account was created. The State of Non-Human Identity Security shows that lack of credential rotation remains a leading cause of NHI-related attacks, alongside inadequate monitoring and over-privileged accounts. That pattern is exactly what happens when provisioning is treated as the control itself. The NIST Cybersecurity Framework 2.0 frames identity as part of ongoing governance, not a one-time setup step.

In practice, many security teams discover the gap only after an incident review reveals that the account was provisioned correctly but never reviewed, rotated, or retired.

How It Works in Practice

Effective NHI security separates access issuance from access assurance. Provisioning creates the credential or workload identity, but security control adds the lifecycle checks that keep it safe: ownership, expiration, rotation, logging, approval, and revocation. For autonomous systems and service workloads, that usually means using short-lived credentials, workload identity, and policy enforcement that is evaluated at request time rather than at initial issuance.

The practical model is closer to lifecycle governance than traditional joiner-mover-leaver automation. A secure workflow typically includes:

• Assigning a clear owner for every non-human identity at the time of creation.
• Issuing the narrowest possible privileges and reviewing them regularly.
• Using NHI Lifecycle Management Guide principles to define when credentials must expire, rotate, or be revoked.
• Logging every use of secrets, tokens, and API keys so access can be investigated later.
• Linking provisioning systems to policy engines so an identity cannot persist without an active business purpose.

For workload-heavy environments, current guidance suggests pairing this with runtime identity signals from SPIFFE and policy enforcement aligned to Zero Trust. The issue is not just where the credential came from, but whether the system can prove, at the moment of use, that the identity is still legitimate. NHIMG research on the Ultimate Guide to NHIs reinforces that lifecycle failures and weak rotation are common root causes of exposure.

These controls tend to break down when provisioning is embedded in CI/CD or infrastructure-as-code pipelines without a separate owner review and automated revocation path, because identities are created faster than governance can follow.

Common Variations and Edge Cases

Tighter lifecycle control often increases operational overhead, requiring organisations to balance speed of delivery against the cost of review, rotation, and revocation. That tradeoff is real, especially where workloads are ephemeral, highly distributed, or shared across teams.

There is no universal standard for this yet, but current guidance suggests the following distinctions matter:

• Ephemeral build agents may need very short TTLs and automatic teardown, while long-lived service accounts need stronger review and owner attestations.
• Third-party integrations can appear properly provisioned even when the real risk sits in delegated OAuth access or shadow API tokens.
• Some environments can tolerate automated rotation, but others need change windows because downstream systems still depend on static secrets.

The common failure mode is assuming that a successful provisioning ticket means the identity is governed. It does not. A control only exists when the organisation can prove the identity is still needed, still monitored, and still removable. NHIMG’s Top 10 NHI Issues and the identity governance expectations in NIST Cybersecurity Framework 2.0 both point to the same operational reality: provisioning without lifecycle enforcement leaves standing access behind.

Related resources from NHI Mgmt Group

• What breaks when organisations manage human and machine privilege the same way?
• What breaks when organisations treat cryptographic migration as a one-time project?
• When should organisations treat an NHI as a high-priority risk?
• Should organisations treat agent audit logs as a security control?