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; } } }

New Guest Access Limitations - Using Email Addresses to determine who is a Guest? Really?

Andy Gladstone

Atlassian sent the notification below today.

I am sure that we are not the only organization that this presents an issue to. We have dozens of non-employee consultants that we assign corporate email addresses to in order for us to maintain SSO with internal applications. We also maintain a Sales Force of 1099 independent contractors that are not company employees, but do have corporate domain email addresses.

In all of these cases, the users are set up as Single Space Guests in Confluence. If email domains will become the arbiter of who is a guest vs. a company user, this will result in a massive increase in our billing.

Who at Atlassian can this be escalated to?

Does anyone have a plan on how to address this?

I'm looking to tackle this before the effective date of this published change.

TYIA.

Hello,
We're writing to notify you that, effective December 1, 2026, existing guest access rules for Jira and Confluence will be strictly enforced. To prevent any disruption to your team's access and collaboration, please ensure the necessary adjustments are made before this date.

What is guest access?
Guest access lets you invite an external collaborator into a single space with limited permissions. Guest access is not intended for managed users who are internal to your organization. Guests are free (up to 5 guests per paid user), but the total number of users (paid + guests) cannot exceed your site's user limit.
Atlassian may adjust guest‑to‑paid user ratios or restrict access if guest access requirements aren't followed.
Who can be a guest?
Guest access is intended for people outside your organization, such as clients, vendors, contractors, or partners. Guests must have an email address with a domain outside your organization and its affiliates.
What is being enforced starting December 1?
Users with guest accounts using email domains associated with your organization or its affiliates will no longer be able to sign in to Jira or Confluence as guests. To maintain access, they will need an appropriate licensed user role.
How to prepare:
Please have your org or site admin(s) review your guest accounts before December 1, 2026. If an internal team member needs continued access to Jira or Confluence, assign them an appropriate licensed user role under each relevant product.
To update a user, your admin can do the following:
Go to Settings (the gear icon) → User management
Select the user to open their profile.
Under the relevant Jira or Confluence site, open the Roles dropdown.
Assign the appropriate licensed user role.
Learn more about how to manage guests in Jira and Confluence.
Thank you for taking the time to review this notice and help your team maintain the access they need.

Accepted answers

All comments

Matthew Sinclair

I think you may want to consider this a little differently.

Anyone with your companies domain is not external - they are internal. A safe assumption from where Atlassian is sitting at. (Claimed domain in Org terms) Even if you grant a "Guest" an email account within your domain.

Atlassian wants to be paid for what is used in that light.

Email addresses have always been required "to a point" in entry to any/all Atlassian products - guest/customer/internal or otherwise.

This is likely a filter to enable a cleaner tracking of who is who.

I can see both points of view as to why/where/what - I won't address the elephant in the room as I can see what's going on here - all I can say is caution is advised.

Speak with your account rep to explore options.

Only option I can see to maintain your trend is to stop granting guest's company accounts - they are guests - let them use their own email accounts (within reason).

Just an Atlassian Nerd

Martin Runge

Hi @Andy Gladstone,

I know a least one customer that also would be affected by this enforcement.
We haven't received this email not yet.

But I found it also here: https://support.atlassian.com/confluence-cloud/docs/invite-guests-for-external-collaboration/ and the Jira guest docs use the same wording. They also state that guest access is not intended for managed users internal to your organization: https://support.atlassian.com/jira-cloud-administration/docs/invite-guests-to-jira/

I would not try a workaround such as a separate subdomain for contractors, as Atlassian also reserves the right to restrict your access to the feature if you’re not using it in compliance with this purpose. A workaround would only shift the risk. Let us know how it evolves.

Cheers, Martin

Arkadiusz Wroblewski

Hi @Andy Gladstone

I anticipated that, because I heard different things from different people. Despite that, the rules were always.
Contact them through our known channels for further clarification. Independent contractors using Corporate Domain Email addresses are treated pretty much like internal staff everywhere, from the outside.

Cheers,

Arek🤠🧙‍♂️

Tomislav Tobijas

Oh well… this is new 🤔

We work with clients in the financial sector, and I can definitely see this becoming an issue in certain scenarios. I don't believe we've received this notification yet, but I'll have to double-check.

That said, I can also understand their reasoning here. I suspect this is partly intended to prevent potential misuse of guest access and ensure it's being used as originally intended.

Still, as you've pointed out, there are legitimate use cases where this distinction isn't quite so straightforward.

I'll definitely need to review our clients' sites and current guest usage to assess the potential impact before Dec 1st. 👀

