Join our Newsletter — 33% off our NHI Course
Home› Guides› Unified Communications Security Guide: Teams, Zoom and Collaboration…
Guide Network Security

Unified Communications Security Guide: Teams, Zoom and Collaboration Platform Controls

PDF for newsletter subscribers · free to read online

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 26 October 2026 17 min read
On this page

Unified communications platforms now carry an organisation's phone calls, meetings, recordings and PSTN connectivity, yet most security programmes still treat them as a chat app with a calendar attached. A Teams or Zoom tenant typically includes telephony routed through session border controllers, meeting rooms running their own operating system and service accounts, dial-in bridges billed per minute and recordings that hold board conversations. This guide covers the voice, meeting and media layer. Chat, guest access, apps and external federation are covered in depth in the Collaboration Tool Security Guide, and tenant-wide identity and email controls in the Microsoft 365 Security Guide. It is written for UC engineers, security architects and SOC teams.

Key takeaways

  • Cloud UC is encrypted in transit by default, but not end to end. Teams uses TLS for signalling and SRTP for media; Zoom uses AES-256-GCM with server-managed keys. The provider can technically access content unless end-to-end encryption (E2EE) is enabled, and E2EE switches off recording, transcription and dial-in.
  • Meeting admission is the control most people actually meet. Lobby bypass, anonymous join and dial-in bypass settings decide who can listen in. Define a stricter policy for sensitive meetings.
  • Telephony brings telecom risks into the tenant. PSTN calling, audio conferencing dial-out and SBC trunks expose the organisation to toll fraud and to exploitation of on-premises voice servers, several of which appear in CISA's Known Exploited Vulnerabilities catalog.
  • Room devices are unattended identities. Every meeting room signs in with a resource account that cannot use interactive MFA, and ships with a local admin account. Govern both like any other non-human identity.
  • A face on a video call is not authentication. Deepfake participants have already been used to authorise large payments. Payment and access decisions need verification outside the meeting.

What unified communications covers and where the risk sits

Unified communications (UC) combines voice calling, video meetings, webinars, voicemail, contact centres and the PSTN gateways that connect them to the public phone network.

ComponentTypical riskPrimary control
Meetings and webinarsUninvited or anonymous joiners, impersonated participants, unwanted recordingLobby policy, authenticated join, passcodes, presenter roles, recording policy
Signalling and mediaInterception on hostile networks, downgrade to unencrypted trunks, media relay abuseTLS for signalling, SRTP for media, E2EE for sensitive sessions
Cloud telephony (Teams Phone, Zoom Phone)Toll fraud, call forwarding to premium numbers, caller ID spoofingDial-out restrictions, international calling limits, call detail monitoring
Direct Routing, SIP trunks and SBCsExposed SIP interfaces, weak certificates, unpatched appliancesMutual TLS, source IP restrictions, patching, SBC hardening
On-premises call control (Unified CM, MiVoice, Asterisk)Internet-facing exploitation, credential theft, ransomware stagingRemove public exposure, patch against KEV entries, segment voice VLANs
Room systems and desk phonesDefault local admin passwords, shared resource accounts, unmanaged firmwareLAPS, Conditional Access for resource accounts, isolated network segment
Recordings, transcripts and AI summariesSensitive content stored outside retention and DLP scope, AI attendeesRecording policy, storage location, retention labels, AI attendee controls

The voice protocols themselves (SIP, RTP, registration hijacking, SPIT) are covered in the VoIP and SIP Security Guide.

Signalling and media encryption

Microsoft's Teams security documentation states that signalling, client to server and server to server traffic use TLS (with MTLS or service-to-service OAuth between servers), and that audio, video and screen sharing use SRTP. Media keys are generated by a secure random number generator and exchanged over the TLS signalling channel, and the Teams call signalling protocol runs over TLS 1.2 with AES-256 in GCM mode. SRTP, defined in RFC 3711, is a profile of RTP that adds confidentiality, message authentication and replay protection to both RTP and RTCP; its default transforms are AES in counter mode and HMAC-SHA1 with an 80-bit tag.

  • Ports: Teams clients use UDP 3478 to 3481 and TCP 443 for audio and video. Allow UDP outbound to the published Teams ranges; TCP 443 fallback degrades call quality.
  • Do not inspect media: Microsoft advises that Teams media should bypass proxies and network security devices because it is already encrypted. See the TLS Inspection Guide for how to build exclusions.
  • Media relays: Teams authenticates to TURN relays with a credential-based token exchanged over TLS. The TURN protocol itself does not mandate encryption, so the protection comes from SRTP on the media inside it.
  • Zoom default encryption: Zoom documents that its default (enhanced) encryption uses 256-bit AES-GCM for audio, video and shared content, with keys generated and managed by Zoom's servers.

