Slack Enterprise Security Guide: Apps and Audit Logs

Slack holds a company's conversations, files and integrations in one place, and most Slack incidents start with a setting nobody changed from its default. App approval is off by default, owners can bypass SSO, and apps installed at organisation level can read data across every workspace. This guide is for Slack Org Owners, IT administrators and security teams running Slack on Business+ or Enterprise plans. It covers identity and SSO, admin roles, app approval and integration governance, the Audit Logs API and the events worth alerting on, a hardening baseline and common misconfigurations. Token types are covered in depth in the Slack Tokens Security Guide, and cross-platform chat risks in the Collaboration Tool Security Guide.

Key takeaways

Turn on app approval. Slack app approval is off by default, so any member can install an app and grant it scopes. Require approved apps and name app managers before anything else.
Enforce SSO, then protect the bypass. SAML SSO can be required for all members, but Workspace and Org Owners can still sign in with email and password; those accounts need strong unique passwords and two-factor authentication.
Org-level apps are the biggest grant. Apps using the admin, Discovery or SCIM APIs can access organisation data once installed at organisation level, without being added to any workspace.
The Audit Logs API is Enterprise-only and must be collected. It needs an app with the auditlogs:read user scope installed by the Org Owner on the organisation, and it is read-only and holds no message content.
Sessions are credentials. Stolen session cookies bypass SSO; shorten desktop and mobile session durations and use admin session resets as a standard response step.

How identity and access work in Slack Enterprise

On Enterprise plans, an organisation contains many workspaces. Members belong to the organisation and are added to workspaces; guests can be limited to specific channels. Authentication options:

SAML SSO: available on Business+ and Enterprise. Org Owners configure it under Organization settings > Security > SSO Settings, with up to 11 additional SSO configurations for other identity providers. Enforcement can be Required for all members, Required, excluding guests or Optional. Slack recommends the partially required option for workspaces with guests.
Owner bypass: Slack lets Workspace Owners and Org Owners bypass SSO and sign in with an email address and password, as a fallback if the IdP fails. This is the account an attacker wants.
Provisioning: Slack supports SCIM so the IdP can create, update and deactivate accounts. Without it, leavers keep access until someone deactivates them by hand.
Sessions: after sign-in, desktop, browser and mobile clients hold session tokens. Owners and Admins set Desktop session duration and Mobile session duration; on Enterprise the admin.users.session.setSettings API can set different durations for subsets of members.

Setting	Default or common state	Recommended
SSO enforcement	Optional when first configured	Required for all members, or Required excluding guests where guests use email sign-in
Owner email and password sign-in	Allowed for owners	Unique long password in a vault, two-factor authentication, alert on owner logins
Session duration	Long-lived sessions	Days, not months, for desktop; stricter for mobile on unmanaged devices
Sign in with Slack to third-party sites	Off by default	Leave off unless there is a reviewed need
Account lifecycle	Manual	SCIM from the IdP

Admin roles and privileged access

Primary Org Owner and Org Owners: control organisation-wide settings, SSO, policies, exports and integrations. Keep to two or three named people.
Org Admins: manage members, workspaces and many settings. Grant on a need basis.
Workspace Owners and Admins: control settings within a workspace unless the organisation locks them. On Enterprise, set policies at org level so workspace admins cannot weaken them.
Integrations Admin system role: can manage apps at organisation level alongside Org Owners and Org Admins. Treat it as privileged because it decides which apps get organisation-wide scopes.
App managers: Workspace Owners can appoint extra reviewers under App Management Settings > Require approved apps > Select App Managers. Choose people who understand OAuth scopes.
Exports: corporate and scheduled exports give a copy of message data. Restrict who can enable and download them, and alert on every export event.

Review role holders quarterly and after reorganisations. Owner and admin accounts should use phishing-resistant MFA at the IdP and, for the bypass path, Slack two-factor authentication.

Integrations, API tokens and service accounts

Apps are where Slack data leaves Slack. Each app gets bot and user tokens with scopes, and some get webhooks. The Slack Tokens Security Guide explains token types; this section is about governance.

App approval at workspace level

