Only a few named people should be able to publish updates to a company extension. Chrome Web Store publishers let you add members to any publisher you administer, with four roles: Admin, Editor, Item Manager and Viewer. Give most people the lowest role that lets them do their job, and keep Admin to one or two owners.
What the documentation says
Chrome's publisher documentation says the old distinction between group publishers and other accounts is gone: you can add members to any publisher you are an admin of. Members are added from the publisher's Settings page, a role is chosen, and an invitation email is sent. The roles, from most to least access, are Admin, Editor, Item Manager and Viewer. Only Admins can manage members and roles, or delete the publisher.
The page does not describe any security benefit of shared ownership and says nothing about 2-step verification. So what follows is our recommendation, not store documentation.
Why this matters for supply chain risk
An extension update reaches every user, and for a force-installed extension that means your whole fleet. The account that can publish it is therefore part of your supply chain. A compromised publisher account lets an attacker ship code under your name, which is the pattern behind several publicly reported extension incidents. See browser extension supply chain attacks for background.
Applying least privilege
| Person | Suggested role | Reason |
|---|---|---|
| Extension team lead | Admin | Manages members and the publisher |
| Backup owner | Admin | So access is not lost with one person |
| Engineers who ship releases | Editor or Item Manager, per Chrome's current role definitions | Can work on items without managing members |
| Security reviewer | Viewer | Can see the state without changing it |
| Everyone else | No access | Not needed |
Check Chrome's current description of what Editor and Item Manager can do before assigning, since we only confirmed the order of the roles, not each role's exact permissions.
Account hygiene we recommend
- Use company-managed accounts, not personal ones, for every member.
- Require strong sign-in for those accounts through your identity provider.
- Review the members table every quarter and after any team change.
- Remove people on the day they leave a team.
- Keep a record of who published each release and when.
- Separate the person who writes a change from the person who approves the release, even if both have access.
Pair it with release controls
Publishing rights are one gate. Add another upstream: require code review before a build is eligible, and scan dependencies before release. See scanning your extension's npm dependencies.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how the inventory lists every package an application pulls in. An extension has the same hidden depth.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation can check an extension's npm packages before a release is published, and policies and gates can hold a build that adds a risky one. A free scan is at gold.safeguard.sh/scan.
Quick check
How many Admins should a publisher have?
At least two, so access survives a departure, and no more than you can name and review.
Does Chrome require 2-step verification for publishers?
The publisher documentation page we read does not mention it. Check your Google account settings and enforce it through your identity provider.
Sources
Last reviewed: 19 October 2026.