Transport encryption protects against eavesdropping on the network path, which is the threat behind ATT&CK T1040 Network Sniffing and T1557 Adversary-in-the-Middle. It does not protect content from the provider or a compromised tenant administrator. See How TLS Works Guide for the handshake detail.

End-to-end encryption: when it is worth the trade-off

E2EE moves key generation to the endpoints so the service cannot decrypt the media. Both major platforms remove features to do so, so treat it as a per-group policy.

AspectMicrosoft TeamsZoom
Where it is configuredEnhanced encryption policies (Set-CsTeamsEnhancedEncryptionPolicy)"Allow use of end-to-end encryption" in the web portal
ScopeOne-to-one calls; meetings for Teams Premium organisersMeetings and Zoom Rooms
DefaultOne-to-one call E2EE disabled; meeting E2EE enabled for Premium organisers to chooseOff until enabled by an admin
Verification20-digit security code derived from the endpoints' call certificate thumbprintsSecurity codes read aloud via the shield icon "Verify" link
Features lostRecording, compliance recording, transcription, live captions, breakout rooms, PSTN dial-in, Microsoft 365 Copilot in meetingsCloud recording, live transcription, AI features, polling, Zoom Apps, whiteboard, pre and post meeting chat
Participant limits and clients200 participants; web and VDI clients blocked1,000 participants; web client, phone and SIP/H.323 endpoints cannot join
Enforcement optionsMeeting templates and sensitivity labels can force E2EEAccount, group or user setting
  • Use E2EE for: board and M&A meetings, legal privilege discussions, incident response bridges during a suspected tenant compromise, and calls with high-risk individuals.
  • Do not use E2EE where: the conversation must be recorded for regulatory reasons. Microsoft notes that users subject to compliance recording cannot use E2EE, so a trader or contact centre agent under a recording obligation must stay on standard encryption.
  • Post-quantum: Zoom offers post-quantum E2EE when all participants run Workplace 6.0.10 or later (Zoom Rooms 6.1.0 or later), falling back to standard E2EE otherwise. Zoom describes it as protection against captured traffic being decrypted later.
  • Verify codes: for sensitive calls, make reading the security code aloud part of the procedure.

Meeting admission and in-meeting controls

The NCSC's video conferencing guidance for organisations sets a simple baseline: allow direct access only to authenticated users and invited guests, require passcodes for anyone unauthenticated, use a lobby to check participants, and make it obvious when a meeting is being recorded. Teams expresses this through meeting policies.

Teams settingPowerShell parameterValuesHardened position
Who can bypass the lobby-AutoAdmittedUsersEveryone, EveryoneInSameAndFederatedCompany, EveryoneInCompany, InvitedUsers, OrganizerOnlyEveryoneInCompany for the standard policy; InvitedUsers or OrganizerOnly for a sensitive meeting policy
People dialling in can bypass the lobby-AllowPSTNUsersToBypassLobbyTrue, FalseFalse (the default): a phone number is not an identity
Who can admit from lobby-UsersCanAdmitFromLobbyOrganizersAndPresentersOnly, OrganizerAndCoOrganizersOnlyOrganisers and co-organisers for large or external meetings
Anonymous users can join a meeting-AllowAnonymousUsersToJoinMeetingTrue, FalseDisable where business allows; otherwise force anonymous users through the lobby
Anonymous users and dial-in callers can start a meetingAdmin centre settingOn, OffOff

