Security Requirements for Selecting a Video Conferencing and Collaboration Platform: A Buyer’s Guide to Criteria and Testing

A video conferencing and collaboration platform carries an organisation's most candid conversations, its recordings and transcripts, its shared files and, increasingly, an AI assistant that listens to all of it. Selections are usually driven by call quality, room hardware and licence bundles, and security is checked late through a questionnaire that rarely asks about guest access, recording stores, encryption modes or meeting bots. This vendor-neutral buyer's guide sets out the security requirements to put in the RFP, how to weight them, what to ask vendors and how to test the answers before signing. It is for security architects, unified communications owners, privacy officers and procurement leads choosing a SaaS meeting and collaboration service. For hardening a platform you already run, see the Collaboration Tool Security Guide and the Unified Communications Security Guide.

Key takeaways

• Decide who may join before you compare products. Authenticated internal users, invited guests, anonymous joiners and telephone dial-in each need a different control, and NCSC guidance is to admit only authenticated users and invited guests directly and to require passcodes for everyone else.
• Know which encryption mode you are buying. Transport encryption to the vendor's servers is the default; end-to-end encryption, where the vendor cannot read content, usually switches off recording, dial-in and AI features, so decide which meetings need it.
• Recordings and transcripts are records. Require retention, legal hold, export, deletion and access controls for recordings, transcripts, chat and shared files, with the storage region stated in the contract.
• AI assistants and bots are new identities in the room. Built-in AI features, third-party note takers and meeting apps read content through tokens and API permissions; require tenant-level control over every one.
• Test the joining paths in the proof of concept. Try an anonymous join, a dial-in join, a guest from an untrusted domain and a revoked user before you sign, and check every attempt reaches your SIEM.

Define requirements

Security requirements follow from how the platform will be used. Agree these points with the communications owner, legal, HR and the privacy team before vendor briefings:

• Meeting types: internal meetings, customer and supplier calls, public webinars, board meetings, HR and disciplinary meetings, clinical or legal consultations. Each class may need its own policy for lobby, recording and encryption.
• External participants: whether external users join as federated users from another tenant, as guest accounts in your directory, or anonymously through a link. See the External Collaboration and Federation Abuse Guide.
• Telephony: PSTN dial-in and dial-out, SIP and H.323 room systems and interoperability gateways. These paths often cannot use the same authentication or encryption as the native client.
• Recording and AI: whether meetings will be recorded, transcribed or summarised, by whom, where the output lands and for how long it is kept.
• Persistent collaboration: chat, channels, file sharing and whiteboards, which turn the platform into a document store with its own retention and eDiscovery needs. See the Enterprise Messaging Retention and Off-Channel Communications Guide.
• Regulatory drivers: recording consent and notice, sector record-keeping rules, data residency and public sector assurance schemes. US federal buyers will meet FedRAMP; NSA's collaboration services guidance lists FedRAMP and NIAP evaluation as one of its selection criteria.
• Endpoints and rooms: desktop and mobile clients, browser joins, virtual desktop optimisation and room devices, each of which must be patched and managed.

A small organisation with one tenant and few external meetings can focus on SSO, MFA, lobby defaults, recording retention and AI controls. Large, regulated or public sector buyers should add end-to-end encryption options for sensitive meetings, customer-managed keys, compliance recording, data residency commitments, independent assurance scoped to the service and full audit export.

Capability areas

Identity and administration

• Single sign-on: SAML 2.0 or OpenID Connect for all users and administrators, with local passwords disabled except for documented break-glass accounts.
• MFA for administrators: enforced through the identity provider, with phishing-resistant methods supported. NCSC advises two-step verification and passkeys where the provider offers them. See the Passwordless and Passkeys Guide.
• Provisioning: SCIM 2.0 so leavers lose meeting hosting rights, recordings ownership is reassigned and personal meeting links stop working. See the SCIM Provisioning Guide.
• Delegated administration: separate roles for platform administration, compliance and eDiscovery, telephony, room devices and support, with admin changes logged.
• Policy inheritance: meeting policies set centrally and assignable by group, with the ability to lock settings so hosts cannot weaken them.

Meeting access control

