You will need a user with administrator rights or the permission: Settings
Single Sign-On (SSO) lets your team sign in to Adversus with their existing Google or Microsoft account instead of, or alongside, an Adversus username and password. This article covers everything you need: connecting a domain, choosing how strict it is, letting each person manage their own connection, and seeing who signs in how.
How to set up an SSO domain
An SSO domain connects one of your company's email domains (e.g., `company.com`) to Google or Microsoft as a sign-in method. Here's how to add one.
Go to Settings in the left menu and choose Security.
Click Add Domain.
Choose the identity provider (Google or Microsoft) and click Continue.
If you are using Google you need to enter the domain, without `https://` or `@`, so for example write `company.com` and then click Continue.
If you are using Microsoft, enter your Microsoft tenant ID (found on your Entra ID portal's Overview page), then click Continue.
If you are using Google, then Adversus generates a DNS TXT record. Copy it and add it at your domain's DNS provider — the same place you manage your MX or SPF records.
If you are using Microsoft, then you will be asked to verify your Microsoft tenant by getting consent from the Microsoft tenant admin. A link is generated that you can send to the Microsoft tenant admin. The admin must log in to verify consent for SSO.
With Google back in Adversus, click Verify domain.
Note: DNS changes can take a few minutes to several hours to take effect. If verification fails right away, wait and try again — and make sure the TXT record was added to the root domain, not a subdomain.
Once verified, you're moved straight into the domain's settings — Sign-in rules and User claims. See the next section for what each one does, then click Update to finish.
Domain settings explained
Every SSO domain has two independent settings. Set them right after verification, and you can change them anytime by editing the domain.
Sign-in rules
Sign-in rules are where you decide whether to
allow, require, or Disable people from logging in with SSO from the domain.
Disabled
If you disable the SSO domain, users can no longer log in with SSO from this domain. Users who normally log in with this domain SSO will instead have to log in with an alternate SSO domain or their normal login credentials (username and password).
Allowed
This lets people sign in either with the provider or their Adversus username and password.
Required
With this setting, every user must log in through SSO with this domain—anyone trying to use a password instead is redirected to a screen asking them to continue with SSO. Switching a domain to Required signs everyone on it out immediately.
User claiming: Allowed / Not allowed
This lets users who are logged in with SSO claim unverified users created with the same email. This makes it easier for a user to set up additional users as needed, as they don't need to receive an invite.
Note: Anyone accepting a normal email invite for a domain with SSO connected always sees both options — set a username and password, or continue with Google/Microsoft — no matter how this setting is configured. Claiming only changes whether SSO works without an invite.
Managing domains after setup
All your connected domains are listed in a table under Settings → Security, showing provider, domain, verification status, login requirement, and user claiming for each one.
Edit reopens the configuration step (or the verification step, if a domain is still unverified).
Remove domain deletes the connection. On a verified domain, you'll be asked to confirm, since anyone currently signed in through it is signed out immediately, and anyone who never set an Adversus password loses access until you reconnect the domain or send them a fresh invite.
Note: A domain can only be added once per workspace — trying to add the same provider + domain pair again returns a "domain already exists" error. Other Adversus workspaces can independently verify and use the same domain; verification isn't shared across workspaces.
Managing your own SSO connection
No special permission needed — every user manages their own login methods from their own profile. We have an article that explains how to manage your login settings: How do I manage my login methods and single sign-on?
The Access column in Users
This section requires either Administrator rights or the Users permission.
The Users table's Username column has been renamed Access. It's hidden by default — enable it from the table's column picker in the top right.
A user with one login method shows it plainly — a username for password login, or a provider icon and email for SSO.
A user with two or more login methods shows a small stacked badge, e.g. "2 login methods". Click it to see the full list in a popup.
A user who was created but never invited or claimed shows No account assigned.
To remove a user's login access without deleting the user, open the row menu and choose Remove access. They lose sign-in access immediately, but keep their history and permissions — send a fresh invite afterward to reassign access to a different email.
For a pending invitation that hasn't been accepted yet, use Revoke invite in the same menu instead.
FAQ
Can two workspaces use the same domain?
Yes. Domain verification is scoped to your own workspace, not shared across Adversus, so another workspace can independently verify and use the same domain.
Does "Required" lock administrators out too?
Yes — enforcement applies to every matching email, including admins. Keep at least one login outside the enforced domain, or make sure every admin has SSO connected, before switching a domain to Required.
What happens to people using SSO if I disable or remove the domain?
Anyone currently signed in through it is signed out immediately. Anyone who never set an Adversus password can't sign back in until you reconnect the domain or send them a fresh invite.
Where does "user claiming" actually get used?
Only for users who exist in Adversus but were never sent an invite — for example, someone created through an API import. Anyone invited normally always gets the SSO option on their invite screen regardless of this setting.