Domains and Enforcement

Single sign-on is on the Enterprise plan. Only administrators can change these settings in Settings → Single sign-on.

Verify a domain

Only people with an email on a verified domain can sign in with SSO. You prove that a domain is yours with a DNS TXT record. Add each email domain your team uses, for example acme.com and acme.co.uk.

Enter the domain and click Add domain

Enter only the domain, such as acme.com, without https:// or @.

Add the TXT record to your DNS

Hyperstack shows the record to add. Copy the Name and the Value:

Type	Name	Value
TXT	`_hyperstack.acme.com`	`hyperstack-domain-verification=<your token>`

Add the record where you manage your domain’s DNS, such as Cloudflare, GoDaddy, Route 53 or your IT team’s DNS. The record goes on _hyperstack.acme.com, not on acme.com itself.

A domain with the Waiting status and the TXT record box with Name, Value and Check now

Click Check now

When Hyperstack finds the record, the domain shows Verified. DNS changes can take up to 48 hours. If the record is not found yet, you see We didn’t find the record. Check the name and value, then try again. We also check every day, so a waiting domain turns Verified by itself when the record appears.

The domain list with acme.co.uk and acme.com Verified, each with its verified date

Keep the TXT record in your DNS after the domain is verified. Hyperstack checks the record again every day. If the record is missing, every administrator gets an email, and the page shows when SSO stops for that domain. If we don’t find the record for 7 days after we last found it, the domain is no longer verified: SSO stops for it and every administrator gets a second email. Add the record again, then click Check now.

Domain status

Status	What it means
Waiting	Hyperstack hasn’t found the TXT record yet, or the record was missing for 7 days. SSO doesn’t work for this domain.
Verified	The record was found. People on this domain can sign in with SSO.
Check failed	The record is missing. SSO still works until the date on the row: We last found the record on … SSO stops for this domain on … if it stays missing. After Check now on a waiting domain, it also means the record wasn’t found.

To check again, show the record, or remove a domain, click the menu at the end of its row: Check now, Show DNS record or Remove. When you remove a domain, people with that email domain can’t sign in with SSO any more. Members keep their accounts.

If a domain is refused

Message	What to do
Enter a domain such as acme.com, without https:// or @.	Enter only the domain.
You can’t use a personal email domain such as gmail.com. Add your company’s domain.	Personal mail domains, such as gmail.com or outlook.com, can’t use SSO.
Another organization uses this domain. Contact support if it belongs to you.	A domain belongs to one organization only. Contact support. We don’t tell you which organization has it.
You already added this domain.	Nothing to do.
You can add up to 20 domains.	Remove a domain you don’t use.
We couldn’t reach the domain’s DNS. Try again in a few minutes.	Try again later.

Turn on SSO

Turn on SSO works when a test sign-in passed and at least one domain is verified. Until then, the page says Pass a test sign-in first. or Verify an email domain first. When SSO is on, your team can sign in with SSO. Passwords, Google and passkeys keep working.

Enforce SSO

When you enforce SSO, members can open your organization only after an SSO sign-in. Use it when your IT team must control who gets in.

Before you enforce

The Enforce SSO section shows what is missing. You need:

SSO turned on.
A test sign-in that passed in the last 7 days. Pass a test sign-in first. A test counts for 7 days.
At least one verified domain.
Two-factor authentication or a passkey on the owner’s account. This is the owner’s way back in if your provider stops working. See Owner emergency access.
If you aren’t the owner: an SSO sign-in of your own in the last 24 hours. The page says Sign in with Okta first, so we know it works for you.

Also check your team:

Members whose email is not on a verified domain lose access. Change their email, or verify their domain, first. The owner keeps emergency access.
Members who never signed in with SSO must be assigned to the app in your provider, or they lose access.

Turn it on

Turn on Require SSO to open Acme

It is in the Enforce SSO section of Settings → Single sign-on.

Read the checks

The Enforce SSO for Acme? dialog shows what passed and who loses access: members outside your verified domains, members who haven’t signed in with SSO yet, and the AI assistant connections (MCP) of other members that are removed.

The Enforce SSO for Acme dialog with the checks, the members who lose access and the emergency access box

If members lose access, tick I understand that 2 members lose access to Acme.

Click Enforce SSO

You see SSO is enforced. Every admin got an email.

What changes for members

