Jira Cloud Audit Log: Temporary User Added to Multiple Administrative Groups

[Nick Languita]

Hi Community,

While reviewing our Jira Cloud audit logs, I noticed a user was created, added to several administrative groups, and subsequently removed. The audit log shows the author as JIRA, and the account is no longer present in our user directory.

I found an Atlassian Community profile with the same name associated with the Atlassian Team, which made me wonder whether this account may have been related to Atlassian Support. However, I cannot confirm that the audit-log user and the Community profile are the same person.

We have also raised a support ticket with Atlassian to clarify the activity, but we've been waiting for an update for some time. We'd like to understand whether this type of temporary account and administrative group assignment is normal for Jira Cloud support or another Atlassian-managed process.

Specifically:

1. Under what circumstances might an Atlassian Support engineer or Atlassian-managed account be created in a customer's Jira site?

2. Is temporary membership in administrative groups an expected mechanism for Atlassian Support troubleshooting?

3. Is there a customer-facing setting where Org Admins can see whether Atlassian Support access is enabled or authorized?

4. Is there a way for customers to identify which support case or request resulted in the temporary access?

5. Should these activities normally appear in the Jira audit log with JIRA as the author?

Any insight from Atlassian staff or other Jira administrators would be appreciated.

Thanks,

[Ajay _view26_]

Hi @Nick Languita 

Welcome to the community!

As far as I know, Atlassian support takes explicit consent to make changes in the cloud instance when working on support tickets. The best would be ask them to confirm the exact ticket or internal case number tied to access event. They should be able to correlate the audit log timestamps with their records.

[Nick Languita]

Hi @Ajay _view26_ ,

Thank you for sharing this information. We have been waiting for an update from the Atlassian Support and have not received a response for almost three weeks, despite sending follow-ups. Hopefully, they will see this discussion and provide us with an update soon.

[SPHIOR]

One thing neither answer mentions, and it is the first place I would look while you wait on Atlassian: there are two audit logs, and they are not the same log seen twice.

You are almost certainly looking at the product-level one (Jira > Settings > System > Audit log). There is a second, separate log at admin.atlassian.com > Insights > Audit log. Different coverage, different retention, different API. For user-management events specifically — user created, user added to group — the product-level log has a documented known issue where the Author field can come back blank or as the system rather than a person. The organization-level log records the actor for some of those same events where the product log does not.

So before concluding the actor is unknowable, check the org log for the same timestamps. It may simply have the name.

The time-critical part, and the reason I am replying at all: the organization-level log is fixed at 180 days and is not configurable. Export both logs now, today, rather than after Atlassian responds. Product-level export goes up to 100,000 events; the org-level one is capped at 10,000 activities and arrives by email with a download link that expires after a day. If this turns into anything formal, you will want the raw export with its own timestamps rather than a screenshot taken later, and you do not want the window sliding while a support case is open.

One caution on the export: when you exceed the cap it keeps the NEWEST events, so on a busy instance the oldest silently fall off the end. Narrow the date range around the period you care about rather than exporting everything and hoping.

Not speculating on what happened — you are right to wait for Atlassian on that. But preserve the evidence before it ages out, because that part is on a clock regardless of how the case goes.

Disclosure: I build a Jira app in this space. Nothing to pitch here; the two-logs thing is just the most common gap I see in questions like this.

[Arkadiusz Wroblewski]

Hello and Welcome to Atlassian Community @Nick Languita 

Did the timestamps of this temporary account activity coincide with any active Atlassian Support case where someone in your organization had explicitly granted Atlassian permission to access the site?

Atlassian documents a limitation in the Jira Cloud audit log for user-management actions, events such as creating users or assigning them to groups may not contain the username of the person who actually performed the change.

I also wouldn't use the matching Atlassian Community profile as evidence that the audit-log account belonged to that employee. Only Atlassian can correlate the account ID and timestamps with their internal records.

You have Open Request at Atlassian, so you should wait on Deterministic answer from them. Here we can only Guess, as Community Members we cannot see Backend.

Best,

Arek🤠

[Nick Languita]

Thanks @Arkadiusz Wroblewski , you're right, hopefully Atlassian will provide us with an answer soon as this is somewhat of a security concern on our end. I've also confirmed with our Team that they don't have any support ticket or request that authorized Atlassian Support to access our instance during that period.