Before you read: this is not a simple role-assignment walkthrough
Site-based RBAC (SRBAC) in Catalyst Center is often summarised in a single sentence: give an operator write access to their sites and nothing else. That summary is accurate as far as it goes, but it understates how much engineering is required to make SRBAC work correctly across a real deployment. Creating an access group in the GUI is a checkbox. Designing the access group structure so that discovery, wireless provisioning, external authentication, and pre-existing accounts all behave the way you intend is an engineering task that the GUI will not warn you about. This article covers both, with particular attention to the constraints that were formally documented for 3.1.6.
This is a technical field note, not a launch announcement. For where 3.1.6 fits in the SRBAC history, see the timeline section below. What follows is a full picture of what SRBAC can and cannot scope.
What SRBAC is, and what it is not
An access group in Catalyst Center pairs two things: a role (which defines what functional permissions the user holds) and a site scope (which defines where in the site hierarchy those permissions apply). Neither element alone constitutes an access group. Under the documented access-group model, a user without a site assignment is treated as having global scope by default; a site without a corresponding role assignment has no access-control effect; verify these behaviors for external AAA users in your deployment. The combination is what produces scoped access, and that distinction matters when you are auditing or troubleshooting user visibility problems.
SRBAC is not a separate product tier and it does not require an additional licence. Any Catalyst Center 3.1.x deployment can use it. Three default access groups are created automatically: SUPER-ADMIN_Global, NW-ADMIN_Global, and OBSERVER_Global. All three carry global site scope, meaning they behave identically to pre-SRBAC role assignments for any user placed in them. Three predefined roles are available (Administrator, Network Administrator, Observer), and administrators can create additional custom roles with granular permission selections. Custom access groups can be created by pairing any of these roles with any site node in the hierarchy.
The three predefined roles map to internal role strings: SUPER-ADMIN-ROLE, NETWORK-ADMIN-ROLE, and OBSERVER-ROLE. Administrator-defined custom roles are a separate category with granular permission selections set by the administrator. When you create a custom access group for site-scoped use, you are most commonly working with NETWORK-ADMIN-ROLE or a custom role, since scoping an Administrator to a single site rarely reflects real operational intent. The role controls the permission set; the site controls the blast radius.
How the site hierarchy enforces scope
Catalyst Center's SRBAC impact table (Table 2 in the 3.1.x Admin Guide, Inventory row) defines three distinct visibility rules for devices and discovery jobs:
- Parent-scope users see resources created by child-scope groups. An access group with scope over a parent site can see devices that were added by access groups scoped to any of that parent's child sites.
- Child-scope users do not see resources created by parent-scope groups. An access group scoped to a child site cannot see devices that were added by an access group at the parent level or above.
- Sibling-scope users do not see each other's resources. Two access groups assigned to different child sites at the same level, say London and Paris, are isolated from each other. Neither can see devices added by the other.
The matrix below makes all visibility outcomes explicit. Read each cell as: can the user whose scope is shown in the row see resources created by the access group shown in the column?
The practical consequence of rule 2 that surprises most people: if a child-site operator tries to add a device that was already discovered by a parent-site user, they receive an "already exists" error but still cannot see the device in their inventory. The device exists from the platform's perspective; it is simply outside the child-site operator's scope. This is not a defect, it is the expected behaviour, but it will generate support calls if operators are not briefed on it beforehand.
Rule 3, sibling isolation, is the London/Paris case. It is correct and important, but it applies only between sites at the same level. It does not extend to parent/child relationships, where the parent hierarchy always retains visibility into child-created resources.
A single user can hold multiple access groups simultaneously. Switching between them does not require logging out: the user looks for a group-switching option in the username menu in the top-right corner (the exact label may vary by version). This is particularly useful for senior engineers who need both scoped access for day-to-day operational consistency and occasional global access for infrastructure-level tasks. Design your access groups with this switching model in mind, rather than creating a single over-permissioned group to cover both operational modes.
Capabilities that cannot be site-scoped
This is where the design work concentrates. Several capabilities in Catalyst Center are permanently global, regardless of what site scope is assigned to the access group. They cannot be granted at Read/Write level to a site-scoped access group. The documented list covers: Extensions (ITSM integration), License, and Network-wide Settings. AAA and ISE server configuration is also global-only: only users with a global site access group can create, edit, or delete AAA or ISE server entries. The Rogue and aWIPS enable/disable toggle, and Allowed List MAC address management, carry the same restriction.
The practical implication is significant. An operator in a non-global access group cannot see the Licensing page or the System Settings pages at all. If your operational model involves regional network admins who also handle licensing renewals or system-level integrations, SRBAC will force you to either elevate those users to global scope (which may not be acceptable from a least-privilege standpoint) or carve out a separate global access group for infrastructure tasks that specific individuals can switch into when needed. Neither option is wrong, but you need to make the decision explicitly at design time rather than discovering it when a site-scoped admin raises a ticket about a missing menu item.
Intent API falls under the Extensions category, which as a whole cannot be site-scoped at Read/Write level. Verify whether individual Intent API calls succeed or fail based on the specific permission each endpoint requires, particularly if your automation uses endpoints that touch globally-restricted capabilities. Review your automation user accounts against this list before enabling SRBAC in a deployment that has existing API consumers.
Wireless provisioning and the parent-site requirement
Wireless provisioning introduces a specific constraint that is easy to overlook in a site-hierarchy design exercise. When a wireless controller manages APs across multiple child sites, the operator provisioning that controller must have access to the common parent site of all the AP locations the controller manages. Access to only some of the child sites is not sufficient. Provisioning will fail if the user's scope does not cover the full set of AP locations managed by that controller.
In a campus deployment where a single 9800 series controller manages APs across three buildings, each modelled as a separate child site, the provisioning operator needs access at the parent-campus level or higher. If you have modelled your site hierarchy to give individual building teams their own scoped access groups, provisioning of the wireless controller is an operation that must be performed by someone with a wider scope. This is worth surfacing explicitly in your RACI documentation for the deployment, because the provisioning step is not obviously different from other wireless configuration tasks until it fails.
External authentication and ISE integration
SRBAC works with external AAA, including ISE-authenticated users. The mechanism for conveying access group membership to Catalyst Center through an external AAA server uses a vendor-specific attribute. Both TACACS+ and RADIUS use the cisco-av-pair / Cisco-AVPair attribute; Catalyst Center accepts either capitalisation for both protocols. The value format in both cases is:
rds=<comma-separated list of access group names>
The first name in the comma-separated list is treated as the default group when the user logs in. Additional groups in the list are available for the user to switch into at runtime. The access groups referenced in this attribute must already exist in Catalyst Center before the external user authenticates; the platform does not create groups dynamically from AAA attribute values.
There is one important constraint on external users and site scope. External users authenticated via ISE are mapped to global-scope access groups by the platform's default handling. Site-scoped access groups for external users must be explicitly defined in ISE and pushed as part of the AAA policy. If your external user population needs site-scoped access, the ISE policy configuration is load-bearing, not optional. An absent or malformed rds= attribute may cause the user to fail authentication, receive a global default role, or be denied access; the exact behavior depends on your ISE policy and Catalyst Center configuration. Verify in a non-production environment before relying on this for access control.
If external authentication is misconfigured in a way that locks out all external users, the recovery mechanism is a CLI command run over SSH to the Catalyst Center instance:
magctl rbac external_auth_fallback enable
This re-enables local authentication fallback. It is worth knowing this command exists before you need it, rather than discovering it during an incident.
The pre-existing account problem
This is the deployment-integrity risk that the 3.1.3 release notes flag directly, and it is the one most likely to create a false sense of security. When SRBAC is enabled on a Catalyst Center deployment that already has users, those existing users do not automatically receive site-scoped access groups. They retain their original role assignment, which carries global implicit scope. Only users who are newly assigned through an access group after SRBAC is enabled receive restricted scope.
The 3.1.3 Assurance release notes state this plainly: "Only new users assigned with site- and role-based access control have restricted access." The corollary is that every pre-existing account remains effectively unrestricted until an administrator explicitly reassigns it through an access group. If you enable SRBAC in a production deployment without auditing and migrating your existing user accounts, you have a configuration that appears to enforce site-based access control but does not, for any user who existed before you turned it on. Audit first, enable second.
The recommended process is to inventory all existing user accounts, determine which access group each account should belong to in the target design, reassign each account to its intended access group, and only then treat SRBAC as operational. In a deployment with a large user population this is a meaningful administrative task, not a toggle.
Where 3.1.6 sits in the SRBAC timeline
For completeness: SRBAC was introduced as a new feature in Catalyst Center 3.1.3, covering both the core platform and Assurance dashboards. The 3.1.6 base release (build 3.1.6-75205) has since been updated through SMU 3.1.6-75405.100 and SMU 3.1.6-75524.200, which became generally available on 2026-06-30. The 3.1.6 release did not introduce new SRBAC capabilities. Both the 3.1.3 and 3.1.6 release notes include a changelog entry dated 2026-02-24 documenting a limitation around the Catalyst Center user role permissions required to apply device credentials to sites.
That limitation is worth understanding directly. To apply device credentials to sites, the user must hold both Network-wide Settings write permission and Device Provision write permission. Network-wide Settings is one of the capabilities that cannot be set to Read/Write on a non-global access group (it is in the permanently global list covered above). This means that applying device credentials to sites is an operation that requires a global-scope access group, not a site-scoped one. A site-scoped operator who attempts this will be missing the Network-wide Settings write permission regardless of what site they have been assigned to. Design your access group structure accordingly: identify which users or service accounts need to apply device credentials, and ensure they hold a global-scope access group with the necessary permissions rather than a site-scoped one.
Our Experience
I have tested SRBAC in Catalyst Center 3.1.6 in organisations where network operations is split across regional teams or where managed service boundaries require strict visibility separation between customer environments. The feature works as documented and the site hierarchy model is genuinely useful for those use cases. I see a lot of potential. The problems I encounter are almost never with the feature itself: they are with the gaps between what operators expect the GUI to enforce and what it actually enforces.
The pre-existing account issue is among the most common remediation tasks I encounter. Organisations that enable SRBAC without auditing their user base first often have a period where they believe access is scoped when it is not. The wireless provisioning constraint catches people in multi-building campus deployments where building-level site modelling seemed like a natural design choice until the first wireless controller provisioning operation failed. The globally-restricted capability list also tends to catch site-scoped admins off guard when they cannot find the Licensing or System Settings pages.
None of these are defects in the platform. They are design consequences that the documentation covers but that do not surface prominently in the normal workflow for enabling a new feature. Working through them before go-live, rather than after, is the difference between SRBAC delivering the access model you intended and creating a set of support escalations that could have been anticipated.
If you are planning to enable site-based RBAC in your Catalyst Center deployment, or if you are seeing unexpected behaviour in a deployment where SRBAC is already active, feel free to reach out to me at Entek IT.
