All Posts
CybersecurityIT Services

Teams, Zoom, and the Meeting Software You Forgot You Installed

· Infonaligy

Collaboration clients like Zoom, Slack, and WebEx pile up on endpoints even in Microsoft 365 shops. Here is how to govern and patch all of them.

Teams, Zoom, and the Meeting Software You Forgot You Installed

Your company standardized on Microsoft Teams two years ago. Every employee has a Teams license, every meeting link points to Teams, and your IT team manages Teams through Intune. That part is under control.

But open Task Manager on any five machines in your office and count the collaboration clients. Zoom is on at least three of them. One machine has Cisco WebEx from a vendor demo last quarter. Another has Slack because a client uses it for project channels. Someone in accounting installed GoTo Meeting for a webinar and never uninstalled it. Each of those applications accepts inbound network connections, processes media streams, and updates on its own schedule, or does not update at all.

Those forgotten installs are where the next breach starts.

Collaboration Clients Are High-Value Targets

Meeting software is unusually attractive to attackers for a specific, structural reason: these applications maintain persistent network connections and continuously process incoming data. When the app is running, it automatically parses inbound packets, protocol messages, and media streams from remote senders without waiting for user interaction. That is the mechanism behind zero-click vulnerabilities: an attacker sends maliciously crafted network data to the running client, and the parsing code executes the exploit before the recipient clicks, opens, or approves anything. Phishing remains the more common initial access vector in most environments, but collaboration client vulnerabilities are especially dangerous precisely because they require zero user interaction and bypass the awareness training that stops a phishing email.

Zoom’s own security bulletin page lists multiple critical remote code execution vulnerabilities disclosed over the past 18 months, including flaws in media parsing and message handling.

These applications also have extensive system access by design. They capture microphone and camera feeds. They share screens. They read contacts and calendar data. They integrate with file storage. An attacker who compromises a collaboration client does not need to escalate privileges or move laterally to reach sensitive information, because the application already has access to exactly the data an attacker wants: conversations, documents, and real-time audio and video.

Why Your “Teams-Only” Policy Is Not Enough

Standardizing on Teams is the right first step. It is not the last one. Collaboration clients accumulate on endpoints through channels that a usage policy does not cover.

Client and vendor requirements are the biggest source. A law firm uses Teams internally but every third client sends Zoom links. A manufacturer’s supply chain partner runs WebEx for weekly standups. A healthcare practice joins a payer’s GoTo Meeting for credentialing reviews. Employees install whatever the meeting invite requires, because missing the meeting is not an option.

Mergers and acquisitions bring entire fleets of machines running different platforms. The acquired company standardized on Slack and Zoom. Those applications persist on devices for months after the acquisition closes, often running outdated versions because nobody is managing updates for software that is “being phased out.”

Personal preference and shadow IT account for the rest. A sales director prefers Zoom because clients are familiar with it. A project manager installs Slack because a contractor uses it. An executive assistant downloads a meeting client for a one-time board call and it auto-launches at every startup after that.

The result, in our experience managing SMB endpoints, is that most Microsoft 365 environments have three to five collaboration clients installed across their endpoint fleet, and only one of them is being actively managed.

What Patch Governance Looks Like for Collaboration Software

Patch governance for collaboration clients follows the same principles as any endpoint software management, but with a few specific practices that matter more here than elsewhere.

Build and Maintain a Software Inventory

You cannot patch what you do not know about. Your RMM (remote monitoring and management) platform or Microsoft Intune should be running regular software inventory scans across all managed endpoints. Filter the results for known collaboration applications: Zoom, Slack, WebEx, GoTo Meeting, GoTo Webinar, RingCentral, BlueJeans, and any others that appear.

Automated inventory is the only practical approach at scale. Manual audits go stale within days as employees install new software for new meetings.

Set Version Floors and Enforce Them

Every collaboration vendor publishes minimum supported versions and security bulletins. Your IT team should define a version floor (the oldest version you allow to remain installed) for each allowed collaboration client. Any installation below that floor gets flagged, updated, or removed.

