Notifications
Clear all
Topic starter
24/06/2026 10:24 pm
TL;DR: On-call teams often trade permanent production access for speed, but that model expands blast radius and weakens least privilege, according to Opal Security. Automating access by schedule restores time-bound privilege and makes on-call governance workable for production systems.
NHIMG editorial — based on content published by Opal Security: How to Automate On-Call Access Management with Opal and PagerDuty
Questions worth separating out
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 birthright access create more risk in production environments?
A: Birthright access creates risk because it gives engineers elevated rights even when they are not performing production work.
Q: What breaks when on-call access is granted manually during incidents?
A: Manual incident access breaks speed, consistency, and revocation discipline.
Practitioner guidance
- Remove permanent production memberships from on-call roles Map which engineering groups still carry birthright access to production systems and strip those entitlements from the default role.
- Bind privileged access to an authoritative schedule signal Use the on-call system as the source of truth for access eligibility, and make the schedule state the trigger for grant and revoke decisions.
- Automate revocation when the on-call window closes Ensure elevated rights disappear without manual cleanup at the end of a shift or incident handoff.
What's in the full article
Opal Security's full article covers the operational detail this post intentionally leaves for the source:
- The exact integration pattern between Opal and PagerDuty for granting access based on schedule state.
- The distinction between static production membership and dynamic on-call elevation in the product workflow.
- The article's own explanation of how privilege is revoked when engineers move off call.
- The vendor's framing of how teams can package fine-grained resources into on-call groups.
👉 Read Opal Security's article on automating on-call access management →
On-call access management and the standing privilege problem?
Explore further
25/06/2026 7:02 am
Standing production access is the real governance flaw this pattern exposes. The article frames on-call access as a trade-off between security and agility, but the deeper issue is that many organisations still treat privileged access as a permanent attribute of the engineer rather than a temporary state of duty. That model fails because access outlives the operational need. Practitioners should treat duration as a first-class control, not an afterthought.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, which shows how thin the confidence margin remains.
A question worth separating out:
Q: Who is accountable when privileged on-call access is overgranted?
A: Accountability sits with the identity and operations owners who define the entitlement model, not just the engineer using it. If the programme allows standing admin access or fails to revoke it after duty ends, the governance design is accountable because it made overgranting the default state.
👉 Read our full editorial: On-call access management shows why standing privilege fails
