The catalog change takes effect on upgrade
ServiceNow's Brazil deprecation summary, stamped Updated September 23, 2026, carries one item unlike everything else on it. Under Service Catalog, the wording is plain. ACL records on request management tables and fields no longer grant access based on the catalog role or the catalog admin role. There is no sunset window and no plugin being hidden. The instance changes once you upgrade.
Everything else on the deprecation summary points at a future you can plan for. This one points at your next maintenance window. If an access control on a request management table or field depends on either of those two roles to grant access, that grant stops after the upgrade, and the first sign will be somebody who could open a record on Friday and cannot on Monday.
What to look for in your access control records
The search is narrow enough to finish in an afternoon. Open the access control list on a sub-production clone, filter to records on request management tables and their fields, and read the roles that grant each one. You are looking for the catalog role and the catalog admin role, either alone or among other roles.
The grants that hurt are rarely the obvious administrative ones. They tend to be access controls somebody added years ago to make a fulfiller view work, where the catalog role was the role everyone already held and the fastest way to open the record up. That grant has been the only reason those people can see the record, and nothing on it says so. Check the read rules on requested items and request approvals first, then the field-level controls, which are the ones nobody remembers writing.
Then check who actually holds those two roles in your instance. Plenty of organisations hand out the catalog role broadly because it looks harmless, which is why the grant worked for so many people and why the fallout will be wider than the access control count suggests. Put the list beside your access request governance records so you can name who loses what.
Tightening a grant is the right direction
ServiceNow is doing the correct thing here. A role that exists so people can order a laptop should not be deciding who reads and writes request management records. Access built on it grants more than anyone designed, and the longer it stands the more processes quietly depend on it. Closing that off is a security improvement, and writing it down before the release is reasonable practice.
Where we would push back is placement. A live behaviour change reads differently from the entries around it, and a deprecation summary is a page most teams skim for names they recognise. Someone scanning for things they run will see a column of future deprecations, decide none apply this year, and close the tab. That line deserves the attention your change board gives anything that alters permissions in production. Your catalog is an operating contract with the business, and this changes its terms.
Prepared for future deprecation is a planning signal
The rest of the page runs one sentence template over and over. Starting with the Brazil release, the feature is being prepared for future deprecation, it will be hidden and no longer available for installation, and it will continue to be supported. ServiceNow applies that wording to Operational Technology Discovery, to CMDB Baseline, to the User Registration Request plugin, and to KPI Composer in Performance Analytics.
Read the second half of that sentence as carefully as the first. Nothing on that list stops working in Brazil, and ServiceNow states support continues. What changes is that these cannot be installed fresh, so any build standard assuming you can add them later has a shorter life. Teams running several instances should check whether any of these sit in the pattern they copy from region to region.
The same page flags the Service Graph Connector Integration for Claroty CTD, the Vulnerability Response Integration with Claroty CTD, and Strategic Spend Tracking for Project Portfolio Management. On the ITSM MCP Server, the requester escalate tool is disabled by default, and ServiceNow points callers at the incident modify tool with its escalate and escalation reason inputs instead. If anything in your instance calls the older tool, rewrite that call before the upgrade.
A model migration across roughly 25 product areas
The biggest piece of scheduled work on the page is the deprecation of LLM Service models across roughly 25 product areas. A model change rarely stays inside one team. It reaches every place your organisation switched on a generative feature, which usually means several groups who never compared notes.
Work out where those features are turned on before you work out what the change does. Output that shifts slightly is harder to catch than a feature that stops, because nobody gets an error and the first report arrives weeks later from someone who noticed the summaries got worse.
Put the roughly 25 product areas against your own adoption list, name an owner for each match, and give them a window to re-test after the models change underneath them. Teams that already read the ServiceNow family release cycle on a cadence will find that scheduling straightforward. Teams meeting this page for the first time on upgrade night will not.
The check to run before you book the window
Before Brazil goes in the calendar, run one query on a clone. List every access control on request management tables and fields, filter to the ones whose grant depends on the catalog role or the catalog admin role, and put a name against each. An empty list means this item costs you nothing. A list with rows means you have found the people who will file tickets on the Monday after the upgrade, and you can tell them first.
Then take the page to whoever owns your ITSM platform roadmap and split it into its two kinds of entry, because the page will not. One line changes behaviour now. The rest tell you what to stop building on. Ask at the next change review who has actually opened that access control list, and what they found.
