Microsoft Entra ID single sign-on

Microsoft Entra ID (formerly Azure Active Directory) can be used to sign your colleagues in to 3rdRisk, so they reach the platform from your corporate identity with one click instead of keeping a separate password. You configure it yourself, and you can test the connection before it applies to anyone.

This article covers the Entra ID side of the setup and the fields that are specific to it. Everything that applies to every provider — how the connection test works, what happens to accounts that do not exist yet, and how to switch single sign-on on — is described in the main article.

Start here for the shared steps: Single sign-on

Overview

You register an application in Microsoft Entra ID, copy three values out of it into 3rdRisk, paste one value back into Entra, and then test. In the SSO Provider list this provider is called Microsoft Entra ID (Azure).

Permissions needed: Configuration settings (read and update). To grant it, navigate to: Left menu: Configuration, then Roles.

Available for: an administrator of both systems. You need an Entra ID role that can create app registrations, and you need to be able to reach Configuration in 3rdRisk.

Note: single sign-on does not create accounts by itself. Either the person already exists in 3rdRisk, or you fill in Default roles so that they are created on their first sign-in, or you provision accounts from Entra ID over SCIM. See Bringing accounts across below.

1. Open the SSO settings in 3rdRisk

• Navigate to: Left menu: Configuration, then General, then the SSO tab.

• Set SSO Provider to Microsoft Entra ID (Azure).

The page then shows the fields Entra ID needs, together with a short summary of the steps below. It also shows a Redirect URI, generated from your platform address — you need it in the next step, and you never have to compose it yourself. Leave this page open.

2. Register the application in Microsoft Entra ID

• Sign in to the Microsoft Entra admin center with an administrator account and open Identity, then Applications, then App registrations, then New registration.

• Enter a name, for example 3rdRisk, choose who can sign in, and select Register.

• On Overview, copy Application (client) ID and Directory (tenant) ID. You need both in step 3.

• Open Authentication, then Add a platform, then Web, paste the Redirect URI from the 3rdRisk SSO page, and select Save.

• Open Certificates & secrets, then New client secret, and copy the secret Value.

Note: the secret Value is shown only once, immediately after you create it. If you navigate away before copying it, delete it and create another — the identifier shown afterwards is not the secret.

3. Enter the details in 3rdRisk

Back on the SSO tab, fill in:

Base URL and Token URL Path are not used by Entra ID. Leave them empty.

Click on Save.

4. Choose how users are identified

Under Identity provider, Username Type decides which value from Entra ID is matched against the account in 3rdRisk:

• Email address — the default, and the right choice for most organisations. The user's e-mail address must match the address on their 3rdRisk account.

• User Principal Name (UPN) — use this when your UPNs are not e-mail addresses, or when you want to match on UPN deliberately.

Note: for guest accounts invited into your directory, Entra ID reports an address containing #EXT#, which is not the person's real address. 3rdRisk detects this and falls back to their mail value, so external contractors invited as guests match correctly on the Email address setting.

5. Require MFA, if you want it enforced here

Under Identity provider, Require MFA on Microsoft Entra ID sign-in refuses a sign-in when the token from Entra ID does not report that multi-factor authentication was used.

This is a check on top of your Entra ID policy, not a replacement for it: Entra decides whether to challenge the user, and this setting decides whether 3rdRisk accepts the result. Switch it on when MFA is mandatory for your organisation and you want a sign-in without it to be refused rather than allowed.

Note: the separate setting Require two-factor authentication for 3rdRisk sign-in applies only while the provider is 3rdRisk. It does nothing once you have selected Entra ID, because MFA is then your provider's responsibility.

6. Test, then enable

Entra ID is the one provider where a successful connection test is required before single sign-on can be switched on, so the switch stays locked until you have run one.

Save first. Until you do, Validate connection tells you so rather than letting you test settings that are not stored:

The Enable SSO switch stays greyed out for the same reason, and names whichever condition is still outstanding:

The test, its three possible results and the order of saving and enabling are described in full here: Single sign-on

Bringing accounts across

Signing in and having an account are two different things, and Entra ID gives you three ways to handle the second:

• The account already exists. Nothing more to do — the person signs in and lands on their existing profile with the roles they already have.

• Default roles are filled in. An unknown user is created on their first sign-in and given those roles. Configured under New users and support on the same tab.

• Accounts are provisioned from Entra ID. Entra creates, updates and deactivates the accounts over SCIM, and group membership drives their roles. This is the option to choose if you want off-boarding handled centrally too.

Learn more about provisioning: Microsoft Entra ID user provisioning (SCIM)

Known limitations

• A connection test never stores the client secret. Save your settings before testing, or the test authenticates and the switch still refuses to unlock because no secret is stored.

• The redirect URI must match exactly. Entra ID compares it character for character, including the scheme and any trailing path, so paste it rather than retyping it.

• Changing the provider does not migrate anyone. Existing accounts keep their e-mail addresses, and matching is done on the value you chose under Username Type.