PagerDuty role automation exposes the IAM gap in manual access

At a glance

What this is: This is a Zluri guide on automating PagerDuty access, role, and team management through workflows tied to identity verification and API keys.

Why it matters: It matters because the same lifecycle gaps that create risk in human IAM also create exposure for NHI-like service access patterns and operational tooling.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Zluri's guide to PagerDuty role automation and lifecycle access control

Context

PagerDuty access governance is really an identity lifecycle problem: who gets access, when access changes, and how fast access is removed when roles change or users leave. Manual workflows make that control plane slow, inconsistent, and difficult to audit across joiner, mover, and leaver events.

Zluri frames the issue around automating role assignment, provisioning, offboarding, team membership, and incident documentation. For IAM and IGA teams, the useful question is not whether automation exists, but whether the workflow still depends on static assumptions that the identity state can be checked and corrected later. For the broader NHI programme, the same logic applies to service identities and tool access governed through lifecycle processes.

Key questions

Q: How should security teams automate PagerDuty access without losing governance control?

A: Security teams should connect PagerDuty changes to authoritative joiner, mover, and leaver events, then constrain the workflow to approved role mappings. Automation should remove delay, not oversight. The strongest model still validates identity, applies least privilege, and records every change for review, but it does so at lifecycle speed instead of through manual ticket handling.

Q: Why does PagerDuty role automation still require IAM oversight?

A: Because automation changes the execution method, not the governance requirement. PagerDuty roles still determine who can see incidents, act on alerts, and modify operational workflows. Without IAM oversight, role sprawl, stale access, and inconsistent approvals can persist even if the administration is faster and more convenient.

Q: What breaks when app provisioning is automated but offboarding is not?

A: Former users can retain active access after they have left, moved teams, or changed responsibilities. That leaves incident tools, notifications, and administrative actions exposed to identities that no longer need them. The failure is not speed but asymmetry: onboarding becomes efficient while revocation remains manual and delayed.

Q: Who should own the API key used for identity workflow automation?

A: Ownership should sit with the team responsible for privileged access and secret lifecycle management, not with whichever administrator first created the integration. The key should have a named owner, a rotation schedule, clear revocation authority, and a documented purpose so it can be treated like any other high-value NHI credential.

Technical breakdown

Why manual PagerDuty role assignment fails at lifecycle speed

PagerDuty role assignment is an access governance workflow, not just an admin task. When roles are assigned by hand, the control depends on a person gathering identity data, checking job function, and selecting the right entitlement after the fact. That creates drift whenever employees move roles, change teams, or need temporary access. The core technical weakness is latency between the business event and the access update. In practice, the longer that delay lasts, the more likely the entitlement no longer matches the person’s actual responsibility set.

Practical implication: tie PagerDuty role changes to authoritative identity events so access changes are triggered by lifecycle signals, not ticket queues.

API keys and workflow integration as an access plane

The integration described by Zluri relies on PagerDuty API access keys and workflow actions to add or remove users, assign teams, and record events. That makes the API key a privileged operational credential, because it can execute changes at scale across the incident-management environment. From an identity perspective, this is an NHI pattern: a non-human credential is used to administer another system. The security question becomes whether the key is scoped, monitored, and retired with the same discipline as any other privileged secret.

Practical implication: treat the PagerDuty API key as a privileged NHI credential and govern its scope, storage, and revocation explicitly.

Audit trails only help if the underlying identity state is correct

Zluri emphasizes audit trails for role assignment and incident documentation, which is useful for review and compliance. But auditability is not the same as governance. A clean record of a bad access decision still leaves the wrong entitlement in place. The value comes when the audit trail reflects a controlled lifecycle process, including onboarding, mover events, and offboarding. Otherwise, the organisation preserves evidence of misalignment instead of reducing it.

Practical implication: validate that every recorded access change maps back to an approved identity event and not just a workflow action.

NHI Mgmt Group analysis

Manual access governance breaks when role changes are faster than review cycles. This article is really about the gap between identity change and entitlement change. PagerDuty access is being treated as a lifecycle problem, but the manual version depends on humans noticing role shifts, validating them, and correcting access after the fact. That model fails whenever joiner, mover, and leaver events occur faster than the review process can keep up. The implication is that access governance has to move from clerical verification to event-driven entitlement control.

