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:
| Situation | Value that applies | Admin implication |
|---|---|---|
| Setting locked at account level | Account value; no group or user can override | Use for non-negotiable controls such as passcodes and authenticated join |
| Setting locked by a group | Value and lock from the highest-priority group that manages the setting; lower-priority locks have no effect | Check priority order before relying on a group lock |
| Unlocked, user changed it | User's value | Hosts can loosen anything you do not lock |
| Unlocked, user has not changed it | Highest-priority managing group's value, else the account default | Defaults 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
- 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.
- 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.
- 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.
- 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.
- 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.usduring a lockout. Keep that account on two-factor authentication and monitor it. See the Break-Glass Account Guide. - 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 governs | Hardening stance |
|---|---|---|
| SingleSignOn:Read / Edit | Single sign-on settings | Edit only for identity administrators |
| Role:Read / Edit | Role management | Owner and one or two admins; changes alerted |
| Group:Read / Edit | Groups, and so group settings and locks | Collaboration admins; review priority changes |
| AccountSetting:Read / Edit | Account-level settings and locks | Small named set; change control |
| MarketPlace:Read / Edit | App pre-approval admin settings in the Marketplace | Security-reviewed app approvers only |
| Recording:Read / Edit, RecordingContent:Read | Cloud recordings and their content | Restrict content read to compliance roles |
| IMChatHistory:Read | Team Chat history | Compliance and investigation roles only |
| UserActivitiesReport:Read | Detailed user activity reports used for audits | Security 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 setting | Suggested baseline | Practical stance |
|---|---|---|
| Screen sharing | Enabled | Keep enabled so sharing is governed by the options below |
| Who can share? | Host Only | Host 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 Only | Host Only to stop share hijacking |
| Remote control | Disabled | Disable account-wide; enable only for an IT support exception group |
| Remote support | Disabled | Same as remote control |
| Annotation; only the user who is sharing can annotate | Annotation disabled; sharer-only annotation enabled | At minimum, sharer-only annotation |
| Hosts and participants can send files through the in-meeting chat | Disabled; only allow specified file types | Disable, or allow listed file types only |
| Add watermark; add audio watermark | Enabled | Enable 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:
- 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.
- 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. - 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.
- 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.
- 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.
| Signal | Source | Why it matters | Suggested response |
|---|---|---|---|
| Role assigned or role privileges changed | Operation Logs | Privilege escalation (ATT&CK T1098) | Alert; confirm change ticket |
| Account setting unlocked or changed (passcode, waiting room, sharing, remote control) | Operation Logs | Loosened baseline | Revert unless approved |
| SSO configuration or sign-in method changed | Operation Logs | Bypass of identity provider controls | Page identity team |
| Sign-in by the SSO-exempt admin | Sign in/sign out activity | Break-glass use or misuse (T1078.004) | Confirm with the account holder |
| New app pre-approved or installed | Marketplace App on account | New non-human identity with data access | Check against approved app list |
| Unknown tool in Active App Notifier Report | Marketplace | Unapproved meeting content access | Disable 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
- Inventory: export users, roles and their privileges, groups with priorities, current account settings and locks, installed apps and API integrations.
- 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.
- 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.
- 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.
- Roles: move staff from admin to custom roles; limit role, SSO and account setting privileges.
- Apps: turn on pre-approval, review App on account and the Active App Notifier Report, remove unused apps.
- 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 area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| Settings baseline and locks | CM-7 | PR.AA-05 | 4.1 |
| SSO, SCIM, 2FA | AC-2, IA-2 | PR.AA-01 | 5.3, 6.3, 6.5 |
| Roles and privileges | AC-6 | PR.AA-05 | 5.4, 6.8 |
| Remote control and screen sharing | AC-17 | PR.AA-05 | 4.1 |
| Logs and review | AU-2, AU-6 | DE.CM-03 | 8.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
- Zoom: SSO Field Guide
- Zoom: Settings Resolution, Groups and Settings Management
- Zoom: Prevent Uninvited Automated Meeting Tools and Participants with Account Settings
- Zoom: Administrative Settings for Automated Meeting Tools
- Zoom: Role Privileges Reference
- Zoom: Secure Your Zoom Account with Two-Factor Authentication
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Unified Communications Security Guide · Screen Sharing Security · AI Meeting Assistant Security Guide · SCIM Provisioning Guide