Endpoint security
A browser extension approval list for shared workstations
A practical list that tells users which browser extensions are supported on shared machines, what each one can read, and how the IT owner removes the rest.
Start with repeatable IT work that has a clear owner, clear access limits, and a review cadence. Keep risky technical decisions with the manager or provider who owns the system.
Delegation playbook
On this pageJump to section
A shared workstation collects browser extensions the way a kitchen drawer collects spare keys. Someone installs a coupon finder, a screenshot tool, or a password helper, and the next person inherits it without knowing what it can read. An approval list names the extensions the company supports, the reason each one exists, and the person who reviews it. The list gives users a clear answer and gives the IT owner a way to remove the rest.
Start from a real inventory
Export the installed extensions from each managed browser profile rather than surveying users from memory. Record the extension name, the publisher, the version, and the permissions it requests. Include the browsers that people actually use, because a policy that covers only one browser leaves a gap. Compare the export with the software catalogue so the same tool is not counted twice.
On shared workstations, check the default profile and any profile that is created at sign-in. A guest profile can still load extensions that were installed by an earlier user. Record whether the extension came from the official store or was loaded from a local file. A locally loaded extension is a separate risk and deserves its own review.
Separate required from optional
Mark the extensions the business depends on, such as a password manager approved by security or a support tool that captures session details. Then list the optional tools that make work easier but are not necessary. Everything else belongs in a third group that should be removed. The distinction keeps the list short and gives the review a clear starting point.
Ask the team that owns each required extension to confirm the business reason and the data it can access. A tool that is required by one department should not be pushed to every shared machine by default. Record the owner and the review date beside the entry. An extension without an owner is difficult to defend when its publisher changes hands or stops issuing updates.
Write the approval questions
Ask who publishes the extension and whether the publisher has a documented security practice. Check what data the extension can read, including page content, cookies, downloads, and clipboard access. Confirm that it is distributed through the official store and that updates are signed. A tool that requests broad access to every site needs a stronger reason than a tool that works on one domain.
Review the extension's recent update history and user reports for unexpected behaviour. Check whether the current version is still maintained and whether the publisher responds to security issues. Record the answer to each question in the approval note. The note does not need to be long, but it should show why the risk was accepted.
Publish the list where people look
Put the approved list in the same place people find software requests and onboarding instructions. Use the extension name as it appears in the store, not an internal nickname that users cannot search. Add a one-line description and the name of the owner. A list that lives in a folder nobody opens will not stop the next install.
Give users a simple way to suggest an addition and a clear expectation for how long the review takes. Explain that unlisted extensions will be removed at the next check rather than treating removal as a punishment. Keep the list visible on the shared workstation itself, for example in a short note beside the browser policy. Visibility is what makes an approval list useful.
Handle requests and temporary exceptions
Record each request with the user, the business reason, and the sites the extension needs. Review the request against the same questions used for the list rather than making a fresh judgment every time. If the tool is approved, add it to the list and deploy it through the managed browser policy. If it is declined, explain what would need to change for a future request.
A temporary exception needs an expiry date and a named owner, just like any other access grant. Limit the exception to the user or device that needs it and record how it will be removed. Do not let a temporary approval become permanent because nobody remembers to revisit it. The list should show the expiry so the next review can close it.
Remove extensions at handover
When a shared workstation changes hands, compare the installed extensions with the approved list. Remove anything that is unlisted, outdated, or tied to a personal account. Clear the browser profile so the next user does not inherit sessions or saved passwords. Record the check in the handover note for that device.
Use the browser management console to enforce the list where the platform supports it. Block installations from outside the approved set and allow specific extensions by identifier. Review the console's exceptions monthly, because a policy that is easy to bypass will be bypassed. The goal is a small number of deliberate choices rather than a long list of forgotten installs.
Review the list each quarter
Check every approved extension for an update, a change of publisher, or a new permission request. Remove tools that are no longer used and replace those that have become abandonware. Confirm that the owner still works at the company and still agrees with the approval. A quarterly review is short when the list stays small and the entries still have a named reason.
Report the number of approved extensions, the number of exceptions, and any removals to the IT manager. Note the reasons for removals so the pattern is visible. If users keep requesting the same unapproved tool, the list may be missing a real need. Treat that as a signal to review the requirement rather than to keep saying no, and record the decision beside the request.
Sources and next step
Use the CISA Cross-Sector Cybersecurity Performance Goals and the NIST Cybersecurity Framework 2.0 as primary references for the asset, endpoint, change, physical access, and identity practices discussed in this guide. The NIST patch management planning guidance supports the change handover steps, and NIST digital identity guidance supports the contractor authentication checks. Apply your own policies, contracts, and system documentation to the workflow. Compare this guide with the MFA enrollment review and the spare laptop loaner log before changing a live process.
Keep decisions, approvals, and evidence in systems the business already controls. If the coordination is recurring and your technical owner can define the boundaries, review the IT virtual assistant service areas and contact ITVirtualAssistant to discuss a limited pilot.
Operating brief
What this guide should help you decide
Routine intake, status updates, records, screenshots, and documentation upkeep.
Approvals, risky system changes, security decisions, and final technical judgment.
How to use this guide
Use this page to decide what an IT virtual assistant should handle first. If the task is recurring, documented, and easy to review, it is usually a better first delegation candidate than work that requires live technical judgment.
Treat the article as an operating brief, not just a topic overview. The goal is to turn loose IT work into a named workflow with inputs, outputs, permissions, review cadence, and a handoff rule that protects the business while reducing manager load.
Workflow
Recommended operating workflow
Define the request
Write what a browser extension approval list for shared workstations means in your company, where requests enter, and what finished work looks like.
Limit the access
Give the assistant only the tool permissions needed for intake, records, status updates, or documentation.
Run a pilot
Use a two-week sample period so the manager can review accuracy before expanding the workflow.
Review patterns
Summarize repeat issues, blocked requests, and escalation volume so the technical owner can improve the process.
Decision rules
| Question | VA fit signal | Escalate when |
|---|---|---|
| Is the work repeatable? | The same request appears weekly and can be described in steps. | The request changes business policy or system design. |
| Can quality be reviewed? | The manager can inspect the output without redoing the work. | Only a senior technical person can judge correctness. |
| Is access contained? | The assistant can work with read-only or role-limited access. | Admin rights, customer data, or security settings are involved. |
Delegation checklist
- Write the intake source, expected output, and manager review cadence.
- Confirm the assistant has only the permissions needed for the workflow.
- List the events that require escalation before work continues.
- Track examples for two weeks before changing the workflow.
- Save examples of good and bad outputs so the assistant has concrete references.
- Review the workflow monthly and remove permissions that are no longer needed.
Example first-week agenda
Day one should cover the workflow owner, tools, allowed actions, forbidden actions, and escalation language. By the end of week one, the assistant should have produced a small sample of completed work, a list of unclear requests, and a manager-reviewed improvement note.
What to review before delegating
Confirm the owner, access level, review cadence, and escalation path before assigning any recurring IT workflow to a remote assistant.
What should an IT virtual assistant handle first?
Start with repeatable, reviewable work such as ticket summaries, account records, documentation updates, and checklist follow up.
Get free IT support review