Microsoft's definition of anonymous is broader than many admins assume: it covers unauthenticated browser joiners and also authenticated users from external tenants with which you have no external access relationship. Users from blocked domains can still join meetings anonymously if anonymous access is allowed, so a federation block list does not keep anyone out of meetings on its own. Admin policy changes can take up to 24 hours; organiser meeting options apply within seconds.

  • Presenter roles: make only organisers and named presenters able to share content, so a joiner cannot take over the screen.
  • Personal meeting IDs: avoid static personal meeting links for external meetings.
  • AI attendees and note-takers: the NCSC asks organisations to understand what third-party AI attendees collect. Treat them as apps that need approval (see the Collaboration Tool Security Guide), and let organisers remove them from the lobby.

Impersonation on calls and meetings

Voice and video have become the preferred channel for social engineering because they feel more trustworthy than email. In the Arup deepfake fraud in 2024, a finance employee joined a video conference in which, according to Hong Kong police, every other participant was a deepfake built from public footage, and made 15 transfers totalling HK$200 million. No system was breached.

  • Label external participants: keep external and unverified tags visible in meetings and calls, and do not let external PSTN callers present an internal display name.
  • Out-of-band verification: payments, credential resets and access grants requested on a call are verified through a pre-registered channel, never through contact details supplied in the call. See the Deepfake and AI Impersonation Guide and the Vishing and Smishing Guide.

Telephony, PSTN and toll fraud

Once a tenant has PSTN calling or audio conferencing, a compromised account can place calls that cost money. Teams provides an OnlineDialOutPolicy with predefined instances that separately control dial-out from meetings and users' own PSTN calls; both default to international and domestic.

  1. Restrict by default: assign a tenant-wide dial-out policy with Grant-CsDialoutPolicy -Global, for example tag:DialoutCPCDomesticPSTNInternational where meeting dial-out should be domestic only, or tag:DialoutCPCandPSTNDomestic where most users never call abroad.
  2. Grant international by group: assign international calling per user or group with a business owner, and review the list quarterly.
  3. Block premium and high-cost ranges: for Direct Routing, apply number pattern blocks on the SBC or in voice routing policies; for calling plans, use the provider's international and premium restrictions.
  4. Control forwarding: unrestricted call forwarding and simultaneous ring to external numbers lets an attacker with mailbox or Teams access redirect calls, including MFA voice calls. Limit forwarding to domestic numbers.

Direct Routing, SIP trunks and session border controllers

Direct Routing connects a tenant to a carrier through a customer-managed session border controller (SBC), which is an internet-facing appliance and an obvious target. Microsoft's Direct Routing planning documentation sets several hard requirements that double as security controls.

ElementMicrosoft requirementSecurity reason
SBC certificateIssued by a CA in the Microsoft Trusted Root Program, SBC FQDN in CN or SAN, Server Authentication EKU; CSR generated on the SBCPrevents self-signed or impersonated trunks; the private key never leaves the SBC
SBC FQDNMust belong to a verified tenant domain; *.onmicrosoft.com not allowedTies the trunk to a domain the organisation controls
SignallingSIP/TLS to port 5061 on sip.pstnhub.microsoft.com, sip2 and sip3No cleartext SIP on the Microsoft leg
Signalling source52.112.0.0/14 and 52.120.0.0/14 (IPv6 2603:1063:400::/40)Restrict SBC inbound SIP to these ranges only
MediaUDP/SRTP on 3478 to 3481 and 49152 to 53247Encrypted media; narrow firewall rules
  • Carrier side: the SBC to carrier leg is often plain SIP on UDP 5060; ask for TLS and SRTP, or keep the circuit private.
  • Management plane: SBC web and SSH interfaces must never face the internet; place them on a management network with MFA through a jump host. See the Edge Device Security Guide.
  • On-premises call control: CISA's KEV catalog includes CVE-2026-20045 (code injection in Cisco Unified Communications Manager, Unity Connection and Webex Calling Dedicated Instance), CVE-2026-20230 (SSRF in Unified CM), and Mitel MiCollab CVE-2024-41713 chained with CVE-2024-55550, the latter flagged as known to be used in ransomware campaigns. Treat UC servers with the same patch urgency as VPN gateways.

Where identity fits: room devices and resource accounts

