nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What is the password policy of Atlassian Cloud service fi a organization is not configured?

Scott Weber_ihb1hw

If an organization does not configure an organization for Atlassian Access, what would the requirements be for users utilizing the system? I'm looking for the following:

Password character requirements

Password reset requirements

Password expiration timeframe

Ability to have forced resets at next login

Accepted answers

Dave Meyer

Hi Scott,

By default, we require all Atlassian account passwords to be a minimum of 8 characters. We do not enforce any other requirements around resets or expiration without an Atlassian Access subscription.

Hope this helps.

Dave

All comments

Dave Meyer

Hi Scott,

By default, we require all Atlassian account passwords to be a minimum of 8 characters. We do not enforce any other requirements around resets or expiration without an Atlassian Access subscription.

Hope this helps.

Dave

unknown

Hey Dave,

Without setting up Atlassian Access, will it be possible for an admin to modify the password policy or atleast set it up.

Regards,

Fahad H.

Dave Meyer

Hi @[deleted]

Currently Atlassian Access is required to set up any kind of password policy. As a site administrator, you can prompt individual users to reset their password from the user's page, but you cannot set a password policy until you have verified your domain and configured Atlassian Access.

One option would be to verify your domain, start an Atlassian Access trial, set up a password policy, and then trigger a password reset for all your users. This would force all users to set new strong passwords. Then you could let the Atlassian Access trial expire. Obviously users could then reset their passwords again but it would increase your organizations general password quality as a one-off step.

Regards,

Dave

Giuliano C.

Hello everyone,

For all the users searching for this information, since October from this year, it is no longer necessary to purchase Atlassian Access in order to set a password policy. As long as you have a verified domain you are free to do so.

More information can be found n our Atlassian Cloud changes the blog from October.

Wish You the Best,
Giuliano de Campos
Atlassian Team

Sam Neilson

Thanks Giuliano!

Patrick Dunnigan (VTHF83)

Password policy is the lowest bar of security, you should make it available without verifying the domain. This should be a no brainer.

Dave Meyer

Domain verification is the process we use for an organization or company administrator to determine which users are internal to the organization, versus external collaborators. Since a user can use the same Atlassian account across multiple Jira or Confluence sites, it would be quite complex of the administrators of different sites tried to impose different password policies on the same user (considering the premise of a single account is that they only have to log in once).

We are developing a solution for customers to enforce an added security layer for external accounts that have access to their content based on one-time passwords. See https://www.atlassian.com/roadmap/cloud??&p=b8d50209-93

While we don't currently enforce password strength requirements on all Atlassian accounts globally beyond a character minimum, we run a rigorous security program across our products and operations: https://www.atlassian.com/trust/security/security-practices

Andrew Clements_g69c9c

*moved

Andrew Clements_g69c9c

If you are with a very large organisation, claiming a domain is next to impossible, and hence it is not possible to enforce enterprise level password policies. Would be nice to be able set a password policy at an (Atlassian) organisation level. In our case, we would not have any kind of external user.

Warren Kent

agreed - we have sister companies that all use the same domain, however have their own instances of applications that they use (JIRA being one of them). This makes it that we cannot use the same domain name for verification. What should be done instead (based on customer needs) is an option to set authentication policy as a whole on your JIRA instance, like it was done in JIRA Server.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-cloud

confluence-cloud

atlassian-guard