How do I enforce SSO in GitHub?

On GitHub Enterprise Cloud, go to the organization's Settings, Authentication security, and select Require SAML SSO authentication for all members. GitHub removes members who have not authenticated through the IdP, so check the list first. Requiring SAML at the enterprise level overrides organization settings.

Can Slack owners bypass SSO?

Yes. Slack's documentation says Workspace Owners and Org Owners can bypass SSO and sign in with email and password, so keep the owner list short and treat every owner as a break-glass account with strong 2FA.

How do I disable password login in Atlassian Cloud?

With Atlassian Guard Standard, edit an authentication policy under Security, User security, Authentication policies and select Enforce single sign-on. Keep a separate policy that does not require SSO for one or two admins so you can still sign in if the IdP fails.

Does enforcing SSO revoke personal access tokens?

Not always. GitHub requires classic tokens and SSH keys to be authorized for SSO and lets owners revoke those authorizations, while Atlassian user API tokens keep working unless the authentication policy blocks them. Check each app's token settings separately.

Why keep a break-glass account if SSO is enforced?

If the IdP is down or misconfigured, an enforced app locks everyone out, including admins. One or two local admin accounts with security keys, stored offline and monitored, give you a way back in without leaving a general password path open.

Enforce SSO and disable local logins in a SaaS app

Make the identity provider the only way into GitHub, Atlassian, and Slack: enforce SSO, keep one or two break-glass admins, end old password sessions, close the token side doors, and alert on what is left.

Enforcing SSO means the app's own login stops working for everyone except a short list you choose, so the IdP's MFA, conditional access, and deprovisioning apply to every session. The work is five moves: turn on the app's require-SSO switch, keep one or two break-glass admins outside it, sign everyone out so old password sessions die, revoke or SSO-gate personal API tokens, and alert on any non-SSO sign-in. This recipe uses GitHub, Atlassian Cloud, and Slack as worked examples; the pattern applies to any app with an SSO enforcement setting.

The reason is the 2024 Snowflake customer tenant campaign: attackers signed in to about 165 customer accounts with infostealer-harvested passwords, and Mandiant found the affected accounts lacked MFA. Every one of those sign-ins was a local, single-factor login the identity provider never saw.

Before you start: list every way in

Path	GitHub	Atlassian Cloud	Slack
Enforcement setting	Org or enterprise "Require SAML SSO"	Authentication policy "Enforce single sign-on"	"Required for all members"
Built-in bypass	SSO recovery codes; EMU setup user	Users in a non-SSO policy	Workspace and Org Owners
Token side door	Classic PATs, SSH keys	User API tokens	Existing sessions
Plan needed	Enterprise Cloud	Atlassian Guard Standard	Business+ or Enterprise

Check the app's row in the MFA matrix for documented exceptions, and see the local login bypass entry for the wider list. If the plan you need costs more, that is the SSO tax.

1. Create the break-glass accounts first

Pick one or two admin accounts that will stay outside SSO. Give each a FIDO2 security key, a long random password in a sealed vault, and no daily use. The Entra break-glass recipe shows the same pattern for the IdP itself.

GitHub org: after enforcement, save the SSO recovery codes. For Enterprise Managed Users, the setup user (<shortcode>_admin) cannot use SSO and needs 2FA plus a recovery code for enterprise settings.
Atlassian: Atlassian's authentication policy settings say to "create another policy for those users that does not require SSO to login." Put only the break-glass admins in it.
Slack: owners already bypass SSO, so reduce owners to the break-glass people.

Check: each break-glass account signs in with its key from a clean browser. Common failure: the break-glass admin is also an IdP user, so enforcement captures it. Rollback: none needed; these accounts are your rollback.

2. Turn on enforcement

GitHub (enforcing SAML SSO):

Organization > Settings > Authentication security
  [x] Require SAML SSO authentication for all members of the ORG organization
  > Remove members and require SAML single sign-on

Requiring SAML at the enterprise level overrides organization settings for every org. On enforcement, members without a linked IdP identity are removed, including bots and service accounts; they regain prior access if they rejoin within three months.

Atlassian: Security > User security > Authentication policies > Edit > Enforce single sign-on. We recommend enabling it on a test policy with a few users first, then on the policy that covers everyone else.

Slack (SAML SSO setup): workspace path Admin > Workspace settings > Security > SSO & authentication; Enterprise org path Tools & settings > Organization settings > Security > SSO Settings. Choose "required for all members", or "required for all members excluding guests" if guests sign in with email and password.

Check: a normal member account gets redirected to the IdP and the app's password form no longer accepts their credentials. Common failure: on GitHub, a CI bot account disappears from the org because it has no IdP identity; move automation to a GitHub App first. Rollback: clear the checkbox, or set the Atlassian policy or Slack setting back to optional.

3. End sessions that started with a password

Enforcement does not always sign people out. Slack says members already signed in "will remain signed in."

Slack: SSO & authentication > Force session reset and rebind SSO > Reset, then choose to sign out members who have not enabled SSO or everyone (reset SSO sessions). Choosing everyone signs you out too.
Atlassian: on the policy's Settings or Members page, select Reset sessions; members are logged out in about ten minutes.
GitHub: members without a linked identity are removed at enforcement; per member, owners can revoke Active SAML sessions under People.

Check: the app's audit log shows a sign-in through SSO for each active user after the reset. Common failure: resetting during working hours without notice floods the helpdesk; announce it. Rollback: not reversible, and it should not need to be.

4. Close the token side doors

Tokens authenticate without a browser, so SSO never sees them.

GitHub: classic PATs and SSH keys must be authorized for SSO; fine-grained tokens are authorized at creation. Review and revoke them under People > member > Authorized credentials > Revoke (managing SAML access). Revoking removes only the SAML authorization; the token still exists.
Atlassian: in the policy, set User API tokens to "Block members from creating a new or using an existing API token", or cap expiry (the default is one year). Changes apply on the next API call.
Any app: list app passwords, legacy API keys, and personal tokens, then move integrations to service accounts or app installations with an owner.

Check: a pre-existing personal token fails against the org's API after revocation. Common failure: a nightly job breaks because it ran on an engineer's personal token. That job was a bypass; give it its own identity. Rollback: reissue a token for the specific integration only.

5. Alert and review

Send the app's audit log to your SIEM and alert on any sign-in that is not SSO, any change to the enforcement setting, and any use of a recovery code. Review the break-glass list and token inventory quarterly (a recommendation, not a vendor requirement).

Check: sign in as a break-glass admin and confirm the alert fires within minutes. Common failure: the alert keys on a username that changes; key it on the account's stable ID. Rollback: not applicable.

Verify it works

Sign in as a regular user in a private window: the app redirects to the IdP, and the password form rejects the user.
Disable a test user in the IdP and confirm they cannot open the app within the session lifetime you set.
Call the API with an old personal token: GitHub refuses it for the org's resources, and Atlassian rejects a blocked token.
Sign in as each break-glass account: it works, and your SIEM records the alert.
Export the member list and confirm every human account has a linked IdP identity.