The identity provider and SSO buyer's guide

what an IdP and SSO actually are

An identity provider is the authoritative source of your identities and the broker that authenticates them. When someone signs in, the IdP checks they are who they claim to be and then vouches for them to the apps they are trying to reach. Single sign-on is the mechanism that lets that one authentication open many applications.

The reason this matters beyond convenience is that the IdP is the natural place to enforce everything else. Require MFA once, at the IdP, and it covers every app behind it. Disable someone at the IdP and, if your apps are properly connected, their access everywhere collapses at once. Set a conditional rule, like blocking logins from an unmanaged device, and it applies across the board. The IdP is where access becomes governable, which is exactly why an app sitting outside it is an app outside your control.

where buyers go wrong

The first and most common mistake is underusing the IdP you already own. The identity provider bundled with your productivity suite almost certainly includes MFA, conditional access, lifecycle features, and more, much of it switched off. A lot of companies go shopping for capabilities they already pay for and have never turned on.

The second is leaving apps outside single sign-on. Every app a team adopted with its own email and password is a separate login the IdP cannot protect, cannot apply MFA to, and cannot switch off when someone leaves. A company can have a beautifully configured IdP and still be wide open, because half its real applications never got connected. Coverage, not configuration, is usually the bigger gap.

The third is running several directories and never consolidating. Companies that grew by acquisition, or that bolted a cloud directory onto an old on-premises one, often run two or three identity systems at once. Every one of them is a place to provision, deprovision, and audit, and the seams between them are where accounts get orphaned.

The fourth is choosing on price or familiarity rather than fit, especially the fit with your actual application estate. An IdP is only as good as its ability to connect to the specific apps you run. The fifth, quieter mistake is forgetting that the IdP is now a single point of failure: if it goes down or is compromised, everything behind it is affected, which makes resilience and the security of the IdP itself a first-order concern.

before you shop: map what you have

Start by finding your directories. You may have more than you think: an Entra tenant that came with Microsoft 365, a Google Workspace directory, an on-premises Active Directory that predates the cloud, an Okta tenant that arrived with an acquisition. Knowing how many identity systems you are actually running, and which is authoritative for whom, is the first thing to establish.

Then look at your single sign-on coverage. Which applications are behind the IdP, and which are not. The ones that are not are your real exposure, and there are usually more of them than expected. This is also where you will meet the SSO tax: some SaaS vendors put single sign-on behind their most expensive tier, which tempts companies to leave apps out of SSO to save money, at a direct cost to security.

Then characterize your workforce and your apps. Are your people all employees at desks, or do you have contractors, frontline staff without company devices, and partners who need access? Are your apps modern SaaS that speak standard protocols, or a mix that includes on-premises and custom systems? And separately, do you need to authenticate external customers into a product you run, which is a different problem called customer identity. Then take stock of your scale, because a ten-person company on a single cloud suite and a multinational with several inherited directories are not making the same decision.

the category in plain terms

Underneath the marketing, the IdP world comes down to a few patterns and a few protocols.

the protocols, briefly

You will meet these acronyms, and they matter because they determine what connects to what. SAML and OIDC (built on OAuth) are the two standards apps use to accept single sign-on from your IdP; most modern SaaS supports one or both. SCIM is the standard for provisioning, the thing that lets the IdP automatically create and remove user accounts in connected apps, which is what turns offboarding from a manual checklist into an automatic action. LDAP and Active Directory are the older, on-premises directory technologies many companies still run. An IdP's support for these, and the quality of its specific app integrations, is what determines whether it can actually govern your estate.

the three patterns

The productivity-suite IdP. If you run Microsoft 365 you have Entra; if you run Google Workspace you have its identity platform. For a large share of companies, especially smaller and cloud-first ones, this is the right answer, because it is capable, already there, and already paid for. The work is to use it fully and get every app behind it, not to replace it.

The dedicated, independent IdP. A standalone identity platform that sits across everything regardless of which clouds and suites you run. This earns its place when you have a genuinely mixed estate, a lot of SaaS, multiple clouds, partners and B2B access, or several directories you want to unify under one neutral layer. Its strength is that it is not tied to one productivity vendor, which matters most when you are not either.

On-premises and hybrid. Many established companies still run Active Directory on-premises and federate it to the cloud. This is a real and valid pattern, especially with legacy and on-premises apps, but the direction of travel is toward cloud identity, and a hybrid setup is usually a stage rather than a destination.