Cheers for raising this @Andy Gladstone!

Tomislav Tobijas

Btw, try raising this somewhere in Champions Slack 👀 Hopefully someone from Atlassian can chime in there or at least point you to someone who can tell you more 🤷

Kristína Salaj

Hello,

I've received this email today and I'm also a little bit confused. So guest access is still possible to set-up but they will investigate if your guest is logging as name@yourcompany.com or name@consultant.com, name@gmail.com or name@anymail.com? Do I understand it correctly?

So our guest who are really external guests with external emails would still have possibility to log-in as free user? But if we would add someone from company with comapany email, we would be charged?

We don't use managed accounts, all licensed users are in directory as external users.

Sarah Marenchino | Devoteam

Hi @Kristína Salaj and @Andy Gladstone,

I work at Devoteam France. It helps to distinguish account management, guest eligibility, and licensed access here.

1. An unmanaged account is not automatically eligible for guest access

Having users listed as external in your directory does not, by itself, make them eligible for the Guest role. Both the Jira and Confluence documentation require guests to be outside your organization and its related entities, with an email domain that is not associated with those organizations.

For Andy’s scenario, being an independent contractor does not override that email-domain requirement.

2. Eligible external guests can still have free guest access

External collaborators using an external email domain can continue to qualify, subject to the other guest requirements and limits. However, an external email address alone does not make an internal employee eligible.

3. The notice describes an access restriction, not automatic billing

The email says affected accounts will no longer be able to sign in as guests from December 1, 2026. It asks administrators to assign an appropriate licensed role if continued access is needed. It does not announce an automatic conversion of those guests into paid users.

The point still requiring clarification from Atlassian is how it will identify domains “associated with” an organization or its affiliates, particularly where accounts are unmanaged. That distinction matters when assessing which existing guests will actually be affected.

Kristína Salaj

Hello @Sarah Marenchino | Devoteam our users on unmanaged accounts are licensed users. But situation is my company, that there is licensed and unlicensed users both on unmanaged accounts. I can filter by e-mail domain, but it's not clear for me, if guest access will be disabled for everyone or it will strictly require differ in email domain, or if it's connected to verified JIRA domain and managed accounts. Would you be able to bring some more light into this differentiation for me? Thank you in advance.

Sarah Marenchino | Devoteam

Hi @Kristína Salaj,

Thank you for clarifying. The notice does not say that all unmanaged accounts, or all guests, will lose access. My earlier reply may not have made that clear enough.

To clarify my answer as a Devoteam France partner:

Users with licensed access: the announced restriction concerns Guest access, not their licensed access to that app.
Users without a license: being unlicensed does not automatically mean they have the Guest role. Check their assigned role for the relevant Jira or Confluence site.
Users with the Guest role: eligibility depends on being outside your organization and using an email domain that is not associated with your organization or its related entities. Being unmanaged does not, by itself, exempt them from that requirement.

Both the Confluence documentation and the Jira documentation describe this email-domain requirement. They do not state that it applies only to verified domains or managed accounts.

What remains unclear is how Atlassian will identify associated domains when enforcing the rule, particularly in an organization like yours without managed accounts. I cannot confirm from the published documentation whether domain verification is part of that technical check.

So, filtering by email domain can help identify potentially affected guests, but it cannot establish exactly which accounts Atlassian will block. That implementation detail still needs confirmation from Atlassian.

Kristína Salaj

What remains unclear is how Atlassian will identify associated domains when enforcing the rule, particularly in an organization like yours without managed accounts. I cannot confirm from the published documentation whether domain verification is part of that technical check.
So, filtering by email domain can help identify potentially affected guests, but it cannot establish exactly which accounts Atlassian will block. That implementation detail still needs confirmation from Atlassian.

This is exactly what confused me. How will Atlassian figure out which accounts will be guests and which will be paid when on our instance there are no managed account and all are external. In these external accounts we have majority licensed users and some guests, so I would like to have some clarification how will Atlassian decide in my case and if there is some similar cases as mine.

Andy Gladstone

Thanks @Tomislav Tobijas! LMK what channel you posted in so I can follow the thread.

Andy Gladstone

And now commenting from my ACTUAL account. 🙄

Arkadiusz Wroblewski

He was only recommending that you can do that. I PM you on Slack where you can address that.

Kris Klima _K15t_

I guess giving guest accounts to people within the Org got out of hand….

Welcome!

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

Quick Links

Find more posts tagged with

confluence

user-management

guest-access

guest-users