Which identity providers work?

Any SAML 2.0 identity provider, including Okta, Microsoft Entra ID (Azure AD), Google Workspace, OneLogin and JumpCloud. The IdP must send each user's email address as the email attribute.

Which plan includes SSO?

Business. Role-based access control is included on every plan with team seats; SSO and the audit log are Business features.

Why do I have to add a DNS record?

To prove you own the email domain. Without it, anyone could claim a company's domain and capture the sign-in of its employees. Only domains you have verified route to your identity provider.

What role does someone get the first time they sign in with SSO?

The default role you choose on the Security & SSO page (Viewer unless you change it). Change anyone's role afterwards under Settings, Team.

Can I require everyone to use SSO?

Yes. With 'Require SSO' on, members can only sign in through your identity provider; email links and social logins stop working for them. The account owner is exempt, so a misconfigured identity provider can never lock you out of your own account.

Do you support SCIM provisioning?

Not yet. Users are provisioned just-in-time the first time they sign in with SSO; removing someone is done under Settings, Team (and by removing them in your identity provider so they can no longer sign in).

What happens if I downgrade from Business?

The SSO requirement stops being enforced (so members are not locked into something you can no longer edit) and new SSO sign-ins are refused. Existing members keep their access and can use their normal sign-in method.

How do I set up single sign-on (SAML) with Cognocient?

Sign in to Cognocient with Okta, Microsoft Entra ID, Google Workspace or any SAML 2.0 identity provider: DNS-verified domains, just-in-time provisioning, and an optional require-SSO policy. Business plan.

Single sign-on lets your team use the identity provider you already run (Okta, Microsoft Entra ID, Google Workspace, or any SAML 2.0 IdP) instead of separate Cognocient passwords, and lets you require it for everyone. It is available on the Business plan and is configured by an Owner or Admin under Security & SSO in the sidebar (Settings → Security).

How it works

You register Cognocient as a SAML application in your IdP.
You paste the IdP's metadata URL into Cognocient and add your email domains.
You prove you own each domain with a DNS TXT record.
Anyone who types a work email on the sign-in page and clicks Continue with SSO is sent to your IdP, and lands in your organization with the role you chose.

Set it up

1. Create the SAML application in your IdP

On the Security & SSO page, the Give your IdP admin panel shows the values to enter:

Setting in your IdP	Value
ACS / Reply URL	shown on the page
Entity ID / Audience	shown on the page
Name ID format	Email address
Attribute	send the user's email as `email`

Then copy the application's SAML metadata URL.

2. Add the metadata URL and your domains

Paste the metadata URL, add each email domain (for example company.com), choose the default role for people signing in for the first time, and save.

Self-serve identity provider setup

If the page says self-serve setup isn't enabled on this deployment yet, you can still add and verify your domains here. Contact support and we will attach your identity provider.

3. Verify each domain

For every domain, Cognocient shows a DNS record like this:

Type	Name	Value
TXT	`_cognocient-verify.company.com`	`cognocient-verify=<token>`

Add it at your DNS provider, wait a few minutes for it to propagate, and click Verify. Only verified domains route to your identity provider, and each domain can belong to one organization only. Public email providers such as gmail.com or outlook.com can never be claimed.

4. Test, then require it

Sign in with SSO in a private window and confirm you land in the right organization. Then turn on Require SSO for all team members if you want it enforced.

The owner is always exempt

When you require SSO, the account Owner can still sign in the normal way. That is deliberate break-glass access: a misconfigured or unreachable identity provider must never be able to lock you out of your own account.

Provisioning and roles

Users are created just-in-time the first time they sign in with SSO. Three things must all be true before Cognocient adds them to your organization:

the session really came from your identity provider,
that provider belongs to your organization, and
the user's email domain is one you have verified.

That is what stops any identity provider from creating members in someone else's account. New members get your default role (or keep the role of an existing invite for the same email), and count against your plan's seat limit.

Requiring SSO

With Require SSO on, a member who signs in another way is refused with 403 and "code": "sso_required", and the sign-in page explains why. Turning the setting off, removing SSO, or downgrading from Business lifts the requirement.

Limits

SCIM provisioning is not available yet; provisioning is just-in-time.
One identity provider per organization.
Removing someone from your IdP stops them signing in with SSO, but their existing Cognocient session remains valid until it expires. To cut access immediately, remove them under Settings, Team.