Managing Chrome Extensions via Google Workspace Admin Console for HIPAA Compliance

Updated 31 Oct 2026 by 2Fifteen Tech

In this article group

Apple Business Manager – Sign Up

This article covers how to restrict Chrome extensions using the Google Workspace Admin Console for HIPAA-regulated environments. Google provides a layered approach to extension management including blocklisting individual extensions, blocking by permission type, and restricting extension access to sensitive websites.

Extension Policy Modes

The Admin Console offers three modes for Chrome Web Store extension management:

Mode	Description	Best For
Allow all apps, admin manages blocklist	Users can install anything except what you explicitly block.	Minimal friction; only need to block a few known-bad extensions.
Block all apps, admin manages allowlist	Users can only install what you explicitly approve.	Highly regulated environments needing strict control.
Block all, allowlist + user requests	Same as above, but users can submit requests for new extensions.	Regulated environments wanting control with less user friction.

Where to find it: Admin Console > Devices > Chrome > Apps & extensions > User app settings (or Settings) > Allow/block mode

Blocklist-Only Approach

Using the “Allow all apps, admin manages blocklist” mode, you can block specific extensions by their extension ID.

How to Block Specific Extensions

Navigate to Devices > Chrome > Apps & extensions > Users & browsers
Select the target Organizational Unit (OU)
Click the yellow “+” in the bottom right to add an extension
Choose to add from Chrome Web Store, by extension ID, or by URL
Set the Installation policy dropdown to Block
Click Save

Note – Note – To find the Extension ID, look at the string at the end of the Chrome Web Store URL. For example, in chromewebstore.google.com/detail/google-translate/aapbdbdomjkkjkaonfhkkikfgjllcleb, the ID is aapbdbdomjkkjkaonfhkkikfgjllcleb.

What Happens When You Block an Extension

If a user already has the extension installed, it will be disabled (but not automatically uninstalled in all cases — see Gotchas below)
The “Add to Chrome” button will appear red with a message that the extension is not allowed
You can set a custom blocked_install_message to direct users (e.g., “Call IT at 555-1234 for an exception”)

Layered Controls Beyond Blocklisting

Google recommends a layered approach rather than relying solely on individual extension blocklists. These additional layers provide stronger protection.

A. Permission-Based Blocking

Instead of blocking individual extensions, block entire categories of permissions. This is the approach Google’s own IT team uses.

Where to configure: Admin Console > Devices > Chrome > Apps & extensions > User app settings > Additional settings > Permissions and URLs

Permission	HIPAA Relevance
Clipboard	Could exfiltrate copied PHI
Browsing data	Access to browsing history
Downloads	Could download data or inject files
Web navigation	Track all browsing activity
Debugger	Full page inspection capability
History	Access to full browsing history
Tab capture	Screenshot/record tab content
Page capture	Save entire pages (potentially containing PHI)
Content settings	Modify browser security settings
Privacy	Modify privacy-related settings
USB devices	Access hardware

Note – Note – When you block a permission, any extension (current or future) that requests that permission will be prevented from installing or running. This is forward-looking — new risky extensions are blocked automatically.

B. Runtime Block Hosts (Protect Sensitive Websites)

Prevent all extensions from interacting with specific websites or domains, even if those extensions are otherwise allowed. This is especially important for HIPAA.

What it blocks on those sites:

Script injection
Cookie reading
Web request modifications
XHR calls

Where to configure: Admin Console > Devices > Chrome > Apps & extensions > User app settings > Additional settings > Permissions and URLs > Runtime blocked hosts

Example: Block all extensions from interacting with your EHR system or patient portal:


*://*.yourehrsystem.com
*://*.patientportal.com

Note – Note – Each instance of runtime_blocked_hosts and runtime_allowed_hosts can have at most 100 host patterns. More than that will invalidate the policy.

C. Block by Extension Type

Using the ExtensionAllowedTypes policy, you can restrict which types of extensions/apps are permitted. Supported types include: extensions, themes, user scripts, hosted applications, legacy packaged applications, and platform applications. Anything not on the list will be blocked.

D. Block External/Sideloaded Extensions

The BlockExternalExtensions policy blocks extensions installed from external sources (e.g., an installed application adding an extension via the Windows registry). This is critical because sideloaded extensions bypass Chrome Web Store vetting entirely. Roughly 26% of enterprise extensions are sideloaded.

HIPAA-Specific Considerations

What HIPAA Requires

HIPAA does not specifically mention Chrome extensions, but the Security Rule requires covered entities to implement safeguards for PHI. Extensions fall under several relevant areas:

HIPAA Requirement	Section	Relevance
Access Controls	164.312(a)	Restrict access to PHI to authorized persons and software
Audit Controls	164.312(b)	Track access to PHI
Integrity Controls	164.312(c)	Protect PHI from unauthorized alteration
Transmission Security	164.312(e)	Protect PHI during electronic transmission

HIPAA Best Practices for Extension Management

Sign a BAA with Google before using any Google Workspace services with PHI
Disable unvetted Marketplace add-ons and extensions — only allow third-party apps that have been contractually vetted
Limit PHI to services covered by the BAA — Chrome extensions are NOT covered by Google’s HIPAA BAA
Require managed browsers or profiles — block unmanaged devices from accessing PHI OUs via context-aware access
Block personal Google account sign-ins on managed devices to reduce data crossing into non-enterprise contexts

