Miro のアクセス管理機能（SSO・MFA・IP制限・監査ログ）

How to configure Google SSO

How to configure OneLogin SSO

Single sign-on (SSO)

With SAML-based single sign-on (SSO), users can access Miro through an identity provider (IdP) of their choice.

Available for: Business Plan, Enterprise Plan

Required role: Company Admin

How SAML SSO works

When a Miro user tries to log in to Miro using SSO, Miro sends a SAML (Security Assertion Markup Language) request to the identity provider (IdP)

The identity provider validates the user’s credentials and sends a response back to Miro to confirm the member's identity

Miro acknowledges the response and grants access, allowing the member to log into their Miro account

Enabling SSO for the first time

The first time you set up SSO, existing users can keep working in Miro without interruption. However, the next time they log out, their session expires, or they try to log in from a new device, they will need to sign in via SSO.

Other login options will be disabled for users, including magic link, Google, Facebook, Slack, AppleID and O365.

Idle session timeout

If you have enabled Idle Session Timeout, users are automatically logged out of their Miro profile and will need to authorize via SSO again.

Multiple teams and organizations

If your users have multiple Miro teams or organizations, you can configure them to use the same identity provider (IdP) for authentication.

Who is required to sign in with SSO

SSO sign in is required for active users that are part of your Enterprise subscription and have a domain listed in your SSO settings.

Users accessing Miro from domains not added in your SSO settings aren't required to log in with SSO, and should instead log in using the standard login methods.

Users from a verified domain, who aren't part of your Miro Enterprise subscription, need to sign in via single sign-on (SSO) only if just-in-time (JIT) provisioning is enabled. These users will automatically be added to a pre-configured team and will be required to use SSO for login.

Managed users, which is any user inside your verified domain(s), including any managed user who is also a member of a team outside of your Enterprise subscription. To restrict access to specific teams, update your domain control settings.

✏️ For an Enterprise subscription, an organization can have verified and unverified domains. For verified domains, users become managed users who must authenticate with SSO. For unverified domain users in the same organization, a magic link or social account is used for authentication.

Managing user details

User data is automatically attributed in Miro by your identity provider upon successful login. Some parameters like name can't be changed. Other parameters like department and profile pics are optional.

Miro Usernames are updated after every successful user authentication. For more information on how to set up Miro usernames, see the advanced SSO settings. If you need to change a user's email address, you can do so only via SCIM. If you don't use SCIM, please reach out to the Support Team.

Domain selection in SSO settings

💡 To prevent a lockout, create a 'break the glass' user with an email that has a domain outside of the domain listed in the SSO settings, like acmebreaktheglass@gmail.com. Otherwise, you can contact support, and they can disable SSO for the whole organization.

Configuring SSO

Identity providers (IdP)

Use any identity provider of your choice. Below are the most popular identity provider platforms:

Entra ID by Microsoft

ADFS by Microsoft

How to configure your IdP

💡 If your Enterprise organization would like to add multiple identity providers (IdPs), sign up for our private beta.

Go to your identity provider's configuration section and follow the provider's instructions to configure single sign-on.

Add the following metadata. We recommend skipping any optional fields and leaving any default values as they're.

Specs (metadata)

HTTP Redirect for SP to IdP

HTTP Post for IdP to SP

The service URL (SP-initiated URL)

Also known as Launch URL, Reply URL, Relying Party SSO Service URL, Target URL, SSO Login URL, Identity Provider Endpoint, etc.

https://miro.com/sso/saml

Assertion Consumer Service URL

Also known as Allowed Callback URL, Custom ACS URL, Reply URL

Also known as Identifier, Relying Party Trust Identifier

https://miro.com/

Default Relay State

must be left empty in your configuration

Signing Requirement

An unsigned SAML Response with a signed Assertion

<md:OrganizationName xml:lang="en-US">Miro</md:OrganizationName>

<md:OrganizationURL xml:lang="en-US">https://miro.com/</md:OrganizationURL>

</md:Organization>

<md:ContactPerson contactType="support">

<md:GivenName>Support Team</md:GivenName>

<md:emailAddress>support@help.miro.com</md:emailAddress>

