Cisco Webex Security: Hardening Control Hub, SSO, Meetings and Integrations

Webex Control Hub concentrates identity, meetings, messaging, calling and integrations for an organisation in one console, so who holds which admin role, how users sign in and what meeting and messaging policies allow decide how much of your conversation data is exposed. This guide covers the customer-side controls in Control Hub: administrator roles, single sign-on, SCIM directory synchronisation, meeting collaboration restrictions, external messaging, integrations and bots, and the admin and authentication audit logs. Product facts come from Cisco's Webex Help Center and developer documentation, 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 Control Hub administrators, 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 Cisco's public Webex documentation as of November 2026. It is not sponsored or reviewed by Cisco. Product features change, so confirm settings against Cisco's current documentation.

Key takeaways

• Use the narrow admin roles. Control Hub offers Read-only, Support, User and device, Device, Compliance officer and Security activity administrator roles, plus custom roles, so few people need Full administrator.
• Full admins can reach content. Full administrators hold Webex site admin and Meeting Content admin privileges by default, which allow recordings and transcripts to be retrieved through APIs; treat the role as tier zero.
• Move from basic authentication to SSO. Webex uses basic authentication until you integrate a SAML 2.0 identity provider; add SCIM provisioning so leavers lose access when the directory removes them.
• Policies follow the host. Meeting collaboration restrictions apply from the host's template, and users can bypass them by joining with personal addresses, so set the OrganizationID on managed devices.
• Integrations are allowed for everyone by default. Decide a global Allow or Block for integrations, allow specific ones by exception, and export the admin and authentication audit logs, which are kept for one year and 12 months respectively.

How identity and access work in Cisco Webex

A Webex organisation in Control Hub holds users, groups, licences, locations and services (Meetings, Messaging, Calling, Contact Center). Users authenticate with basic Webex authentication or through a SAML identity provider. Administrators are users with Control Hub roles. Integrations, bots and API clients reach data on behalf of users or as their own identities.

Single sign-on

Cisco documents that Webex uses basic authentication by default and that SSO lets users sign in with your organisation's identity provider credentials. The integration requires:

1. A SAML 2.0 identity provider with NameID format urn:oasis:names:tc:SAML:2.0:nameid-format:transient and a uid claim mapped to email or User Principal Name; Webex supports mapping up to five email addresses to the uid.
2. Metadata exchange: the identity provider metadata (entity ID, signing certificate, SSO service) goes into Control Hub, and the Webex service provider metadata goes into the identity provider.
3. Single Logout: include Single Logout in the metadata; without it, Webex prompts users to close their browsers to end sessions.
4. Multiple identity providers: add routing rules under Management > Security > Authentication > Identity provider.
5. Ongoing management: renew the signing certificate before it expires, manage SSO alerts and review the self-recovery options so an expired certificate or identity provider outage does not lock admins out.

Enforce MFA and conditional access at the identity provider once SSO is live. Where any users remain on basic authentication, enable the MFA Cisco offers for basic authentication in Control Hub. See the Identity Provider and SSO Security Guide and the Phishing-Resistant MFA Guide.

Directory synchronisation

Webex supports SCIM 2.0 provisioning from Microsoft Entra ID with no on-premises connector. Cisco documents that only users and groups assigned to the enterprise app are synced, that the SCIM bearer token is generated with a full admin account and is valid for 365 days, and that Entra ID does not sync null values, so clearing an attribute in the directory does not clear it in Webex. Treat the bearer token as a privileged non-human credential: store it in a secrets manager rather than the text file the setup steps suggest, record its expiry date and owner, and set the app's "Visible to users?" property to No. See the SCIM Provisioning Guide.

Admin roles and privileged access

• Group-based roles: roles can be assigned to groups (up to 100 groups, 20 roles per group), and removing a user from the group removes the role. Cisco notes a user can hold conflicting direct and group roles, so audit direct assignments separately.
• Custom roles: build custom roles for narrow duties rather than stretching a prebuilt role.
• Propagation: role changes can take up to 10 minutes; allow for this when removing access during an incident.
• Exports: the CSV export from Management > Users lists administrators and roles. Review it monthly. See the Privileged Access Management Guide.

Meeting and messaging security settings

Meeting collaboration restrictions

Organisation-wide meeting policies live at Services > Meeting > Settings; group and user exceptions use meeting settings templates, which support internal and external meeting policies. Cisco documents these settings:

• Host template governs: if the host's template turns a feature off, it is off for all participants; if on, each participant's own settings still apply. "Override participant settings when hosting" makes participants follow the host's policy for internal meetings.
• Close the bypass: Cisco notes users can bypass restrictions by joining with personal email addresses or as guests, and recommends setting the OrganizationID on company devices through the registry, plist or AppConfig. Deploy it through your device management.
• Client versions: restrictions apply from Webex Meetings 42.3 and Webex App 43.6; keep clients updated through managed deployment and apply vendor security updates promptly.

See the Screen Sharing Security guide.

External messaging

At Organization Settings > External Communication, choose "Allow all external messaging", "Allow all domains except the blocked domains" or "Allow selected domains only" (an empty allow list blocks all external messaging), and scope the rule to all users or selected groups. Domain lists can be imported as CSV (up to 1,000 domains). Enabling Group Spaces there stops users being invited to group spaces owned by other organisations. Cisco notes that restrictions apply to new spaces and participants, so existing external members keep access until removed, and that bots are not affected by these rules. These controls need Pro Pack for Control Hub. For most organisations, "Allow selected domains only" for regulated groups and a blocked-domain list for everyone else is a workable split. See the External Collaboration and Federation Abuse Guide.

