In certain organizations, it is desired or required that access to Falcon is possible exclusively via Single Sign-On (SSO). Falcon provides appropriate control options for this directly within the platform.
Control within Falcon
Within Falcon, you can specify that login is only permitted via SSO—meaning traditional logins with username and password are no longer allowed. When this setting is enabled, invited users can authenticate exclusively via SSO. In total, there are three different modes (see the Help Center for details):
Optional: SSO is voluntary; providers can be assigned or detached at any time → maximum flexibility, ideal for testing.
Individual (recommended): The provider is defined when inviting users; users cannot reset it themselves; IT admins can manage exceptions → a good balance between control and flexibility.
Mandatory: SSO is enforced for all users, with no exceptions or fallback option → higher risk, only advisable with a stable provider configuration.
Just-in-Time Provisioning (JIT)
JIT in the context of SSO (Single Sign-On) stands for “Just in Time” and refers to a method in which user accounts for applications are automatically created or updated when a user logs in to the application via SSO for the first time. This means IT administrators do not need to manually create user accounts in each application; instead, they are dynamically created when a user attempts to log in.
Falcon supports JIT.
The prerequisite is that the user does not already exist in Falcon and has not yet been invited or activated. This scenario assumes that the original invitation flow is followed.
⚠️ Note: Pay attention to permissions!
If JIT is enabled, it is recommended to configure programs as protected. Otherwise—if program access is public—users will see all public content after logging in.
Interaction between Falcon and the IdP
Using Falcon’s user management, users can be invited and it can be ensured that only SSO is used (see above).
However, Falcon does not allow you to define who may receive and accept an invitation. This can often be configured on the side of the selected Identity Provider (IdP).
👉 The setting in Falcon does not influence who may log in—only how.
👉 The Identity Provider determines who is allowed to access Falcon via SSO.
Responsibility Overview
Setting | Configuration Location | What is controlled? |
Who is allowed to log in via SSO? | In the IdP | Access control via groups, policies, etc. |
How users may log in (e.g. with/without SSO) | In Falcon | Allows or blocks classic login |
Control via the Identity Provider (IdP)
Examples: Microsoft Entra, Google Identity, Okta
The IdP is the central authority that manages who is allowed to log in to Falcon via SSO at all. Configuration takes place outside of Falcon, in the administration interface of the respective IdP.
Common restriction options include:
Assigning the Falcon application only to specific groups or users
Configuring security policies (e.g. only devices with a corporate certificate)
Blocking external accounts
Enabling multi-factor authentication (MFA)
👉 Important: Only users who are authorized for Falcon in the IdP can log in via SSO at all—regardless of Falcon’s internal settings.