For Teams, Windows Autopatch and Intune handle this natively. Classic Teams updated through the Microsoft 365 update channel, but the new Teams client (default since late 2023) updates through the Microsoft Store or Windows Update depending on how it was deployed. If your patching strategy relies on Office update rings, verify that new Teams is actually controlled by those rings, because in many deployments it is not. Intune compliance policies can enforce minimum version requirements either way. This is one of the real advantages of standardizing on Teams: it lives inside the same management plane as the rest of your Microsoft stack.

For Zoom, the admin console supports minimum version enforcement and auto-update policies. For full version control, deploy through Intune or your RMM using Zoom’s enterprise MSI, which gives your IT team control over update timing and specific version requirements.

For Slack, WebEx, and others, the approach depends on the platform. Some support enterprise deployment and centralized update management. Others do not, which is itself useful information: if a collaboration client cannot be centrally managed and updated, that is a strong argument for removing it from your environment.

Decide What Stays and What Goes

Not every collaboration client on your endpoints needs to remain there. Once you have a complete inventory, sort applications into three categories.

Managed and allowed. Your primary platform (Teams) and any secondary platform with a documented business justification, enterprise deployment support, and centralized update management. These get patched on a defined schedule.

Tolerated with conditions. Clients that specific teams need for external collaboration but that lack full enterprise management. These get version-floor enforcement through your RMM. If they fall below the floor, they get updated or uninstalled automatically.

Blocked. Clients with no business justification, no enterprise management capability, or no active security update program. Remove them and add them to your application blocklist in Intune or your endpoint protection platform. Your EDR solution can alert on reinstallation attempts.

Automate Update Deployment

Manual patching does not work for collaboration software because the update cadence is too fast. Zoom releases updates multiple times per month. Teams updates continuously through the Microsoft Store or Windows Update. Slack ships updates weekly. Waiting for a monthly patch cycle means running known-vulnerable versions for weeks at a time.

Configure auto-update where the vendor supports it. For clients deployed through Intune or your RMM, push updates within 48 hours of release. For critical security updates, your vulnerability response process should treat collaboration clients the same as operating system patches: assess the advisory, skip the pilot ring (the small test group that normally receives updates first), and push the update fleet-wide within 24 hours. A staged rollout makes sense for routine updates, but when a zero-click RCE is in the wild, speed matters more than a test cycle.

Three Questions to Ask Your IT Provider

If an outside firm manages your IT environment, these three questions will tell you whether your collaboration software is actually governed or just installed and ignored.

1. Can you show me a current list of every collaboration application installed across our endpoints?

If the answer involves manual checking or “we’d need to look into that,” your provider does not have automated software inventory running. That means they cannot patch what they do not know about, and they will be in reactive mode when the next collaboration-client vulnerability drops.

2. What is our update policy for Zoom, Slack, and other non-Microsoft collaboration tools?

The right answer includes specific version floors, a defined update timeline (auto-update or within 48 hours), and a mechanism for enforcement. “We handle all patching” is not specific enough. You want to know whether collaboration clients are included in the same patch management workflow as everything else, or whether they fall through the cracks because they are not part of the “standard” software stack.

3. When did you last remove unauthorized collaboration software from our environment?

This reveals whether your provider actively governs what runs on your endpoints or simply manages what was there when they onboarded you. Collaboration clients accumulate over time. A provider who has never cleaned up unauthorized installs is not governing your endpoint software, they are just maintaining it.

The Work Before the Advisory

The pattern here extends beyond Zoom or any single vulnerability. Every few weeks, a security researcher discloses a critical flaw in a collaboration client that most businesses forgot they had installed. The companies that scramble are the ones whose IT teams do not know what is on their endpoints. The companies that send a calm email saying “your fleet is confirmed at the fixed version” are the ones with actual patch governance in place.

That difference is not about speed. It is about having done the work before the advisory drops: knowing what is installed, keeping it updated, and removing what should not be there. Managed IT that covers only your primary platform and ignores everything else leaves gaps that attackers specifically target.

If your Dallas-Fort Worth business needs help building a collaboration software governance program, or you just want to know what is actually installed across your endpoints, our team can run that inventory and give you a clear picture of where you stand.

Know What's Running on Your Endpoints?

We will inventory your collaboration software, enforce version floors, and remove what should not be there.

Get a Free Assessment

Serving Businesses Across Texas & Oklahoma