Collaboration / Source date:

Zoombombing and the Rush to Secure Video Platforms

Default-open meeting settings created incidents that forced rapid security feature releases.

Illustration of a meeting host checking an attendee list beside a shuttered conference camera and muted microphone controller.

Nobody was hacked. That is the part of this spring's video conferencing panic that still has not been properly absorbed, four months after strangers started appearing in school lessons, council meetings and Friday team calls to shout abuse and share pornography. There was no exploit. Meeting identifiers were short and predictable, meetings had no passcode, anyone who joined could share their screen, and the links were being posted on public websites and social media by the organisers themselves. The attack required a browser. What the industry called a security crisis was a configuration default, chosen years ago to make it easy for a stranger to join a call, meeting a world in which every school and community group on earth had suddenly become a broadcaster. The response has been instructive, and mostly for the wrong reasons.

What the vendor response actually revealed

The market leader took the sensible course in April: a public pause on new features, passcodes and waiting rooms enabled by default for education and free accounts, a security menu consolidated into the meeting toolbar, and a steady run of releases through the spring. By any reasonable standard that was a fast and competent reaction. The more useful revelation was adjacent to it. Under scrutiny, the platform's description of its encryption turned out to mean something looser than customers had assumed, and researchers found that some call traffic and key material had been routed through infrastructure in a jurisdiction that no enterprise customer had knowingly selected. Both were corrected, the company published a roadmap for genuine end-to-end encryption, and after a public argument in June about whether that protection would be reserved for paying customers, committed to offering it to everyone. The lesson for buyers is not about one vendor. It is that a security claim in a marketing page is a summary, sometimes a generous one, and the only way to know what you have bought is to ask what the words mean technically, where the keys live, where the media is routed, and what changes when you enable a particular feature. That question should be a standing item in collaboration procurement now, and in most organisations it still is not.

Banning the platform is not a control

Several governments, school systems and large companies responded by prohibiting a platform outright. Some of those decisions were defensible on other grounds. As a security measure the manoeuvre mostly fails, because the meetings do not stop. They move to whatever the participants can reach: a personal account on a different service, an unmanaged free tier, a consumer messaging app with a video button. The organisation trades a configurable, logged, centrally administered platform for a dozen invisible ones. The alternative is unglamorous and works. Pick the platforms you will support, configure the tenancy properly, enforce the settings that matter centrally rather than advising users about them, and make the sanctioned route the easiest one to use.

Configure by meeting class, not by paranoia

The reason settings arguments become circular is that organisations try to find one configuration for every meeting. There are three classes, and they want different things. Routine internal meetings. Require an authenticated account from your own directory to join. That single setting eliminates the entire intrusion problem for most of the calendar, without a passcode for anyone to fumble. External and confidential meetings. Passcode plus waiting room, host-only screen sharing until granted, a named person responsible for admitting participants, chat and file transfer restricted, and the meeting locked once the expected attendees have arrived. For anything genuinely sensitive, the host should read the participant list aloud at the start; it takes fifteen seconds and it is the only reliable check. Public and broadcast events. Registration rather than an open link, attendees muted and non-video by default, a separate host and moderator, and a rehearsed procedure for removing and reporting a disruptive participant. A webinar function exists for exactly this and is consistently under-used. Then fix the lifecycle problem underneath all three, which is where the real exposure sits. Personal meeting rooms used as permanent front doors. Recurring links created for a project two years ago that still work, still admit anyone who ever had the invitation, and are pasted in documents that have since been shared outside. Calendar invitations forwarded beyond the intended group. Meetings that continue after the host leaves. None of these are exotic; all of them are a stranger's route into a conversation, and none are addressed by turning on a passcode.

Set controls by meeting classCondensed from the article's settings guidance. This does not verify a platform's current defaults or guarantee confidentiality.
Meeting classControls to define
Routine internalCorporate-directory authentication and centrally enforced settings
External and confidentialPasscode, waiting room, named admission owner and restricted sharing
Public and broadcastRegistration, muted attendees, separate moderation and a rehearsed removal procedure

Qualitative summary of this article's source text, not a measured outcome or performance estimate.

The recordings are the bigger problem

An intruder in a meeting is humiliating for an afternoon. A recording library is a breach waiting for an index. Most organisations that expanded video usage this spring now hold thousands of cloud recordings, many with sharing links that work for anyone who has the URL, automatic transcripts attached, no retention rule, no owner and no deletion process. They contain salary discussions, disciplinary conversations, client negotiations, medical information and board deliberations, and they are discoverable in litigation and reportable in a breach. Decide who may record, where recordings are stored, how long they live, whether transcripts are generated, and how sharing links are restricted. Then go back and deal with the five months of recordings already accumulated, which is the unpleasant part and the reason it keeps getting deferred.

