The process of controlling which browser extensions can be installed, what permissions they can use, and when they should be removed. In security terms, it reduces the chance that add-ons become hidden privileged code capable of reading pages, stealing tokens, or altering authentication workflows.
Expanded Definition
Extension governance is the set of policy and technical controls that decide which browser extensions are approved, how their permissions are scoped, and when they must be reviewed or removed. In NHI environments, that matters because an extension can behave like hidden privileged code with access to pages, sessions, and authentication flows.
Definitions vary across vendors, but the operational boundary is clear: governance is broader than simple allowlisting and narrower than full endpoint management. It includes approval workflows, permission review, version control, monitoring for risky capability changes, and enforced removal when an extension is no longer needed. The same discipline shows up in NIST Cybersecurity Framework 2.0 and in NHIMG guidance on Lifecycle Processes for Managing NHIs, where access, exposure, and lifecycle status are treated as governance problems rather than one-time installation decisions.
The most common misapplication is treating extension approval as a one-time procurement step, which occurs when teams forget that an extension update can introduce new permissions after deployment.
Examples and Use Cases
Implementing extension governance rigorously often introduces friction for developers and analysts, requiring organisations to weigh productivity gains against tighter review and removal controls.
- A security team allows only signed extensions in managed browsers and blocks consumer add-ons that request read-and-write access to all sites.
- An identity operations team reviews extensions used by help desk staff because session capture or DOM manipulation could interfere with authentication workflows.
- A browser hardening program removes dormant extensions that are no longer tied to an approved business need, following the lifecycle logic described in Ultimate Guide to NHIs.
- A developer environment prohibits extensions with hard-coded credentials or broad token access, a risk pattern highlighted in Hard-Coded Secrets in VSCode Extensions.
- A governance committee requires security review before any extension that interacts with SSO, password managers, or admin consoles can be deployed.
These controls align with NIST Cybersecurity Framework 2.0 and the broader control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, where software configuration and access control must be enforced continuously, not assumed at install time.
Why It Matters in NHI Security
Extension governance matters because browser extensions often sit close to the same data and trust boundaries that NHIs depend on: tokens, admin portals, OAuth consent flows, and web-based control planes. If an extension is over-permissioned or abandoned, it can become an unmonitored path for credential theft, session hijacking, or tampering with access decisions. NHIMG research shows that the average organisation believes more than 1 in 5 of their NHIs are insufficiently secured, a reminder that weak governance often hides in plain sight when privileged software is not tracked as part of the identity perimeter.
This is especially important for organisations that rely on browser-based admin work, because the extension layer can bypass assumptions made by application security tooling. The operational model should include inventory, approval, periodic revalidation, and revocation, as described in Top 10 NHI Issues and in the 2024 ESG Report: Managing Non-Human Identities. Organisations typically encounter extension risk only after a token leak, account compromise, or browser-based persistence event, at which point extension governance becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Extension permissions and hidden code expand the attack surface of non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access applies to browser add-ons that can interact with sensitive identity workflows. |
| NIST SP 800-53 Rev 5 | CM-7 | Functionality should be restricted to the minimum necessary for the managed browser environment. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous verification of client-side components that can alter access decisions. |
Limit extension access to only approved functions and review permissions whenever browser state changes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
