# PagerDuty SAML SSO and SCIM provisioning: access control capabilities for enterprise teams

*July 15, 2026*

> **TL;DR:** Enterprise security teams evaluating PagerDuty must navigate SAML SSO and SCIM 2.0 configurations across its plan tiers. While PagerDuty automates basic user provisioning, its role-based access control (RBAC) model creates gaps in private incident isolation. Team-level privacy controls don't restrict visibility at the individual incident level, leaving sensitive breach details exposed to non-privileged responders. For compliance-first organizations that need to lock down a single active incident to a named subset of responders, incident.io provides native private incident isolation: restrict access at the individual incident level, convert public incidents to private mid-response, and generate immutable audit trails automatically.

Most enterprise security teams configure PagerDuty SAML SSO to check a compliance box, only to discover during a SOC 2 Type II audit that their incident response tool has no native way to isolate a sensitive breach from the rest of the engineering team. Standard identity integrations handle user provisioning but don't solve secure incident coordination, granular access control, or audit trail automation.

This guide evaluates PagerDuty's SAML SSO and SCIM 2.0 provisioning capabilities, details configuration steps for Okta, Microsoft Entra ID, and OneLogin, and analyzes the RBAC limitations that create compliance exposure for security-first organizations, alongside a direct comparison with incident.io as a compliance-first alternative. You can also compare both platforms in the [PagerDuty vs. incident.io breakdown](https://youtube.com/watch?v=ECF_QKg0G7w) if you're evaluating them side by side.

## Deploying PagerDuty SAML SSO at enterprise scale

Here's what you need to know about PagerDuty's identity integration options, from plan availability to MFA enforcement and session controls.

### Verified SAML and SCIM integrations

The following capabilities reflect PagerDuty's published documentation and third-party sources. Verify current plan availability directly with PagerDuty. PagerDuty supports SAML SSO across its Professional, Business, and Enterprise for Incident Management plans, with both SP-initiated and IdP-initiated flows. The platform integrates with Okta, Microsoft Entra ID (formerly Azure AD), and OneLogin. SCIM 2.0 provisioning is available on Business ($41/user/month) or Enterprise plans, with full automation requiring compatible IdP support from one of those three providers.

### Configuration requirements and session controls

The capabilities in this section are drawn from PagerDuty's help center and third-party testing. Confirm behavior in your specific plan tier. The Account Owner navigates to Account Settings, selects Single Sign-On, and chooses SAML. You then paste three values from your identity provider: the X.509 signing certificate, the Login URL, and the Logout URL. PagerDuty supports just-in-time (JIT) provisioning to auto-create user accounts on first login.

PagerDuty does not expose a native session timeout setting in the UI. Session duration is configurable through the PagerDuty API, and your identity provider can apply session policies at the application layer. You enforce timeout policies in Okta or Entra ID directly. The practical implication: if your IdP session policy differs across applications, PagerDuty defaults to your IdP's broadest setting unless you configure application-specific policies at the IdP layer or use the API to set account-level session timeouts.

PagerDuty delegates MFA enforcement entirely to your identity provider and does not enforce MFA at the application layer when you enable SSO. Your MFA posture is only as strong as the IdP policy you configure. For Entra ID, some sources suggest you must enable "Require EXACT authentication context comparison" in PagerDuty's SAML settings, and you may need to disable AuthnContext entirely if your organization uses Entra MFA or Passwordless, which requires explicit testing to confirm your MFA policies still enforce correctly through the IdP.

