Join our Newsletter — 33% off our NHI Course
Home› Guides› Zoom Workplace Security: Hardening Settings, SSO, Screen Sharing,…
Guide Email & Communications Security

Zoom Workplace Security: Hardening Settings, SSO, Screen Sharing, Apps and Logs

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 8 November 2026 14 min read
On this page

Most Zoom Workplace security is decided by account and group settings that individual hosts can override unless an admin locks them, so the difference between a well-run tenant and an exposed one is usually how settings, locks, sign-in and apps are managed centrally. This guide is the admin walkthrough: how account, group and user settings resolve, SSO and SCIM, two-factor authentication, admin roles, screen sharing and remote control restrictions, meeting access controls, Marketplace app approval and the logs that show what changed. Product facts come from Zoom's own technical library, developer documentation and support material, plus the CIS Zoom Benchmark audit items, checked on 8 November 2026; hardening stances, alerts and metrics are NHI Mgmt Group guidance. These are customer-side settings under the shared responsibility model. It is written for Zoom account owners and admins, identity teams and security engineers. For the wider communications picture, see the Unified Communications Security Guide.

This is an independent guide from NHI Mgmt Group, based on Zoom's public documentation as of November 2026. It is not sponsored or reviewed by Zoom. Product features change, so confirm settings against Zoom's current documentation.

Key takeaways

  • Lock what matters. An account-level lock overrides every group and user; an unlocked setting can be changed by the host. Lock passcode, waiting room, authentication, screen sharing and remote control settings at account or group level.
  • Use a baseline group plus exceptions. Zoom's settings model resolves by group priority, so a lowest-priority baseline group for everyone and higher-priority exception groups keep settings predictable.
  • Enforce SSO, keep a way back in. Enforced SSO redirects users on associated domains to your identity provider; Zoom recommends exempting at least one admin for lockout recovery.
  • Screen sharing is a data channel. Set "Who can share?" to Host Only by default, disable remote control and in-meeting file transfer where they are not needed, and open them by exception group.
  • Apps and bots need approval. Use Marketplace pre-approval, review App on account activity and the Active App Notifier Report, and treat each app as a non-human identity with access to meeting content.

How identity and access work in Zoom Workplace

A Zoom account contains users, groups and roles. Settings exist at account, group and user level, and SSO, provisioning and sign-in methods are set at account level. Apps from the Zoom App Marketplace, including automated meeting tools, connect with their own permissions.

How settings and locks resolve

In Zoom's current groups and settings model, each group has a priority rank, with P1 highest. Zoom documents this resolution order:

SituationValue that appliesAdmin implication
Setting locked at account levelAccount value; no group or user can overrideUse for non-negotiable controls such as passcodes and authenticated join
Setting locked by a groupValue and lock from the highest-priority group that manages the setting; lower-priority locks have no effectCheck priority order before relying on a group lock
Unlocked, user changed itUser's valueHosts can loosen anything you do not lock
Unlocked, user has not changed itHighest-priority managing group's value, else the account defaultDefaults matter for users who never touch settings

Zoom recommends a baseline group containing all users at the lowest priority, with exception groups at higher priority holding only the tabs that differ. Groups configured with a full settings category automatically receive new settings added to that category in monthly releases; groups configured with individual settings do not, so review new settings after each release.

Single sign-on and SCIM

  1. Prerequisites: Zoom requires an approved vanity URL before SSO, and an associated (managed) email domain for SCIM and for enforcing SSO. SAML 2.0 and OIDC identity providers are supported.
  2. Provisioning mode: "Provisioning at Sign-In" creates accounts on first sign-in; "Prior to Sign-In" only lets users in if an SSO account already exists, created by SCIM or bulk upload. Zoom recommends starting with Provisioning at Sign-In and switching to Prior to Sign-In once SCIM is confirmed working, so leavers removed in the identity provider cannot sign in again.
  3. SCIM: creates, updates, deactivates and deletes accounts independently of sign-in. SCIM request logs (most recent 100) appear under Call Logs in the Zoom Marketplace. See the SCIM Provisioning Guide.
  4. Advanced mapping: SAML attributes can assign licences, groups and roles on every authentication, applied top-down. Map roles only from tightly controlled identity provider groups, because whoever controls that group membership controls Zoom admin rights. Setting the default licence type to None blocks new users unless mapping assigns a licence.
  5. Enforce SSO: under Sign-in Methods on the Security page, enforcement redirects users with associated domains to the identity provider on all platforms. Zoom recommends exempting at least one admin; exempt admins with the standard admin role can sign in at admin.zoom.us during a lockout. Keep that account on two-factor authentication and monitor it. See the Break-Glass Account Guide.
  6. Sessions: Zoom documents an enforced automatic logout configurable from 15 minutes to 180 days, a two-hour default web inactivity period ("Set period for inactivity on the web (minutes)"), and client access tokens of two hours with refresh that is unlimited by default. Set automatic logout to match your policy so desktop sessions do not outlive employment.

Zoom also notes that the Employee Unique ID feature cannot change admin and owner email addresses, which protects privileged accounts from silent email changes through the identity provider. See the Identity Provider and SSO Security Guide.