</md:ContactPerson>

</md:EntityDescriptor>

User credentials

Any additional fields outside the below aren't required. We recommend skipping any optional fields and leaving any default values as they're.

Required user credential attributes

NameID (equals a user’s email address)

<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">

(updated with every new authentication via SSO, used when present/available)

Go to your Company settings > Authentication > Single sign-on

Testing your SSO configuration

Complete the steps above to configure your SSO settings.

Testing SSO configuration

Optional advanced SSO settings

The optional settings section is used by advanced users who are familiar with SSO configuration.

Just In Time Provisioning for new users

Subscription type

Behavior when licenses run out

Users aren't automatically added; JIT feature stops working.

Enterprise Plan (without Flexible License Program)

Enterprise Plan (with Flexible License Program activated)

Depends on the default license settings

Go to your SSO settings

You can find your organization ID from the Miro dashboard by clicking on your Profile in the upper right corner > Settings > it's shown in the URL in the address bar.

Enterprise two-factor authentication (2FA) – user guide

Relevant for: Enterprise Plan

Set up by: Company Admins

Two-factor authentication (2FA) for organizations

2FA adds an extra layer of security to online profiles. Enterprise Company Admins can mandate an additional proof of identity when users access their organization's Miro subscription. This requirement is applicable to users signing in with a magic link.

For companies using SSO, 2FA includes only non-SSO external collaborators. For companies not using SSO, 2FA extends to all users.

✏️ This article explains two-factor authentication (2FA) for Enterprise plans. For all other plans, see Two-factor authentication (2FA) in Administration.

Setting up enforced 2FA for your organization

✏️ Before activating two-factor authentication (2FA), it's important to inform all impacted users, including both members within your organization and external collaborators. To ensure a smooth transition, we suggest sharing our 2FA user guide to assist them through this process.

How to enable 2FA for your users

Go to Admin console > Security > Authentication.

Toggle on Enforce 2FA for non-SSO users.

Enforcing 2FA authentication for non-SSO users

Trusting 2FA devices

When enabled, your 2FA users will be shown a checkbox which allows them to skip 2FA each time they sign in on that device for the next X days, where "X" is the time frame set by the administrator. You can allow user devices to be trusted for 7 to 90 days. By default, trusting 2FA devices is enabled, though you can disable the feature in your Admin console.

⚠️ If trusting 2FA devices is disabled, users will have to enter a 2FA code on every sign in. This will slow down the sign in experience.

2FA will be required again after the trusted period passes.

2FA won't be skipped if users sign in on a new device or browser or if they clear their browser cookies.

Resetting 2FA for users

If a user loses access to their 2FA method, admins can reset their 2FA. Once a user requests that their 2FA method be reset, the appropriate admin will receive an email notification.

✏️ Admins can reset two-factor authentication only for users whose email domains are verified in their organization, if the admin initiates the reset. If the user requests a reset, then any admin in the organization can approve it.

To reset the 2FA method for the user:

Go to Admin console > Users > Active users tab.

Find the user who needs their 2FA method reset.

Click the three dots (...) icon on the user's row.

Resetting two-factor authentication in the Admin console

Click Reset two-factor authentication.

A dialog will open asking for confirmation.

Click the Reset 2FA button in the dialog.

A confirmation message will appear at the top of your screen confirming that reset instructions have been sent to the user.

Impact on user experience

Non-SSO users will be prompted to set up their second factor during their next login. This process won't log them out from any ongoing sessions.

Users are required to configure 2FA using their mobile device along with a time-based one-time password (TOTP) application, such as Microsoft Authenticator, Google Authenticator, or Authy.

For users using 2FA, there is a limit of 3 attempts to enter a valid TOTP code. If this limit is exceeded, they will need to start the authentication process again.

While 2FA login is available on mobile and tablet apps, the initial registration process is supported exclusively on browser and desktop applications.

Important to know

Enforcement of 2FA only applies to users authenticating via magic links (sent via email).

2FA isn't enabled for external collaborators who authenticate using SSO.

If an external collaborator to your Enterprise organization is already authenticating using SSO from their home organization, they will continue to access all the teams and boards in Miro using SSO.

