Single Sign-On

Everything that decides who can sign in to your organization lives on one page: user menu → Organization Settings → Sign-In Policy. This page explains what each section does and, just as importantly, what it does not do.

Single Sign-On requires The Growth plan or higher.

The three sections

1. Allowed Providers

The list of sign-in methods your people are offered. It always contains at least one entry. Out of the box that entry is Email / Password.

Once you have connected your own identity provider and it is Active, it appears here as a fourth option alongside Email / Password, Google, GitHub and Microsoft.

Whatever you select here is exactly what your people are offered when they sign in through your organization’s sign-in link. Select only your own provider and nobody sees a password field.

Two things to know:

• Choosing among Email / Password, Google, GitHub and Microsoft is available on every plan. Adding your own identity provider requires The Growth plan or higher.
• Removing Email / Password asks you to confirm. Read that dialog — it is the one change on this page that can lock people out.

2. Single Sign-On

Where you connect your company’s identity provider. AutoCISO supports:

A new connection starts as Pending. Use Test connection to move it to Active. A pending connection deliberately does not appear in Allowed Providers — you cannot select a provider nobody has proven can sign in yet.

After saving, the section shows the values to paste into your identity provider (Redirect URI, or ACS URL and Entity ID for SAML). Copy them from here rather than typing them.

Automatic account creation (also called just-in-time provisioning) is off by default. Turn it on and anyone your identity provider authenticates gets an AutoCISO account on first sign-in, at the role you choose. That role can be Member, Contributor or Auditor — never Owner or Manager (what each role can do). With it off, people still need an invitation from User Management.

Your client secret is sent to your identity provider’s configuration and is never stored by AutoCISO. When you edit a connection, leaving the secret blank keeps the existing one. SAML metadata works differently: because AutoCISO keeps no copy, an edit to a SAML connection requires pasting the metadata XML again.

3. Email domains

An optional restriction. Leave it empty and anyone your identity provider authenticates can sign in.

Add domains and the restriction applies to everyone signing in to your organization, not only to people arriving through your identity provider. Someone whose address is outside the list cannot sign in at all.

Because of that, AutoCISO refuses a domain list that would exclude you or any other active Owner. If you need to add a domain list that does not cover an Owner’s address, change that person’s address first.

Email domains never route anyone to a provider — they only narrow who is accepted. Your sign-in link is what routes people.

Your organization’s sign-in link

Also on this page: a copyable link of the form https://app.autociso.io/console/login/your-org.

Share it with your team or put it on your intranet. It sends people straight to your identity provider, skipping the provider chooser. If your organization has no active connection, the link quietly shows the ordinary sign-in page.

If you lock yourself out

Two ways back, in order of preference:

1. Restore email & password sign-in. When Email / Password is not in your Allowed Providers, a button of that name appears on the Sign-In Policy page. It is available on every plan, including an expired trial, and it can only add password sign-in back — it never changes anything else. Any Owner can use it, as long as they can still sign in.
2. Contact support. If nobody can sign in at all, AutoCISO support can restore your providers for you. This is the path for “our identity provider is down and password sign-in was switched off”.

The first option is why we recommend keeping at least one Owner able to sign in by password while you are setting up a new connection.

If activating or saving a connection fails

When Test connection or Save on an active connection shows “sign-in could not be prepared in the identity provider; try again, and contact support if it keeps failing” (error code SSO_CLAIMS_ACTION_FAILED), AutoCISO could not finish preparing your organization’s sign-in in the identity service. Nothing about your sign-in has changed:

• A new connection stays Pending, so nobody is sent to it yet.
• An active connection stays Active, and your edits are saved. Saving again retries the step that failed.

Try again after a minute. If it keeps failing, contact support and mention the error code. The cause is logged on our side, and the message deliberately does not show it.

What this does not do

Deliberately out of scope today, so you can plan around it:

• No SCIM. Accounts are not created or deactivated from your directory in the background. Automatic account creation happens at sign-in; removing someone from your directory stops them signing in, but does not remove their AutoCISO membership. Remove them in User Management, and open a leaver case if they left the company.
• No group-to-role mapping. Automatic account creation uses one role for everyone. Change individual roles in AutoCISO afterwards.
• No email-domain routing. Typing a work address on the generic sign-in page does not send anyone to your identity provider. Use your sign-in link.
• One connection per organization.
• SP-initiated SAML only. Starting from a tile in your identity provider is not supported; people must start at AutoCISO.

Email verification with corporate SSO

Corporate Microsoft Entra ID, Okta, OIDC and SAML connections trust the email address supplied by the identity provider configured for your organization. Users do not need a separate email verification code after successful corporate SSO. Your identity-provider administrators control the accounts and email addresses allowed to sign in, including any guests. Google sign-in uses Google’s email verification result. Multifactor authentication requirements still apply.