• 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. Go to admin.atlassian.com. Select your organization if you have more than one.

  2. Select Security > Authentication policies.

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

  4. 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. Go to admin.atlassian.com. Select your organization if you have more than one.

  2. Select Security > Authentication policies.

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

  4. Select Delete policy.

What is a non-billable policy?

The ability to see a default policy as non-billable will be available in August of 2022. Until August of 2022, a default policy can’t be a non-billable policy. A default policy is always billable.

When users are either manually invited or sign themselves up, you can decide whether to include them in your Atlassian Access subscription.

With an Atlassian Access subscription, you can create a non-billable policy when you don’t want to pay for certain users. We won't bill you for users in a non-billable policy. You can only have one (1) non-billable policy. You can only create a non-billable policy in a local directory. Learn more about directories

When you edit authentication policies and make a policy non-billable, 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

You can't add the users you sync from your identity provider (e.g., Okta, Azure AD, Google Workspace) to a non-billable policy.

If you sync users that are part of a non-billable policy, we move them to a different policy and directory. You can find these users in the default policy of your identity provider directory.

You can easily update your policy to include all security settings. Once you do, the users in the policy may count towards your Atlassian Access bill.

To make a policy non-billable:

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

  2. Select Edit for the policy you want to make non-billable.

  3. Select Make policy non-billable.

To update a non-billable policy to all security settings:

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

  2. Select Edit for the non-billable policy.

  3. Select Add all security settings to policy.

  4. Update policy.

Additional Help