Every Teams Room, Zoom Room and smart desk phone is a shared device that signs in unattended. Microsoft's Teams Rooms security guidance makes the identity trade-off explicit: create one resource account per device, preferably cloud-only, and do not apply interactive MFA because it would stop automatic sign-in after a reboot. Use Conditional Access and Intune compliance instead.

  • Resource accounts are non-human identities: restrict them with Conditional Access to compliant devices and trusted locations, exclude them from licences and mailboxes they do not need, and alert on any interactive sign-in from elsewhere. See the RPA and Bot Identity Security Guide for the same pattern applied to other unattended accounts.
  • Default local admin: Teams Rooms on Windows ships with an "Admin" account and a default password. Change it immediately, or create an alternate admin and then remove it, and manage it with LAPS.
  • Kiosk account: the app runs as a local "Skype" account with no password under Assigned Access and Shell Launcher. Do not change it and never give it local admin rights.
  • Platform hardening is on by default: Secure Boot, TPM 2.0, Kernel DMA Protection, HVCI and Credential Guard are enabled; BitLocker is not, and if you enable it, do so without pre-boot PIN so the room can restart unattended.
  • Not a workstation: Microsoft advises against extra software, local CIS benchmark scans and configuration-changing Defender policies; use external penetration tests and let updates install in the 02:00 to 03:00 window.
  • Network: rooms need no internal LAN access, so put them on an isolated segment with direct internet access and wired networking. Collaborative device controls (camera and microphone indicators, no remote activation) are what NIST SP 800-53 SC-15 Collaborative Computing Devices and Applications asks for.

Recordings, transcripts and retention

A recording holds everything said, often including personal data. Decide who can record, where recordings land and how long they live.

  • Storage location: Teams stores meeting recordings in OneDrive or SharePoint, so they inherit the sharing, retention and DLP settings of those locations; Zoom cloud recordings live in Zoom's storage with their own sharing links and passcodes. Inventory both.
  • Expiry: set a default expiry for recordings that are not records, and apply retention labels to those that are.
  • Transcripts and AI summaries: these are searchable text and usually more exposed than the video. Include them in eDiscovery and DLP scope. See the Microsoft 365 Copilot Security Deep Dive.

Implementation roadmap

  1. Inventory (weeks 1 to 2): list every UC platform in use (including shadow Zoom, Webex and Google Meet accounts), PSTN numbers and trunks, SBCs, on-premises call control, room devices and their resource accounts.
  2. Close external exposure (weeks 2 to 4): remove internet-facing management interfaces on SBCs and call servers, check every UC appliance against the KEV catalog and patch, and restrict SBC SIP to provider ranges.
  3. Baseline meeting policy (weeks 3 to 6): create a standard and a sensitive meeting policy. Pilot with executive assistants and legal, then assign by group. Roll back by reassigning the previous policy.
  4. Telephony restrictions (weeks 4 to 6): assign a domestic-only dial-out policy at tenant level, grant international by exception, and set forwarding limits. Compare call records before and after to catch blocked legitimate traffic.
  5. Room devices (weeks 6 to 10): move resource accounts to cloud-only with Conditional Access, rotate default admin passwords with LAPS, move rooms to an isolated VLAN, and enrol them in device management.
  6. E2EE and recording (weeks 8 to 12): define which groups may or must use E2EE, publish the verification procedure, and set recording expiry and retention.
  7. Monitoring (ongoing): feed audit logs, call records and SBC logs into the SIEM with the detections below.

For a small organisation on a single cloud platform with calling plans, steps 2 and 5 shrink to a few settings: there is no SBC, and the main work is dial-out restriction, meeting policy and resource account hygiene. Large organisations with Direct Routing, contact centres and on-premises PBXs need the full sequence and a named UC security owner.

Detection and measurement

