Hey everyone.

I 100% agree that it's a poor decision for Atlassian to only offer this feature for Enterprise customers, and that the feature is incomplete, and that it really should be considered a security vulnerability as opposed to a feature request.

However, in my experience, 100% of the 67 sites created since we migrated to Cloud were created by accident because users were simply trying to log into our "new" Jira or Confluence sites and they had forgotten the URL.

That's why in June 2024 I asked, Why is Atlassian promoting Shadow IT? Or Accidental IT?

So I was happy when 7a79c351a973 was finally able to get Atlassian in January 2025 to create CLOUD-12193 - Reduce occurrences of accidental site creations and even happier (and frankly surprised) that Atlassian implemented a fix last week.

I feel like perhaps 48d91e7b076f didn't realize that they should have provided that additional context when closing this ticket.

At any rate, I realize that there's outstanding and valid concerns about security, feature completeness, and the unfairness of this being an Enterprise-only feature, but for me, the root cause of all of my accidental site creations was broken login/create new site flow. And Atlassian has (finally) fixed that. 

48d91e7b076f gjones@atlassian.com 

How can this be closed? This is a privilege escalation vulnerability even if Atla$$ian coded it intentionally.

I find it insulting that the comment posted as this issue is 'closed' (it should have the status 'Won't Do'), includes a link to controlling your shadow IT, when this unresolved issue causes shadow IT by letting non-admins take actions on behalf of the company that can result in added products, increased and unbudgeted costs without any oversight.

I am curious to know if anyone tracking this thread knows how we can open a CVE on this vulnerability. The good news we don't need to worry about Responsible Disclosure timelines as Atla$$ian has openly admitted the problem exists, they just refuse to fix it.

48d91e7b076f 

So you are effectively acknowledging the fact that Atlassian has essentially handicapped it's lower subscription tiers with security vulnerabilities and administrative controls that are only accessible from the Enterprise tier. 

This is more than just a paywall to a premium "feature". This is tying the hands of Atlassian administrators at your Premium and standard tiers by restricting access to something that would normally fall into basic admin controls behind your paywall.

That's a crap excuse to close this ticket.

48d91e7b076f: From your comment, you appear unaware that this is still a problem for Enterprise users. Atlassian's own documentation explains ways users can create products when an Enterprise administrator has (theoretically) denied this.

In any case, fixing it for Enterprise only is clearly insufficient, as this is a security vulnerability. Administrative actions like signing up for products should not be available to managed users without permission from an org admin. Worse, for organisations using Atlassian Guard, this allows any user on a company domain to incur costs for the organisation without authority to do so – this is unacceptable.

48d91e7b076f gjones@atlassian.com 

I enjoy using Atlassian products, and highly suggest them to anyone that asks, but I find the closure of this ticket to be very troublesome.  I understand that there may be a need out there for users to quickly spin up Atlassian software, across organizations.  However, in my organization, we have strict controls on data, software and vendor management.  Simply "discovering" products that people in my organization have created by accident is not a good practice.  As an Atlassian Organization Admin, I should be able to define exactly who in my domain has the ability to create new products or organizations. 

Over the past few months, we have seen an uptick in the number of instances where users are erroneously creating new products.  When this happens, I have to reach out to Atlassian support, delete the new product, then wait 60 days and delete the new organization.  This takes time, and if I'm reading this article correctly, it also opens the door to potential security risks.  [What is the impact of shadow IT on my organization? | Atlassian Support|https://support.atlassian.com/organization-administration/docs/what-is-the-impact-of-shadow-it-on-my-organization/]

This is a widespread issue and a solution should be developed for Cloud users.  Thank you.

48d91e7b076f, your post does not add any new information.

On the contrary, it looks like Atla$$ian keeps ignoring the elementary security of their "PREMIUM" and "GUARD" products.

These are only some of the tickets that I'm aware of (and many have been closed by Atla$$ian during the past years!):

• https://jira.atlassian.com/browse/CLOUD-10325
• https://jira.atlassian.com/browse/CLOUD-11690
• https://jira.atlassian.com/browse/CLOUD-12089
• https://jira.atlassian.com/browse/CLOUD-12193
• https://jira.atlassian.com/browse/ACCESS-1135
• https://jira.atlassian.com/browse/ACCESS-1272
• https://jira.atlassian.com/browse/ACCESS-1468
• https://jira.atlassian.com/browse/ACCESS-1645
• https://jira.atlassian.com/browse/ACCESS-1651
• https://jira.atlassian.com/browse/ACCESS-1679
• https://jira.atlassian.com/browse/ID-7697
• https://community.atlassian.com/t5/Articles/What-s-the-word-I-m-looking-for/ba-p/2862486
• https://community.atlassian.com/t5/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895
• https://community.atlassian.com/t5/Atlassian-Account-questions/How-to-Prevent-Atlassian-Products-being-added-by-users-w-company/qaq-p/2401874
• https://community.atlassian.com/t5/Questions/Why-is-Atlassian-promoting-Shadow-IT-Or-Accidental-IT/qaq-p/2731538
• https://community.atlassian.com/t5/Enterprise-articles/An-update-on-product-requests-bringing-shadow-IT-controls-to/ba-p/2840760
• https://community.atlassian.com/t5/Articles/Proposal-to-prevent-Accidental-Site-Creations-accidentalit/ba-p/2867193#M558

Why exactly is it that your customers need to FIGHT against their "trusted supplier"?
Why is Atla$$ian not interested/willing to provide "good value for money" products?

Why is this ticket closed? This has not been addressed for any tier other than Enterprise. 

Enterprise only? Come on Atlassian that's BS.

We truly value your suggestion and the thought you've put into it. The Cloud Enterprise (CE) plan solves the challenges of customers operating our products at a large scale by addressing their complexity, governance, advanced security, and compliance needs. The Atlassian Access product solves for more foundational security requirements and provides identity and access management support. We have implemented solutions for shadow IT risks based on customer differentiation in both CE and Atlassian Access.

For more information, see https://support.atlassian.com/organization-administration/docs/control-your-shadow-it-footprint/

Thanks for your understanding and for being such an important part of our community!

The feature to prevent users from arbitrarily creating products should be available in all plans.
It is difficult for administrators to manually track newly created products, and this process takes a significant amount of time.

Moreover, canceling these unauthorized products is also a cumbersome and frustrating task.

In addition, allowing products to be created without administrative approval can lead to billing and security issues, so it is unreasonable for this feature to be available only in the Enterprise plan.

Atlassian must recognize that if this feature is not implemented, many Cloud users may turn away from Atlassian.
Cheers

I'm flabbergasted that such a feature even exists where owners of a domain cannot control their own resources. If there is an unauthorized data leak due to Atlassian enabling setup of unauthorized product registrations, it's a fundamental BAD PRACTICE and a VERY BAD ATTITUDE by Atlassian essentially telling their customers they don't give a damn about security of their customers data.  I'm really VERY SORRY to be writing such as review of a company that is supposed to be reputable.

992b0dfccfdd 

Ok thanks. That makes me feel a little bit better. At least they're not actively targeting higher-tier subscriptions with these "features"

I still find no justification for handicapping org admins in managing their products they way this has been implemented.

Org admin at any tier should have the ability to control product discovery and adoption within their own org. Simple as that.

67a7415e6eb8: This problem affects those of us on the Standard plan too. I suspect it's a coincidence that you upgraded to Premium around the same time that Atlassian introduced the accidental signups "feature".

I was all fired up to post a lengthy complaint about the paywall feature that doesn't allow admins at lower subscription tiers to actually admin their own systems. I see now that a ton of other people have already done so more eloquently than I could/would have.

I still have to say that I can't think of another SaaS system out there that intentionally takes away permissions from an org admin and forces them to run through this tedious, time-consuming process of chasing down rogue products/sites created by non-admin users. 

I've been frustrated by past evolutions of Atlassian's product suite...but this crap really makes me want to start looking for a replacement platform.

Also, for what it's worth, I never had these issues on the Standard plan. It's only after we upgraded to Premium that this stuff started happening. So you open the door to unfixable issues only AFTER we upgrade to a higher, more expensive tier, then you slap us in the face with a paywall to upgrade to Enterprise just to stop the undesired results of upgrading from Standard to Premium? I don't get it. 

Thanks to 7a79c351a973 for getting CLOUD-12193 - Reduce occurrences of accidental site creations created. I hope everyone can vote for this Suggestion that is actually addressing the issue of accidental creations.

Why is the ability to block site creation locked behind a paywall?

We have ~1300 employees and I end up with 3-4 sites to delete per month, which I typically forward to your support for expedited deletion as I don't wish to wait the 60+ days. With this, not only are you creating unnecessary work for us as site admins, but you are also creating unnecessary work or your own support agents.

Please reconsider locking this basic functionality behind a paywall (enterprise-only, no less! https://support.atlassian.com/organization-administration/docs/update-product-request-settings/), allowing our employees to create rogue sites is not going to win you more customers or bring in more revenue, nor is it going to inspire existing customers to upgrade. 

Thanks for your consideration, and happy 2025!

SUGGESTION FOR ATLASSIAN...

Since Atlassian has locked out our ability to block creation behind a paywall, then +How about improving TWO THINGS: (1) Improve the ability to DELETE the sites/products, and (2) Improve the Site creation process?

• Please ADD A WAY to QUICKLY remove the product & site – an EXPEDITED removal process.

• • Simply give us multiple confirmation prompts to ensure we know we're deleting the site – and then let us delete it, immediately! (Similar to how a "Product" is deleted.)
    • I understand the need for confirmation-delays, but ~90 days is excessive.
        
    • The current deletion process in the “improved” billing experience takes almost 3 months. (The old way took 2 weeks!) Think about that for a second. I have to keep a trouble ticket open for 3 months to track the work on this. I have to show it in my stats for 3 months. I have to keep this on my radar for 3 months. All for a mistaken click from a user.
        
• During CREATION, the Atlassian system should improve user prompts – add CONFIRMATIONS.

• • Confirm the user's actions with pop-ups/messages to ensure they know what they are doing.

• • • Prompts like, “{_}YOU ARE ABOUT TO CREATE A WHOLE NEW SITE…” and “YOU ARE ABOUT TO ADD A BILLABLE PRODUCT TO THIS SITE” and a confirmation, "CONFIRM: I AM  AUTHORIZED TO CREATE THIS NEW SITE AND ADD THIS NEW BILLABLE PRODUCT" and "CHECK WITH YOUR ATLASSIAN ADMINISTRATOR BEFORE CONTINUING" !!
       
    • This would reduce the accidental creations.
      • Every one of the site creations in my organization were created accidentally. This is 100% due to the way the system presents options for our users. The Jira App prompted it or the user wasn’t logged in and so they thought they were clicking into Confluence but they were actually creating a new site.

Respectfully,

Mark

Good Morning! I have to add my comments because this is really ridiculous! I have 4 pages of users creating Jira instances with confluence spaces by mistake 77 new projects that are not being used. Seriously is this a joke? I have to purchase Enterprise license because paying 1.4M a year for your services is not enough. Get this fixed and sorted out asap before we move back to the standard plan or move to Service Now. The admins have enough work without babysitting newly created instances by mistake. Thank you.

This is such a farse.

Atla$$ian keeps closing similar issues claiming that somehow Product Discovery is the same as implementing adequate access controls to prevent standard users from taking admin level actions.  While this does have the effect of resetting the vote count and diluting the customers voice on the issue it does not in fact address the problem as implied by the comments on the closed issues.

Hint: Discovery <> Prevention. Please stop insulting your customers, or if you really think those two words mean the same thing, it's time for the management team to go back primary school and work on their vocabulary.

Over the past 8+ years there have been over a dozen separate issues raised for the exact same problem. A quick total of just the top issues shows over 3000 votes. I know there is some duplication there as I have voted on many of these issues, but that is 3000 times a customer took the time to read the issue and let Atla$$ian know how they are being negatively impacted.

I like Jira, and I see the value for allowing users in free accounts to add products to get sales, but we have a paid subscription, so we should be able to limit adding new products, and hence new costs, to only those persons in the company that are empowered to make those decisions. This is a fundamental control that you will find in any reputable paid service.

Yet here we are with another "Gathering Interest" issue asking Atla$$ian to implement basic system controls in their product that will some be closed with the text as seen in issue CLOUD-11690:

"With the Enterprise plan feature product requests, admins can set a policy and then either deny or approve requests for a new user-created instance." i.e., "To address the problem we created, and have now fixed, pay use some more money.".

Here are just the top three (by votes) related issues all closed.

ACCESS-1468 Allow Administrators to control managed users' associated sites and products - Create and track feature requests for Atlassian products. - https://jira.atlassian.com/browse/ACCESS-1468 (1611)

CLOUD-10325 Allow non-Enterprise administrators to control managed users' associated sites and products - Create and track feature requests for Atlassian products. - https://jira.atlassian.com/browse/CLOUD-10325 (750)

CLOUD-11690 The ability to remove managed users from external sites - Create and track feature requests for Atlassian products. - https://jira.atlassian.com/browse/CLOUD-11690 (243)

ID-7697 Prevent managed users from creating cloud site using a verified domain. - Create and track feature requests for Atlassian products. - https://jira.atlassian.com/browse/ID-7697 (501)

Agree!!  As a customer and system admin, this makes me feel unappreciated, ignored, discounted, and taken advantage of. I've spent HOURS in just the last few days UNDOING the problems around unauthorized site/product creation. 

Here's what we encounter:

1. Managed domain user creates a rogue site "mysite-mycompanyname.atlassian.net"
2. They then and add paid products
3. Other managed users see this in their list of available sites when they login (such as in the Jira App) and join or are invited.
4. I then reply to the emails I get from my managers wondering why we got a new billing notice and "who installed a trial of xyz?!"
5. I then spend HOURS cleaning it all up (i.e., removing users, deleting products, etc.)
6. Then, it in on my TO DO list for WEEKS as I WAIT through each step the process of canceling the products, then canceling the site. This takes WEEKS.
7. Lastly, I play catch-up on the other work that didn't get done while jumping through all the hoops (above).

PLEASE GIVE US CONTROL!!!!!  At least give us an APPROVAL STEP BEFORE A USER is allowed to create a site or add products.

Respectfully,

An Atlassian Admin

If there's an impeding technical challenge for implementing such controls around managed users, then at the very least Atlassian can resolve (aka BANISH) the sketchy misdirection strategy they've had in place that streamlines users to create a new site when they attempt login from any Atlassian URL except domain they're claimed in.

But since this was addressed for Enterprise customers, seems the only reason it's not available to Premium or Standard is because $$$$$.

I agree shadow IT is a nightmare I am constantly blocking sites and url that allow users to try or spin up instances. I think this is my biggest issue along with users able to request apps (I want to be able to disable that section for users)

The same here, people are creating these sites by mistake, they are not aware of this fact.  

Currently I create a support ticket for every newly created product outside our organization to permanently remove it. I hope it will impact Atlassian operational metrics, so they will have to handle this topic sooner or later.

All users at my employer who have spun up products outside our org reported the same feedback to me: they weren’t aware of what they were doing as they were simply following instructions noted in Atlassian tutorials they found online. There are 3 things our company would greatly appreciate serious consideration of:

1. Updating your tutorials to add a disclaimer about the downstream effects of users spinning up these orgs and associated instances. It would be helpful to include:
   1. Describing in more detail what the user is setting up
   2. Cost implications
   3. Shadow IT implications
   4. Potential data compliance violation implications
   5. How involved the cleanup process would be for their employer if they proceed
   6. It would be great to preface any org setup steps in tutorials by saying something like “Please consult with your Atlassian administrators to ensure understanding of your employer’s policies before proceeding with this part of the tutorial.”
2. Shorten the timeframe to delete an org and its associated site(s) by doing one or more of the following:
   1. Shorten the product removal period to a week to complete it all from beginning to end: https://support.atlassian.com/organization-administration/docs/delete-your-organization/
      1. Shorten the cancellation process to 48 hours.
      2. Shorten product deactivation from 15 days to 5 days.
      3. This would allow the org to be deleted about a week after creation. That’s much better than several weeks.
   2. Add a button to the ‘Manage subscriptions’ page called ‘Expedite cancellation’. It would appear as part of the yellow ‘Cancellation pending’ prompt that displays once the subscription cancellation has been initiated. It would allow the user to either:
      1. Go through a series of prompts to complete cancellation in that moment. They could be required to input text that confirms they understand the implications, much like what I had to do above. You could add all disclosures to it about the risks of accidental data loss, etc.
      2. Create a ticket with Atlassian Support that includes all data your team needs to proceed with expedited cancellation/deletion, like hostname, org name, requester contact info pulled from the user’s profile, etc.
   3. Add the details about the remaining steps and their timelines to the ‘Delete organization’ section on the Settings → Details page under Atlassian Administration. I found it difficult to understand how the process works. Documenting it as something like a checklist would be clear. It could list all steps from beginning to end. Any steps the admin has completed are checked off. The remaining steps would note what they are, who is responsible, and the earliest those steps can be completed would be very helpful since currently, this process takes several weeks at minimum.
   4. Add a button labeled ‘Expedite organization deletion’ to the ‘Delete organization’ section on the Settings → Details page under Atlassian Administration. Clicking this would prompt either a:
      1. Series of prompts to complete org deletion in that moment, including any preliminary steps that must be completed. They could be required to input text that confirms they understand the implications as they complete each step in this process, much like what I had to do above. You could add all disclosures to it about the risks of accidental data loss, etc.
      2. Page noting that it will create a ticket with Atlassian Support for assistance and ask them to confirm if they’d like to proceed. If they do, then a ticket would be auto-created that includes all data your team needs, like hostname, org name, requester contact info pulled from the user’s profile, etc.
3. Allow Atlassian global administrators to enable or disable the ability for users to spin up separate orgs/instances. I think the https://admin.atlassian.com/ page is the most suitable location to add a toggle for this. It could be labeled something like ‘Allow users to create and administer products outside the primary organization(s).’ Ideally, there would also be a link there that takes the user to a page describing what this functionality entails, which users would have these permissions, and #1.1-6 above. By default, the toggle should be disabled, so that data compliance policies aren’t unintentionally violated. It should be a conscious decision that a company should make to enable this feature that allows end users to create new orgs/instances.

We've now had 4 separate instances created by users this week alone. This is unacceptable. Not only is it a horrible compliance and data security practice to not allow this to be controlled by org admins in all plan tiers but the length of time it takes to clean up these mistakes is asinine.

Classic vendor lock-in drama! Atlassian's just doing what almost every SaaS company does - squeeze you dry once you're stuck. (Doctorow breaks down this mess here: https://www.youtube.com/watch?v=4EmstuO0Em8)

Only way to fight back? Vote with your wallet and scale back your license count / cancel subscriptions. With AI becoming their new excuse, expect prices to skyrocket while actual value... not so much.

Real talk: Either get leadership to wake up or embrace the Stockholm syndrome. Your choice!

After 4 site deletions in a few months, it sure seems Atlassian's open door policies allowing licensed users with a claimed domain to go out and create new sites that get billed back to the original is just too convenient.

The provided "solution" is just shuffling off additional manual work to administrators & waste time going through the same mundane & tedious steps: reach out to user that created organization, cancel whatever subscriptions they set up, create a ticket to Atlassian support to DELETE the organization, wait for 2-3 weeks, repeat.

Oh my lord, you guys really put what should be a standard (or at least Premium, what are we paying extra for??) security feature behind the Enterprise paywall?  

I'd say that decision did accomplish one thing, now we know this security 'gap' is a monetary decision, an opportunity to collect unintended subscription fees. And their solution to fix the gap is....collecting even higher unintended subscription fees.

In the last two days, we have seen the creation of 10 new products outside the organization. Additionally, our users are not aware of this situation. This occurs due to a gap in the process maintained by Atlassian. It seems unreasonable to require an upgrade to the enterprise plan only for this reason.

100% agree with everyone here, this has been a major pain point for our instance for several months.

Absolutely the same opinion as 09bb9c7a8ac1! Takes a lot of time.

A managed domain account/email address should not be able to create a new Org with products. Yes, I can join as admin & cancel and delete the org, but that takes time, and it should not be allowed in the first place.

+1 Any ETA on it?

I think we need to reframe the conversation to this being a privilege escalation security vulnerability. What we have here is non-administrator users being able to perform an administrator level task. Add to this the fact that the Atlassian product can prevention this vulnerability, but only in their Enterprise offering, shows willful negligence on the part of Atlassian.

In line with ac4b6d5a70f8 and e33e73164351's comments:

I am currently battling to remove a <companyname>-team.atlassian.net instance, but due to (I believe) having Atlassian Access getting its tentacles straight into it, I can't even self-serve delete it after a month+ of waiting for products to die out.

So not only has some graduate followed the bouncing ball and created a shadow site, but I now need Atlassian Support assistance to clean up the mess!

To echo ac4b6d5a70f8, this needs to be completely prevented. In my experience, users aren't even really aware that they've created an organisation (and products, subscriptions etc) when they may have just been trying to sign in and got a bit lost. To tidy up, admins have to go through the painstaking process of removing products & subscriptions and waiting two weeks~ until they can delete the organisation, only for it to potentially happen again.

I don't understand how administrators can stay in control of their organisation's global set up if anyone with the right email address can create sites without approval.

Hi gjones@atlassian.com,

you might think that would be the solution to the problem. In our company, it has already happened twice that another site was created with <companyname>-team.atlassian.net. Unfortunately, in both cases I have not managed to delete these accidentally created sites and companies without the help of Atlassian support, as the product subscriptions cannot be removed! Even cancelling these products did not lead to their complete removal, so that the site and the company could have been permanently deleted afterwards. It would be desirable if Atlassian would check the cancellation of product subscriptions again - especially if they are the last remaining products of a site/company, after which no product should remain!

See also the comment by Darryl Lee [~8fc8181ac0d1] on 14.06.2024 in Issue CLOUD-10325: It looks like ATLASSIAN'S SALES FUNNEL automatically inserts the name <companyname>-team.atlassian.net for a new instance and user. This automatic user guidance leads users of an already registered domain to the unwanted shadow IT sites! This should be prevented by Atlassian.

Kind regards,
Klaus

Hi everyone,

We recently released "Join as Admin" for our Guard customers. This functionality will allow you, as an Org Admin, to add yourself to shadow it product that your managed users have created and determine the next steps for that product. This means you could delete, merge, or let it continue to exist. Please see: https://support.atlassian.com/organization-administration/docs/how-to-work-with-admins-of-discovered-products/ for more info! 

Cross referencing with issue https://jira.atlassian.com/browse/ACCESS-1272 that I think is the simplest description of the root problem we are all facing and some older issues, like https://jira.atlassian.com/browse/CLOUD-10325 and https://jira.atlassian.com/browse/ACCESS-1468 were attempting to highlight to get fixed.

Please add this function as fast as possible. We had multiple cases in just a few weeks. That something like that isn't already integrated is not very funny. Thanks.

Please add this control to prevent users creating new sites and adding products on their own without administrator approval.  Why is this not included out of the box in the premium license tiers?

I love how many of these issues, which are basic in their function and vital for a well-managed environment, are turning into a meme show here.

I understand it may not help much, but is Atlassian aware of this request and how badly they are disappointing customers who often already pay a "premium" tier?

Yes; https://www.youtube.com/watch?v=rimtaSgGz_4.

I'd really love to be able to block users on my domain from spinning up new products.  Chasing people down to find out there are lost in the Atlassian menus grows tiresome, let alone the months of follow up to ensure the products are made non-billable and deleted.

I'd love to hear the rationale behind letting us see these instances but not block their creation....does it really make more money for you to make end users happy at the expense of Security, IT and all of the other groups that have to maintain (and pay for) all of your products?

+10 we have the same issue; this also poses security-issues as we can't manage the contents of these products. Critical company data could easily leak this way.

+1

Vote here https://jira.atlassian.com/browse/CLOUD-11072 as it's "In Progress"