On-call access management shows why standing privilege fails

At a glance

What this is: This is a product-focused analysis of automating on-call access management, with the key finding that permanent production access is still the default risk trade-off many teams make.

Why it matters: It matters because IAM, PAM, and lifecycle teams need a way to grant high-risk access only when engineers are on-call, without leaving standing privilege in place across the rest of the estate.

👉 Read Opal Security's article on automating on-call access management

Context

On-call access management is the problem of giving engineers the right level of privileged access only when they are actively handling an incident or production issue. The governance gap is straightforward: permanent admin access is easy to operate, but it breaks least privilege and expands exposure across production systems.

For IAM and PAM teams, the question is not whether engineers need urgent access. The question is how to bind access to an operational condition such as being on-call, while still preserving accountability, revocation, and review across the lifecycle of the entitlement. That is where time-bound access governance becomes a practical control rather than a policy aspiration.

The same tension appears across human, NHI, and autonomous identity programmes. When access is granted because of role or birthright rather than current need, the security model is carrying standing privilege that no longer matches the work being done.

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. The key is to design the entitlement so that production rights are temporary by default, with audit evidence showing both grant and removal.

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. If the account is compromised, the attacker inherits always-on privilege. That widens the blast radius and makes compromise more damaging than a time-bound, task-scoped access model would allow.

Q: What breaks when on-call access is granted manually during incidents?

A: Manual incident access breaks speed, consistency, and revocation discipline. Teams may approve access quickly in an emergency, but they often lose the traceability needed to prove when the privilege began and ended. That creates residual privilege and weakens both accountability and post-incident review.

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.

Technical breakdown

Standing production access and birthright privilege

Standing production access means an engineer has privileged rights all the time, regardless of whether they are currently on-call. Birthright access is the same failure mode expressed through group membership or default entitlements. In practice, this creates a wide attack surface because compromise of the engineer account immediately inherits production reach. The control problem is not just privilege scope, but privilege duration, because the entitlement remains available long after the legitimate need has ended.

Practical implication: remove permanent admin entitlements from on-call workflows and make duration part of the access policy.

Dynamic on-call scheduling as an access signal

The article’s core mechanism is to use an external scheduling signal, such as PagerDuty, to determine whether access should be active. That shifts access from job function to current operational state. Instead of asking who someone is in abstract terms, the system asks whether they are currently responsible for incident response. This is a classic least-privilege improvement because eligibility becomes time-bound and task-bound, not just role-bound.

Practical implication: tie privileged access eligibility to live on-call state, not static organisational role.

Revocation at the end of the on-call window

Revocation is the part that makes the model defensible. If access is granted when the engineer is on-call but not revoked when they are off-call, the system merely rebrands standing privilege. True on-call governance requires automated removal of elevated rights when the duty window closes, plus audit evidence that the access actually disappeared. Without that lifecycle step, the programme still carries residual privilege risk after the operational need has ended.

Practical implication: enforce automated revocation at shift end and log the removal as a control evidence point.

Threat narrative

Attacker objective: The attacker wants durable privileged access to production systems so they can act as an authorised operator rather than fight for escalation.

1. Entry occurs when an engineer account with permanent admin access is compromised, giving the attacker immediate production reach without needing to wait for a valid on-call window.
2. Escalation follows because the privileged account already carries the rights needed to administer production systems, so the attacker does not need to escalate within the environment before acting.
3. Impact is broad production exposure, since permanent access allows changes, triage actions, or data access across mission-critical systems at any time.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• BeyondTrust API key breach — compromised BeyondTrust API key led to unauthorized SaaS access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

On-call scheduling is an identity signal, not just an operational convenience. When access is bound to PagerDuty state, the entitlement can follow the work instead of the org chart. That matters for IAM and PAM because it moves privilege decisions from static role assignment into a live operational context. The practitioner takeaway is that access policy should consume authoritative duty signals, then revoke automatically when the duty state changes.

Least privilege becomes enforceable only when revocation is automatic. If the system grants access on-call but depends on humans to clean it up later, the model collapses back into standing privilege with extra steps. This is the same lifecycle failure pattern seen across NHI governance when credentials persist beyond their intended use window. Practitioners should judge the model by whether it leaves no residual access after the on-call period ends.

Access review alone cannot fix a workflow that is designed to overgrant first. Reviews can confirm who had access, but they do not stop the exposure created when privileged rights are issued too broadly or for too long. That is why on-call governance should be built as a time-bound entitlement model, not a periodic certification exercise. The implication is that access design must do more of the work than audit does.

Time-bound privilege is the named concept that matters here. This is the governance pattern in which high-risk access exists only for the active duty window and is removed automatically when that window closes. It is more than JIT branding. It is a control model that reduces the period in which a compromised engineer account can damage production. Practitioners should build on-call access around that principle, not around permanent production membership.

From our research:

• 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.
• For a related governance view, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding reduce residual access risk.

What this signals

Time-bound privilege is becoming the practical standard for any workflow that grants high-risk access on demand. Teams that still rely on static production membership will keep carrying excess exposure, even if their incident response process looks efficient on paper. The programme question is whether access can be granted and removed with the same level of automation as the operational event that triggered it.

The broader signal is that access governance is moving away from identity alone and toward identity plus duty state. That aligns with the direction of the NIST Cybersecurity Framework 2.0, where continuous protection and response depend on current conditions, not stale entitlements. Practitioners should prepare for more controls that measure whether access is active for the right reason, at the right moment.

For teams responsible for sensitive systems, this pattern also raises the bar for review evidence. If the entitlement model cannot show when elevated access started and stopped, the programme will struggle to demonstrate control effectiveness during audit or incident review. Access design, not just access review, becomes the deciding factor.

For practitioners

• 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. Replace them with duty-based elevation that is issued only when the engineer is actively on-call.
• 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. The access decision should follow current duty, not static job function.
• Automate revocation when the on-call window closes Ensure elevated rights disappear without manual cleanup at the end of a shift or incident handoff. Keep revocation logs as evidence that the entitlement actually ended, not just that a policy said it should.
• Separate emergency triage access from baseline engineering access Create a distinct high-risk access path for production response so day-to-day engineering permissions do not double as incident-response privileges. That reduces accidental overexposure and makes review simpler.

Key takeaways

• On-call access becomes a security problem when teams keep permanent production rights instead of granting access only for active duty windows.
• The evidence in this pattern is operational, not theoretical: static privilege makes compromise more damaging because the account already has production reach.
• Automated grant and revoke logic is the control that matters, because it turns least privilege into a live access state rather than a policy statement.

Key terms

• Standing Privilege: Standing privilege is access that remains active all the time, regardless of whether the user or system currently needs it. In identity programmes, it is a high-risk condition because compromise inherits always-on power, and review processes often struggle to prove the access was truly necessary at every moment.
• On-call Access: On-call access is privileged access that is granted only when an engineer is actively responsible for incident response or production support. In a mature programme, the entitlement is tied to an authoritative schedule signal and automatically revoked when the on-call duty window ends.
• Birthright Access: Birthright access is entitlement granted by default because someone belongs to a role, team, or job function. It is convenient but dangerous for production systems because it treats access as a permanent property of position rather than a temporary permission based on operational need.
• Time-bound Privilege: Time-bound privilege is a governance model where elevated access exists only for a defined period and is removed automatically when the need ends. It reduces the blast radius of compromise and creates clearer evidence for audit, because access duration is part of the control design.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Opal Security: How to Automate On-Call Access Management with Opal and PagerDuty. Read the original.