To open your organization, members must sign in with SSO. A password, Google or a passkey still opens their wallet and their other organizations.
A member who signs in another way and opens your organization sees Acme requires single sign-on, with a Continue with Okta button (Continue with SSO for other providers). The owner also sees Use owner emergency access.
Every 24 hours, members sign in with SSO again. They see Sign in again to open Acme. This is how a person you turn off in your provider loses access within a day.
On the sign-in page, a member who enters an email on your domain sees Continue with SSO. The password, Google and passkeys are behind Sign in another way.
A member whose only organizations all enforce SSO can’t sign in to the Studio with a password, Google or a passkey. They see Your organization requires single sign-on and Continue with SSO. Their password still opens their wallet.
While SSO is enforced, you can only invite people with an email on your verified domains. Other emails get Acme requires SSO, so only people on acme.com can join.
Settings → Team shows Can’t sign in next to members outside your verified domains, and Emergency access only next to an owner outside them.
AI assistant connections (MCP) of members, except the owner, are removed. Members connect them again after an SSO sign-in.
API keys, webhooks and integrations keep working.

Globex Learning requires single sign-on, with Continue with Okta and Use owner emergency access

Stop enforcing

Turn off Require SSO to open Acme. The dialog Stop enforcing SSO? asks you to confirm. Click Stop enforcing. Members can open your organization with a password, Google or a passkey again at once. Every administrator gets an email.

Turn off SSO or delete the connection

The Turn off or delete section has two buttons:

Turn off SSO: members can’t sign in with your provider any more. Your settings stay, and Turn on SSO brings SSO back. Turning off SSO also stops enforcement. People without a password can set one with Forgot password or sign in with Google. Every administrator gets an email.
Delete connection: removes the connection and its settings, and unlinks people from your provider. People keep their accounts and roles. Your domains stay verified.

Both buttons ask you to confirm first.

Change the connection

Click Edit connection. A change applies at once and asks for a new test sign-in. Until a new test passes, the page shows Test needed. To see our values again, click Show the values for your provider. Some values decide whom Hyperstack trusts: the metadata URL, the sign-in URL, the issuer, the signing certificate, the issuer URL, the client ID and the client secret. When SSO is on and you change one of them, SSO turns off:

The sheet warns you first: Saving this change turns SSO off for Acme until a new test sign-in passes and you turn it on again. Every member’s SSO link is reset. The button reads Save and turn off SSO.
Enforcement also stops. Passwords open your organization again.
Every member links their account again on their next SSO sign-in.
The owner and every administrator get an email.

Edit the Okta connection with a new metadata URL, the warning and the Save and turn off SSO button

After the change, run Test sign-in, click Turn on SSO, and enforce SSO again if you used it.

Certificate notices

For SAML, Hyperstack shows a notice on Settings → Single sign-on from 30 days before your provider’s certificate ends. Every administrator also gets an email 30, 7 and 1 days before.

A notice: Okta's certificate expires on Nov 26, 2026, with the Update certificate button

With a metadata URL: make the new certificate active in your provider before the date. Hyperstack reads the metadata URL once a day and adds the new certificate next to the old one, so both work until the old one ends. After your provider makes a new certificate active, click Refresh certificates in the Connection section. Hyperstack reads the metadata URL at once and adds the new certificate. SSO stays on, and members don’t need to link again. The audit logs show the new certificate.
Without a metadata URL: click Update certificate and add the new certificate before the date. A new certificate is a change of a trusted value, so SSO turns off until a new test passes. See Change the connection. Plan the change with the person who manages your provider.

When the certificate ends, you see SSO sign-in stopped and members can’t sign in with SSO. The owner can still use emergency access.

Troubleshooting

Members see these messages on the sign-in page when an SSO sign-in doesn’t go through.

