A monday.com account often becomes the system of record for projects, customer pipelines and HR workflows, and every personal API token can do whatever its owner can do in the interface. Work management platforms grow quickly from one team to the whole business, so permissions, guests and integrations sprawl unless someone owns them. This guide explains how to secure monday.com from the customer side: SAML SSO and 2FA, account, workspace, board and column permissions, SCIM provisioning, API tokens and marketplace app scopes, IP restrictions and session duration, the audit log and the Panic Button. It is written for monday.com account admins, platform owners and SaaS security teams. For the general SaaS control model, see the SaaS Security Guide; this page stays specific to monday.com.
This is an independent guide from NHI Mgmt Group, based on monday.com's public documentation as of November 2026. It is not sponsored or reviewed by monday.com. Product features change, so confirm settings against monday.com's current documentation.
Key takeaways
- Start from monday.com's own checklist. monday.com publishes a secure configuration checklist covering authorised domain, minimal admins, SSO, 2FA, IP restrictions, SCIM, the Panic Button, session duration, permissions and logging.
- Require SAML for everyone but guests. On Enterprise, the option "All users except guests must use SAML authentication" moves sign-in for staff to your identity provider; start with SAML optional while testing.
- Control who can create API tokens. Personal API tokens carry all permission scopes and match the user's own access, and account permissions on Enterprise decide which user types can generate them.
- Layer permissions from account to column. Account, workspace, board and column permissions stack, and a lower level cannot grant more than the level above allows.
- Feed the audit log to your SIEM. The Enterprise audit log records logins, failed logins, downloads and board exports, and the Audit Log API lets you pull it into monitoring tools.
How identity and access work in monday.com
monday.com users are one of four user types: admin, member, viewer or guest. Sign-in settings live under Administration > Security, with SSO under the Login tab. monday.com's checklist also recommends restricting sign-up to your authorised domain and blocking new accounts from your email domain, so staff cannot create unmanaged accounts outside the company one.
| Control | Plan (monday.com docs) | Options | Recommended use |
|---|---|---|---|
| SAML SSO | Enterprise | Okta, Azure AD (Microsoft Entra ID), OneLogin or Custom SAML 2.0; optional, or "All users except guests must use SAML authentication" | Test as optional, then require for all users except guests |
| Google SSO | Pro and Enterprise | Sign in with Google accounts | Use on Pro where SAML is not available, with your Google Workspace MFA policy |
| Two-factor authentication | Confirm plan availability in monday.com docs | SMS or authenticator app (per the checklist); confirm who can enforce it in the current documentation | Turn on for accounts not covered by SSO, preferring an authenticator app |
| SCIM provisioning | Check your plan in monday.com's docs | Creates, updates and deactivates users; creates teams from groups; sets user types through custom roles | Use for joiners, movers and leavers; see the SCIM Provisioning Guide |
| IP address restriction | Enterprise | Single IPs or CIDR ranges with names; applies to web and mobile sign-in | Office and VPN egress, plus IPs for connected integrations |
| Session duration | See monday.com's docs | Automatic logout interval | Match your internal session policy; our view is a working day or less for most staff |
Guests still sign in with email and password under the SAML setting, so govern guests separately: use shareable boards for guest work, and review guest lists regularly. For SCIM with Microsoft Entra ID, monday.com recommends setting scope to "Sync only assigned users and groups" before turning on provisioning; deprovisioned users are deactivated, not deleted, and stop counting towards your seats. See the Identity Provider and SSO Security Guide and the SaaS deprovisioning guide.
IP restriction safeguards: your own IP must be on the list before activation, and connected third-party apps need their IPs added to keep working. Shared views and monday Forms stay reachable through their links regardless of IP, so review what is shared that way.
Admin roles and privileged access
Account admins control Administration settings, apps, security and billing. monday.com's checklist advises keeping the number of admins to the minimum required, and on Enterprise admins can delegate privileges for specific areas without granting full admin, using custom account roles.
Account permissions (Enterprise)
Under Administration > Permissions, admins set what each user type can do. The permissions with the most security effect are below.
| Account permission | Why it matters | Recommended baseline |
|---|---|---|
| Generating API tokens | Personal tokens carry the user's full access through the API | Admins and named integration owners only |
| Creating automations and integrations | Integrations move data to other systems and act as the creator | Members with a business need; viewers and guests off |
| Exporting to Excel | Bulk export of board data | Limit to roles that need reporting |
| Inviting guests | Brings external people into the account | Admins or a delegated group |
| Creating workspaces and managing teams | Shapes who can see what | Admins and workspace owners |
Workspace, board and column permissions
- Workspaces (Enterprise): use Closed workspaces for HR, finance and legal, so main boards are visible only to members. A workspace cannot grant more than account policy allows.
- Board types: Main boards are visible to all team members; Private boards (Pro and Enterprise) only to invited people; Shareable boards are for guest collaboration.
- Board roles (Enterprise): Owner, Editor, Contributor, Assigned contributor and Viewer, each a ceiling that admins can tailor by category. Board owners bypass board settings, so keep ownership with accountable people.
- Board permission sets (other plans): Edit everything, Only edit content, Only edit assigned items (Pro and above), and View and comment.
- Columns (Enterprise): Restrict column view for salary, personal or contract fields, and Restrict column editing for approval and status fields.
See the SaaS Admin Account Protection guide and the Least Privilege Techniques Guide.
Integrations, API tokens and service accounts
monday.com has two kinds of API credential: personal API tokens and app tokens issued to OAuth apps. Integrations and automations created by users are a third access path, because they run on behalf of whoever set them up.
| Credential | Where it comes from | Scope and lifetime (monday.com docs) | Security handling |
|---|---|---|---|
| Personal API token | Developer Center (profile > Developers > API token) or, for admins, Administration > Connections > Personal API token | Tied to one user; permissions match that user's access; all permission scopes; no stated expiry; regenerating invalidates the old token at once | Restrict the "generate API tokens" permission; use a dedicated integration account; store tokens in a secrets manager |
| App token (OAuth) | Marketplace or private apps | Limited to the app's permission scopes, each read or write, on areas such as boards, updates and teams | Admins approve scopes at install; prefer read scopes where possible |
| SCIM token | Administration > Security > SCIM | Used by the identity provider to provision users and teams | Treat as privileged; store in the identity provider only and rotate when admins change |
| Integrations and automations | Created by users on boards | Run as the creator; ownership can be transferred | Transfer ownership before a creator leaves |
Because a personal token matches its owner's access, an integration built on an admin's token has admin reach. Our recommendation: create a named integration user with only the boards and workspaces the integration needs, generate the token there, and record owner and purpose in your inventory. Regenerate the token when the owner changes or exposure is suspected; regeneration breaks every integration using the old value, which also makes it a quick containment step. See the SaaS API Token Security Guide and the Service Account Security Guide.
Marketplace apps
- Admin approval: only account admins can install apps; other users select Request to add, which notifies an admin.
- Scopes: the admin sees requested scopes at install and can approve or cancel. Question write scopes on boards and teams.
- Vendor information: check the app's Security & Compliance tab and badges, then apply your own third-party review.
- Integrations feature: monday.com's checklist notes integrations can be turned off in the admin section and limited to users with a business need.
- AI features: govern at account, workspace and custom role level; turn AI off for workspaces holding sensitive data if your policy requires it.
See the SaaS and OAuth App Governance Guide.
Logging and detection
The Enterprise audit log sits under Administration > Security > Audit and is limited to account admins. It shows last login and logout, the device, the session IP and security events such as failed logins, attachment downloads and board data exports, with timestamps in GMT and filters by user and event type. monday.com states records are not currently deleted after a set period, while noting that this may change, so keep your own copy.
| Source | What it shows | Detection use |
|---|---|---|
| Audit log | Logins, logouts, device, IP, failed logins, downloads, board exports | Account takeover signs and bulk data movement |
| Audit Log API | Programmatic access to audit records | Scheduled feed into the SIEM for correlation with identity provider logs |
| Board activity log | Board history: statuses, group moves, automations, permission changes; queryable by API | Investigate changes on sensitive boards |
| SCIM and identity provider logs | Provisioning and deactivation events | Confirm leavers were deactivated |
Panic Button (Enterprise): when admins see clear signs of compromise, the Panic Button blocks the whole account for everyone, including admins, until an account admin asks monday.com support to unblock it. Write it into the incident runbook with named decision makers, because it stops all work. Our suggested SIEM alerts: repeated failed logins, sign-ins from new countries, board exports outside business hours, and new admin assignments. See the SaaS Forensics guide.
Metrics that show it is working:
- Share of non-guest users signing in through SAML (target 100% on Enterprise).
- Number of account admins (trend down, each named).
- Users with the permission to generate API tokens, and tokens without a recorded owner (target zero).
- Installed apps with write scopes, each with an owner and review date.
- Board exports per month by user, each explained.
- Days of audit log held in the SIEM.
Hardening baseline
A phased rollout. Each step can be rolled back by reverting the setting; start SAML as optional and add IP restrictions only after listing every required address.
- Inventory: list admins, users by type, guests, installed apps and their scopes, integrations and automations by creator, and users who can generate API tokens.
- Set the authorised domain and block new accounts from your email domain.
- Configure SAML SSO (Enterprise) as optional, test with admins, then require it for all users except guests. On Pro, use Google SSO.
- Turn on 2FA for accounts not covered by SSO.
- Connect SCIM with scope set to assigned users and groups.
- Tighten account permissions: restrict API token generation, exports, guest invites and integration creation.
- Restructure access: closed workspaces and private boards for sensitive teams; column restrictions for personal data.
- Move integrations to integration users and transfer ownership away from individuals.
- Review apps and remove unowned ones; agree an approval process with IT and legal.
- Apply IP restrictions and session duration, connect the Audit Log API to the SIEM and add the Panic Button to the runbook.
| Plan | Priority choices |
|---|---|
| Standard | Authorised domain, 2FA, board permission sets, shareable boards for guests, app approval by admins |
| Pro | Add Google SSO, private boards and Only edit assigned items |
| Enterprise | SAML required, SCIM, account and column permissions, closed workspaces, IP restrictions, audit log to SIEM, Panic Button |
Common misconfigurations
- SAML left optional: users keep password sign-in. Move to "All users except guests must use SAML authentication" after testing.
- Everyone can generate API tokens: restrict the permission and issue tokens from integration users.
- Integrations owned by leavers: transfer automation and integration ownership during offboarding.
- Sensitive data on main boards: main boards are visible to all team members. Use private boards, closed workspaces and column restrictions.
- Too many admins: delegate specific privileges through custom roles instead of full admin.
- Shared views forgotten: shared views and Forms are reachable regardless of IP restrictions. Review them regularly.
Apply monday.com security updates and notices as they are published, and run leavers through the Employee Offboarding Security Guide.
Framework mapping
| monday.com control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK technique it helps address |
|---|---|---|---|
| SAML SSO, 2FA, session duration, IP restriction | IA-2, AC-12 | PR.AA-01 | T1078.004 Cloud Accounts |
| SCIM provisioning and deactivation | AC-2 | PR.AA-01 | T1078.004 Cloud Accounts |
| Account, workspace, board and column permissions | AC-6 | PR.AA-05 | T1213 Data from Information Repositories |
| API token permission and integration users | IA-5, AC-6 | PR.AA-01 | T1528 Steal Application Access Token |
| Marketplace app approval | SA-9, CM-7 | GV.SC-07 | T1550.001 Application Access Token |
| Audit log and Audit Log API | AU-6 | DE.CM-03, PR.PS-04 | T1098 Account Manipulation |
Practitioner checklist
- Authorised domain set and new accounts from your email domain blocked.
- SAML required for all users except guests (Enterprise), or Google SSO on Pro; 2FA on for the rest.
- SCIM connected, scoped to assigned users and groups.
- Account admins kept to a minimum; specific privileges delegated through custom roles.
- API token generation, exports, guest invites and integration creation restricted by user type.
- Integrations run from owned integration users; tokens stored in a secrets manager.
- Apps approved by admins against scopes, each with an owner.
- Closed workspaces, private boards and column restrictions in place for sensitive data.
- IP restrictions and session duration set; shared views and Forms reviewed.
- Audit log pulled into the SIEM by API; Panic Button documented in the incident runbook.
Standards and references
- monday.com: Secure configuration checklist
- monday.com: SAML Single Sign-on
- monday.com: Permissions on monday.com
- monday.com: SCIM provisioning with Entra ID
- monday.com Developers: Authentication
- monday.com: Understanding monday marketplace security
- monday.com: The Audit Log
- monday.com: The Panic Button
Related NHI Mgmt Group resources: SaaS Security Guide, SaaS API Token Security Guide, SaaS and OAuth App Governance Guide, SCIM Provisioning Guide, SaaS deprovisioning.