How to choose · Identity and access
How to choose a single sign-on and identity provider
Last updated 25 October 2026 · 1 source listed · Reading time about 3 minutes
Short answer
Choose an identity provider by checking which of your applications support standard federation, how provisioning and deprovisioning work, what authentication methods and policies are available, and how the provider behaves when it fails. The directory you already run, the number of unsupported legacy apps, and your admin capacity shape the best fit more than feature lists do.
Who this is for: An IT manager at a growing company who wants to centralise logins, enforce multi-factor authentication and automate account setup and removal.
What to evaluate
Application coverage
Single sign-on only helps for apps that can connect to it, and unsupported apps remain password islands.
How to check: Inventory your applications and confirm each supports a standard federation protocol or has a maintained connector.
Provisioning and deprovisioning
Automatic account creation and removal is where much of the security value sits.
How to check: Test that disabling a user in the provider removes access in connected apps, including those using separate local accounts.
Authentication policy engine
You need conditions such as device state, location or risk to shape when stronger checks apply.
How to check: Build a sample policy during the trial and review how exceptions and break-glass accounts are handled.
Resilience and recovery
If the provider is down, everyone loses access to everything.
How to check: Ask about availability design, status history, and how emergency admin access works offline.
Directory integration
Existing directories and HR systems often act as the source of truth.
How to check: Verify synchronisation direction, attribute mapping and how conflicts are resolved.
Logging and reporting
Authentication events are essential for investigations and audits.
How to check: Confirm log detail, retention and export to your monitoring tools.
Comparison
| Type | Good when | Watch out for |
|---|---|---|
| Cloud-native identity service | Most apps are cloud-based and you want low maintenance | Vendor dependence and licensing tiers for key features |
| Identity bundled with productivity suite | You already standardise on that suite | Coverage of non-suite apps may need extra configuration |
| Self-hosted or open-source option | You need control or customisation and have engineering capacity | Operational burden, upgrades and resilience are yours |
| Directory federation for legacy estate | On-premises systems dominate | Aging protocols and limited modern policy features |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 6 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Application coverage | |||
| Provisioning and deprovisioning | |||
| Authentication policy engine | |||
| Resilience and recovery | |||
| Directory integration | |||
| Logging and reporting | |||
| Total (max 18) | 0 | 0 | 0 |
Questions to ask before you commit
- Which of our applications are supported natively and which need custom work?
- Does automated deprovisioning cover every connected app we use?
- Which authentication methods are included, and which are premium add-ons?
- How do you protect against administrator account compromise?
- What is the emergency access plan if your service is unavailable?
- How are logs exported and for how long are they kept?
- Can we leave with our user data and configuration?
Typical trade-offs
Single provider for everything versus mixing providers
- Upside
- One policy and one place to audit.
- Downside
- The provider becomes a critical dependency and target.
Strict conditional access versus convenience
- Upside
- Reduces account takeover risk.
- Downside
- Can frustrate users and generate support requests if poorly tuned.
Rapid rollout to all apps versus phased by risk
- Upside
- Quickly closes password sprawl.
- Downside
- Phasing is slower but allows lessons and pilot feedback.
Common mistakes
- Forgetting a break-glass account; create protected emergency accounts excluded from risky policies and monitor their use.
- Leaving local app passwords active after enabling single sign-on; disable them where the app allows.
- Rolling out without communicating; brief users and train the help desk first.
- Granting broad admin roles; use least privilege and separate admin accounts.
Related questions
Do small companies need a dedicated identity provider?
Often the identity service included with an existing productivity suite is enough at first, especially if most applications are cloud-based. A separate provider becomes attractive when you have many applications outside that suite, need richer lifecycle automation, or must apply consistent policies across several directories. Start by measuring where passwords and manual account work still exist.
What is the difference between authentication and provisioning?
Authentication proves who a user is at login, typically through the identity provider. Provisioning creates, updates and removes the accounts and permissions inside each application. Both matter: strong login does little if departed employees retain active accounts in connected tools. Look for standards such as SCIM-style provisioning and test removal end to end. Whatever you decide, write the reasoning down, name who is accountable for the follow-up, and revisit the choice after a realistic trial period so that early assumptions are tested against what actually happens in practice.
How long does a rollout take?
It depends on application count and complexity more than the provider. Core cloud apps can often be connected quickly, while legacy systems, custom internal tools and apps requiring vendor involvement stretch the schedule. Plan in waves, beginning with high-risk and high-usage applications, and keep a living inventory so shadow applications are discovered and added. Whatever you decide, write the reasoning down, name who is accountable for the follow-up, and revisit the choice after a realistic trial period so that early assumptions are tested against what actually happens in practice.
What happens if the provider has an outage?
Users may be unable to sign in to any connected application. Mitigate with documented emergency procedures, protected break-glass administrator accounts, cached sessions where policy allows, and clear communication plans. Ask vendors for availability history and design details, and test your emergency process occasionally so it works when needed. Whatever you decide, write the reasoning down, name who is accountable for the follow-up, and revisit the choice after a realistic trial period so that early assumptions are tested against what actually happens in practice.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- Digital Identity Guidelines — NIST, retrieved 27 October 2026
Related guides
Comparison · Identity and access
Passkeys, authenticator apps, hardware keys and text message codes compared
Methods differ mainly in how resistant they are to phishing and in how easy they are to deploy and recover. Passkeys and hardware security keys bind sign-in to the genuine site and resist phishing. Authenticator app codes are a solid, widely supported middle option. Text message codes are better than a password alone but are exposed to interception and number takeover, so reserve them as a fallback.
Suitability · Identity and access
Does your organisation need privileged access management
Privileged access management becomes worthwhile when powerful accounts are numerous, shared, long-lived or poorly audited. It vaults credentials, issues time-limited access, and records sessions. Smaller environments may achieve much of the benefit with separate admin accounts, strong authentication and just-in-time role activation built into existing platforms before buying a dedicated product.
Problems & fixes · Identity and access
Why former employees keep access and how to close the gaps
Orphaned access usually survives because accounts are created outside central identity, ownership is unclear, and offboarding depends on manual steps across many tools. Fix it with a single authoritative trigger from HR, central sign-in for as many apps as possible, regular access reviews, and a reconciled list of accounts that bypass single sign-on, such as shared logins, API keys and personal-email registrations.
How to choose · Network security
How to choose a business firewall
Choose a firewall by matching throughput under your real security features, management model and update commitments to your environment. Inspect how much traffic it can handle with inspection enabled, what remote access it supports, how policy is managed and logged, and how long the maker supplies security updates. Support lifetime and management effort matter more than the feature list.
How to choose · Cloud security
How to choose cloud security posture and workload protection tooling
Choose cloud posture tooling by how well it prioritises findings, how it reaches your accounts without excessive permissions, and how it hands work to engineers. Check multi-cloud coverage, identity analysis, infrastructure-as-code scanning and exception handling. A tool that lists thousands of unranked issues creates fatigue; context about reachability and privilege is what makes findings actionable.
Comparison · B2B software
Single-suite ERP versus a best-of-breed application stack
A single-suite ERP offers one data model, one vendor relationship and consistent reporting, but individual modules may be shallower. A best-of-breed stack gives deeper functions in each area at the price of integration work, divided accountability and reconciliation effort. The right balance depends on how unusual your processes are in the areas that create competitive advantage and how much integration capability you can sustain.
How to choose · Managed IT providers
How to choose a managed IT provider
Choose a managed IT provider by testing how they run service, not how they describe it. Look for a documented onboarding process, clear scope and exclusions, security practices applied to their own systems, named responsibilities for patching and backups, and references from clients similar to you. Contract terms on exit, data ownership and administrative access matter as much as response times.