Notifications
Clear all
Topic starter
08/06/2026 4:29 pm
TL;DR: Access requests can stall when approvers are unavailable, so SLA escalation policies automate routing changes, policy switching, or cancellation when approval deadlines are missed, according to ConductorOne. The governance lesson is that access workflows need time-bound enforcement, but they still depend on the quality of the underlying approval model.
NHIMG editorial — based on content published by ConductorOne: How SLA Escalation Policies Work in C1
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
Questions worth separating out
Q: How should security teams design SLA escalation for access approvals?
A: Security teams should design SLA escalation around request risk, not convenience.
Q: When does SLA escalation create more risk than it reduces?
A: SLA escalation creates more risk when the fallback path is easier to trigger than the original review, or when replacement approvers lack the context to make a sound decision.
Q: What do access teams get wrong about approval delays?
A: Teams often treat delays as a workflow nuisance instead of a governance signal.
Practitioner guidance
- Map escalation branches to access risk tiers Apply stricter escalation rules to privileged, production, and third-party access than to low-risk requests.
- Document the fallback approval authority Define who can replace an unavailable approver, who can switch the policy path, and who can cancel the request.
- Log every SLA breach as a governance event Record the missed SLA, the resulting action, and the reason the request moved forward.
What's in the full article
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step configuration options for SLA durations across multi-step approval policies
- Examples of escalation actions, including approver replacement, policy switching, and cancellation
- How the ticketing system records SLA violations for audit visibility
- The planned Thomas AI agent context-evaluation approach for dynamic escalation
👉 Read ConductorOne's blog on SLA escalation policies for access approvals →
SLA escalation policies for access approvals: where do they help most?
Explore further
08/06/2026 6:10 pm
Static approval chains expose a workflow dependency problem, not just a user-experience problem. Access governance breaks down when a request can only move if one specific approver is available on time. SLA escalation policies are an answer to bottlenecks, but the deeper lesson is that identity programmes still rely on human-paced approval assumptions even when the business expects uninterrupted access. Practitioners should treat delay tolerance as a design variable, not an afterthought.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who should be able to override or reroute a stalled access request?
A: Only clearly defined governance roles should be able to replace approvers, switch policy paths, or cancel a stalled request. The authority should be separate from the requester and separate from the original approver. That separation prevents escalation from becoming an informal approval shortcut.
👉 Read our full editorial: SLA escalation policies expose the limits of static approval workflows
