Hi,
I’m happy to share that Two-Factor Authentication (2FA) is currently in active development and is planned for release in early 2026. (We will, of course, do our best to deliver it sooner if possible!)
I would like to share the major implementation concepts:
- Who is this for?
2FA will apply to native Sisense users only - those created in Sisense Admin and who log in with a Sisense username and password.
Active Directory (AD) or Single Sign-On (SSO) users will be excluded. This is intentional, as their authentication (including any MFA) is configured and managed by their external identity provider. - Where will it be available?
2FA will be available for both cloud and on-prem deployments, as long as an email server is configured for your instance. - What is the second factor?
The second factor will be a secure, one-time code sent to the user’s email.
Support for other methods (such as authenticator apps or SMS) is not planned at the moment. - How will I control the rollout?
This was a key part of your feedback. To ensure a smooth rollout and flexible control, we are implementing two levels of management:- System-Level Toggle: The master switch that enables or disables 2FA across your entire deployment.
- User-Level Configuration: Determines whether 2FA is required for an individual user.
Admins will be able to manage individual user configurations through a “Require Two-Factor Authentication” control in the Users list (GUI) or via the API.
The default value will be ON, allowing easy and secure enablement for the majority of users while still providing flexibility for exceptions (e.g., system, integration, or QA accounts).
- joeshepper11-12-2025Cloud Apps
Hi Oleksandr,
Thanks for your update on this feature.
Firstly, I’m pleased to hear our feedback has been taken on board and this has been put into active development. I have two points to raise off the back of this:
Firstly, my opinion is using email as a second factor (and having this as the only option) is a half-baked approach to 2FA. There is a flaw with this approach, in that if a user’s email is compromised, the attacker can both reset the account password AND receive a 2FA token to the email. This ‘single weak point’ goes against the spirit of 2FA in my view. Granted, this is more secure than not having 2FA at all, but has this weakness been considered by the team? (https://www.identityserver.com/articles/the-dangers-of-considering-email-as-two-factor-authentication)
Secondly, I appreciate it’s early days but it would be good to understand more about the mechanics of the rollout – specifically with the ‘default on’ approach. I am in a bit of an unusual position in that we have several thousand users of our platform and the majority will not want to use 2FA. Will I be able to control the rollout of this so that users receive no communications / prompts to use 2FA unless I decide to turn it on? (I don’t want the update landing, users being asked to use 2FA, and then me later turning it off). In other words, will I be able to configure this before it ‘goes live’ and starts affecting users?
Thanks again for the update on this - Joseph