Require approved apps: turn on Only allow pre-approved apps under App Management Settings. Approval is off by default.
Request flow: enable Allow members to request apps for approval and require a comment with each request so reviewers know the business need.
Approve and Restrict: approving an app also approves its scopes. Restrict blocks installs and requests, but restricting an app that is already installed does not remove it: uninstall it separately.
Automation rules: Slack can approve, restrict, dismiss or flag requests automatically; use rules to restrict apps requesting high-risk scopes and route the rest to a human.

App governance at organisation level

Under Organization settings > Integrations, each app has an App resolution: Approved (installable to any workspace), Restricted (not installable) or Set by workspace. Approved apps can be pushed with Add to more workspaces or Default for future workspaces. You can limit Who has permission to initiate interaction with this app and Where can this app be used (all channels, specific channels, or all except). When a developer changes an approved app's scopes, members must request it again, and admins choose Approve for Organization or Restrict for Organization in the Requests tab.

App type or scope area	Risk	Approval stance
Admin, Discovery or SCIM API apps	Organisation-wide data or account control once installed at org level	Org Owner sign-off, security review, named owner, yearly re-approval
Apps reading message history and files across channels	Bulk data access; a vendor breach exposes your messages	Approve per channel where possible, check vendor security and data residency
Apps that post or act as users (user token scopes)	Impersonation and internal phishing	Limit to specific people and channels
Incoming webhooks and simple bots	Posting only, but webhook URLs are secrets	Approve, store webhook URLs in a secrets manager
Internally built apps	Tokens held by your own developers and pipelines	Approve through the same process, rotate tokens, monitor scope expansion

Vendor-held tokens are the recurring failure. In the Slack GitHub breach, stolen employee tokens held by a compromised third-party vendor were used to download private code repositories from Slack's externally hosted GitHub account. See the SaaS and OAuth App Governance Guide for a cross-platform approval process.

Logging and detection

The Audit Logs API is available only on Enterprise plans. Create an app with the auditlogs:read user token scope, have the Owner of the Enterprise organisation install it on the organisation (not a single workspace), and poll https://api.slack.com/audit/v1/logs. The /schemas and /actions endpoints list object types and actions. The API is Tier 3 rate limited (about 50 calls per minute, counted per organisation), read-only, and contains no message content. Each event carries id, date_create, action, actor, entity and context, with optional details and app; an actor of USLACKSECURITY means Slack's security systems reset credentials.

Behaviour	Audit actions	Response
Suspicious sign-in	`anomaly`, `user_login_failed`, `user_login` for owners from new locations, `user_logout_compromised`	Reset sessions, confirm with the user, check the IdP
Session resets	`user_session_reset_by_admin`, `bulk_session_reset_by_admin`, `user_sessions_reset_by_anomaly_event_response`	Confirm resets match open incidents
Authentication weakened	`pref.sso_setting_changed`, `pref.two_factor_auth_changed`, `pref.session_duration_changed`	High-severity alert to identity team
App governance changes	`app_installed`, `app_approved`, `app_scopes_expanded`, `app_restricted`, `app_uninstalled`, `pref.app_dir_only`, `pref.app_whitelist_enabled`	Check the app against the approved list and owner
Data leaving Slack	`file_downloaded`, `file_public_link_created`, `manual_export_started`, `scheduled_export_started`, `corporate_exports_enabled`	Alert on exports always; baseline downloads per user
Data controls weakened	`pref.disallow_public_file_urls`, `pref.block_file_download_for_unapproved_ip`, `team_authorized_ip_range_set`	Confirm a change ticket exists
External sharing	`pref.who_can_manage_ext_shared_channels`, `approved_orgs_added`	Review new Slack Connect partners

Slack states that audit logs do not perform intrusion detection or judge whether an action was appropriate, so the analysis is yours. Combine audit events with IdP sign-in logs to spot session token reuse from a different network than the SSO login, a sign of cookie theft covered in the Infostealer Logs and Session Token Abuse Guide.

Responding to a compromised account or app

