Enforcing SSO Per Organization: Domain Capture, Breakglass, and the Edge Cases

The request arrives in a security questionnaire and sounds simple: "Can you enforce SSO for our organization?"

What it actually means is a cluster of requirements that touch your identity model, your billing, your support process, and several flows you have not thought about. Implementing SAML or OIDC is the easy part — that is a well-trodden integration described in SAML vs OIDC. Enforcement is where the design work is, because enforcement means taking away login methods from users who currently have them.

What the customer is actually asking for

Unpack the request and there are four distinct requirements, usually conflated:

Every member must authenticate through our IdP. No passwords, no social login, no magic links. This is what "enforce" means.

When we deactivate someone, they lose access here too. This is provisioning, not authentication, and SSO alone does not deliver it — a deactivated employee simply cannot log in via SSO, while their account, API keys, and sessions persist. Delivering this properly means SCIM.

Anyone with our email domain who signs up should land in our organization. Domain capture. This is the requirement with the sharpest edges.

We want to see who has access. An audit surface, not an auth feature.

Answering only the first is a common mistake, and it produces a customer who believes they have control they do not have. Be explicit about which of the four you support.

Domain verification, and why it must be strict

Domain capture is the feature where an organization claims @acme.com and every user with that address is routed to their SSO connection. It is genuinely useful and it is an account takeover primitive if you get the verification wrong.

Consider: if any customer could claim @gmail.com, they would capture a large fraction of your user base into an organization they control, with an IdP they control. Even claiming a smaller domain lets the claimant intercept the accounts of everyone at that company.

So verification must be proof of control over the domain, not proof of an email address at it:

A DNS TXT record is the standard. Generate a unique token, have the customer publish it at _yourapp-verification.acme.com, and check it. Only someone with DNS control can do this, which is exactly the right bar.

A file at a well-known HTTPS path is an acceptable alternative — https://acme.com/.well-known/yourapp-verification.txt — though it proves control of the web server rather than the domain, which is very slightly weaker.

An email to a role address like [email protected] is weaker still and should not be your only mechanism.

Three rules beyond the mechanism itself:

Block public email providers, categorically. Maintain a denylist of consumer domains and refuse to let them be claimed at all, regardless of verification. Nobody should be able to claim outlook.com even if they somehow prove control.

Re-verify periodically. Domains change hands. A verification performed three years ago by a company that no longer owns the domain is a stale grant. Re-check quarterly and revoke on failure, with notification well before.

Handle subdomains explicitly. Does claiming acme.com capture eng.acme.com? Both answers are defensible; the failure is not deciding, and then being surprised. Require separate verification per domain and let the customer add as many as they need.

What happens to the users who already exist

This is the migration problem, and it is where enforcement gets genuinely difficult.

When an organization enables enforced SSO, its members already have accounts — with passwords, maybe with passkeys, maybe with Google login. Enforcement means those methods must stop working. Doing it abruptly locks out an entire company on a Monday morning.

A staged rollout that works:

Stage 1 — connection configured, not enforced. SSO works as an additional login method. Members can use it; nothing else changes. This is where you find out that the customer's attribute mapping is wrong, which is a support conversation, not an outage.

Stage 2 — SSO promoted. The login screen leads with "Sign in with Acme SSO" for anyone whose email matches a verified domain. Other methods still work, one click away. Adoption rises without risk.

Stage 3 — enforced for new members. Anyone invited from now on can only use SSO. Existing members are unaffected. This stops the problem growing while you work on the tail.

Stage 4 — enforced for everyone, with a scheduled date, notifications to every member, and an admin dashboard showing who has not yet successfully authenticated via SSO. That last item is what makes the cutover safe: the admin can see the six people who will be locked out and deal with them beforehand.

At cutover, disable the other credentials rather than deleting them. If the SSO connection breaks — an expired certificate, a misconfigured IdP — you want a recoverable state, not a destroyed one. And in the same operation, revoke existing sessions, or enforcement takes effect only when current sessions happen to expire.

The edge cases that generate support tickets

The personal account with a work email. Someone signed up with [email protected] two years ago for their own project, in their own organization. Acme now claims the domain. Does Dana's personal organization get absorbed?