SignalSourceWhat it suggests
Spike in international or premium-rate minutes, especially out of hoursPSTN usage report, carrier CDRs, SBC call logsToll fraud from a compromised account or trunk
New call forwarding to an external numberPlatform audit log, user call settings changesAccount takeover redirecting calls or MFA voice codes
Meeting policy, encryption policy or dial-out policy changesMicrosoft Purview Audit or Zoom admin operation logsAdmin compromise or unauthorised weakening of controls
Resource account sign-in from a non-compliant device or new locationEntra ID sign-in logsRoom account credentials used outside the room
SIP traffic to the SBC from outside provider ranges; repeated SIP registration or INVITE failuresSBC and firewall logsScanning, toll fraud attempts or exploitation
Anonymous joiners in internal-only meetingsMeeting attendance reportsLeaked links or over-permissive lobby settings

Metrics that show the programme is working:

  • Percentage of users on a restricted dial-out policy, and the number with international calling by exception.
  • International PSTN spend per month against the agreed baseline.
  • Percentage of room resource accounts covered by a Conditional Access policy and with LAPS-managed local admin.
  • Days to patch UC appliances after a KEV listing.
  • Percentage of meetings in sensitive groups using the sensitive meeting policy or E2EE.

Common failure patterns

  • Treating a block list as meeting control: blocking a domain for chat while anonymous meeting join stays on, so the blocked party simply joins through the browser.
  • Letting dial-in callers bypass the lobby: turning on PSTN lobby bypass for convenience, so anyone with the conference number and ID is admitted without being seen.
  • Unrestricted international calling for everyone: leaving the default dial-out policy in place, so one compromised account can run up premium-rate charges over a weekend.
  • Room accounts with passwords that never change and no Conditional Access: a shared resource account that works from anywhere is a standing credential, as are default local admin passwords on room PCs.
  • SBCs and call servers exposed to the internet and patched like phones, not servers: several UC products are in the KEV catalog, and MiCollab exploitation is linked to ransomware.

Framework mapping

Control areaNIST SP 800-53 Rev. 5NIST CSF 2.0ISO/IEC 27001:2022 Annex AATT&CK v20
Media and signalling encryptionSC-8, SC-23PR.DS-02A.8.24 Use of cryptographyT1040, T1557
Meeting devices and room systemsSC-15, IA-9PR.PS-01A.8.1 User endpoint devicesT1123, T1125
Meeting admission and accessAC-17PR.AA-05A.5.14 Information transferT1566.003
SBC and call server exposureSI-2, SC-7PR.PS-02A.8.20 Networks security, A.8.8 Management of technical vulnerabilitiesT1190
Monitoring calls and admin changesAU-6, SI-4DE.CM-01A.8.16 Monitoring activitiesT1078

In CIS Controls v8.1, see Controls 3, 4 and 12.

Practitioner checklist

  • Inventory every UC platform, PSTN trunk, SBC, on-premises call server and room device, with an owner for each.
  • Remove internet exposure of SBC and call server management interfaces, and check all UC products against the CISA KEV catalog.
  • Restrict SBC SIP signalling to the provider's published ranges over TLS 5061, with a publicly trusted certificate generated on the SBC.
  • Assign a tenant-wide restricted dial-out policy and grant international calling by exception with quarterly review.
  • Keep dial-in lobby bypass off, limit anonymous join, and create a sensitive meeting policy with InvitedUsers or OrganizerOnly lobby bypass.
  • Define which groups use E2EE, how security codes are verified, and which users must stay on standard encryption for compliance recording.
  • Put room resource accounts under Conditional Access and Intune compliance, manage room local admin with LAPS, and isolate rooms on their own network segment.
  • Set recording expiry and retention, and bring transcripts and AI summaries into DLP and eDiscovery scope.
  • Alert on international call spikes, new external forwarding, policy changes and resource account sign-ins from unexpected devices.

Standards and references

Related NHI Mgmt Group resources: Collaboration Tool Security Guide · Microsoft 365 Security Guide · VoIP and SIP Security Guide · Deepfake and AI Impersonation Guide · Edge Device Security Guide

PDF for subscribers

Take this guide with you

Every section, table and checklist in one PDF, with links to the sources and related guides. Subscribe to our weekly NHI & AI Identity Journal and we’ll email you a download link.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 26 October 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org

PDF Downloads for Newsletter Subscribers

Get the guide

Enter your details and we’ll email you a download link.

The full guide is free to read online. The PDF is a thank you for subscribing.

Fill in all fields marked * and tick the PDF box to continue.