Miro boards collect strategy maps, architecture diagrams, customer journeys and workshop notes, and a single public link can put that content in front of anyone who has the URL. Whiteboard content is often more sensitive than people assume, because it is where early plans and system designs are drawn before they become formal documents. This guide explains how to secure Miro from the customer side: SAML SSO with domain control, SCIM provisioning, admin roles, board sharing policies, app management and API scopes, classification and Enterprise Guard, and audit logs. It is written for Miro Company Admins, collaboration platform owners and data security teams. For the wider discipline, see the Secure File Sharing Guide; this page stays specific to Miro.
This is an independent guide from NHI Mgmt Group, based on Miro's public documentation as of November 2026. It is not sponsored or reviewed by Miro. Product features change, so confirm settings against Miro's current documentation.
Key takeaways
- Verify domains, then enforce SSO. Miro SAML SSO needs a domain verified in Domain Control, and users on verified domains then become managed users who must sign in through your identity provider.
- Sharing defaults need setting. Team and company-wide sharing and team-level public links are on by default, so decide on public links, passwords, link expiry and allowed domains early.
- Restrict apps to an approved list. On Enterprise, "Restrict members to add apps only from the list below" turns the Marketplace into an allow list, with approval by toggle or client ID.
- Classification labels plus guardrails. Labels describe sensitivity; Enterprise Guard's Intelligent Guardrails and auto-classification turn those labels into enforced sharing and copying rules.
- Set audit log retention deliberately. Enterprise audit logs keep 180 days by default, configurable to 30, 90, 180 or 365 days, with export, an Audit Log API and SIEM integrations.
How identity and access work in Miro
Miro organises users into an organisation (company) and teams, with boards owned inside teams. Identity control rests on three linked features: Domain Control, single sign-on and, on Enterprise, SCIM provisioning.
| Feature | Plan (Miro docs) | What it does | Recommended use |
|---|---|---|---|
| Domain Control | Enterprise (full); Business (basic) | Verifies company domains; audits users and teams on the domain outside the subscription; can add newly registered domain users automatically; restricts users from creating their own subscriptions; blocks deactivated users from using their corporate email | Verify every corporate domain and run a domain audit to consolidate unmanaged teams |
| SAML SSO | Business and Enterprise | Users on listed verified domains must sign in through the identity provider; password, Google, Slack, Apple ID and other login methods stop applying after next logout | Enforce for all corporate domains; test with "Test SSO configuration" first |
| Just-in-time provisioning | With SSO and Domain Control | New users from listed domains join the subscription and a default team you choose | Point the default team at a low-privilege landing team |
| SCIM | Enterprise | Creates users, maps SCIM groups to Miro user groups, deactivates users when the identity provider deactivates or deletes them | Use for joiners, movers and leavers; see the SCIM Provisioning Guide |
| Idle Session Timeout | Enterprise | Signs out idle members and guests; default 1 day, range 1 hour to 14 days; Miro recommends at least 8 hours | Our view: 8 to 12 hours for most organisations |
SSO setup uses the ACS URL and Entity ID published in Miro's SSO article, NameID as the user's email address, and a signed assertion from the identity provider. When certificates are renewed in the identity provider, replace the certificate under Company settings > Authentication > Single sign-on during quiet hours. Miro advises a break-glass admin account on a domain outside the SSO domains so you can still sign in if the identity provider fails; protect that account with Miro two-factor authentication (see Miro's 2FA admin guide and confirm how it applies to accounts outside SSO), and monitor its sign-ins.
Leavers: SCIM deactivation frees the licence but leaves board ownership and group membership in place, so reassign ownership of important boards as part of offboarding. Full removal uses Miro's Delete API, which reassigns content to team members. The sessions:delete API scope allows resetting all of a user's sessions during an investigation. See the SaaS deprovisioning guide.
Admin roles and privileged access
Miro defines four predefined organisation-level admin roles. Splitting them lets you avoid giving every administrator the full Company Admin role.
| Role | Privileges (Miro docs) | Least-privilege guidance |
|---|---|---|
| Company Admin | Account settings, users, teams, user groups, billing groups, apps, admin roles and security settings (audit logs, authentication, collaboration, managed domains); manages Trash | Two or three named people, SSO plus monitored sign-ins |
| Security Admin | Configure and export audit logs; view and edit authentication (including SSO), collaboration settings and managed domains | Give to the security team instead of Company Admin |
| User Admin | View, edit, add and remove users; manage invitations and licence requests; view and edit teams | Service desk or IT operations |
| Content Admin | View and edit boards and board access, manage project access, manage Trash including force-deleting boards under retention, manage templates | Highest content reach: a very small group, reviewed often |
Team Admins manage settings for their own team, including team sharing and app settings, within the limits set at company level. Review all admin assignments quarterly (our recommended cadence) and record a justification for every Content Admin. See the SaaS Admin Account Protection guide.
Board sharing policy
Sharing settings sit under Company settings > Security > Sharing, with team-level options under each team's settings. Changes apply immediately and users are not notified, so communicate before you tighten them.
| Setting | Default or range | Recommended baseline |
|---|---|---|
| Boards can be shared publicly | Company toggle; turning it off removes "Anyone with the link" and stops existing public links and embeds | Off, or on only with passwords and expiry |
| Allow editing on publicly shared boards | Company toggle | Off |
| Team public link options | View and comment (default for new teams), view comment and edit, or restrict | Restrict for teams handling confidential work |
| Require passwords for publicly shared boards | Password length 6 to 14 characters (default 8) with complexity rules | On, with at least 12 characters (our recommendation) |
| Expire public sharing link | 30 to 999 days of inactivity | 30 to 90 days |
| Restrict allowed domains | Company and team allow lists; team list overrides company list | On, with your domains and approved partner domains |
| Allow sharing with guests outside these domains | Option under allowed domains | On only where guest collaboration is governed |
| Allow moving boards to other organizations | Off by default | Keep off |
| Sharing via embed | Optional "Also allow editing. No sign-in required." | Keep the no sign-in editing option off |
Use Verify all users against the allowlist after turning on allowed domains to find existing users from other domains, because users invited before the restriction keep their access.
Integrations, API tokens and service accounts
Miro apps reach boards through OAuth with scopes, and organisation-level automation such as audit log collection or SCIM uses dedicated tokens. Each of these is a non-human identity that needs an owner.
App management
- Allow list: on Enterprise, Company Admins turn on Restrict members to add apps only from the list below under Company settings > Apps and integrations > Apps > Manage apps. Users can then add only approved apps and can request others.
- Approve internal apps by client ID: paste the client ID of internally developed apps to approve them.
- Block: disabling an approved app's toggle stops it for users in all Enterprise teams.
- Team level: on Business and Enterprise, Team and Company Admins can allow or restrict members from adding apps per team; by default users can add any app for their team.
- Preauthorisation: admins can preauthorise Web SDK apps when adding them, so approve with care because users skip the consent step.
API scopes and tokens
| Scope | What it allows | Handling |
|---|---|---|
boards:read / boards:write | Read, or create, update and delete, boards, members and items | Prefer read-only where the app only displays content |
team:write | Change team title, invite users, change user roles | Treat as privileged |
organizations:teams:write, organizations:groups:write | Create or delete teams; modify user groups | Admin automation only, owned by the platform team |
auditlogs:read | Read the organisation's audit logs | Use for the SIEM collector only |
boards:export, contentlogs:export | Export organisation boards as PDF; export activity across all boards (Enterprise Guard) | Bulk data access: restrict to eDiscovery tooling |
sessions:delete | Reset all of a user's sessions | Containment automation for investigations |
Miro apps choose expiring or non-expiring access tokens when they are created, and the choice is fixed for that app. Expiring access tokens last one hour, refresh tokens 60 days, and each refresh issues a new refresh token. Our recommendation: build internal apps with expiring tokens, keep client secrets and tokens in a secrets manager, and treat the SCIM token (generated under Company settings > Enterprise integrations > SCIM Provisioning) as a privileged credential with a named owner. See the SaaS and OAuth App Governance Guide and the SaaS API Token Security Guide.
Logging and detection
Enterprise audit logs live under Company Settings > Security > Audit logs. You can filter by date range, actor, category and event, and preview the last 90 days in the console.
| Category | Example events (Miro docs) | What to watch for |
|---|---|---|
| Company | SSO/SAML and SCIM settings, sharing and guest controls, allow lists, domain control | Any change to authentication or sharing policy |
| Users | Admin promotion or demotion, guest conversion, deactivation and reactivation | New admins outside change records |
| Boards | Sharing and public link changes, owner changes, moves, exports and file downloads | Public link creation on classified boards; bulk exports |
| Access and authentication | Sign-ins, failed sign-ins, sign-outs, email changes, including activity from deactivated users | Break-glass account use; sign-ins by deactivated users |
| Apps and AI | App install, uninstall, approval and restriction; Miro AI usage | Unapproved app activity; changes to the allow list |
Retention defaults to 180 days and can be set to 30, 90, 180 or 365 days; Miro notes deleted logs cannot be recovered. CSV exports are available for 24 hours. For long-term retention, collect through the Audit Log API with a token holding only auditlogs:read, or use a supported SIEM integration. With Enterprise Guard, Content Logs add user activity on board content for audit and legal review. See the SaaS Audit Log Retention and Licensing Guide.
Metrics that show it is working:
- Share of active users who are managed users signing in through SSO (target 100% for corporate domains).
- Number of boards shared by public link, and the share with passwords and expiry.
- Apps approved versus requested, and approved apps with a named owner.
- Number of Company Admins and Content Admins (trend down).
- Days of audit history held in the SIEM.
- Boards labelled at the highest classification with public or company-wide sharing (target zero where guardrails apply).
Hardening baseline
A phased rollout. Most settings change immediately and can be rolled back by reverting the same toggle, with one exception: re-enabling public sharing does not restore old public links, so each board must be reactivated by hand.
- Inventory: list admins by role, approved apps, teams, and boards with public links (owners can report these).
- Verify domains in Domain Control and run a domain audit to bring unmanaged teams into the subscription.
- Configure SSO with a break-glass account outside the SSO domains, test, then enable for all corporate domains.
- Turn on SCIM (Enterprise) and map identity provider groups to Miro user groups.
- Split admin roles: move security staff to Security Admin and service desk to User Admin.
- Set sharing policy: allowed domains, password requirement, link expiry, no public editing, and team overrides for confidential teams. Announce first.
- Restrict apps to an approved list and review preauthorised apps.
- Set classification labels and a company default; with Enterprise Guard, add auto-classification and Intelligent Guardrails for the top labels.
- Set Idle Session Timeout and audit log retention, and connect the Audit Log API or SIEM integration.
- Schedule reviews: quarterly admin and app reviews, monthly public link review (our recommendations).
| Organisation profile | Priority choices |
|---|---|
| Business plan | SSO on verified domains, team-level public link restriction and app restriction per team, regular review of guests |
| Enterprise | SSO plus SCIM, company sharing policy, app allow list, split admin roles, audit log retention and SIEM |
| Enterprise with Enterprise Guard | All of the above plus Data Discovery, auto-classification, Intelligent Guardrails, retention and legal holds |
Common misconfigurations
- Public links left at defaults: team-level public sharing starts on, so turn on passwords and expiry or restrict it.
- Labels treated as controls: classification labels on their own do not change sharing. Pair them with Intelligent Guardrails or a sharing policy.
- SSO without domain coverage: users on domains not listed in SSO settings keep standard login. Verify and list every corporate domain.
- No break-glass path: without an account outside the SSO domains, an identity provider outage locks out admins. Create and protect one.
- Every admin a Company Admin: use Security, User and Content Admin roles for narrower jobs.
- Audit logs left to age out: collect through the API before the retention window closes.
Apply Miro's product updates and security notices as published, and see the Data Classification Guide for label design.
Framework mapping
| Miro control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK technique it helps address |
|---|---|---|---|
| SSO, Domain Control, Idle Session Timeout | IA-2, AC-12 | PR.AA-01 | T1078.004 Cloud Accounts |
| SCIM provisioning and deactivation | AC-2 | PR.AA-01 | T1078.004 Cloud Accounts |
| Admin roles and sharing policy | AC-6 | PR.AA-05 | T1213 Data from Information Repositories |
| App allow list and API scopes | SA-9, CM-7 | GV.SC-07 | T1528 Steal Application Access Token |
| Audit logs and SIEM | AU-6 | DE.CM-03, PR.PS-04 | T1098 Account Manipulation |
Practitioner checklist
- All corporate domains verified in Domain Control and listed in SSO settings.
- Break-glass admin account outside SSO domains, with 2FA and monitored sign-ins.
- SCIM connected, groups mapped, and board ownership reassigned during offboarding.
- Admin roles split; Company Admin and Content Admin limited to named people.
- Public sharing off, or on only with required passwords, link expiry and no public editing.
- Allowed domains set, with guests outside them allowed only where governed.
- Apps restricted to an approved list, each with an owner; preauthorised apps reviewed.
- Classification labels and default set; guardrails applied to the most sensitive labels where Enterprise Guard is licensed.
- Idle Session Timeout set and audit log retention chosen deliberately.
- Audit logs collected by API or SIEM integration with a token scoped to
auditlogs:read.
Standards and references
- Miro: Sharing policy on Enterprise Plan
- Miro: Single sign-on (SSO)
- Miro: SCIM
- Miro: Understand admin roles and their privileges
- Miro: App management
- Miro: Enterprise Guard introduction
- Miro: Audit logs
- Miro Developers: Permission scopes
Related NHI Mgmt Group resources: Secure File Sharing Guide, Data Classification Guide, SCIM Provisioning Guide, SaaS and OAuth App Governance Guide, SaaS Security Guide.