-
Suggestion
-
Resolution: Unresolved
-
9
-
Problem Definition
User access admins cannot login as another user. Previously, before the user management UI update, site admins could impersonate users.
Suggested Solution
Allow user access admins to login as another user if they are a user they manage.
Why this is important
User access admins could assist organization admins with product administration by troubleshooting issues.
Workaround
User access admins can collaborate with organization admins, who are able to login as another user.
It may be possible to revert to the old user management UI, thus returning the ability for site admins to impersonate users. Please contact Atlassian support to see whether this is an option for your team.
[AX-158] User Access Admins should be able to login as another user
We've recently migrated to the new Vortex experience, however the loss of impersonation capabilities to for non-Organisation Admins is a step backwards. We have multiple Sites whose Admins used this capability in the original user experience.
Promoting site administrators to organization administrators to maintain the "Log in as user" functionality creates several significant security risks:
Principle of Least Privilege Violation
- Excessive Access Rights: Organization admins have access across ALL sites in the Atlassian Cloud organization, not just their designated site
- Access Control Boundaries: This breaks the intentional separation between site-level and organization-level permissions
Expanded Attack Surface
- Cross-Site Access: A compromised admin account now has access to multiple sites rather than just one
- Credential Value: Org admin accounts become high-value targets for attackers due to their expanded capabilities
Compliance and Governance Issues
- Audit Challenges: More difficult to track who has accessed what across the organization
- Regulatory Violations: May violate compliance requirements (GDPR, SOX, etc.) that mandate strict access controls
- Data Segregation: Different sites may contain data with different security classifications
Operational Risks
- Accidental Changes: Increased risk of admins making unintended changes to sites they shouldn't be managing
- Configuration Drift: More admins with broad permissions increases risk of inconsistent configurations
Business Impact
- Scalability Issues: As the organization grows, the number of org admins would increase disproportionately
- Incident Scope: Security incidents involving admin accounts would have organization-wide impact rather than site-specific impact
This change in Atlassian's permission model forces organizations to choose between proper security practices and operational efficiency, which is why the improvement request is important for maintaining both security and usability.
There really should be an intermediate role below ORG ADMIN that allows for user impersonation without the ability to make top-level changes to an instance.
This is an absolute bug that needs to be fixed before this is rolled out to any other organization. This leaves folks without the ability to validate any security changes for users.
2905f797471e explained the issue very well.
Whilst the introduction of more admin levels is much appreciated, this particular function of logging in as a user should not be with the highest level of admin rights, but with the user access admin as this is the level that needs this function.
At the user access admin level the admin is responsible to create the correct profile of a user and typically troubleshoots any user issue. The users cannot always express their issues well and logging in as the user is a time saver and allows for efficient management of issues.