Integrations, API tokens and service accounts

Webex integrations are OAuth applications that act for the users who authorise them; bots are their own identities that join spaces. Both are non-human identities with access to messages, meetings or recordings.

1. Decide the default: Cisco documents that access is allowed for all users to all integrations unless an admin changes it. At Management > Apps > Integrations > Manage, choose Allow or Block globally.
2. Allow by exception: with Pro Pack, open an integration by name or App ID and use Integration Access to revoke access for all users or grant Access for Future Users to all or specific users. Download the adopted user list from the integration's overview to see who is using it.
3. Force Reset with care: Force Reset deletes all exception policies and they cannot be restored automatically; export your policy before using it.
4. Bots: because external communication rules do not restrict bots, keep an inventory of bots in your spaces, require an owner for each and remove bots nobody claims.
5. Admin API clients: audit and compliance integrations need high privilege (the admin audit events API requires a full administrator with the audit:events_read scope; content retrieval needs Compliance officer or Meeting Content admin). Run them under dedicated accounts, store their tokens in a secrets manager and review their use. See the Service Account Security Guide and the Consent Phishing and Illicit OAuth Grants Guide.

Logging and detection

Two logs matter most. The admin activity log, at Security > Admin activities, records site configuration changes and recording management activities; full and read-only administrators can view it, events are kept for one year, and Export to CSV downloads up to 20,000 events per report, with admin audit event APIs for automation. The authentication activities log, at Management > Security > Audit > Authentication activities, shows status, time, email, sign in or sign out, service, IP address and method (interactive or non-interactive), kept for 12 months; API retrieval needs Pro Pack and the "Allow user authentication data" toggle under Organization Settings.

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

Metrics: number of Full administrators (target two to four); users signing in through SSO (target 100 percent); users provisioned by SCIM (target 100 percent); integrations allowed by explicit exception versus default; days until the SCIM bearer token and SSO signing certificate expire (alert at 30); days since last admin and authentication log export.

Hardening baseline

1. Inventory: export administrators and roles, group role assignments, meeting settings and templates, external communication policy, integrations with adopted users, bots and API clients.
2. Roles: reduce Full administrators, move others to narrow or custom roles, restrict Compliance officer and Meeting Content admin to named people and integrations.
3. SSO: integrate the SAML 2.0 identity provider, test with a pilot group in an incognito session, then enable for the organisation; confirm self-recovery and certificate renewal.
4. SCIM: connect SCIM, assign users by group, store the token in a vault and diarise its expiry.
5. Meetings: set the organisation default (remote control off, file transfer off for external meetings, cloud recording only) and create templates for exceptions; deploy the OrganizationID to managed devices. Pilot with one department before applying to all.
6. Messaging: choose the external communication policy and enable Group Spaces protection.
7. Integrations: set global Block, allow approved integrations by exception, review bots.
8. Logging: schedule admin and authentication log exports and build the alerts above.

Record each setting before changing it so a template or policy can be reverted if users lose a needed feature.

Common misconfigurations

• Many Full administrators: each one can retrieve recordings and transcripts. Use narrow roles.
• Basic authentication left in place: integrate SSO and enforce MFA at the identity provider.
• SCIM token kept in a text file with no expiry reminder: vault it and track the 365-day expiry.
• Meeting restrictions without the OrganizationID: users bypass policy by joining with personal addresses. Deploy the OrganizationID.
• Integrations on the default allow-all: set global Block and allow by exception.
• Logs left in the console: admin events age out after a year and exports are capped per report. Export on a schedule.

Framework mapping

Practitioner checklist

• Keep two to four Full administrators and move everyone else to narrow or custom roles.
• Restrict Compliance officer, Meeting Content admin and Advanced Troubleshooting Access to named, reviewed people and integrations.
• Integrate a SAML 2.0 identity provider, include Single Logout, and enforce MFA there.
• Provision with SCIM, vault the bearer token and track its 365-day expiry.
• Set organisation meeting defaults with remote control off and exceptions by template; deploy the OrganizationID to managed devices.
• Choose an external communication domain policy and enable Group Spaces protection.
• Set integrations to global Block, allow approved integrations by exception and inventory bots.
• Export admin activities and authentication activities to your SIEM and alert on role, SSO and integration policy changes.
• Review administrator exports and integration adopted-user lists monthly.

Standards and references

• Cisco Webex: Assign Organization Account Roles in Control Hub
• Cisco Webex: Single Sign-On Integration in Control Hub
• Cisco Webex: Synchronize Microsoft Entra ID Users into Control Hub with SCIM
• Cisco Webex: Collaboration Restrictions for Webex Meetings in Control Hub
• Cisco Webex: Control Messaging with External Users in Your Webex App Spaces
• Cisco Webex: Configure User Access to Integrations in Control Hub
• Cisco Webex: Log and Analyze User Sign-ins and Sign-outs
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Unified Communications Security Guide · Screen Sharing Security · External Collaboration and Federation Abuse Guide · SCIM Provisioning Guide