• Lobby or waiting room with configurable bypass by user type (organisation only, verified external domains, invited guests, dial-in users).
• Passcodes for unauthenticated joiners, unique meeting IDs per meeting, and the ability to disable anonymous join entirely or per policy.
• Clear labelling of external, guest, anonymous and telephone participants in the roster, so hosts can see who is not authenticated. NSA lists the ability to see unauthenticated participants, such as dial-in users, among its criteria.
• External domain allow and block lists for federation and chat, so suppliers can be trusted while look-alike domains and unknown tenants are refused.
• Host controls: lock meeting, remove participant, restrict screen sharing, disable participant recording and end meeting for all.

Encryption

• TLS 1.2 or later for signalling and web traffic and SRTP (RFC 3711) or an equivalent for media in transit, using NIST-approved algorithms and published IETF protocols, which NSA lists as a criterion.
• An end-to-end encryption mode for designated meetings and calls, with the vendor's documentation stating exactly which features are disabled in that mode and how participants verify it.
• Encryption at rest for recordings, transcripts, chat and files, with an option for customer-managed keys where your risk assessment needs one.

Recordings, transcripts and content

• Visible and audible indication to all participants when recording or transcription starts, which NCSC lists as a basic requirement.
• Policy control over who can record, where recordings are stored, who can view or download them and whether download can be blocked.
• Retention by policy with automatic deletion, legal hold that overrides deletion, and search and export for eDiscovery. See the eDiscovery and Legal Hold Guide.
• Data loss prevention and sensitivity labelling for chat and files, and malware scanning for shared files.
• Stated storage region for recordings, transcripts, chat logs and files, and a statement of whether content or metadata is shared with third parties or affiliates, which NSA also lists as a criterion.

AI features, bots and apps

• Tenant-level switches for each built-in AI feature (summaries, live transcription, assistants), assignable by group and by meeting type.
• A statement of whether meeting content is used to train models, how long AI outputs and prompts are kept and where they are processed.
• Control over third-party apps and meeting bots: admin approval, permission review, the ability to block external AI note takers from joining, and an inventory of installed apps with their scopes. See the AI Meeting Assistant Security Guide.
• Prompt injection resistance where an assistant reads invites, chat or shared files. The Gemini calendar prompt injection showed a malicious meeting invite steering an assistant into leaking private meeting data.

Audit, logging and evidence

• Audit events for sign-ins, policy and admin changes, meeting creation and joins (with participant type), recording start, view and download, file sharing, app installs and eDiscovery searches.
• Export to your SIEM by API or streaming, with retention of at least six months at no extra charge, the baseline CISA's Secure by Demand guide asks SaaS buyers to look for.
• Call detail records for telephony, including dial-out destinations, to detect toll fraud and unusual dialling.

Clients, rooms and vendor assurance

• Clients distributed through managed channels with automatic or centrally managed updates; NCSC advises downloading apps only from official stores or the provider's site.
• Room devices that can be enrolled in device management, use per-device accounts and receive vendor security updates for a stated support period.
• Independent assurance scoped to the service and region (SOC 2 Type II, ISO/IEC 27001 certificate, CSA STAR entry, FedRAMP where relevant), a published vulnerability disclosure policy and security advisories with CVE records.

Evaluation criteria

Weights are illustrative, set by NHI Mgmt Group as a starting point. Raise encryption and recording weights for legal, health, finance or government use; raise access control weights where public webinars are common.

The second table links the threats that matter in meetings and collaboration to the requirement that answers each. ATT&CK IDs are from ATT&CK v20.

Choosing an encryption mode

Ask each vendor for its own list of features lost in end-to-end mode rather than assuming; the trade-offs differ by product and change between releases.

Where identity fits

The platform consumes workforce identities through SSO and SCIM, but it also issues identities of its own: guest accounts, room device accounts, telephony resource accounts, bots, AI assistants and third-party meeting apps with API tokens that can read calendars, transcripts and recordings. Require an owner, scope and review date for each, and include them in your non-human identity inventory. See the NHI Discovery Guide. Live video is also no longer proof of identity: the Arup deepfake fraud used a faked video call of senior staff to authorise transfers, so ask how the platform labels external and unverified participants, and keep payment and access approvals out of band. See the Deepfake CEO Fraud Response Playbook.