Is a Blocklist Sufficient for HIPAA?

For strict HIPAA compliance, many security professionals recommend the allowlist approach (“Block all apps, admin manages allowlist”) because:

A blocklist is inherently reactive — you can only block what you know about
New extensions with data exfiltration capabilities appear constantly
53% of extensions request high-risk permissions (cookies, passwords, browsing history, web content)
54% of extension publishers identify themselves only with free webmail accounts

Note – Note – If the customer strongly prefers the blocklist approach to reduce user friction, the layered strategy (blocklist + permission blocking + runtime host blocking) can provide reasonable protection — as long as they understand the residual risk.

Gotchas and Important Caveats

Gotcha	Details
Policies only apply to managed browsers/users	Policies require either a managed Google Workspace sign-in or Chrome Browser Cloud Management enrollment. Unmanaged browsers or incognito profiles without management are unaffected.
500 app-group limit	Total number of apps multiplied by number of groups cannot exceed 500. Many groups/OUs with different policies can hit this ceiling.
Chrome Web Store must be enabled	If the Chrome Web Store service is turned off, users cannot access the store at all — including extensions you have allowed. Force-installed extensions will still install.
Force-installed extensions override the blocklist	`ExtensionInstallForceList` takes precedence over `ExtensionInstallBlocklist`. Force-installed extensions install silently and cannot be removed by users.
ExtensionSettings overrides other policies	The `ExtensionSettings` JSON policy (via GPO or registry) overrides `ExtensionAllowedTypes`, `ExtensionInstallAllowlist`, `ExtensionInstallForcelist`, `ExtensionInstallSources`, and `ExtensionInstallBlocklist`. Ensure a single source of truth.
Blocked extensions are disabled, not always uninstalled	Blocklisted extensions are disabled but data may remain on the device. Use the `“removed”` installation mode in `ExtensionSettings` policy to fully remove them.
Permission blocks can break legitimate extensions	Blocking permissions like “cookies” or “tabs” globally may break needed extensions. Create per-extension exceptions in the Admin Console to override.
Extensions auto-update and permissions can change	Extensions update automatically (within minutes of Chrome launch, then every 5 hours). A previously safe extension could gain new permissions. Permission-based blocking mitigates this.
OU inheritance	OU settings inherit from the parent. Blocklists set at the top-level OU cascade to all children. Override per child OU as needed — ensure HIPAA-sensitive OUs have the tightest policies.
Manifest V3 transition	~73% of extensions have migrated from Manifest V2 to V3. V2 extensions are being phased out and disabled in some environments. Force-installed V2 extensions can still be enabled via policy.

Recommended Approach for HIPAA Customers

For customers who prefer to avoid a full allowlist while maintaining HIPAA compliance, use this layered strategy:

Step 1: Enable Chrome Browser Cloud Management

Ensure all browsers in the organization are enrolled. This is free with Chrome Enterprise Core and is the prerequisite for any policies to be effective.

Step 2: Use Permission-Based Blocking as the Primary Control

Block high-risk permissions globally. Suggested permissions to block for a HIPAA environment:

debugger
pageCapture
tabCapture
desktopCapture
contentSettings
privacy

Note – Note – Evaluate carefully before blocking permissions like cookies, tabs, or webRequest as these may break many legitimate extensions.

Step 3: Set Runtime Block Hosts for PHI-Handling Websites

Add all web applications that handle PHI to the runtime blocked hosts list. This prevents any extension from reading, modifying, or intercepting data on those sites.

Step 4: Block Known-Bad Extensions by ID

Maintain a blocklist of specific extensions that pose known risks (VPN proxies, unapproved GenAI tools, etc.).

Step 5: Block External/Sideloaded Extensions

Enable the BlockExternalExtensions policy to prevent extensions from being installed outside the Chrome Web Store.

Step 6: Monitor with the Apps & Extensions Usage Report

Regularly review installed extensions across the fleet: Admin Console > Devices > Chrome > Apps and extensions usage report. This provides install counts, permissions required, and risk assessment data.

Step 7: Consider the Extension Request Workflow

If the customer later decides to tighten controls, the “Block all apps, admin manages allowlist, users may request extensions” mode provides a middle ground: strict control with a built-in process for users to request what they need.

Quick Reference

Task	Location
Set allow/block mode	Admin Console > Devices > Chrome > Apps & extensions > User app settings > Allow/block mode
Block specific extensions	Devices > Chrome > Apps & extensions > Users & browsers > [OU] > + > Block
Block permissions	Devices > Chrome > Apps & extensions > User app settings > Additional settings > Permissions and URLs
Set runtime blocked hosts	Devices > Chrome > Apps & extensions > User app settings > Additional settings > Permissions and URLs > Runtime blocked hosts
View extension usage report	Admin Console > Devices > Chrome > Apps and extensions usage
Enable Chrome Browser Cloud Management	Admin Console > Devices > Chrome > Managed browsers
Block external extensions	Admin Console > Devices > Chrome > Settings > BlockExternalExtensions policy