Overview
Once single sign-on (SSO) is active for your organization, you decide who uses it by placing people in a user group with the SSO requirement enabled. Members of an SSO user group are provisioned through your identity provider and must sign in with SSO — their Mobaro password sign-in is switched off. Everyone outside these groups is unaffected, so you can roll SSO out to part of your organization, or enforce it for specific teams, without a support ticket for each change.
Users must be Super Users or an administrator of the user group to manage its membership and settings.
Why this matters: SSO at the identity layer is usually all-or-nothing. Controlling it through user groups lets you stage a rollout, require SSO for staff who should never hold a password, and keep contractors or seasonal users on standard login — all managed in Mobaro, on your schedule.
Before you begin
Organization-level SSO must already be configured and active. That's a one-time setup handled with Mobaro support — see Setting up single sign-on (SSO) with Microsoft Entra ID. The user-group control below only takes effect once your organization's SSO is live.
Requiring SSO for a user group
1. Open or create a user group
In the Backend, go to where you manage User Groups and create a new group or open an existing one. See Managing user groups as an administrator.
2. Add the users who should use SSO
Add each User who should be provisioned through your identity provider and sign in with SSO.
3. Enable the SSO requirement
Turn on Require SSO for the group and save. From now on, members are governed by SSO as described below.
Critical: Enabling Require SSO disables password sign-in for everyone in the group. Before you enable it, confirm SSO is working and that each member exists in — and is assigned to Mobaro in — your identity provider. Otherwise you can lock users out. If organization-level SSO isn't active yet, set that up first.
What the requirement does
Area | What happens |
Registration | Members are provisioned through your identity provider when they first sign in with SSO. This is how you control who can be registered via SSO — only people you place in an SSO user group. |
Sign-in | Members must sign in with SSO. Password sign-in — including the |
Everyone else | Users who aren't in an SSO user group are unaffected and continue to sign in as before. |
Best practice: Start with a small pilot group, confirm those users can sign in with SSO, then expand. Keep an emergency route in mind — a Super User who is not in an SSO-required group can still sign in with a password to make changes if something goes wrong.
Frequently asked questions
Q: What happens to a member's existing password?
A: While they're in an SSO-required group, password sign-in is disabled — they sign in through your identity provider instead. The password isn't used.
Q: Can I require SSO for only part of my organization?
A: Yes — that's the point. Only members of SSO user groups are affected; everyone else keeps their current sign-in.
Q: A user is in the group but can't sign in with SSO. What should I check?
A: Confirm organization SSO is active, that the user is assigned to Mobaro in your identity provider (Microsoft Entra ID), and that their Mobaro email matches the identity provider. See How do I troubleshoot login issues or disabled accounts in Mobaro?
Q: How do I remove the SSO requirement for someone?
A: Remove them from the SSO user group, or disable Require SSO on the group. They can then use standard sign-in again.
Q: Does this create new users automatically?
A: Yes — members are provisioned through your identity provider on first SSO sign-in.
Q: How do I turn SSO on for my organization in the first place?
A: Organization-level SSO is activated with Mobaro support. See Setting up single sign-on (SSO) with Microsoft Entra ID.