Two-factor authentication

For users who sign in with a Zoom password rather than SSO, turn on Sign in with Two-Factor Authentication under Advanced > Security and apply it to all users, to specified roles or to specified groups. Zoom supports TOTP authenticator apps and codes by SMS or phone call. Zoom also lets admins enable or disable SAML, OAuth and password sign-in methods per account: where SSO is enforced, turn off sign-in methods you do not use. Apply 2FA at least to every role with admin privileges and to the SSO-exempt admin. See the Phishing-Resistant MFA Guide.

Admin roles and privileged access

Zoom accounts have an account owner, admin and member roles, and custom roles built from privileges. Zoom's developer reference lists the privilege families that matter most for security:

Privilege (Zoom name)What it governsHardening stance
SingleSignOn:Read / EditSingle sign-on settingsEdit only for identity administrators
Role:Read / EditRole managementOwner and one or two admins; changes alerted
Group:Read / EditGroups, and so group settings and locksCollaboration admins; review priority changes
AccountSetting:Read / EditAccount-level settings and locksSmall named set; change control
MarketPlace:Read / EditApp pre-approval admin settings in the MarketplaceSecurity-reviewed app approvers only
Recording:Read / Edit, RecordingContent:ReadCloud recordings and their contentRestrict content read to compliance roles
IMChatHistory:ReadTeam Chat historyCompliance and investigation roles only
UserActivitiesReport:ReadDetailed user activity reports used for auditsSecurity operations, read only
  • Custom roles over admin: give help desk staff user management without account settings, and compliance staff recordings and chat history without role management.
  • Role assignment through SSO: if advanced mapping assigns roles, the identity provider group is now the privileged control. Protect it with your privileged access process. See the Privileged Access Management Guide.
  • Owner account: one named owner, 2FA, not used for daily work.

Screen sharing, remote control and meeting access

Screen sharing is central to Zoom security: it is how sensitive content leaves a screen, and how a disruptive participant takes over a meeting. Zoom places the screen sharing settings in the web portal account settings, under the Meeting tab and its In Meeting (Basic) and In Meeting (Advanced) sections. The table suggests a baseline value and a practical stance for the main settings.

Zoom settingSuggested baselinePractical stance
Screen sharingEnabledKeep enabled so sharing is governed by the options below
Who can share?Host OnlyHost Only in the baseline; All Participants for an exception group such as internal project teams
Who can start sharing when someone else is sharing?Host OnlyHost Only to stop share hijacking
Remote controlDisabledDisable account-wide; enable only for an IT support exception group
Remote supportDisabledSame as remote control
Annotation; only the user who is sharing can annotateAnnotation disabled; sharer-only annotation enabledAt minimum, sharer-only annotation
Hosts and participants can send files through the in-meeting chatDisabled; only allow specified file typesDisable, or allow listed file types only
Add watermark; add audio watermarkEnabledEnable for groups handling confidential content

Remote control lets another participant drive the sharer's keyboard and mouse, which is also a favourite of support scams. Lock it off in the baseline and give support staff an exception group with clear procedures. See the Screen Sharing Security guide.

Meeting access

  • Waiting room: "Enable Waiting Room when scheduling meetings or for your entire account", lock at account or group level.
  • Passcodes: "Require a meeting passcode", locked, with minimum complexity; Zoom notes admins can lock this and set minimum requirements.
  • Authenticated join: "Only authenticated meeting participants and webinar attendees can join meetings and webinars", optionally restricted to your email domains, for internal meetings. Zoom notes it is required for audio and image watermarks, and that people without Zoom accounts cannot join, so use an exception for external meetings.
  • Meeting IDs: use automatically generated meeting IDs and limit Personal Meeting ID use.
  • Dial-in: if you do not use phone audio, select Computer Audio only; otherwise block dial-in users when Waiting Room is disabled.
  • Recording: enable "Who can request host permission to record" restrictions so external participants do not get a record button.
  • In meeting: train hosts on the Security icon: Lock Meeting, Suspend Participant Activities and Remove Participant.
  • Encryption: for highly sensitive meetings, use end-to-end encryption where its feature trade-offs are acceptable. See the End-to-End Encryption and Messaging Protocols Guide.

Integrations, API tokens and service accounts

Marketplace apps, bots and API integrations are non-human identities with access to meetings, recordings, chat and user data. Zoom documents these controls:

  1. Pre-approval: on multi-user managed accounts, admins can pre-approve or restrict apps, including automated meeting tools. Require pre-approval and route requests through a security review with a named owner.
  2. App on account: at marketplace.zoom.us, Manage > App on account shows each app with an activity log of who pre-approved, installed or uninstalled it and when, and API calls made by account users.
  3. Active App Notifier Report: lists tools that accessed meeting or webinar content from any account user in the past 30 days. Review it monthly and disable unapproved tools.
  4. Outside bots: Zoom notes that blocking a tool on your account does not stop uninvited external automated tools joining your hosts' meetings; waiting rooms and authenticated join address that. See the AI Meeting Assistant Security Guide.
  5. Internal API integrations: build account-level integrations as Server-to-Server OAuth apps owned by a dedicated developer identity, with the minimum scopes, credentials stored in a secrets manager and an owner recorded. Report APIs such as operation logs depend on the app owner's role privileges as well as the API scope (see the Role Privileges Reference), so grant the role deliberately. See the Machine-to-Machine OAuth Guide and the Secrets Management Guide.