Questions to ask vendors

• Are SSO, SCIM, admin MFA enforcement, audit logs and eDiscovery included in the tier we are buying, or sold separately?
• Which joining paths (browser, dial-in, SIP or H.323 room systems, interop gateways, legacy clients) bypass SSO or the lobby, and can each be turned off by policy?
• Can we lock meeting security settings so hosts cannot weaken them, and assign different policies by group?
• What exactly is encrypted end to end in your E2EE mode, how are keys generated and verified, and which features stop working?
• Where are recordings, transcripts, chat, files and AI outputs stored and processed, and can we pin them to a region?
• Is any customer content or metadata used to train AI models or shared with affiliates or third parties, and how is that stated in the contract?
• Can we block external AI note takers and unapproved apps from joining meetings, and list every app with its permissions and last use?
• What audit events record recording views and downloads, and how long are logs kept at no extra cost?
• Who on your staff can access our meeting content or recordings, under what approval, and is that access visible to us?
• How quickly do you publish advisories and CVEs for client and room device vulnerabilities, and how are updates forced?

Red flags

• SSO, audit logs or retention controls available only in a premium tier.
• "End-to-end encryption" claims that turn out to mean transport encryption to the vendor's servers.
• No way to disable anonymous join, or lobby bypass that hosts can override against policy.
• Recordings downloadable by any participant with no audit event.
• AI data use terms that allow training on customer content by default, or that cannot be switched off per tenant.
• Third-party apps and bots installable by any user without admin approval.
• Assurance reports whose scope excludes the region, telephony service or AI features you are buying.

Proof of concept

1. Connect the trial tenant to your IdP with SSO and SCIM, enforce admin MFA and confirm a disabled user cannot host, join as internal or open their recordings.
2. Apply a locked meeting policy (lobby for everyone outside the organisation, passcode for anonymous users) and try to override it as a host.
3. Join as an anonymous browser user, a dial-in caller, a guest from an untrusted domain and a federated user from a blocked domain; record which were admitted and how each was labelled.
4. Start an end-to-end encrypted meeting and list which features disappear; compare against the vendor's documentation.
5. Record and transcribe a test meeting, apply a retention policy and a legal hold, then confirm the hold blocks deletion and the export works.
6. Install an approved and an unapproved meeting app, try to add an external AI note taker, and confirm the controls and the audit trail.
7. Stream audit logs to your SIEM and check that joins, recording downloads, policy changes and app installs arrive with the right identities.

Score each step pass or fail against the criteria table. If identity, access control or audit tests fail, stop there rather than signing on the promise of a future release; keeping the incumbent platform until the gap closes is the rollback.

After selection: measures and common failure patterns

Track after go-live: the share of meetings with external participants that used the lobby; the number of anonymous and dial-in joins by month; recordings past their retention date that still exist; approved versus discovered meeting apps and bots; and median time from IdP leaver event to loss of hosting rights. The Collaboration suite migration playbook covers moving between platforms.

• Defaults left open: anonymous join and lobby bypass for everyone remain on because the pilot never changed them.
• Recordings everywhere: recordings and transcripts land in personal storage with no retention, so they are neither deleted nor discoverable.
• AI switched on tenant-wide: summaries and transcripts are enabled for HR and legal meetings that should never have been processed.
• Federation open to all: any external tenant can chat staff, which attackers use for help desk impersonation. See the Email Bombing and Help Desk Impersonation over Teams Guide.
• Room devices forgotten: shared room accounts with static passwords and devices outside patch management.

Framework mapping

Standards and references

• NCSC: Video conferencing services, security guidance for organisations
• NSA: Selecting and Safely Using Collaboration Services for Telework
• CISA: Secure by Demand Guide
• NCSC: The Cloud Security Principles
• IETF: RFC 3711, The Secure Real-time Transport Protocol (SRTP)
• NIST: SP 800-53 Rev. 5
• Cloud Security Alliance: Cloud Controls Matrix

How NHI Mgmt Group can help

We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.

Related NHI Mgmt Group resources: Collaboration Tool Security Guide · Unified Communications Security Guide · AI Meeting Assistant Security Guide · Security Requirements for Selecting an ITSM and Service Desk Platform