Practical Guidance for Meeting Platform Security Review

  • Require directory authentication for internal meetings and enforce it centrally. One tenancy setting that removes most of the intrusion risk without inconveniencing anyone.
  • Define three meeting classes with fixed configurations and publish them on one page. Arguments about settings end when the classification decides the answer.
  • Retire personal meeting rooms and expire recurring links. Permanent links are permanent access, and they outlive the teams that created them.
  • Restrict screen sharing and file transfer to hosts by default. The disruption people remember was screen sharing, not speaking.
  • Write the recording policy and apply retention to what you already have. Ownership, storage location, transcript generation, sharing restrictions and a deletion date.
  • Assign an owner to each platform and review the settings monthly. Vendors are shipping weekly this year, and defaults you changed in April can return in an August release.
  • Rehearse the removal procedure with meeting hosts. Knowing where the button is, before an incident, is most of the response.
  • Ask vendors what their security claims mean technically. Where keys are generated and held, where media is routed, and what is disabled when a given feature is turned on.

The Regional Angle

Four things are specific to the Gulf, and the first constrains the whole discussion. Platform choice here is not purely a security decision. Internet-based voice and video have long been restricted in parts of the region, and the relaxations granted this spring for remote work and distance learning were specific, conditional and limited to named services. That has two practical consequences. Generic advice to "move the call to a different platform" may be unavailable to your staff, and a permission granted as an emergency measure is not a permanent licence. Confirm which services are currently permitted for business use in each country you operate in, keep that list current, and standardise on something that is actually reachable by everyone on the call, including colleagues dialling in from Saudi Arabia, Oman or Qatar. Second, the question "who is in the room" is harder here than the participant list suggests. A large share of regional meetings involve a speakerphone in an office or a majlis with several people present who never appear on screen, a senior participant joining from a car with a driver listening, or a group huddled around one laptop. Every control described above governs named accounts, and none of them sees the fourth person on the sofa. For confidential conversations, ask explicitly who else is present and expect to have to ask; it is a reasonable question and treating it as routine is the only way to make it socially comfortable. Third, be careful with recordings, because the legal exposure in this region is not primarily a data protection one. Several GCC jurisdictions treat recording or photographing people without consent as a criminal matter, and defamation and insult provisions mean a recorded remark carries a weight it would not carry elsewhere. Announce recording at the start, capture consent in the meeting itself, and think about where the file lands, because the default storage region for most platforms is outside the GCC entirely and a recording of a board discussion is precisely the sort of content your sovereignty policy was written for. Fourth, note what has changed in corporate governance. Emergency measures introduced this spring across the region permitted boards and general meetings to be held electronically, which many companies used for the first time during the annual meeting season. Those arrangements carry conditions: verification of attendee identity, evidence of quorum, voting records, sometimes an obligation to record or to have the minutes attested. A shareholder meeting held on a consumer video link with no attendance verification is a governance defect, not a security one, and it is the kind of defect that surfaces two years later during a dispute.

The objection worth taking seriously

The strongest objection is that the whole episode was disproportionate. Organisations that had not patched an internet-facing gateway since 2018, and had no multi-factor authentication on email, convened emergency committees about meeting passcodes because the problem was visible, embarrassing and easy to explain to a chief executive. Attention is a finite resource in security, and this spring a great deal of it went to a category of incident that, for most companies, produced no data loss at all. The counter is worth stating with equal force. For schools, universities, community groups and support organisations, this was not a prank. Children and vulnerable adults were shown violent and pornographic material, and targeted racist abuse was delivered directly into classrooms. Dismissing that as harmless disruption is a failure of imagination about who uses these tools and what harm looks like when it is not measured in records exfiltrated. The reconciliation is to be honest about where the durable risk sits. The intrusion problem was real, was mostly solved by defaults changing in April, and should now be a settings exercise rather than a programme. The recordings, the permanent links and the inability to say who is actually in the room are the parts that will still be generating incidents in two years, and they are receiving a fraction of the attention.

Common Questions

Are passcodes and waiting rooms enough?

For internal meetings, requiring an authenticated corporate account is better and less irritating. Passcodes and waiting rooms matter most for external and public sessions.

Should we ban a platform that has had security problems?

Rarely. Bans move meetings to unmanaged personal accounts. Configure the tenancy, or migrate deliberately to another supported platform, but do not create a vacuum.

Who should own meeting platform security?

A named owner in IT, with the settings baseline agreed with legal and reviewed monthly. Unowned platforms drift back to vendor defaults within two releases.

What should we expect over the next twelve months?

Expect end-to-end encryption to ship broadly and to become a procurement question rather than a differentiator. Expect the defaults to keep moving, which makes configuration drift a permanent operational task rather than a one-off project. Expect regulators and privacy authorities to turn their attention from meeting intrusion to recordings, transcripts and analytics features. And expect the organisations that banned a platform in April to be quietly using it again by the new year, because the meetings never stopped.


Meeting Platform Security Review — we set the configuration baseline by meeting class, retire the permanent links, and deal with the recording library nobody wants to open.

Continue reading

Talk to OPS

Start with the operating problem.