When a user authenticates through a third-party login integration (for example, Google, Microsoft, Slack), they will maintain access to all Miro teams and boards via that login method. Admins have the option to encourage these users to set up a second factor within their respective login integration. However, Miro's authentication flow won't prompt these users to set up a second factor.

Administrators can track users who have set up 2FA, along with 2FA login successes and failures with the following audit log events:

mfa_setup_succeeded - if a user has successfully set up their second factor

Update to sign_in_succeeded event to include MfaFactorType attribute if a successful login is completed with 2FA

Update to sign_in_failed event to include MfaFactorType attribute if a login with 2FA was unsuccessful due to the user exceeding the maximum number of attempts (non-technical failure)

Related articles

Single sign-on (SSO)

SCIM (legacy documentation)

Self-serve teams to Enterprise plan consolidation

Two-factor authentication (2FA) – user guide

We have removed the option to sign in with username and password. Please sign in with a magic link, single sign-on (SSO), or a social account (Google, Microsoft, Apple, etc.) instead.

Who can do it: Team admins, Company admins

Which plans: Starter, Business, Education, Enterprise

Which platforms: Browser, Desktop, Mobile

Two-factor authentication (2FA) adds an extra layer of security to online accounts by requiring users to provide two unique verification methods before accessing their accounts.

Miro admins can enable 2FA for their teams, and reset 2FA for team members. Users have the option to trust a device for 30 days.

✏️ This article explains 2FA for Starter, Business, and Education plans. To learn about 2FA for Enterprise, see Two-factor authentication (2FA) (admin guide).

Enable two-factor authentication (2FA)

For Starter and Education plans, ensure that you have the Team admin role.

For a Business plan, ensure that you have the Company admin role.

Follow these steps:

From your Miro dashboard, click your avatar in the top-right and select Admin Console.

(Starter) Go to Security > Permissions.

(Education) Go to Permissions.

(Business) Go to Security > Authentication.

Under Two-factor authentication (2FA), toggle Require two-factor authentication when signing in to the on position.

Two-factor authentication (2FA) setup for users

For teams that have 2FA enabled, users signing in with a magic link must also authenticate using an authenticator app. 2FA doesn't apply when signing in with SSO or a social account (Google, Microsoft, Apple, etc.).

To learn how to setup 2FA as a user, see Two-factor authentication (2FA) – user guide.

Trusted devices

A user logging in to Miro with 2FA can choose to trust their device.

When using the trusted device to log in, the user will only be prompted to authenticate with their first factor, skipping their second factor, because the device is trusted.

Trusted device for 2FA is enabled by default.

At sign in, Trust this device for 30 days is selected by default, which the user can optionally deselect.

✏️ The trust device period can only be modified on an Enterprise plan. For more information, see Two-factor authentication (2FA) (admin guide).

To untrust a device that was accidentally trusted, a user can sign themselves out of everywhere. Go to Profile, under Profile settings, click Sign out of everywhere.

Reset two-factor authentication (2FA)

If a user loses access to their second factor, then they can request that their admin reset their 2FA.

To reset 2FA for users on Starter and Education plans, ensure that you have the Team admin role.

To reset 2FA for users on a Business plan, ensure that you have the Company admin role.

Go to Users > All users.

Locate the user, then select the three dots (...) at the end of the row.

Click Reset two-factor authentication.

The user receives reset instructions by email.

Related articles

Enterprise two-factor authentication (2FA) – user guide

Enterprise two-factor authentication (2FA) – admin guide

Conduct and Content Standards

Miro apps and integrations overview

User permissions for boards embedded in third-party apps

Which platforms: Browser

Audit logs allow organization admins with relevant privileges to track user activity in their Miro organization. Logs are extremely useful when investigating a problem or getting a detailed report of important events (for example, changes to the global security settings, invitations of new users, or new boards created).

✏️ Currently, the events are logged from the moment of the Enterprise subscription creation and are stored for 180 days by default:

a) If you upgrade to Enterprise from a different plan, the events will be logged from the moment of the upgrade.