what the IdP increasingly includes

The line between "IdP" and "the rest of identity" keeps blurring, because modern IdPs bundle in capabilities that used to be separate purchases: multi-factor authentication, conditional access, some lifecycle and governance features, and increasingly identity threat detection. This is good news, because it often means the thing you need is a feature of what you own rather than a new product.

a note on customer identity

If part of your question is how to let external customers sign in to a product you operate, that is customer identity and access management, a related but distinct category with different priorities (scale, sign-up experience, consent). Do not try to solve it with the same workforce IdP decision; flag it as its own problem.

what's right for your size and situation

• Lean / small (under ~50) · What good looks like: Use the IdP in your productivity suite. Standardize on one directory, get every SaaS app behind its SSO, and turn on the MFA and conditional access it already includes. · What to skip: Buying a separate dedicated IdP. You almost certainly do not need one yet.
• Growing mid-market (50 to 500) · What good looks like: The same, unless you have a mixed multi-cloud estate, a large SaaS footprint, or B2B access, in which case a dedicated IdP starts to earn its place. Consolidate any extra directories. Turn on SCIM provisioning so joiners and leavers are automatic. · What to skip: Running multiple directories indefinitely because no one owns the consolidation.
• Larger / multi-entity (500 to 2000) · What good looks like: A dedicated IdP is often justified, especially across multiple clouds or after acquisitions. Hybrid AD where legacy demands it, with a plan to reduce it. Lifecycle and governance features in active use. · What to skip: Leaving inherited directories federated forever instead of consolidating.
• Enterprise / regulated (2000+, finance) · What good looks like: A resilient identity core with governance, threat detection, failover, and the access evidence regulators expect, treated as critical infrastructure. · What to skip: An IdP architecture with no answer for what happens when the IdP itself is unavailable.

Some situations change the shape regardless of size. Multi-cloud and vendor-neutral needs point to a dedicated independent IdP, and that neutrality is the main thing you are buying. Growth by acquisition makes the IdP decision a consolidation project, where an independent layer over several inherited systems can be the way to do it. B2B SaaS companies probably need both a workforce IdP for staff and customer identity for users, kept separate. Heavy on-premises or legacy estates should weight an IdP's ability to handle them through federation, because a cloud-only tool may leave the hardest apps stranded. Frontline and deskless workforces bring shared devices, no company phone, and intermittent connectivity, so make sure the IdP can authenticate the people you actually employ.

sourcing: four ways to get there

Use the IdP in your productivity suite. For most small and mid-market companies this is the right first move and frequently the right final one. Standardize on it, cover your apps, turn on the features you already pay for. Exhaust this before buying anything.

Adopt a dedicated independent IdP. Justified by a mixed estate, multi-cloud, heavy SaaS, B2B access, or a consolidation need across several directories. The independence is the point, so buy it when independence is what your situation calls for.

Run hybrid. Keep on-premises identity federated to the cloud where legacy genuinely requires it, ideally as a managed transition rather than a permanent state.

Bring in help. Identity consolidation and IdP migration are among the higher-risk projects in IT, because everything authenticates against this thing and a botched migration locks people out of everything at once. A co-managed approach or an advisor-led migration, through an MSSP or VAR, is worth it when you are consolidating directories, migrating between IdPs, or do not have the identity expertise in-house to do it safely.

the decision criteria that actually matter

• App coverage · What to look for: Solid, tested integrations and SSO for the specific applications you actually run, including the awkward and legacy ones. This is the make-or-break, and it is specific to your estate.
• Protocol support · What to look for: SAML, OIDC, and especially SCIM for automated provisioning and deprovisioning, plus whatever your legacy apps need.
• Lifecycle and provisioning · What to look for: Can it create and remove access automatically as people join, move, and leave, or does that stay manual?
• MFA and conditional access · What to look for: Does it include strong, ideally phishing-resistant authentication and policy you can control, so you do not need a separate product?
• Multi-cloud neutrality · What to look for: If you need it, does it sit cleanly across clouds and suites rather than favoring one vendor's world?
• Migration and lock-in · What to look for: How hard is it to get in, and how hard would it be to get out later? Identity is sticky, so understand the exit before the entrance.
• Resilience · What to look for: What happens when the IdP is down or attacked? Uptime, failover, and the security of the IdP itself are first-order.
• Governance and evidence · What to look for: Can it produce the access reporting and lifecycle controls a regulator or auditor expects?
• Data residency and EU · What to look for: Where do your identities and authentication data live?
• Cost, including the SSO tax · What to look for: The IdP's own pricing, plus what SSO costs you across your SaaS apps, since that shapes whether you can realistically get everything behind it.

