VT currently supports SSO authentication with the following services:

• Google
• GitHub
• Microsoft

This means, if you have an account in any of those services, you can use it at VT too!

Create a new VT account using SSO

When creating a new VT account, you can either create it in the traditional way by entering all your personal information or you can do it using SSO with any of the aforementioned services.

When choosing any SSO option, you’ll be asked to introduce a username to associate with your account:

After clicking on “Create account”, you’ll have a fully operational VT account. No need to confirm your email address or make any additional steps.

Login to an existing account using SSO

If you already have a VT account whose email address is also associated with an account at any of our supported SSO providers, you can login with that provider at VT too.

When logging in using SSO, if Two-Factor Authentication (2FA) is enforced for your group or enabled on your account, you will be prompted to complete two-factor verification immediately after authenticating with your identity provider. If 2FA is not required or configured, you will be redirected directly to VirusTotal’s main page.

Two-Factor Authentication (2FA) with SSO

Two-Factor Authentication (2FA) works seamlessly with Single Sign-On (SSO), providing an additional layer of security for organization accounts in VirusTotal.

Group-level 2FA enforcement

When a group administrator enables Two-Factor Authentication enforcement in the group's security settings, 2FA is mandatory for all group members.

This requirement applies universally, including to users who authenticate through an SSO Identity Provider (IdP) via SAML, OIDC, or integrated social providers (Google, GitHub, Microsoft). Individual users cannot bypass or disable 2FA when it is enforced at the group level.

SSO login flow with 2FA

When 2FA enforcement is active, the sign-in workflow proceeds as follows:

1. SSO Authentication: The user initiates sign-in via their configured corporate Identity Provider (SAML/OIDC) or supported SSO provider (Google, GitHub, Microsoft).
2. Policy Validation: After successful authentication at the IdP, the platform validates the organization's group security policies and 2FA enforcement requirements.
3. 2FA Setup (First-time / New Users): If the user has not yet configured 2FA on their account, they are immediately prompted to set up their two-factor authentication method before they can proceed.
4. 2FA Verification: If 2FA is already configured, the user is prompted to enter the 6-digit verification code generated by their authenticator app (TOTP) or provide one of their single-use backup codes.
5. Access Granted: Upon successful 2FA verification, the user is redirected to the VirusTotal dashboard.

Offline backup codes

To ensure continuous access in the event that an authentication device is unavailable, lost, or offline:

• Users can generate up to 30 single-use backup codes.
• Each backup code can be used once to verify identity during the login process.
• If a user loses access to their authenticator device and has exhausted their backup codes, a group administrator can perform a 2FA reset to allow re-enrollment.

Group SSO settings

In the group settings page, a group administrator can choose among a set of already configured SSO identity providers: google.com, github.com and microsoft.com.

When any of these 3 providers is enabled for the group, all group users will be forced to authenticate exclusively through that provider. If no specific provider is enabled, users have the flexibility to sign in using either basic authentication (username and password) or SSO method if their account is linked to any of the listed services.

SAML

Clients with different identity providers can enable SAML for SSO by selecting that option in the drop-down menu and filling out the required details in the displayed form to complete the setup.

Please note that for forcing users to only authenticate via SAML, a checkbox is provided. If this checkbox is not selected, users can use both methods of authentication: SAML and common credentials.

We have articles with examples of how to configure SAML with Okta, configure SAML with Ping or configure SAML with EntraID

Please note that you must manually update rotated certificates in the SAML settings on the platform.

OIDC

Clients with other identity providers that prefer OIDC for SSO, can select that option in the drop-down menu and fill out the required data in the displayed form to complete the setup.

Again note that for forcing users to only authenticate via OIDC, a checkbox is provided. If this checkbox is not selected, users can use both methods of authentication: OIDC and common user/password credentials.

SCIM integration

After completing your SAML or OIDC setup, you can enable a SCIM (System for Cross-domain Identity Management) webhook to automate user deprovisioning. This integration ensures that when a user is deactivated in your Identity Provider (IdP), they are automatically removed from your Google TI group.

Once a user is deactivated, a 7-day grace period begins. Group administrators will receive an email notification regarding the pending removal and can contact the support team to cancel the action if necessary. If no action is taken, the user will be removed after 7 days, and their associated assets including graphs, collections, Livehunt rules, etc, will be automatically reassigned to a randomly selected administrator of the group.

At the bottom of the Single Sign-On section you can find SCIM Webhook URL and SCIM Secret Token automatically generated once your SSO configuration is finalized.

Note that the SCIM Secret Token is provided in the following format: Bearer <token>.

Configure these details in your IdP using this Okta example as a reference.

Currently, we only support SCIM-based deprovisioning, so you only need to enable the Deactivate Users feature in your application settings.

🚧

SCIM Secret Token Regeneration

Administrators can regenerate the SCIM Secret Token at any time. However, generating a new key immediately invalidates the previous one. To avoid service disruption, ensure the new token is updated in your Identity Provider (IdP) immediately, and pause all provisioning activity in your IdP until the update is complete.