TL;DR: PagerDuty’s App Store groups 400-plus integrations that help teams detect, triage, and resolve incidents faster, but the article also shows how tightly incident response now depends on SaaS visibility, lifecycle control, and access governance according to Zluri. The governance problem is not integration count, but whether identity, renewals, and deprovisioning keep pace with the sprawl those integrations create.
At a glance
What this is: This is Zluri’s analysis of PagerDuty’s 400-plus app integrations, showing that incident-response tooling can widen the SaaS identity governance gap when lifecycle control and visibility do not keep up.
Why it matters: It matters because IAM, IGA, and SaaS governance teams need to manage integration sprawl as an identity problem, not just an operations convenience, or access and renewal drift will accumulate.
By the numbers:
- PagerDuty’s App Store offers over 400 apps and integrations for incident management.
Context
PagerDuty’s App Store is an integration layer for incident-response workflows, not just a catalog of add-ons. In identity terms, the issue is that each connected app can extend access, automation, and data sharing beyond the point where teams can easily see who still has what permissions.
Zluri’s article uses the PagerDuty ecosystem to show a familiar SaaS governance problem: integrations accumulate faster than lifecycle controls. When application discovery, renewal management, and deprovisioning do not keep pace, the incident-response stack itself becomes harder to govern than the incidents it was meant to help resolve.
The broader lesson is that SaaS integration strategy now overlaps with identity governance, compliance, and shadow IT control. That makes the question less about how many tools connect, and more about whether the organisation can inventory, certify, and revoke those connections on a reliable cadence.
Key questions
Q: What should teams do first when SaaS integrations start multiplying across incident-response tools?
A: Start with a complete integration inventory that records the app, owner, permissions, and business purpose. Without that baseline, access reviews, deprovisioning, and renewal decisions are operating on partial information. The first control is visibility, because you cannot govern what you have not identified.
Q: Why do delegated SaaS integrations complicate identity governance?
A: They complicate governance because the access is often granted by business users or vendor workflows, yet the blast radius reaches production data and privileged APIs. Teams must govern scopes, approval owners, and reauthorisation cycles with the same seriousness they apply to human access, because the risk lives in the delegation chain.
Q: What breaks when SaaS management platforms cannot discover all connected apps?
A: When discovery is incomplete, the organisation loses the inventory needed for access review, offboarding, and risk assessment. Shadow apps and hidden accounts remain outside governance, so SaaS management becomes reactive instead of controlled. The practical failure is not just poor reporting. It is an incomplete identity map that leaves unmanaged access in place.
Q: How should security teams govern app renewals and deprovisioning together?
A: Treat renewal and offboarding as one lifecycle decision. If an app is no longer needed, the contract renewal should not preserve the access path, and if the business still needs the app, the associated permissions should be reviewed before renewal. That alignment reduces stale access and wasted spend at the same time.
Technical breakdown
How app-store integrations expand the SaaS identity surface
An app store that exposes hundreds of integrations creates a federated identity surface across monitoring, collaboration, automation, and line-of-business tools. Each connection can introduce its own service account, OAuth grant, API token, or delegated permission set. The technical risk is not the integration itself, but the number of identity bindings created outside a central lifecycle process. Once those bindings multiply, visibility depends on discovery coverage, not on the incident platform alone.
Practical implication: Map every PagerDuty-connected app to its identity mechanism, ownership, and revocation path.
Why renewal and offboarding become governance controls
SaaS renewals and deprovisioning are part of the same control chain. A license renewal can preserve access after a business need ends, while poor offboarding leaves users or integrations active after they should be removed. In practice, renewal dates, access reviews, and lifecycle events need to be tied together because SaaS sprawl creates dormant access that is easy to miss and expensive to clean up later.
Practical implication: Tie app renewals and user offboarding to the same governance workflow so stale access is not preserved by contract timing.
Why shadow IT and discovery matter in incident-response stacks
Incident-response platforms often sit in the operational center of the business, which makes them attractive for fast integrations and difficult to govern manually. That is exactly why discovery matters: if teams cannot identify all apps in use, they cannot assess permissions, monitor usage, or apply consistent policy. The governance gap is therefore not only SaaS sprawl, but incomplete inventory of the connections that make the stack work.
Practical implication: Use application discovery to baseline every tool linked into incident response and treat unknown integrations as governance exceptions.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Integration sprawl is an identity governance problem, not an operations bonus. PagerDuty-style app stores can improve response speed, but each added integration expands the number of identities, permissions, and lifecycle events that must be governed. The category is drifting from simple tool connectivity toward access surface management. Practitioners should treat integration inventory as part of the identity programme, not a separate operations catalogue.
SaaS discovery is the control that decides whether lifecycle governance is real. Zluri’s article points to discovery, licence management, renewal alerts, and user lifecycle management as linked concerns, which is the right framing. If discovery misses an app, offboarding and review are already incomplete. That means the real gap is not just hidden software, but hidden access paths tied to that software.
Renewal timing now shapes security posture. In SaaS-heavy environments, auto-renewals can preserve unused applications and their associated access for another cycle, even when business need has faded. That makes contract operations and identity operations inseparable. Procurement, IT, and IAM teams need one shared view of which apps are still authorised and who can still reach them.
Shadow IT becomes shadow identity when integrations are added informally. An integration may look harmless in isolation, but every unmanaged connection can create delegated access, data exposure, and accountability ambiguity. This is where SaaS governance and NHI governance start to overlap, because the same lifecycle discipline applies to user grants, service accounts, and API-based connections. The programme implication is straightforward: unmanaged integrations should be treated as unmanaged access.
PagerDuty integration ecosystems sharpen the need for continuous entitlement review. The named concept here is access surface drift. As teams connect more tools to incident-response workflows, the effective access surface changes faster than annual review cycles can capture. The result is a governance lag between what the business thinks is connected and what is actually authorised. Practitioners should move review cadence closer to change cadence.
What this signals
Access surface drift is the governance pattern this article exposes. Incident-response ecosystems accumulate integrations faster than annual review cycles can absorb, so the practical control target is not just SaaS count but the pace at which permissions, owners, and offboarding steps change.
SaaS governance and IAM can no longer be separated cleanly when incident-response tooling is highly extensible. The operational stack now creates its own access surface, which means discovery, lifecycle management, and renewal decisions have to be treated as one programme rather than three disconnected tasks.
For practitioners
- Baseline every connected SaaS app Build and maintain a complete inventory of all applications integrated into incident-response workflows, including owners, permissions, and business purpose.
- Tie renewals to access reviews Require renewal decisions to reflect current usage, access scope, and business need so auto-renewals do not preserve stale SaaS access.
- Govern integration offboarding Remove or disable integrations when a business relationship, workflow, or user group no longer requires them, and verify the associated permissions are revoked.
- Track shadow IT as shadow access Treat undiscovered SaaS tools and unapproved integrations as access risks, not only software sprawl, because each one can carry permissions and data exposure.
Key takeaways
- PagerDuty-style integration hubs create a wider SaaS identity surface, and that surface needs lifecycle governance, not just operational convenience.
- The governance weak point is usually incomplete discovery and delayed offboarding, not the presence of integrations themselves.
- Teams that align renewal management, access review, and deprovisioning can reduce stale access without slowing incident-response workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party SaaS integrations expand the trusted access surface around PagerDuty. |
| NHI-05 — Overprivileged NHI | Integrated apps can accumulate permissions beyond the business need for incident workflows. | |
| NHI-09 — NHI Reuse | The article highlights repeated use of the same SaaS ecosystem across many connected workflows. | |
| Recommendation — Inventory third-party integrations and revoke any SaaS connection without an accountable owner. Review integration scopes and remove privileges that are not required for incident handling. Reduce reused access paths by separating app-specific credentials and lifecycle records. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on who can still access connected SaaS apps and when that access should end. |
| Recommendation — Apply entitlement reviews to connected SaaS apps and retire access when business need ends. | ||
| CIS Controls v8 | CIS-5 — Account Management | Offboarding and access revocation are central to the governance gap described here. |
| Recommendation — Tie account and integration removal to the same offboarding workflow and verify completion. | ||
Key terms
- SaaS Identity Surface: The SaaS identity surface is the full set of identities, connections, and access paths created by cloud applications in use across an organisation. It includes human accounts, service connections, OAuth grants, and dormant subscriptions that may still have authority even when no one is actively using them.
- Access Surface Drift: The gradual mismatch between the access a business thinks it has authorised and the access that still exists across connected tools. It appears when integrations, renewals, and offboarding move faster than review cycles, and it is especially visible in SaaS-heavy environments.
- Vendor offboarding: Vendor offboarding is the controlled removal of a third party's access, data paths, and operational dependencies when the relationship ends or changes. It is a lifecycle control, not an administrative closeout, because any surviving credentials or integrations remain active security exposure.
- Renewal-Governed Access: A lifecycle model in which contract renewal, usage review, and access review are linked before an application is kept in service. It helps prevent auto-renewed SaaS tools from preserving stale permissions, wasted spend, and hidden governance debt.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org