• Products
  • Documentation
  • Resources

Understand authentication policies

An authentication policy allows you to specify authentication settings for different sets of users and configurations in your organization. It verifies that users who access your Atlassian organization are who they claim to be.

Authentication policies look like this:

Screenshot of the Authentication policies with a number next to each element
  1. Default policy – We automatically add members from your managed accounts to the default policy.

  2. Single sign-on (SSO) – Track when you enforce login to Atlassian through SAML or G Suite SSO.

  3. Two-step verification – Track if you require a second step when logging in or make it optional for members.

  4. Password requirements – Track minimum password strength and expiration.

  5. Idle session duration – Track how long members can be inactive before logging them out.

  6. Nonbillable policy - Use a nonbillable policy when you don’t want to pay for certain users. This policy has limited security for its members. 

  7. Members – This helps you track when members have been added to a policy or moved from one policy to another policy.

Learn more about Authentication policies in this video

When you have an organization with multiple products, you create authentication policies for users within your organization and not for products. If you’d like to give users access to a product, you do that by granting them product access.

Learn about how to edit settings or add members

Atlassian Access for multiple authentication policies

Your organization is up and running with one policy. Flexibility comes from having multiple policies for subsets of users and from being able to test settings before you roll them out to your entire organization.

You need an Atlassian Access subscription to create more than one authentication policy. Learn more about Atlassian Access.

Use cases for authentication policies

To manage your organization, you create multiple policies to address the security of different user sets. You also test settings for subsets of users. When you test settings on a small set of users, you avoid rolling out a policy that may not work for your entire organization.

You can create up to twenty policies for your organization.

Here are some examples of how to use authentication policies for your organization:

A diagram showing default policy for many, Test SSO policy for some, Bot account policy for bots

Multiple policies for different subsets of users

Your users have different authentication needs. To meet these needs, you create a policy for each subset of users in your organization. This means you create multiple policies.

For example, you can:

  • Create different policies for specific sets of users such as full-time employees, contractors, the C-Suite, partners

  • Customize authentication settings for your bot accounts

Testing your authentication settings

You need to reduce risk and be able to test a configuration setting for a subset of users before rolling it out.

For example, you can:

  • Test two-step verification on a smaller subset of users to ensure it is set up correctly before rolling it out across your organization.

  • Test SSO by setting up a different policy for different admin test accounts so you can log in and troubleshoot your policy.

What is a default authentication policy?

Your managed accounts provide you with a pool of users for authentication policies. You assign users to be members of policies. Your organization starts with a default authentication policy. The default policy contains login settings for its members. When you provision new managed accounts, we add them as members to your default policy.

To make another policy the default policy:

  1. Navigate to Authentication Policies at admin.atlassian.com.

  2. Select Edit for the policy you want to make the default.

  3. Select Make default policy.

You can’t delete a default policy
1. Select another policy to be the default.
2. Delete the policy (which is no longer the default policy).

To delete a policy:

  1. Navigate to Authentication Policies at admin.atlassian.com.

  2. Select Edit for the policy you want to delete.

  3. Select Delete policy.

What is a nonbillable policy?

With a subscription to Atlassian Access, you can use a nonbillable policy when you don’t want to pay for certain users. We won't bill you for members in a nonbillable policy.

You can only have one (1) nonbillable policy. You can only create a nonbillable policy with a subscription to Atlassian Access. A nonbillable policy has limited security for its members. When you edit authentication policies and make a policy nonbillable, you won't be able to:

  • Enforce single sign-on

  • Require two-step verification

  • Add users that you sync from your identity provider (e.g., Okta, Azure AD, G Suite) to the policy

Synced users can’t be in a nonbillable policy. If you add synced users to a nonbillable policy we will move them to the default policy. It may take a while for you to see this in the policies.

To create a nonbillable policy:

  1. Navigate to Authentication Policies at admin.atlassian.com.

  2. Select Edit for the policy you want to make nonbillable. The policy can't be a default policy.

  3. Select Make policy nonbillable and update the policy.

Learn how to add and move policy members

You can easily update your policy back to all security settings. Once you do its members may count towards your Atlassian Access bill.

A default policy can’t be a nonbillable policy. A default policy is always billable. If you don't want to pay for certain members, make another policy nonbillable and add them to it.

Additional Help