Message	Why	What to do
Your organization requires single sign-on	The person signed in with a password, Google or a passkey, and every organization they belong to enforces SSO.	Click Continue with SSO. Their password still opens their wallet.
Sign in with your password first	The person is the owner or an administrator, and their account isn’t linked to your provider yet. They can link it only while signed in.	Sign in with the password. Then run Test sign-in in Settings → Single sign-on, or sign in with SSO again in the same browser.
You don’t have access yet	The person isn’t on your team and has no invitation.	Invite them in Settings → Team. Then they sign in again.
This email can’t sign in with SSO	Your provider sent an email that isn’t on one of your verified domains.	Verify that domain, or change the person’s email in your provider.
SSO doesn’t work for your email domain right now	The domain was added but isn’t verified, or its TXT record is missing.	Add the TXT record and click Check now.
Your company’s sign-in page sent no email	Your provider didn’t send an email, sent one that isn’t valid, or sent one it says is not verified.	Send the email to Hyperstack. See your provider’s guide.
Another account already uses this email	The Hyperstack account with this email is linked to another person in your provider. For example, the person was removed and added again in your provider.	Check the person’s email in your provider. If it is right, the old link must go: click Delete connection and connect again. This unlinks everyone, and each person links again on their next SSO sign-in.
SSO is turned off for your organization	SSO is off, or the connection was deleted.	Sign in with a password, or turn on SSO.
Your company’s SSO certificate has expired	Every saved certificate of your provider has ended.	Make the new certificate active in your provider. Then click Refresh certificates in Settings → Single sign-on, or add the certificate with Edit connection.
This account can’t sign in	The Hyperstack account is blocked.	Contact support.
SSO isn’t set up completely	The connection is missing a value, or your provider’s settings can’t be read.	Check the connection, save it, and test again.
This way of signing in is turned off	The sign-in started from the provider’s tile and Hyperstack refused it.	Sign in from the Hyperstack sign-in page with your work email.
Too many sign-in attempts	Too many SSO sign-ins came from the same place in 10 minutes.	Wait a few minutes, then try again.
This sign-in took too long	The sign-in took more than 10 minutes, was used already, or came back to a different browser.	Start again, in one browser.
Your company’s sign-in page sent an error	Your provider answered with an error, or its answer failed a check.	Run Test sign-in in Settings → Single sign-on to see the exact reason.
SSO sign-in didn’t go through	Another error.	Try again, then run Test sign-in.

On the Sign in with SSO step:

Message	What to do
Your organization hasn’t set up SSO. Sign in with your password.	The email’s domain has no SSO that is on. Sign in with your password.
Use your work email. Personal email addresses can’t use SSO.	Enter your work email.
Too many tries. Wait a few minutes, then try again.	Wait a few minutes.

Test sign-in shows the exact reason when a test fails. Click Show technical details for the full answer, and send it to the person who manages your provider.

A failed test: Okta sent the wrong Audience URI, with the value to copy and Show technical details

Result	What to do
… sent the wrong Audience URI	Set the entity ID field in your provider to the value the page shows.
… sent the answer to the wrong address	Set the ACS URL or the redirect URI in your provider to the value the page shows.
The signature doesn’t match the certificate we have	With a metadata URL, click Refresh certificates. Without one, add the current certificate with Edit connection.
…‘s certificate expired	Make a new certificate in your provider and make it active. Then click Refresh certificates, or, without a metadata URL, add it with Edit connection.
The time of the answer is wrong	The answer is more than 3 minutes away from our clock. Check the clock of your provider’s server.
… isn’t on a verified domain	Add and verify that domain, or test with a user on a verified domain.
… isn’t verified yet	Add the domain’s TXT record, then click Check now.
No email came back	Send the person’s email to Hyperstack. See your provider’s guide.
You aren’t assigned to the app in …	Assign yourself to the app in your provider.
… isn’t on your team	The connection works. Invite this person in Settings → Team, or test with a team member.
… didn’t accept the client ID or secret	Check both values, and that the secret hasn’t expired.
Another account already uses this email	Check the person’s email in your provider.
The connection isn’t complete	Check the connection, save it, then test again.
… encrypts the assertion	Turn off assertion encryption for the app in your provider. Hyperstack doesn’t read encrypted assertions yet.
… didn’t sign the answer or The signature doesn’t cover the answer	Sign the assertion or the whole response with SHA-256 in your provider.
… sent another issuer	Save the connection again with the current metadata URL or file.
This answer was already used	Start the test again from the page.
Too many sign-in attempts	Wait a few minutes, then test again.
The test took too long or The test didn’t finish	Close the other tab and start the test again from the same browser.
Your browser blocked the new tab	Allow pop-ups for the Studio, then try again.

Locked out

If your provider stops working while SSO is enforced, the owner uses emergency access and fixes the connection, or stops enforcing. If the owner can’t sign in either, contact Hyperstack support from the owner’s email. We check who is asking before we stop enforcing SSO. If your plan no longer includes SSO, you can still stop enforcing or turn SSO off. See What happens to SSO if we leave the Enterprise plan? See What Hyperstack support can and can’t do.

Welcome

Getting Started

Credential Setup

Branding

Advanced Setup

Single Sign-On

For Recipients

Miscellaneous

Miscellaneous

FAQs