Single sign-on and sign-in policy
Every client signs in on the same Risk Core sign-in page, reached through its own domain. By default that means a password and a 6-digit authenticator code. A client can instead use Microsoft or Google single sign-on, so the second step follows its own identity provider.
Who this page is for: client IT and the administrator. What users see when they sign in is in Signing in.
The sign-in policy
Section titled “The sign-in policy”| Setting | Default | Set by |
|---|---|---|
| Second factor | 6-digit authenticator code (TOTP) for every account | fixed; with SSO on, the client’s identity provider |
| Remember this device | 30 days | per client |
| Sign-out during an incident | none while a BCP incident is open | fixed |
| Single sign-on | off | per client: Microsoft or Google |
Set up single sign-on
Section titled “Set up single sign-on”- Agree it with Qirin X. SSO is set up per client on the platform; tell Qirin X which provider — Microsoft or Google — and which e-mail domains your staff use.
- Register Risk Core with your identity provider. Qirin X gives you the values your provider asks for; you return the values Risk Core needs from your side.
- Test with one account that is in the staff register.
- Switch SSO on. From then on, staff sign in with their company account. The sign-in page sends them to your identity provider and back.
When SSO is on
Section titled “When SSO is on”- The second step follows your identity provider. MFA is whatever your provider requires; Risk Core does not ask for its own code.
- The staff register still decides who gets in. A company account signs in only if its e-mail is an active person in the staff register. Deactivating a person in Risk Core ends their access, whatever their status at the provider.
- Roles still come from Risk Core. The provider proves who the person is; the roles panel decides what they may do.
- Remember this device still follows the number of days your company sets.
- A lost phone is handled by your identity provider, not by an authenticator reset in Risk Core.
Without SSO
Section titled “Without SSO”Staff set their own password from the e-mail invitation and enrol an authenticator app. A lost phone is handled by an authenticator reset.
What the system does or refuses
Section titled “What the system does or refuses”- No forced re-sign-in while an incident is open, with or without SSO, so nobody is locked out while the plan is running.
- A sign-in from an account not in the staff register is refused.
- Changes to the sign-in policy are recorded in the audit log.