Reset the member's sessions (an admin session reset appears as user_session_reset_by_admin) and revoke the account at the IdP so SSO cannot re-issue a session.
Pull the member's audit events for the incident window: sign-ins, file downloads, public links, app installs and channel joins.
For an app, restrict it and then uninstall it so its tokens stop working; check app_scopes_expanded history to see what it could reach.
Rotate any secrets shared in messages the account could read, and search channels for further exposure.
Record what was found in the incident log and update app approval rules to block the pattern.

Metrics

Share of installed apps that went through approval, with a named owner (target 100%).
Number of apps with admin, Discovery or SCIM scopes, reviewed each quarter.
Share of members covered by required SSO and SCIM.
Count of owner and admin accounts, and of owner email sign-ins per month.
Audit log ingestion lag in the SIEM (target under 15 minutes) and days of history held.

Hardening baseline

Inventory: export installed apps (the org Integrations page offers Export CSV), list owners and admins, and record current SSO, session and export settings.
Identity: require SAML SSO, connect SCIM, protect owner bypass accounts with two-factor authentication and vaulted passwords.
Sessions: set desktop and mobile session durations to match your device policy; use shorter durations for unmanaged devices.
Apps: turn on app approval, appoint app managers, set organisation-level resolutions, restrict unused apps and uninstall them, and limit where sensitive apps can be used.
Data: disable public file links if not needed, block file downloads from unapproved IP ranges where your plan supports it, and restrict exports.
External sharing: decide who can manage Slack Connect channels and which partner organisations are approved.
Logging: install the audit log app, stream events to the SIEM and build the alerts above.
Test and roll back: pilot SSO enforcement and shorter sessions with IT first, communicate the binding email (the link expires after 72 hours), keep one tested owner bypass account, and turn on app approval with a pre-approved list of existing business apps so work does not stop.

Decision guidance

Business+ versus Enterprise: Business+ gives SAML SSO and workspace app approval, but not organisation-level app policies or the Audit Logs API. If you need audit evidence or many workspaces, plan for Enterprise.
Strict versus open app approval: strict approval slows teams; mitigate with automation rules and a published list of pre-approved apps rather than leaving approval off.
Guests: use Required excluding guests only when guests cannot use your IdP, and keep guests to specific channels.

Framework mapping

Framework	Reference	Slack control
NIST CSF 2.0	PR.AA-03, GV.SC-07, DE.CM-03, DE.CM-06	SSO authentication, third-party app risk, user and provider activity monitoring
NIST SP 800-53 Rev. 5	AC-2, IA-2, AC-20, CA-3, SA-9, AU-6	Account management, authentication, external systems and information exchange, external services, audit review
MITRE ATT&CK v20	T1078.004, T1539, T1528, T1550.001, T1213.005, T1534, T1199	Cloud accounts, stolen session cookies and app tokens, messaging data collection, internal phishing, trusted third parties

Common misconfigurations

App approval never switched on: years of member-installed apps with broad scopes and no owners.
Restricting instead of removing: restricting an installed app blocks new installs but leaves the existing installation and its tokens working.
SSO optional: some members keep email and password sign-in, so phishing those passwords bypasses the IdP's MFA and conditional access.
Too many owners: every owner can bypass SSO. Each extra owner is another password-only path into the organisation.
Audit logs not collected: the API exists but no app was installed, so nothing is retained outside Slack when an incident starts.
Long sessions on personal devices: a stolen session cookie from an unmanaged laptop stays valid for weeks.

Practitioner checklist

Require SAML SSO for all members and connect SCIM provisioning.
Limit Org Owners and Admins to named people and protect owner bypass sign-in with two-factor authentication.
Set desktop and mobile session durations to match device trust.
Turn on app approval, name app managers and publish a pre-approved list.
Review every app with admin, Discovery or SCIM scopes and uninstall, not just restrict, unused apps.
Restrict exports and alert on every export and public file link event.
Install an auditlogs:read app on the organisation and stream events to the SIEM.
Alert on SSO, two-factor and session duration preference changes.
Include admin session reset in the incident playbook for compromised accounts.
Rotate tokens and webhook URLs held by vendors after any vendor incident.

Slack Enterprise Security Guide: Workspace Settings, Apps and Audit Logs