Notion workspaces hold product plans, runbooks, credentials pasted into pages and customer notes, yet most of them were set up by a team rather than by security, so public links, open guest invitations and unreviewed API connections are common. This guide explains how identity, roles, sharing, connections and logging work in Notion, which settings exist on which plan, and the baseline a security team should apply. It is for IT administrators, workspace owners and security engineers responsible for a Notion workspace or organisation. Facts come from Notion's own help centre and developer documentation, read on 8 November 2026; Notion changes settings often, so confirm names in your admin console. For the wider SaaS programme, see the SaaS Security Guide.
This is an independent guide from NHI Mgmt Group, based on Notion's public documentation as of November 2026. It is not sponsored or reviewed by Notion. Product features change, so confirm settings against Notion's current documentation.
Key takeaways
- Plan decides the controls. SAML SSO starts at Business; SCIM, the audit log, SIEM streaming, connection allowlists, export and public-link controls and managed users are Enterprise features.
- Enforce SAML, then keep the bypass small. "Only SAML SSO" logs out domain users and forces IdP sign-in, but owners can still sign in with email and password to repair SSO, so owner accounts are the highest-value targets.
- Connections are non-human identities. Any member can add a connection by default, and each one reads or writes only the pages it is added to; on Enterprise, restrict installs to an approved list.
- The SCIM token belongs to a person. It is tied to the owner who created it and is revoked if that owner leaves or changes role, which breaks provisioning silently unless someone watches for it.
- Audit log retention is 365 days. Export or stream it to a SIEM, noting that organisation-level events are not streamed by the webhook.
How identity and access work in Notion
Notion has two layers: workspaces (where pages and teamspaces live) and, on Enterprise, an organisation that groups workspaces and the users on your verified domains. People sign in to a Notion account, and that account is a member, restricted member or guest of each workspace.
| Control | What it does | Plan |
|---|---|---|
| Allowed email domains | Anyone with an address on the domain can join the workspace | Workspace setting |
| Verified domains | Proves ownership; needed for SAML, SCIM name and email changes, managed users | Business or Enterprise |
| SAML SSO | Sign-in through the corporate IdP; Business has one configuration, Enterprise up to 25 | Business or Enterprise |
| Login method | "Any method" (SAML alongside email, Google, Apple) or "Only SAML SSO" | Business or Enterprise |
| Automatic account creation (JIT) | SAML users join as members on first sign-in | Business or Enterprise |
| SCIM provisioning | IdP creates, updates and removes users and groups | Enterprise |
| Managed users | Organisation control over accounts on verified domains: session length, log-out, suspension, external workspace access | Enterprise |
- Domain hygiene: a parent domain does not cover subdomains, so verify each one. An email domain can belong to only one Notion organisation. On Business, Notion advises removing allowed email domains before SAML setup so only IdP-provisioned users join.
- Guests sit outside SSO: page guests cannot use SAML and sign in with another method, and SCIM cannot manage guests. Govern them through invitation settings and periodic review instead.
- JIT and SCIM together: Notion does not recommend using automatic account creation alongside SCIM, because allowed email domains can let membership drift from the IdP. Pick SCIM on Enterprise.
- Sessions: on Enterprise the session duration defaults to 180 days and can be set from 1 hour to 180 days, across all devices. Owners can log out all users or one user; a logged-out user can sign straight back in unless suspended.
- External workspaces: Enterprise can decide whether managed users may join workspaces your organisation does not own, and remove them from those, which closes a common data leakage route into personal or client workspaces.
Sharing model
| Setting | Options | Security note |
|---|---|---|
| Page permission levels | Full access, Can edit, Can edit content (databases), Can create (databases, Business and Enterprise), Can comment, Can view | Only Full access can share onwards; grant it sparingly |
| General access | Only people invited; Everyone at [workspace]; Anyone on the web with link | "Anyone on the web with link" exposes the page to whoever holds the URL |
| Link expiry | Expiry date and time on web links | Use for any external share that must stay public |
| Publish (Notion Sites) | Public site, optional search engine indexing | Indexed pages can be found by anyone searching |
| Teamspaces | Own members and permission levels; default teamspace pages visible to all members except restricted members | Do not put sensitive pages in a default teamspace |
| Inheritance | Subpages inherit parent permissions unless changed | Moving a page under a public parent can expose it |
Admin roles and privileged access
| Role | Power | Control |
|---|---|---|
| Organisation owner (Enterprise) | Manages all workspaces and users in the organisation, generates SCIM tokens, sees the organisation audit log, can bypass SAML for organisation-managed configurations | Two or three named people, phishing-resistant MFA at the IdP and on the Notion account, reviewed quarterly |
| Workspace owner | All workspace settings, delete the workspace, manage owners, admins, members and guests, revoke SCIM tokens, bypass workspace-managed SAML | Small number per workspace; no shared owner accounts |
| Membership admin (Enterprise) | Adds and removes members in workspaces or groups; cannot change settings | Use for help desk tasks instead of owner rights |
| Member | Reads, edits and comments on shared pages; can add connections unless restricted | Restrict connection installs on Enterprise |
| Restricted member | Needs explicit access to each teamspace or page; cannot create teamspaces | Good default for contractors on your domain |
| Guest | Only pages they are invited to; cannot add members or connections | Review and expire |
| Temporary member | Approved marketplace consultant, time-limited access up to one year | Track the end date |
- The SAML bypass: when SAML fails, organisation owners (organisation-managed configurations) or workspace owners (workspace-managed ones) can sign in with email and password to fix it, and workspace owners can switch off enforcement temporarily. Treat owner accounts as break-glass: strong unique passwords in a vault, MFA, and an alert on any owner email-and-password sign-in or SAML settings change.
- Delegate: use membership admins and organisation-level delegated admin work for routine tasks so fewer people need owner rights. See the SaaS deprovisioning guide for leaver handling.
Integrations, API tokens and service accounts
Notion calls integrations "connections". Public connections are partner apps added through OAuth; internal connections are created for one workspace and authenticate with an internal API token. A connection only works on pages where it has been explicitly added (page menu, Connections, Add connections), or the pages chosen during the OAuth consent step.
| Capability (developer docs) | What it allows | Least privilege advice |
|---|---|---|
| Read content | Read existing content | Only for connections that must read; reporting tools often need nothing else |
| Update content | Change existing content | Avoid for read-only use cases |
| Insert content | Create new content without reading full objects | Suits form or ticket intake |
| Read comments, Insert comments | Comment access | Enable only if the use case needs it |
| User information: none, without email, with email | How much user data the API returns | Default to no user information unless required |
- Who can add connections: members and owners, from Settings, Connections. On Enterprise, owners can restrict which connections members install, keep an approved connections list, restrict adding and page-level connect or disconnect to owners, see which members have a connection installed and disconnect them.
- Page access governance (Enterprise): "Manage page access" lets owners set whether connection owners and workspace members, or connection owners only, can change which pages a connection reaches.
- Internal API tokens: owners can retrieve an internal connection's token from its menu. Store it in a secrets manager, never in a Notion page, and rotate it when the person who built the integration leaves. See the SaaS API Token Security Guide.
- SCIM token: only Enterprise organisation owners can generate and view SCIM tokens, one per workspace. The token is tied to the owner who created it and is revoked if that owner leaves the workspace or their role changes; remaining owners are notified. Provisioning stops until it is replaced, so create it from a dedicated, durable owner identity and monitor the "SCIM token generated" event. That owner cannot be removed through SCIM.
- OAuth consent: each partner app a member authorises is a standing grant to company content. Review these grants regularly: see the OAuth and SaaS integration breaches guide and the SaaS and OAuth App Governance Guide.
Logging and detection
The audit log is an Enterprise feature. Organisation owners find the organisation log under Manage organization, Data & Compliance, Audit log; the workspace log is under Settings, Audit log. Events are recorded only from the time of upgrade to Enterprise.
- Retention and export: the log covers up to 365 days. CSV export includes only events matching the active filters, with data up to two hours before the export. Export on a schedule if you need longer retention. See the SaaS Audit Log Retention and Licensing Guide.
- SIEM streaming: Notion streams workspace events as JSON over webhooks, one webhook per workspace, retrying failed deliveries up to seven times over about 24 hours. Payloads carry metadata, not page content. Syslog is not supported and organisation events are not streamed, so organisation-level changes such as SAML updates need the CSV export or a manual review. Teamspace data is included for events from 9 August 2026.
- Filters: date, person or agent (including removed users and integrations), event type, teamspace, and "Related" to show events triggered by the same action.
| Detection | Audit event | ATT&CK |
|---|---|---|
| Page made public | Page shared to web | T1567 Exfiltration Over Web Service |
| New integration | Integration created | T1528 Steal Application Access Token |
| Provisioning credential change | SCIM token generated | T1078.004 Cloud Accounts |
| SSO weakened | SAML settings updated (organisation log) | T1078.004 Cloud Accounts |
| Admin escalation | Admin role assigned (organisation log) | T1078.004 Cloud Accounts |
| MFA removed from an account | MFA TOTP toggled | T1078.004 Cloud Accounts |
| Bulk reading or moving of pages by one user or agent | Spike in page events for one actor | T1213 Data from Information Repositories |
Hardening baseline
- Verify domains (and each subdomain) and remove allowed email domains if SAML or SCIM will control membership.
- Configure SAML in "Any method" mode, test with a pilot group, then switch to "Only SAML SSO". Roll back by switching the login method back if the IdP fails; owners can use the bypass.
- Enable SCIM (Enterprise) from a durable owner identity, map IdP groups to Notion groups, and turn off automatic account creation.
- Set session duration to match corporate policy rather than the 180-day default, and restrict managed users from joining external workspaces where data policy requires it.
- Lock down sharing on the Security tab: disable public links or publishing sites and forms where not needed, disable duplicating pages to other workspaces, control guest invitations and page access requests, and decide on "Disable export".
- Restrict connections to an approved list, restrict page-level connect rights, and review installed connections per member.
- Stream the audit log to the SIEM and schedule CSV exports of organisation events.
- Set trash retention (Enterprise) so deleted content stays recoverable for investigations and legal holds.
- Classify content: keep secrets out of pages and use a scanner or DLP control for credentials pasted into Notion. See the Data Loss Prevention (DLP) Guide.
Framework mapping
| Notion control | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| SAML enforcement, session duration | IA-2 | PR.AA-05 |
| SCIM provisioning and deprovisioning | AC-2 | PR.AA-05 |
| Roles, page permissions, connection capabilities | AC-3, AC-6 | PR.AA-05 |
| Audit log export and SIEM streaming | AU-2, AU-6 | DE.CM-03 |
| Public link and export controls | AC-3 | PR.DS-01 |
Common misconfigurations
- Pages left on "Anyone on the web with link": internal wikis, onboarding pages and runbooks shared once for a supplier stay public for years. Search the audit log for "Page shared to web" and use link expiry.
- Credentials in pages: API keys and passwords pasted into runbooks are readable by every member and every connection with read access to that page.
- SAML on, but "Any method" left in place: users keep email or social sign-in that bypasses IdP MFA and conditional access.
- SCIM token created by a departing admin: it is revoked when they leave and provisioning stops, so leavers keep access until someone notices.
- Unrestricted connections: members authorise automation apps with read and update rights to large page trees, creating non-human access no one reviews.
- Default teamspace used for sensitive work: every member except restricted members can see it, including contractors on the corporate domain.
Practitioner checklist
- Confirm which plan you are on and which of the controls above it includes.
- Verify all corporate domains and subdomains; remove allowed email domains once SSO or SCIM controls membership.
- Enforce "Only SAML SSO" and alert on owner sign-ins and SAML settings changes.
- Limit organisation and workspace owners to a few named people; use membership admins for routine work.
- Generate the SCIM token from a durable owner identity and monitor for its revocation.
- Restrict connections to an approved list and review each connection's capabilities and pages.
- Find and fix pages shared to the web; disable public links or publishing where not needed.
- Stream workspace audit events to the SIEM and export organisation events on a schedule.
- Set session duration and trash retention to match corporate policy.
- Review guests and temporary members quarterly and remove those without a current need.
Standards and references
- Notion: SAML SSO configuration
- Notion: Provision users and groups with SCIM
- Notion: Audit log
- Notion: Workspace settings
- Notion: Sharing and permissions
- Notion: Add and manage connections with the API
- Notion Developers: Capabilities
- Notion: Managed users dashboard
Related NHI Mgmt Group resources: SaaS Security Guide · Collaboration Tool Security Guide · SaaS API Token Security Guide · SaaS and OAuth App Governance Guide