If you take one row, take app coverage. An IdP that cannot cleanly govern the specific applications your company runs is an IdP that will leave gaps no amount of configuration closes.

how it's priced, and the real cost

IdP and SSO are usually priced per user per month, with the more useful capabilities, advanced conditional access, lifecycle automation, governance, sitting in higher tiers. When the IdP comes with your productivity suite, a lot of this is bundled into licensing you already hold, which is the first reason to inventory what you own.

The license is rarely the real cost. Budget for migration, which dominates year one and is the expensive, risky part of moving between IdPs or consolidating directories. Budget for app integration, especially legacy and custom apps. Budget for the SSO tax, what your SaaS vendors charge to enable single sign-on, which determines how much of your estate you can actually bring under the IdP. And budget for the tier you actually need, since the features that make the IdP a security control often sit in the upper tiers. Think in total cost over a couple of years including migration and the SSO tax.

how to run the evaluation

Shortlist deliberately, and include the option of standardizing on and fully configuring the IdP you already have, because for many companies that is the real competitor to any purchase. Send questions that probe fit rather than features: tested integrations for your specific apps, how SCIM provisioning works at offboarding, what a migration actually involves, the uptime record and failover story, where identities live, and how legacy apps are handled.

Then run a proof of concept against your real estate. Connect your top few applications, including a tricky one, over SSO and SCIM. Run a real joiner and a real leaver through it and confirm access actually appears and disappears across those apps. Test a conditional access rule. Set the success criteria up front, and make automated deprovisioning one of them, because that is where the security value concentrates. Then take references, focused on migration: how long it took, what broke, and what they would do differently.

the traps the demo won't show

The signature failure is the half-connected IdP: configured carefully, but with a long tail of apps still outside it, each one a login the IdP cannot protect or revoke. Right behind it is the SSO tax quietly winning, with teams leaving apps out of single sign-on to dodge a vendor's pricing, which fragments exactly the control you were building.

Then there is the multiple-directories problem that never gets resolved, so accounts keep slipping through the seams between systems. There is the IdP you underuse, paying for capabilities you never switch on while shopping for them elsewhere. There is migration pain and lock-in, discovered too late, because identity is the stickiest thing in your stack. And there is the resilience blind spot: no plan for the day the IdP itself is down or compromised. The major identity-provider breaches of recent years made the point that the IdP is itself a top-tier target, and its own security and availability are part of what you are choosing.

where this meets the rules

The IdP is how you actually deliver several things the regulations require. NIS2's Article 21 expects access control and multi-factor authentication, and the IdP is where both are enforced. DORA expects financial entities to control identity and access, including least privilege and timely removal of access, which in practice means lifecycle and provisioning at the IdP. Auditors and insurers increasingly want evidence of access control and offboarding, and a well-run IdP with proper provisioning is the cleanest place to produce it. The deprovisioning point is sharp: a large majority of people retain access to at least one former-employer system after leaving (Beyond Identity, 2022, self-reported), and automated deprovisioning at the IdP is the control that closes that gap.

a sequenced path

Identity rewards consolidating first and elaborating later.

Crawl: pick one primary IdP and standardize on it, consolidating stray directories where you can. Get every SaaS app you can behind its single sign-on. Turn on the MFA and conditional access it already includes. This alone makes your access governable in a way a scattered estate never is.

Walk: turn on SCIM provisioning so joiners, movers, and leavers flow automatically into and out of your connected apps, which is where the deprovisioning risk gets solved. Hunt down and connect the apps still outside SSO, dealing with the SSO tax deliberately rather than letting it push apps out. Bring basic governance and access reviews into use.

Run: move toward passwordless at the IdP, add identity threat detection, automate the full lifecycle, extend to multi-cloud entitlements, and build in resilience and failover so the single point of failure has a backstop. At this point the IdP is the working control plane for all of your access, which is what it was always meant to be.

The most common situation is a company that never consciously chose an IdP at all and uses a fraction of what it has. So the honest first move is usually to see your current identity estate clearly, standardize on one IdP, get your apps behind it, and turn on what you already own, before deciding whether you need something more.