TL;DR: Identity operations often stall in a semi-async middle layer where workflows are neither truly interactive nor fully delegated, leaving teams supervising automation instead of trusting it, according to Redblock. The governance problem is not more tooling, but deciding which identity tasks belong in human-paced review and which require auditable autonomous execution.
NHIMG editorial — based on content published by Redblock: Identity’s Real Problem Isn’t Tools. It’s the Semi-Async Middle Layer Where Automation Fails
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: How should security teams decide which identity controls to automate first?
A: Start with high-volume, repeatable tasks that create delay when handled manually, such as access review routing, entitlement reminders, and offboarding follow-up.
Q: Why do semi-async identity workflows create more governance risk than manual tasks?
A: They create risk because they look controlled while still depending on humans to catch failures.
Q: What breaks when identity automation stops at connected applications?
A: Lifecycle management breaks first, then access review quality, then confidence in the overall identity programme.
Practitioner guidance
- Classify identity workflows by execution mode Separate tasks into synchronous human review, supervised automation, and fully delegated autonomous execution so the control model matches the actual work.
- Map disconnected apps to their control path Inventory which applications can support API-based governance, which require UI-assisted execution, and which still need manual handling with compensating controls.
- Define evidence requirements for autonomous identity actions Require every delegated identity action to produce auditable proof, including what changed, when it changed, and which boundary conditions applied.
What's in the full article
Redblock's full blog post covers the operational detail this post intentionally leaves for the source:
- The full walkthrough of the semi-async valley model and the identity execution modes behind it
- Specific examples of connector failures, CSV drift, and approval bottlenecks in production identity workflows
- The article's own framing of autonomous identity agents and where Redblock believes they belong in the stack
- The closing product context on replacing ticket-driven identity execution with continuous lifecycle enforcement
👉 Read Redblock's analysis of the semi-async identity middle layer →
Identity’s semi-async middle layer: are your controls keeping up?
Explore further
The semi-async identity middle layer is a governance failure, not an efficiency gap. Identity programmes do not fail here because teams lack dashboards or workflows. They fail because the operating model asks people to supervise automation that is neither trustworthy nor fully delegated. The implication is that control design must start with execution mode, not with another layer of orchestration.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who is accountable when an autonomous identity exceeds intended scope?
A: Accountability sits with the programme owners who defined the lifecycle, access, and monitoring model, not with the software actor itself. If no team owns actor classification, delegated authority, and revocation, then the gap is organisational, not technical. Governance must assign responsibility before the system acts.
👉 Read our full editorial: Identity’s semi-async middle is where automation fails