API-key driven administration turns PagerDuty into an NHI governance problem. Once workflow automation uses an API key to add, remove, and assign users, the credential is no longer just a technical connector. It becomes a privileged non-human identity that can create or remove access at scale. That means the organisation has introduced a second governance surface alongside human admin rights. The practitioner conclusion is that the API key must be managed as a high-value NHI credential, not as a convenience setting.

Access trails without lifecycle discipline create an audit illusion. The article rightly highlights logging and reports, but those records only prove that a workflow ran. They do not prove that the right person had the right access at the right time. This is the named concept here: auditability without entitlement correctness. It describes environments where evidence exists but governance quality does not improve. Practitioners should read audit output as a control signal, not as control assurance.

Identity lifecycle governance is now shared across human users and machine-managed administration. PagerDuty provisioning, role changes, and offboarding mirror the same lifecycle controls that now apply to service accounts and other non-human identities. That convergence is why IAM and NHI teams need a common operating model. When the same workflow family governs people, admin keys, and service access, the governance standard has to be consistent across actor types. The implication is that lifecycle design should be unified, not siloed by tool or subject type.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• For the lifecycle side of this problem, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding should be governed.

What this signals

Auditability without entitlement correctness will become a recurring failure mode as more IT workflows move into automation. The issue is not whether the system can write logs, but whether those logs reflect a valid identity decision at the moment access changes. Teams that cannot reconcile workflow evidence with current entitlements will accumulate quiet privilege drift across admin tools, incident platforms, and non-human credentials.

With 92% of organisations exposing NHIs to third parties, access workflows that rely on integration keys need stronger lifecycle ownership, not just better convenience. The same secret that simplifies provisioning can widen exposure if it is shared, copied, or left active after operational change. That is why identity programmes should treat workflow automation as part of NHI governance, not as a separate IT efficiency layer.

The practical signal for IAM and NHI leads is simple: if access change timing depends on humans checking a queue, the governance model is already behind the business event. A tighter design binds change to authoritative identity state, then uses review and reporting to confirm that the entitlement actually matches current need. That is the difference between visible administration and real control.

For practitioners

• Bind PagerDuty access changes to authoritative lifecycle events Trigger add, move, and remove actions from joiner, mover, and leaver signals in the identity source of truth instead of relying on manual ticket handling.
• Classify the PagerDuty API key as a privileged NHI credential Store the integration key in a controlled secret store, limit its scope to the minimum required workflow actions, and review who can rotate or revoke it.
• Reconcile role assignments against current job function Run recurring checks to compare PagerDuty entitlements with current department, location, and operational responsibilities so stale roles are removed quickly.
• Separate workflow evidence from access assurance Use audit trails to verify that a change occurred, then validate independently that the resulting entitlement still matches approval and role intent.
• Automate offboarding before account closure slips Require removal of PagerDuty access as part of the leaver workflow so former staff do not retain incident-management access after departure.

Key takeaways

• PagerDuty automation solves speed, but it does not remove the need for identity governance, especially when roles and teams change mid-lifecycle.
• The API key used for workflow administration is a privileged non-human credential and should be governed like one.
• Audit trails are only useful when the entitlement they record still matches the user’s current role and approval state.

Key terms

• Non-Human Identity: A non-human identity is any credentialed machine, service, or automated actor that can authenticate and receive privileges. In practice, that includes API keys, service accounts, tokens, certificates, and workflow integrations. Governance focuses on lifecycle, scope, rotation, and revocation rather than user experience.
• Identity Lifecycle: Identity lifecycle is the full sequence from creation through change, review, and removal of access. For humans, it covers joiner, mover, and leaver events. For non-human identities, it also includes provisioning, rotation, offboarding, and the retirement of integration credentials.
• Privileged Access: Privileged access is any entitlement that can change security state, operational state, or administrative configuration. It is high-risk because misuse or stale ownership can affect many downstream systems. In automation workflows, the API key or admin account used to make changes should be treated as privileged access.

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 Zluri: Automation How To Get More Out Of PagerDuty By Integrating With Zluri? Read the original.