Skip to main content

Implementing a break glass SSO bypass with Atlassian Access

This guide is for Atlassian organizations with existing Atlassian Access subscriptions and teams who are in the process of implementing SSO (single sign on) or SAML (security assertion markup language) for their Atlassian organization.

If your organization implemented, or is planning to implement, a simplified login process with Atlassian Access using either SSO (single sign on) or SAML (security assertion markup language), we recommend having a backup authentication plan in place. Otherwise, if your SSO provider has an outage, or you misconfigure either SSO or SAML, your organization's Atlassian cloud users won't be able to access their Atlassian account and use services like:
  • Jira, Confluence, and Jira Service Management Cloud
  • Bitbucket Cloud
  • Statuspage
  • Trello
  • my.atlassian.com
  • getsupport.atlassian.com
  • id.atlassian.com

Back up authentication options

Below we'll present three back up authentication options.

RECOMMENDEDOption A: Don't enforce SSO for the organization admin

  1. Create an organization admin.
  2. Follow the steps for editing authentication settings and members at Atlassian Support.
  3. The organization admin will never be required to sign in with SSO. 
    1. This user will only login with basic authentication, so you should configure two step verification for added security.
    2. You should also consider a frequent password rotation policy and secure password sharing if multiple people need to use the password.
  4. In case of an SSO incident, the organization admin will go to to https://admin.atlassian.com/ > select the org > security tab > Authentication policies.
  5. The admin will edit the existing policy enforcing SSO, uncheck the enforce sign-on, and save.
  6. All users will then be able to login with basic authentication. The account password will be the one that was used before setting up SSO, or, if those do not exist, users will be asked to setup a password while authenticating.

Option B: Have the organization admin use an email address that isn't tied to a verified domain

  1. Create an organization admin using an email address that is not tied to a verified domain.
    1. This user will never be required to authenticate with SSO.
  2. This user will never be required to sign in with SSO.  
    1. As with option A, this user will only login with basic authentication, so you should configure two step verification for added security.
  3. The admin can follow steps 4-6 in Option A in the case of an SSO incident.

Option C: Request a passwordless login from support

This option will take the longest because the licensing team will need to triage the ticket to our support team.

  1. Have an organization admin open a support ticket with our billing and licensing team and ask support to activate a passwordless login request because your team has misconfigured SSO or SAML.
  2. A customer advocate engineer will triage the request to technical support.
    1. Technical support will follow our internal standard operating procedure to trigger the passwordless login request.
  3. The organization admin will receive a one-time link via email that will bypass authentication and automatically log them in as an organization admin.
  4. The organization admin can then follow steps 4-6 in Option A (above).

If the identity provider has downtime, this does not mean all users will be automatically logged out. Depending on the session duration parameter, users will continue to use their previously-established session and any action from a user will reset the counter.

We recommend Option A.

Was this content helpful?

Connect, share, or get additional help

Atlassian Community

Purpose-fit guidance and support to ensure your team's success

Each deployment of Atlassian products is unique, so we offer a breadth of services to design, implement, and optimize solutions for scale.

Learn More