Skip to main content
Your identity provider (IdP), such as Okta or Microsoft Entra ID (formerly Azure AD), becomes the source of truth for dashboard access: deactivate someone in your directory and they lose access to incident.io, with no manual step. incident.io supports any identity provider that uses SAML or OIDC. Setup happens in two parts: verify the domains your team signs in with, then connect your IdP through a guided setup. You never paste ACS URLs or certificates into incident.io.
Every plan already includes single sign-on through Sign in with Slack or Sign in with Microsoft. Connecting your own identity provider adds sign-in managed independently of Slack or Teams, and is available on the Pro and Enterprise plans.

​
Connecting your identity provider

You’ll need the Manage security settings permission in incident.io and admin access to your IdP.
1

Connect and verify your domain

Go to Settings → Security and, under Single sign-on (SAML), click Connect.
The Single sign-on (SAML) section of the Security settings page, with a Connect button
A drawer opens where you add and verify the email domains your team signs in with, so incident.io can route those sign-ins to your IdP. For each domain, add the TXT record shown (its type, name, and value) to your DNS, then click Check verification. incident.io also checks automatically, and DNS changes can take a few minutes to appear.
The Configure SAML domains drawer showing an unverified domain with the TXT record to add and a Check verification button
2

Choose your provider

Once your domain is verified, click Continue to SSO setup. Choose your provider and follow the provider-specific steps to exchange metadata and certificates.
The Select your identity provider screen, listing Okta, Entra ID, Google, and other providers plus Custom SAML and Custom OIDC options
We support the major identity providers, including Okta, Microsoft Entra ID, Google, OneLogin, and PingFederate, plus generic Custom SAML and Custom OIDC options for anything else. If you leave before the connection is live, the Security page shows Finish setup so you can pick up where you left off.
3

You're connected

Once the connection is active, single sign-on is live. Anyone whose email matches a verified domain is now signed in through your IdP.From the Security page you can Configure domains, Manage connection to update your provider setup, or Disable SAML.
The connected Single sign-on (SAML) section, showing the success banner, the Additionally show Sign in with Slack checkbox, and Disable SAML, Configure domains, and Manage connection buttons
From here, you might also want to set up SCIM against the same identity provider, so users, roles, and seats are provisioned from your directory automatically.

​
Controlling who must use SSO

By default, once single sign-on is enabled, everyone whose email matches a verified domain must sign in through your IdP, and a Sign in with Slack or Sign in with Microsoft attempt is redirected there. You can loosen that:
  • Keep the platform login available. On the Security page, tick Additionally show Sign in with Slack on login page to keep the Slack or Microsoft option alongside single sign-on.
  • Let specific roles bypass. Grant the Bypass SAML Login permission to a role at Settings → Permissions → Account-level so those users can always use Slack or Microsoft sign-in.

​
Avoiding lockout

Even with single sign-on enforced, you keep ways in if your IdP has a problem:
  • Admins always keep access. The Manage security settings permission includes SSO bypass, so anyone who can configure single sign-on can still sign in with Slack or Microsoft to fix or disable it.
  • Turn on an email backup. Enable sign in with email before you need it. It works independently of your IdP.
  • Broken connections fall back automatically. If your IdP connection breaks, incident.io stops enforcing single sign-on and allows your other sign-in methods, so a misconfiguration won’t lock out your team.
Still stuck? Contact help@incident.io.

​
Disabling single sign-on

To turn single sign-on off, go to Settings → Security, click Disable SAML, and type disable SAML to confirm. Disabling logs everyone out; they sign back in with Slack or Microsoft. If you’ve removed the incident.io app in your IdP, disable single sign-on here too, to avoid authentication errors.

​
Mobile app sign-in

When single sign-on is enabled, it’s enforced in the mobile app too. Users signing in on mobile, whether directly or by scanning a QR code from the web dashboard, are redirected through your identity provider. You control whether QR code sign-in is available at Settings → Security under QR code mobile login. Turning it off prevents the QR flow but doesn’t affect direct sign-in on the mobile app.

​
FAQs

When someone signs in through single sign-on, incident.io looks for a matching Slack or Microsoft Teams account by email. If there’s no match, or the email addresses differ, they’re created as a dashboard-only user. These users can’t be assigned incident roles, referenced in workflows, or receive subscriptions as Slack or Teams messages.
Yes. incident.io supports any identity provider that uses OIDC, and the setup is the same as for SAML. Click Connect, verify your domain, then choose your provider. Use Custom OIDC if your provider isn’t listed.
If a user’s email stays the same during a migration, incident.io associates their account with the new provider and doesn’t create a duplicate user. If their email also changes, they’ll appear as a new account and the accounts can’t be merged.
Yes. SCIM can be set up independently from single sign-on but can use the same identity provider. See SCIM provisioning for details.
Yes. If your team uses managed device policies, you can configure a secondary SAML provider to redact sensitive data on the mobile app. See mobile access restrictions for details.