Deploying Claude in your organization means deciding who gets in, but more importantly, how they get out. Single sign-on is the setting that turns a collection of personal accounts into enterprise access you actually control.
The real problem isn't onboarding, it's offboarding
In most organizations, Claude doesn't arrive through a decision: it arrives through a person. Someone creates an account with their work address, finds it useful, mentions it to colleagues. Three months later, a dozen people use it every day, each with their own account, their own password, and their own work history.
As long as everyone stays, it holds together. The day someone leaves, the question becomes uncomfortable: is their access actually cut off? You can disable their Microsoft 365 account in thirty seconds, but you have no control over a Claude account they created themselves, using your domain address as a simple identifier and a password you've never seen.
Single sign-on fixes exactly that, and it does so by moving the question somewhere else. Your people no longer have a Claude password at all: they click "sign in," your identity provider (Microsoft Entra ID, Okta, Google Workspace) authenticates them, and they're in with the same rules and the same multi-factor authentication as every other tool you use. When you then disable their account with that provider, the Claude door closes along with the others, no parallel steps, no checkbox missed at the bottom of an offboarding list. It's the same action, in the same place, and that's exactly what an audit will ask you to demonstrate.
There's a second dimension, less visible but just as foundational. Anthropic lets you verify your domain through a DNS record, then restrict organization creation: no one can open a Claude or Console organization using an address on your domain. That setting is what stops the proliferation of parallel accounts opened under your name, without your knowledge. Automatic provisioning works in the other direction: a new employee who signs in for the first time gets access without a ticket and without waiting, so onboarding follows hiring instead of lagging behind it.
What SSO doesn't do
Better to be clear about this, because the confusion is common and it's costly.
SSO answers the question "who gets into Claude." It doesn't answer "what Claude can see in your data", that's the role of connectors, their permissions, and your document governance. The two questions are distinct and are solved separately. If the second one is what's on your mind right now, we've covered it in detail in Claude's Microsoft 365 Connector: The Administrator's Guide and in Claude and Microsoft 365: The User's Guide. Those two pieces explain how Claude gets into your data; this one explains how your people get into Claude. You need both.
SSO also doesn't replace a usage policy, training, or the classification of what can and cannot be submitted to an AI tool. It's an access control: a good one, a necessary one, but only one.
What's documented, and what's our take
Anthropic documents domain verification via TXT DNS record, the "Require SSO for Claude" and "Require SSO for Console" settings (which are indeed two separate settings), organization creation restrictions, which also cover personal accounts, and JIT provisioning, which creates the user on first sign-in. There is also a procedure for claiming and migrating accounts already present on your domain, with specific conditions attached.
Everything else is our read, based on migrations we've carried out.
Enable the organization creation restriction from the start, before you roll Claude out broadly. It's the least dramatic setting of the bunch and the most consequential: a personal account opened under your domain before that door is closed becomes, under certain plans, an account you can no longer reclaim. You can't recover what you didn't prevent.
And don't treat SSO as an isolated IT project. It's a leadership decision, because it touches offboarding, audits, ownership of work history, and your ability to answer a simple question: who has access to what, and since when?
In practice, the order of steps matters more than their difficulty. Here's the sequence we follow.
- Take inventory of the Claude accounts that already exist under your domain. The answer is almost always higher than expected.
- Verify your domain with Anthropic, then restrict organization creation.
- Connect your identity provider and make sure you can actually sign in through that door before requiring SSO.
- Plan the migration of existing accounts: they don't move on their own, and some content doesn't carry over.
That last step deserves its own piece, because that's where the costly pitfalls are. We've written it: Migrating Your Claude Accounts to SSO Without Losing Anything.
If you're deploying Claude in your organization and want to validate your sequence of steps before touching any settings, reach out. We've been through it.
Sources cited
- Anthropic, Set up single sign-on (SSO), support.claude.com/en/articles/13132885-set-up-single-sign-on-sso (updated September 17, 2026)
- Anthropic, Important considerations before enabling single sign-on (SSO) and JIT/SCIM provisioning, support.claude.com/en/articles/10276682 (updated August 11, 2026)
- Anthropic, Claim and migrate accounts on your domain, support.claude.com/en/articles/14625619 (updated September 3, 2026)
- Anthropic, Set up JIT or SCIM provisioning, support.claude.com/en/articles/13133195 (updated September 17, 2026)
- Anthropic, Identity management (SSO, JIT, SCIM), support.claude.com/en/collections/17270717 (updated September 18, 2026)
Sequencing and ordering recommendations come from migrations carried out by our team and are identified as such in the text.