It must not. Domain capture should govern how someone authenticates, not what they own. The workable rule: the domain claim routes authentication through Acme's IdP, and Dana keeps her existing memberships. Acme's admins gain no visibility into her personal organization. Anything more aggressive means a customer can capture data by claiming a domain, which is a serious problem.

The contractor with a Gmail address. Acme enforces SSO and needs to give access to an external consultant who has no account in their IdP. Either the customer adds them to their IdP — often slow or impossible — or you support an explicit per-user exception: a member flagged as exempt from enforcement, visible in the admin UI, logged when set. Exceptions must be a deliberate, auditable act, never a silent fallback.

The user in two organizations, one enforcing. Dana is a member of Acme (SSO enforced) and Globex (not). Enforcement is a property of the organization, not of the user, so Dana authenticates via SSO to access Acme resources and by password for Globex. If your session model has a single global authentication state, this does not work, and you will discover it late. The session needs to record which method authenticated it and which organizations that satisfies — the amr-style claim described in designing JWT claims.

The service account. Integrations and CI jobs cannot complete an interactive SSO flow. They need API keys or client credentials, which by definition bypass SSO. This is correct and it must be visible: enforced-SSO organizations should see every non-SSO credential in their account, with an owner and a last-used timestamp, so "enforced" does not quietly mean "except for these eleven tokens nobody remembers creating."

The IdP outage. The customer's identity provider is down. Every member is locked out of your product, and your support queue fills with a problem you cannot fix. This is why breakglass matters.

Breakglass access

Every enforced-SSO organization needs a way back in when SSO fails, and designing it badly is how enforcement becomes a joke.

A breakglass path should:

• Be limited to a small number of designated administrators, chosen at configuration time.
• Require strong, independent authentication — a passkey or hardware key, never a password alone.
• Be loudly audited: every use recorded, and every organization admin notified immediately.
• Be time-limited: a session that expires in an hour, not a permanent bypass.
• Be testable, so the customer can verify it works before they need it.

The alternative — no breakglass — means an IdP outage or an expired SAML certificate becomes an unrecoverable lockout that only your support team can resolve, manually, under pressure, with no verification process. That is worse for security than a well-designed, audited breakglass path, because the ad-hoc process that emerges will not be audited at all.

Make the trade-off explicit to the customer and let them choose the number of breakglass admins. Some will want zero and should be told what that means.

Implementation notes

Identifier-first login. Ask for the email, look up whether its domain maps to an enforced connection, and route accordingly. This is what makes a mixed population work, and it also avoids showing a password field to someone who cannot use one.

Do not leak the connection's existence to non-members. Whether acme.com has SSO configured with you is information about your customer. An unauthenticated endpoint that reveals it is a small intelligence leak, and enumerable.

Just-in-time provisioning, carefully. Creating a user on first successful assertion is convenient. Decide explicitly what role they get — the answer is the lowest one — and whether an assertion for an unknown user should create an account at all, or require a pending invitation. The latter is safer and some customers require it.

Map attributes defensively. IdPs send attributes under inconsistent names, and the values are customer-controlled. Never let an IdP attribute directly set a privileged role unless the customer explicitly configured that mapping and you validate the value against a known set. An IdP that can send role=owner for any user is an IdP that can escalate anyone.

Monitor certificate expiry. SAML certificates expire, and every member is locked out at once when they do. Alert at 60, 30, and 7 days, to the customer's admins and to your support team.

Key takeaways

• "Enforce SSO" bundles authentication, deprovisioning, domain capture, and audit. Say which you support.
• Domain verification must prove control of the domain — DNS TXT — with public providers permanently blocked and periodic re-verification.
• Roll out in stages, ending with enforced-for-new-members before enforced-for-everyone, and give admins a list of who has not yet authenticated via SSO.
• Disable other credentials, do not delete them, and revoke sessions at cutover.
• Domain capture governs authentication, not ownership. Never absorb a user's personal organization.
• Enforcement is a property of the organization, not the user. Sessions must record which method satisfied which org.
• Surface every non-SSO credential — API keys and service accounts are the real exception, and they must be visible.
• Design audited, time-limited breakglass access, or an IdP outage becomes an unrecoverable lockout handled by an unaudited manual process.

EmbedAuth keeps identity separate from authentication method, so enterprise SSO slots in alongside passwords, OAuth, and passwordless per organization — with enforcement, exceptions, and every credential visible in one place.