Let the level of access decide who approves. Users can self install plugins that touch nothing sensitive. An admin should approve anything that reads company data or acts on behalf of users. Security should review anything that reaches secrets, production systems or regulated data. Write the thresholds down so people do not guess.
Three tiers
| Tier | What the plugin can reach | Who approves | Typical examples |
|---|---|---|---|
| 1 | Nothing outside its own interface, no company data | The user | A theme, a color picker |
| 2 | Company documents, mail, chat or calendars | The platform admin, with a short review | A meeting add-in, a document add-on |
| 3 | Source code, secrets, production systems, customer or regulated data | Security plus the data owner | An IDE extension, a CI integration, a connected SaaS app with broad scopes |
The tier follows the data, not the platform. A browser extension that reads every page can be tier 3. The same category with narrow site access may be tier 1 or 2.
What the platforms let you enforce
Controls differ. Microsoft Teams admins can block or allow third-party apps in bulk, review apps one at a time and scope them to groups. VS Code organizations can restrict which extensions are allowed. In ecosystems like Obsidian, where plugins inherit the application's access, the control is whether community plugins are allowed on a device at all.
Pick the strictest control the platform offers for tier 3, and use the register in assign an owner to every plugin to track approvals.
Questions that raise the tier
Raise a plugin one tier if any answer is yes:
- Does it request broad scopes such as all mail or all files?
- Does it send data to the vendor's servers?
- Can it run code on endpoints or servers?
- Does it keep tokens that outlive the user's session?
- Is the publisher new, unverified or recently changed?
For the permission side of browsers, see Chrome extension permission warnings decoded.
Keep approvals fast
A slow process pushes people to shadow installs. Aim for a clear service level. A tier 2 decision within a few working days is a reasonable target, written into the process, and tier 3 may take longer with a defined path. Pre-approve common plugins with a standard review so repeat requests are quick.
What an approval record contains
- Plugin, version and publisher
- Requester, approver and date
- Tier and reasons
- Data and scopes
- Conditions, such as group limits or a review date
- Evidence reviewed, with links
Auditors often ask how third-party tools are approved. This record is the answer. See how to answer how you manage third-party integrations.
Avoid these traps
- One size for all plugins. It either blocks harmless things or waves through risky ones.
- Approval by the requester's manager alone for tier 3.
- No expiry. Approvals should come up for review.
- Letting a badge decide. See what a marketplace trust badge proves.
Safeguard supports policy as code for software you build: policies, gates and guardrails that decide what may merge or ship. The same tiering logic can guide which dependencies need a closer look.
Quick check
Can users ever self install?
Yes, for tier 1 plugins that reach no company data. Define tier 1 clearly so users know where the line sits.
Who owns a tier 3 approval?
Security and the data owner together, with the requester named as the plugin's owner in the register.
Sources
- Manage your apps in the Microsoft Teams admin center
- Extension runtime security, Visual Studio Code documentation
- Plugin security, Obsidian Help (source text)
Last reviewed: 19 October 2026.
