Why does PagerDuty role automation still require IAM oversight?

Why This Matters for Security Teams

PagerDuty role automation changes how access is assigned, but it does not remove the need to govern who can see incidents, acknowledge alerts, edit schedules, or alter escalation paths. Those are operational permissions with direct blast-radius implications, so they still need IAM controls, approvals, and periodic review. NIST’s NIST Cybersecurity Framework 2.0 treats access governance as an ongoing control, not a one-time setup.

This matters because automation often expands the number of people who can self-serve access while hiding the drift that builds up behind the scenes. In the broader NHI landscape, NHI Management Group notes that 97% of NHIs carry excessive privileges in Ultimate Guide to NHIs, which is a useful warning sign for any system that distributes access faster than it reviews it. The same pattern shows up in operational tooling: convenience increases, but governance can lag.

In practice, many security teams discover role sprawl only after a privileged incident channel has already been overexposed, rather than through intentional access design.

How It Works in Practice

The right model is to treat PagerDuty as an integrated workload in the identity program, not as a separate administrative island. Role automation can speed provisioning, but IAM should still define who is eligible for each role, what approval path applies, and when access must be removed. That means mapping PagerDuty permissions to business function, enforcing least privilege, and reviewing standing access on a schedule aligned with risk.

For operational teams, the practical controls are straightforward:

• Use group-based assignment so role changes inherit IAM governance instead of being edited ad hoc.
• Require approval for elevated roles that can modify schedules, integrations, or escalation policies.
• Review access when employees change teams, leave on-call rotations, or move into incident response leadership.
• Log role changes and monitor for bulk edits or unexpected privilege expansion.

Where possible, tie PagerDuty access to the identity source of truth and centralise offboarding so dormant roles do not survive personnel changes. This is consistent with the governance patterns described in The 2024 Non-Human Identity Security Report, which highlights how many organisations value dynamic access but still struggle with consistent control. Current guidance suggests that automation should reduce manual friction, not weaken review discipline. These controls tend to break down in organisations that let service desk shortcuts bypass the identity lifecycle because the exceptions quickly become the default.

Common Variations and Edge Cases

Tighter access governance often increases administrative overhead, so organisations must balance speed of assignment against the risk of unmanaged privilege. That tradeoff is especially visible in 24x7 operations, where responders need fast access during incidents and teams are tempted to leave elevated roles in place permanently.

There is no universal standard for PagerDuty role governance yet, but best practice is evolving toward just-in-time elevation for sensitive actions and periodic recertification for standing roles. That approach is stronger than static role assignment, particularly when contractors, managed service providers, or globally distributed responders are involved. If the platform is used across multiple business units, separation of duties becomes harder to preserve and shared admin roles often accumulate over time.

One common edge case is automation that provisions roles from HR or directory events but never verifies whether the person still needs incident-management privileges in practice. Another is a shared support queue where legacy access remains because no one wants to disrupt coverage. The Azure Key Vault privilege escalation exposure illustrates a broader lesson: role design errors become security issues when operational access is granted faster than it is reviewed.

Related resources from NHI Mgmt Group

• How should IAM teams evaluate whether RBAC is still working?
• Why do access control models still fail in mature IAM programmes?
• What do IAM and IGA teams get wrong about ITSM automation?
• Why do access reviews still fail when organisations use compliance automation?