Topic starter
13/10/2026 1:21 pm
TL;DR: Opal Security says on-call workflows can grant elevated access only when engineers are scheduled to respond, then revoke it automatically after the incident window closes. That shifts the control problem from static privileges to time-bound authorization, where access must be tied to incident context rather than employee status.
Editorial analysis by NHI Mgmt Group, based on content published by Opal Security: “From Detection to Resolution: How Opal and Rootly Secure On-Call Access”.
Key questions
Q: How should security teams implement on-call access without creating standing privilege?
A: Security teams should bind privileged access to an authoritative on-call signal, issue it only for the active duty window, and revoke it automatically when the duty ends.
Q: Why does break-glass access increase risk if cleanup is manual?
A: Manual cleanup creates a gap between the incident ending and the privilege actually disappearing.
Q: What are the signs that on-call privilege is too broad?
A: Warning signs include engineers receiving access to systems unrelated to the incident, approvals that last beyond the on-call period, and no clear link between incident records and authorization events.
Practitioner guidance
- Map on-call state to privilege issuance Define which production and PII systems can be opened only while an engineer is actively scheduled for incident response, and ensure the policy engine uses on-call status as a trigger for elevation.
- Automate privilege revocation after the incident Remove elevated rights as soon as the on-call window closes, and verify that cleanup is enforced by policy rather than relying on manual follow-up from responders.
- Correlate access logs with incident timelines Keep authorization events, scheduling data, and incident records in the same review set so auditors can confirm access matched the response window and did not persist beyond it.
Bottom line: The article shows that on-call access becomes safer when elevated privileges are tied to incident context and removed when the response window closes.
What's in the full article
Opal Security's full article covers the operational detail this post intentionally leaves for the source:
- The exact Rootly integration flow for adding on-call scheduling as an authorization signal
- Implementation details for granting and revoking elevated access based on on-call assignment
- Guidance on configuring auto-approval and second-engineer escalation for sensitive systems
- Practical setup notes for aligning Slack notifications with access requests and incident routing
👉 Read Opal Security's analysis of on-call access governance with Rootly →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
13/10/2026 1:22 pm
On-call access is a lifecycle control, not an exception to governance. The article frames incident response as the moment when privilege must become time-bound, not the moment when governance is suspended. That is the correct framing for engineer access because the risk is not only who can enter production, but whether that access is guaranteed to expire when the operational duty ends. Practitioners should treat on-call status as a lifecycle attribute that drives issuance and revocation.
A question worth separating out:
Q: What should security teams do after an incident to verify access was appropriate?
A: Compare the access timeline with the incident timeline and confirm that every elevated entitlement was tied to an active on-call assignment. If the two timelines do not align, the review should treat the mismatch as a governance failure, not a documentation issue.
👉 Read our full editorial: On-call access needs just-in-time governance, not standing privilege