What breaks when organisations rely on manual identity provisioning and revocation?

Why This Matters for Security Teams

Manual provisioning and revocation turn identity into a human workflow problem, but identities themselves operate on machine speed. That mismatch creates the real risk: access arrives late, leaves late, and is rarely applied consistently across SaaS, cloud, CI/CD, and service accounts. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. In practice, manual queues often stretch far beyond the business event that triggered them.

That delay matters because stale access is not just an audit issue, it is an exposure issue. NIST control guidance in SP 800-53 Rev. 5 Security and Privacy Controls expects disciplined account and credential lifecycle management, but many environments still rely on tickets, spreadsheets, and email approvals. NHI Management Group’s Top 10 NHI Issues highlights why that gap keeps showing up in real incidents: identity sprawl grows faster than human review can contain it. In practice, many security teams discover stale access only after a joiner-mover-leaver event has already become a breach path.

How It Works in Practice

Manual identity operations fail because they depend on people noticing every change, translating it into the right control action, and completing it before the access window becomes risky. For humans, that creates onboarding delays and orphaned entitlements. For NHIs, the failure mode is worse: service accounts, API keys, certificates, and tokens continue to function after the application, owner, or vendor relationship has changed.

The operational alternative is lifecycle automation tied to authoritative events. That means provisioning identities from source-of-truth systems, issuing access only when a task or system state requires it, and revoking or rotating credentials automatically when the event ends. NHI Management Group’s NHI Lifecycle Management Guide frames this as a repeatable process, not an occasional cleanup activity. For control design, NIST does not prescribe a single tool, but SP 800-53 Rev. 5 aligns the practitioner expectation: access should be approved, enforced, reviewed, and removed with evidence.

• Use HR, CMDB, IAM, or workflow events to trigger provisioning and deprovisioning.
• Separate human identity workflows from machine identity workflows, because their lifecycles differ.
• Prefer short-lived credentials and automated rotation over static secrets kept by hand.
• Log issuance, use, and revocation so audit teams can prove when access actually ended.

Where teams usually get this wrong is by automating onboarding but leaving revocation manual, which creates a false sense of maturity and leaves access active in the systems that matter most.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead at first, requiring organisations to balance speed of delivery against assurance and clean revocation. That tradeoff is real in hybrid estates, regulated environments, and vendor-managed platforms where direct automation is limited.

Some exceptions need special handling. Shared service accounts may require staged migration before full automation. Legacy systems may not support API-based deprovisioning, so compensating controls such as vault-based rotation, network restrictions, or privileged session monitoring become necessary. In federated environments, best practice is evolving, and there is no universal standard for every offboarding workflow, especially when third-party operators hold part of the lifecycle. The practical test is whether access can be removed deterministically, not whether a ticket was closed.

The biggest edge case is third-party and cross-region access, where manual reviews often lag behind contract changes or business exits. NHI Management Group’s 52 NHI Breaches Analysis and Lifecycle Processes for Managing NHIs show how often stale credentials survive long after the event that should have ended them. In those environments, manual revocation tends to break down when ownership is split across teams, because no single reviewer sees the full path from creation to retirement.

Related resources from NHI Mgmt Group

• What breaks when organisations rely only on document imaging for remote onboarding?
• What breaks when organisations rely on spreadsheets for machine identity management?
• What breaks when SaaS applications rely on manual provisioning?
• What breaks when organisations rely on manual data classification for AI security?