b) If you migrate some teams to the Enterprise subscription, their data will be logged only when they become a part of the subscription.

Accessing audit logs

To access audit logs, do the following:

Go to Company Settings.

On the left panel, click Security > Audit logs.

You can filter the audit logs by choosing a Date range, one or more Actors (including apps and AI agents acting on behalf of a user), one or more Event categories, one or more specific Events, and one or more Affected objects.

Click the View events button to preview the events matching your filtering criteria. Time is displayed in ISO 8601 format, in the local time zone. You can see details of a particular event by clicking on three dots in the Details column.

✏️ You can preview events as far back as your organization's audit log retention period reaches (up to 365 days).

Export audit logs

You can export logs in a CSV file format.

In the CSV Export file, the event date and time are provided in ISO 8601 format, UTC time zone. There is no limit on the number of records to be exported at a time; however, the more data you export, the longer it takes to prepare the file to download. Also, be mindful that popular applications for working with tables have their limits to the volume of data they can open. The exported file reflects any filters you've applied, including Affected object.

To export logs, click the Export to CSV button.

The bar with your export file details will appear below. When the file is ready to download, you can click the Download CSV button. The file will be available for download for 24 hours.

✏️ Currently, only one export file is available for download per organization at a time. Clicking the Export to CSV button will replace the current export file.

Access audit logs via API

Admins can use the Audit Log API or supported SIEM Integrations to programmatically access and collect audit log data.

The API supports the same filters as the UI: Actor, Event category, Event, and Affected object, each accepting multiple values. You can retrieve your organization's complete audit log history via the API.

Audit Logs API v1 retirement

Audit Logs API v1 has been retired. If you have a custom integration built on v1 (GET /v1/audit/logs), migrate it to v2 (GET /v2/audit/logs). Authentication and the time-window parameters are unchanged, but pagination, response format, and some field names differ, see the API reference for details. If you use a Miro-provided app or marketplace connector (for example, the Miro app for Splunk or Microsoft Sentinel), update it to the latest version, which already supports v2.

Notable changes in the v2 response:

Pagination is cursor-based (an opaque cursor value) instead of offset-based; there's no total record count.

createdBy.id is returned as a string (previously a number).

Each event includes a top-level category field.

Event IDs are UUID strings (previously a numeric suffix); treat them as opaque values.

createdAt reflects when the event was stored rather than exactly when the action occurred (typically a lag of a few seconds).

details fields use camelCase (e.g. organizationId), large numeric values are serialized as strings, timestamps use ISO 8601, and keys with null values are omitted.

For actions performed by an app, integration, or AI agent on behalf of a user, the actor object includes an onBehalfOf field identifying that user.

The actor name for signed-out visitors is now "Visitor" (previously "Guest").

Board-related events reference the board's public boardKey instead of an internal numeric ID.

Event types and categories that referenced "project" now use "space" (for example, project_created is now space_created); this applies retroactively to historical events retrieved via v2.

Deleting audit logs

Admins can set a retention policy for audit logs. You can choose between 30, 90, 180, or 365 days.

⚠️ Once audit logs are deleted, they can't be recovered.

✏️ Indefinite retention for audit logs has been deprecated.

To set a deletion period, do the following:

Under Audit logs, click the Settings tab.

Choose an option from the drop-down list. You will be asked to confirm your choice.

Events in Audit logs

The audit logs include records about the following categories of events:

Change Company name

Change, remove Company logo

Created access request

Declined access request

Enable, disable user activity metrics in Analytics

Enable, disable or change SSO/SAML settings

Enable, disable SCIM

Generate token for SCIM API

Enable, disable SCIM notifications

Enable, disable, change allowlist

Enable, disable sharing with guests outside of allowed domains

Enable, disable sharing via public link

Create, delete, restore a board

Change board description

Change board cover

Add a board to a space, remove from a space, move to another space

Change a Board owner

Share a board with a Viewer/Commenter/Editor

⚠️ Login events will include the activity of Deactivated users.

Use Miro AI feature

Frequently asked questions

Is there a way to automatically pull Audit Logs?

Yes, you can configure the Miro app for Splunk to access Miro logs from Splunk.