Logging and detection

Zoom offers several admin-visible sources. The Operation Logs report records admin changes in the account; check in the Role Privileges Reference which roles can view it, and grant that report permission only to the roles that need it. User activity reports include sign in and sign out activity. SSO SAML response logs can be saved for seven days for troubleshooting, SCIM call logs show the last 100 requests, and Marketplace App on account logs show app approvals, installs and API calls. Pull reports through the API on a schedule into your SIEM, since the console views are short-term.

SignalSourceWhy it mattersSuggested response
Role assigned or role privileges changedOperation LogsPrivilege escalation (ATT&CK T1098)Alert; confirm change ticket
Account setting unlocked or changed (passcode, waiting room, sharing, remote control)Operation LogsLoosened baselineRevert unless approved
SSO configuration or sign-in method changedOperation LogsBypass of identity provider controlsPage identity team
Sign-in by the SSO-exempt adminSign in/sign out activityBreak-glass use or misuse (T1078.004)Confirm with the account holder
New app pre-approved or installedMarketplace App on accountNew non-human identity with data accessCheck against approved app list
Unknown tool in Active App Notifier ReportMarketplaceUnapproved meeting content accessDisable and contact the user

See the SIEM Guide and the SaaS Audit Log Retention and Licensing Guide.

Metrics: security-relevant settings locked at account or group level (target 100 percent of the baseline list); users signing in through SSO (target 100 percent of associated domains); admins with 2FA or SSO MFA (target 100 percent); apps with a named owner and approval record; unapproved tools in the Active App Notifier Report (target zero); days since last Operation Logs export.

Hardening baseline

  1. Inventory: export users, roles and their privileges, groups with priorities, current account settings and locks, installed apps and API integrations.
  2. Design groups: create a lowest-priority baseline group for all users with full categories, and exception groups (IT support, external webinars, internal project teams) at higher priority.
  3. Lock the baseline: waiting room, passcodes, authenticated join for internal meetings, Who can share Host Only, remote control and remote support off, chat file transfer off or allow-listed. Pilot with one department for two weeks, collect issues, then apply account-wide.
  4. Identity: configure SSO with Provisioning at Sign-In, add SCIM, then switch to Prior to Sign-In; enforce SSO with one exempt admin on 2FA; set automatic logout.
  5. Roles: move staff from admin to custom roles; limit role, SSO and account setting privileges.
  6. Apps: turn on pre-approval, review App on account and the Active App Notifier Report, remove unused apps.
  7. Logging: schedule Operation Logs and sign-in report pulls into the SIEM and build the alerts above.

Record each setting before changing it; rollback is reverting the setting or lock at the same level.

Common misconfigurations

  • Settings configured but not locked: hosts quietly turn off passcodes or open sharing. Lock at account or group level.
  • Group locks overridden by priority: a higher-priority group that leaves a setting unlocked wins over a lower-priority lock. Check priority order.
  • Remote control left on for everyone: disable in the baseline, enable for an IT support group.
  • SSO enforced with no exempt admin, or with an exempt admin nobody monitors: keep exactly one, with 2FA and an alert on use.
  • Provisioning at Sign-In left on after SCIM: switch to Prior to Sign-In so only provisioned users get in.
  • Apps installed freely: require pre-approval and review the Active App Notifier Report.

Framework mapping

Control areaNIST SP 800-53 Rev 5NIST CSF 2.0CIS Controls v8.1
Settings baseline and locksCM-7PR.AA-054.1
SSO, SCIM, 2FAAC-2, IA-2PR.AA-015.3, 6.3, 6.5
Roles and privilegesAC-6PR.AA-055.4, 6.8
Remote control and screen sharingAC-17PR.AA-054.1
Logs and reviewAU-2, AU-6DE.CM-038.2

Practitioner checklist

  • Build a lowest-priority baseline group and higher-priority exception groups, and check priorities after every change.
  • Lock waiting room, passcode and authenticated-join settings at account or group level.
  • Set Who can share? and Who can start sharing when someone else is sharing? to Host Only in the baseline.
  • Disable remote control, remote support and in-meeting file transfer except for named exception groups.
  • Enforce SSO on associated domains, switch to Prior to Sign-In once SCIM works, and keep one monitored exempt admin with 2FA.
  • Turn on Sign in with Two-Factor Authentication for any password-based users and all admin roles.
  • Replace broad admin use with custom roles; restrict Role, SSO, AccountSetting and MarketPlace privileges.
  • Require Marketplace pre-approval and review the Active App Notifier Report monthly.
  • Pull Operation Logs and sign-in reports into the SIEM and alert on setting, role and SSO changes.

Standards and references

Related NHI Mgmt Group resources: Unified Communications Security Guide · Screen Sharing Security · AI Meeting Assistant Security Guide · SCIM Provisioning Guide

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 8 November 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