> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xdr/onboard-cortex-xdr/post-deployment-steps/manage-user-roles-and-access-management/access-context-switching.md). # Access Context Switching Implement Access Context Switching to isolate you work to a specific user group context in Cortex XDR. Access Context Switching is a session-level authorization mechanism that allows users to dynamically adjust their effective permission set and data scope within Cortex XDR. When a user belongs to multiple user groups, the system normally merges all assigned RBAC permissions and SBAC scopes. While this ensures broad access, it can lead to "permission accumulation," where a user unintentionally has high-level permissions across all their data scopes. Access Context Switching allows you to isolate your work to a specific user group’s context, ensuring you operate with precisely the required access for a task and reinforcing the principle of least privilege (PoLP). ### Key benefits * **Enforce least privilege**: Users with multiple responsibilities can isolate their work to a specific scope, reducing the risk of accidental privileged actions. * **Administrative validation**: Administrators can adopt the exact view and permissions of a specific user group to verify access settings and troubleshoot visibility issues. * **Administrative elevation**: Allows Instance Administrators to maintain a restricted, non-administrator context for daily tasks and temporarily switch to a user group with administrator privileges only when necessary. ### How it works * **Self-service**: Once enabled at the tenant level, authorized users can switch their context directly from the platform navigation bar. * **Immediate effect**: Switching between user groups does not require logging out or refreshing your session. Cortex XDR updates the user interface to reflect the active context. * **Persistence**: The last selected user group persists across sessions. If a user logs out and back in, they will remain in the last active context. * **Default context**: For new users or when a previously active group is deleted, the system defaults to the first non-administrator user group (alphabetically). {% hint style="info" %} #### Note Access Context Switching is different from Support Impersonation. It operates solely on the user's own assigned privileges and is used for internal self-management rather than external support. {% endhint %} {% hint style="warning" %} #### Prerequisite Access Context Switching is an optional feature that must be enabled by an Account or Instance Administrator. Before users can switch their access context, an administrator must enable the feature. 1. Select **Settings** → **Configurations** → **General** → **Server Settings**. 2. Locate the **Access Context Switching** section, and enable the toggle. 3. Click **Save**. Once enabled or disabled, all active users will receive a **Configuration update available** notification and must refresh their page to apply the latest settings. {% endhint %} ### Switch your access context 1. In the Cortex XDR navigation bar, click on your active access context (displayed next to your profile icon, such as "Operating as: SOC Analyst"). 2. Select a different group from the **Assigned Groups** list. 3. User Groups with administrator privileges are visually indicated by a crown icon next to the user group name. 4. If you belong to a large number of user groups, the dropdown may display a subset of your assigned groups. If you do not see a specific user group that you are looking for in the dropdown menu, scroll through the list or use the search filter within the menu to locate it. 5. To return to your previous settings, select a different group or (if in validation mode) click **Exit Validation Mode**. ### Important considerations * **Effective access logic**: When you switch to a specific user group, your effective access is a combination of the permissions and scope provided by that group and any roles or scopes assigned directly to your user account. * **Best practice for group management**: To ensure predictable access and fully leverage context switching, we recommend avoiding direct role and scope assignments for users who belong to multiple user groups. Instead, manage all permissions and data boundaries through user group memberships. * **Availability**: Access Context Switching is not available for users who: * Do not belong to any User Group or belong to exactly one User Group. * Have a direct Account or Instance Administrator role. * Are members of User Groups that all provide administrative roles. * **API integration**: API keys created interactively are bound to the user's active context at the time of creation. * **Notifications**: Users continue to receive all notifications related to all their assigned groups, regardless of the currently active context. * **Audit logging**: Every context switch is recorded in the **Management Audit Logs** page, including the original context, the new context, and whether the switch included an escalation to administrative privileges. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-xdr/onboard-cortex-xdr/post-deployment-steps/manage-user-roles-and-access-management/access-context-switching.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.