Initial Situation
When SSO is introduced at a later stage, the following typically already exist:
active user accounts in Falcon
logins via username and password or social login
possibly external users or test accounts
SSO is therefore not enabled during the initial setup, but activated while the system is already in use.
Step 1: Prepare the Identity Provider
Before SSO is activated in Falcon, the selected Identity Provider must be properly configured (e.g. Microsoft Entra, Google Identity, Okta).
This includes, among other things:
registering Falcon as an application in the IdP
assigning users or groups
configuring security policies such as MFA
Important: The IdP determines who is allowed to log in via SSO. Falcon controls only how users authenticate.
A detailed overview of how to prepare the IdP can be found in the Help Center.
Step 2: Activate SSO in Falcon
Once the IdP has been prepared, SSO can be activated in Falcon. For the initial rollout, it is recommended not to select the mandatory mode right away.
Recommended starting point: “Optional” mode
In Optional mode, authentication remains flexible:
existing users can continue to log in using classic credentials
SSO can be tested in parallel
provider assignments can be changed or reset at any time
This mode is particularly suitable for validating the technical configuration and migrating the first users in a controlled manner.
Step 3: Assign existing users retrospectively
SSO in Falcon is user-based. Existing users must therefore be explicitly assigned to an Identity Provider.
The assignment is performed directly in Falcon’s User Management:
Owners and IT Admins can right-click an existing user to select and assign an Identity Provider. From that point on, the user account is linked to the chosen provider and the next login will take place via SSO.
To do this, open the user overview and select the users you want to assign to an IdP by checking the box on the left. Then use the right-click menu and choose Edit Identity Provider to assign the desired IdP.
This approach enables a gradual migration:
individual users or pilot groups can be migrated first
potential issues with the IdP configuration can be identified early
ongoing operations remain stable
Step 4: Switch to “Individual” mode (recommended)
Once it is clear that:
the IdP configuration is stable
the majority of users are successfully logging in via SSO
Falcon recommends switching to Individual mode.
In this mode:
new users must be assigned to a provider when invited
users can no longer reset their login on their own
IT Admins retain a controlled fallback option for exceptions
IT Admins can grant selected users (e.g. external users) access without SSO
This mode provides the best balance between security, control, and flexibility—especially when enabling SSO retrospectively.
Step 5: Mandatory – only with proven stability
The Mandatory mode enforces SSO for all users without exception. It should only be activated when:
all productive users reliably authenticate via SSO
no external or temporary access is required anymore
the IdP configuration is stable in the long term
⚠️ Warning:
In this mode, even IT Admins must always authenticate via the provider. A misconfiguration can result in a complete lockout. There is no technical fallback without support.
Special Case: Just-in-Time Provisioning (JIT)
Just-in-Time provisioning usually plays a minor role when SSO is enabled retrospectively, as users already exist.
JIT only applies if:
a user does not yet exist in Falcon
no invitation is present
the first login occurs directly via SSO
Note: If JIT is enabled, programs should be configured as protected. Otherwise, newly created users will see all public content after logging in.