We built [incident.io's SAML SSO configuration](https://docs.incident.io/admin/saml-sso) for Enterprise and newer Pro customers. We pair SAML with [SCIM-backed team provisioning](https://docs.incident.io/catalog/scim-teams), which translates your IdP group memberships into incident access controls.

## SCIM provisioning capabilities and constraints

Here's how PagerDuty handles automated user lifecycle management through SCIM, including the key limitations that affect ongoing access control.

### SCIM workflows for access control

PagerDuty supports SCIM 2.0 for automated user lifecycle management, covering user creation and deactivation. However, critical limitations exist: deactivating users through SCIM deletes them from PagerDuty (reactivation creates a new user rather than restoring the original account), and attribute updates after initial provisioning don't sync automatically. SCIM provisioning is available on Business or Enterprise plans. The Business plan runs $41/user/month versus $21/user/month for Professional, adding $12,000 annually for a 50-person team.

We offer [SCIM provisioning](https://docs.incident.io/admin/scim) on our Enterprise plan, and support Okta, Microsoft Entra ID, and additional identity providers as they're confirmed. We use SCIM group mappings to populate our Service Catalog, which maps services and team ownership structures from your IdP.

### Automating PagerDuty access groups and field mapping

The Team visibility defaults and SCIM attribute behavior described here reflect PagerDuty's published SCIM documentation. Test against your specific IdP configuration before relying on these defaults in production. You map IdP groups to PagerDuty Teams during SCIM configuration.

PagerDuty allows you to set Teams to Private or Public, with Teams defaulting to public, which typically means broader visibility within the account. Private Teams restrict visibility to members plus Global Admins and the Account Owner. Mapping this correctly requires deliberate group architecture in your IdP before you configure SCIM, because changes after the fact require manual reconciliation.

PagerDuty's SCIM integration does not support custom attributes such as department, region, or cost center. OneLogin environments face an additional limitation: roles, timezone, and entitlements lack basic User object mappings, which may require additional configuration. A critical limitation applies across all IdPs: SAML-provisioned attributes (email, name, role) apply only at initial account creation. If you update these values in your identity provider after the account exists, PagerDuty won't sync the change, and you must update them manually.

### Automating user deprovisioning workflows

When you deprovision a user through SCIM, PagerDuty deletes their account rather than deactivating it. If you reactivate the user in your IdP, the behavior depends on your IdP's SCIM client implementation. Okta creates a new user, while OneLogin throws a provisioning error. This means the original account and its associated data are not restored, which can affect historical incident attribution during audit reviews.

[Vanta](https://incident.io/customers/vanta), a compliance platform operating under continuous SOC 2 audit pressure, automated a manual five-step incident process using incident.io and now alerts the right people within minutes. We cite Vanta specifically because their own business depends on getting compliance right, and they chose us to run their incident workflows.

## Defining least privilege for PagerDuty responders

Here's how PagerDuty's role model works in practice, from base role assignment through team-level permissions.

### Mapping SCIM groups to PagerDuty roles

PagerDuty assigns users one of four flexible base roles: Restricted Access, Observer, Responder, or Manager. Fixed roles, including Account Owner, Global Admin, and Stakeholder, operate separately. SCIM provisioning can assign flexible base roles automatically based on IdP group membership, but these base roles apply globally across the account. You must configure granular team-level permissions separately on top of base role assignment, which requires deliberate architecture and periodic reconciliation.

### Configuring SCIM-based team permissions and incident visibility

PagerDuty uses a three-layer permission model: base role, team role, and object-level grants. Configuring all three layers correctly to enforce least privilege means maintaining a mapping of intended permissions alongside your actual IdP group configuration and reconciling them periodically.

A critical gap in PagerDuty's model appears at the individual incident level: Team-level privacy controls don't restrict per-incident visibility. When an admin reassigns a service to a different private Team, historical incidents remain visible under the original Team's permissions.

When an admin associates a previously-unteamed service with a private Team for the first time, historical incidents remain visible on the Incidents overview page even when PagerDuty locks down the detail pages. This creates exposure during zero-day investigations or executive-account compromises where you need to lock down a single active incident to a named subset of responders.

## Syncing user lifecycle with your IdP

For Okta, PagerDuty's documentation describes adding the PagerDuty application from the Okta Integration Network and configuring the Provisioning tab with your PagerDuty API credentials. Group push maps your Okta groups to PagerDuty Teams. You should test the SCIM connection before enabling live provisioning. Our [Okta SCIM group setup](https://docs.incident.io/admin/okta-scim) follows a similar flow, mapping Okta groups to incident.io roles, with those groups also becoming visible in our Service Catalog for use in workflows.

For Entra ID, some sources suggest you must enable "Require EXACT authentication context comparison" in PagerDuty's SAML settings. You may need to disable AuthnContext entirely if your organization uses Entra MFA or Passwordless, and then test that MFA policies still enforce correctly through the IdP. For OneLogin, you must configure custom User roles for the roles, timezone, and entitlements fields because these lack standard User object mappings.

Regardless of IdP, maintain a test user in staging and run a full lifecycle test (provision, update, deprovision) before enabling SCIM in production. For PagerDuty, also confirm your audit evidence strategy accounts for how deactivated users are retained in the system and whether your export format captures responder attribution from historical incidents.

## Automating immutable audit evidence collection

PagerDuty provides audit records for the previous year on demand. Administrators must export these records manually during compliance review cycles. If your SOC 2 audit observation window covers multiple months of incident response actions, you're searching through manually exported logs and correlating them with Slack exports and call transcripts. That process regularly costs dozens of hours per audit cycle.

PagerDuty's audit trail covers account-level administrative changes. Your IdP logs SSO login events and SCIM sync failures (Okta System Log, Entra ID Sign-in Logs), not PagerDuty itself. During a SOC 2 audit, you need to pull evidence from at least two separate systems to reconstruct a complete access event record. PagerDuty logs administrative changes to SSO configuration (updating the signing certificate, modifying the Login URL, enabling or disabling JIT provisioning) in its self-service audit functionality, but correlating these changes with specific incident timelines requires manual cross-referencing.

We capture incident timelines automatically and make them immutable. We timestamp every incident update, severity change, and role assignment as events occur, preserving accurate chronology across the full incident lifecycle. This transforms audit preparation from forensic archaeology into a simple export task.

## Closing access control holes for audit readiness

Here's where PagerDuty's access model leaves gaps that matter most during a compliance review, and how to address them.

### Limitations on sensitive incident isolation

PagerDuty lacks native private incident isolation at the object level. A user with base Responder access can view active incident details for services their Team owns, and the Team-level visibility controls don't provide granular, per-incident access restriction. This creates a specific risk: a junior on-call engineer can encounter remediation details for an executive-account compromise because the platform has no native mechanism to restrict a single active incident to a named subset of responders. 

Teams work around this by managing separate Slack channels manually, but those workarounds break automation and produce exactly the inconsistent, undocumented process that makes auditors question control effectiveness.

We solve this natively. When you create a private incident in incident.io, access is restricted to users who receive it through one of three explicit paths: direct invitation, membership in a team associated with the incident, or an org-wide "Manage private incidents" permission grant. Slack workspace admins retain override access to all private incidents regardless of invitation status, which supports administrative oversight without requiring broad access grants.

You manage access through the Manage Access control, where you grant access (automatically adding users to the Slack channel and dashboard view) or revoke access (removing them from both). You can also convert a public incident to private at any point during response, and we handle the lockdown automatically. See [Sensitive Incidents doc](https://docs.incident.io/incidents/sensitive-incidents) for the full access model.

### Data residency and provisioning limits

PagerDuty documents data residency options on its Service Regions page. You select US or EU when signing up. If your organization requires contractual guarantees of EU data residency, verify SLA terms directly with PagerDuty during contract negotiation.

Our primary data residency is in the EU (Belgium, europe-west1, with hot standby in the Netherlands, europe-west4), with GDPR compliance shipping on every plan. See [our data storage documentation](https://docs.incident.io/admin/security-faqs#data-storage) for full region details. For AI features, OpenAI and Anthropic process data in the US as sub-processors. We hold Zero Data Retention agreements with both, and sensitive data is automatically redacted before reaching those models. Disclose both sub-processors to your auditors as part of your sub-processor inventory; our GDPR DPA covers both relationships.

PagerDuty's attribute-update gap, where SAML-provisioned fields don't sync after initial account creation, creates ongoing administrative overhead. Security teams maintaining accurate role assignments must either run periodic manual audits or use SCIM's automated lifecycle features alongside the Business-tier offboarding workflow to deprovision users cleanly from escalation policies, schedules, and assigned incidents.

## Assessing secure alternatives to PagerDuty

Here's a direct comparison of PagerDuty and incident.io across the security and compliance features that matter most to enterprise teams.

### Security and compliance comparison

PagerDuty is a battle-tested alerting engine. We coordinate the response in a way that's auditable, private when needed, and designed to produce compliance evidence as a natural byproduct of the incident itself.

| Security feature | PagerDuty | incident.io | Compliance impact |
| --- | --- | --- | --- |
| SAML SSO | Professional, Business, Enterprise* | Enterprise and newer Pro plans | Automates authentication |
| SCIM 2.0 | Business or Enterprise (advanced RBAC features included) | Enterprise plan | Automates user lifecycle |
| Private incident isolation | No native object-level support | Native, Slack-native private channels | Prevents PII exposure, restricts sensitive breach details |
| Immutable audit trails | API access available | Automated CSV/JSON export | Streamlines audit preparation |
| SAML attribute sync | Initial provisioning only* | Continuous SCIM sync | Prevents role drift between IdP and incident tool |
| Data residency (EU) | US or EU region | EU primary, GDPR DPA available | GDPR residency compliance |
| SOC 2 Type II | Certified | Certified | Satisfies audit requirement for both platforms |
| Pricing with on-call | From $41/user/month (Business) | $45/user/month (Pro) or custom Enterprise | Similar cost with different feature sets |

_Capabilities marked reflect PagerDuty's published documentation and third-party sources. Verify current availability with PagerDuty directly._

We hold SOC 2 Type II certification, maintain GDPR compliance, and provide AES-256 encryption at rest with a 99.99% uptime SLA. For security teams assessing vendor viability, our Series B funding and 1,200+ customers including Netflix, Etsy, and Vanta provide the financial and operational evidence.

> "For our engineers working on incident, the primary interface for incident.io is slack. It's where we collaborate and where we were gathering to handle incident before introducing incident.io." - [Alexandre R. on G2](https://www.g2.com/products/incident-io/reviews/incident-io-review-8830447)

### Budgeting for access control

A 150-person team on PagerDuty Business ($41/user/month) that wants AI capabilities would pay approximately $73,800/year in seat costs. PagerDuty's AIOps add-on is consumption-based, priced per accepted event from $699/month, so total AI costs vary with your alert volume rather than headcount. At moderate event volumes the combined annual spend can reach approximately $87,168, but confirm against your actual alert load before budgeting. 

Our Pro plan with on-call costs $45/user/month ($25 base + $20 on-call add-on), totaling $81,000/year for the same 150-person team, with private incidents and automated audit trails included. Our Investigations product automates up to 80% of incident response. Confirm current [Investigations plan inclusion](incident.io/pricing) before finalizing your budget comparison.

Teams migrating off PagerDuty, like [Fin](https://incident.io/customers/fin), report faster MTTR and less cognitive overhead after switching. We provide [migration tools](https://docs.incident.io/getting-started/migrate-from-pagerduty) to ease the transition, including support for parallel running during the switchover period.

Before your next SOC 2 audit cycle, run through this checklist to confirm your current PagerDuty configuration:

1. **SCIM connection test:** Provision a test user, update their role in your IdP, and confirm whether PagerDuty reflects the change. Due to SCIM limitations, attribute updates after initial provisioning may not sync automatically.
2. **Orphaned account audit:** Pull your PagerDuty user list and cross-reference against your IdP. Any user present in PagerDuty but absent from your IdP is a residual access risk.
3. **Team privacy audit:** Confirm which Teams are Private vs. Public and verify that intended responders match actual membership.
4. **Incident visibility test:** Create a test incident and confirm which users can see it from the Incidents overview page, including users outside the associated Team.
5. **Audit log export:** Export one year of audit records and confirm the format matches your auditors' evidence requirements.
6. **Deprovisioning evidence check:** Confirm your incident export captures responder names and roles at the time of the incident, accounting for the fact that deprovisioned users are deleted rather than deactivated in PagerDuty.

[Book a demo](https://incident.io/demo) to see native private incidents, SAML/SCIM configuration, and automated audit trail export in a live environment.

## Key terms glossary

**SCIM (System for Cross-domain Identity Management):** An open standard protocol that automates user provisioning and deprovisioning between identity providers and downstream applications.

**SAML SSO (Security Assertion Markup Language Single Sign-On):** An XML-based protocol that allows users to authenticate once with an identity provider and access multiple secure applications without re-entering credentials.

**Private incident isolation:** The security capability to restrict visibility and access of a sensitive incident, such as a data breach or executive-account compromise, to a designated subset of authorized responders. PagerDuty lacks native support at the individual incident level. We provide it natively through Slack-native private channels with RBAC enforcement.

**RBAC (Role-Based Access Control):** A method of restricting system access based on roles assigned to individual users. In incident management, effective RBAC must control both platform access (who can log in) and incident access (who can view or act on specific active incidents).

**IdP (Identity Provider):** A system that creates, maintains, and manages digital identity information and provides authentication services to other applications. Common enterprise IdPs include Okta, Microsoft Entra ID, and OneLogin.

**Immutable audit trail:** A record of incident events that cannot be altered after capture, preserving an accurate chronological account of who did what and when. Required for SOC 2 Type II control evidence and GDPR incident documentation obligations.