by Quick answer: Yes, you need both. Single sign-on (SSO) lets people use one login for many applications. Multi-factor authentication (MFA) requires extra proof of identity beyond a password. SSO improves convenience and control; MFA improves security. Together they are stronger than either one alone.
What SSO does
With SSO, employees sign in once to an identity provider and then reach all connected apps without entering separate passwords. Behind the scenes, the identity provider vouches for the user to each application.
The benefits are fewer passwords to forget or reuse, faster access, and one central place to grant or remove access. When someone leaves, disabling one account cuts them off from everything connected.
What MFA does
MFA asks for two or more kinds of proof: something you know (a password), something you have (a phone or hardware key) and something you are (a fingerprint). Even if a password is phished or leaked, the attacker still lacks the second factor.
For a deeper look, see our guide: What Is MFA? Multi-Factor Authentication Explained.
They solve different problems
| SSO | MFA | |
|---|---|---|
| Main goal | Simplify and centralise access | Prove the user is who they claim to be |
| Reduces | Password fatigue and reuse, access sprawl | Account takeover from stolen passwords |
| Weakness alone | One stolen password opens every app | Many separate logins to manage |
| Admin benefit | Central onboarding and offboarding | Strong authentication at each login |
Why SSO without MFA is risky
SSO concentrates access. If the single password is stolen and there is no MFA, the attacker gets into everything the user can reach. That is why SSO sign-in should always require MFA.
Why MFA without SSO is painful
You can enable MFA app by app, but staff end up managing many logins and prompts, IT manages many separate user lists, and offboarding becomes a checklist of manual steps that someone will eventually miss.
How to set it up well
- Choose an identity provider that supports SSO and MFA together.
- Connect your most sensitive apps first: email, file storage, finance and admin consoles.
- Enforce MFA on the SSO login, preferring phishing-resistant methods such as passkeys or hardware keys for administrators.
- Apply conditional access, for example requiring stronger checks from new devices or unusual locations.
- Connect HR or directory processes so leavers lose access automatically.
How SSO works behind the scenes
Single sign-on relies on a trust relationship between an identity provider (IdP), such as Microsoft Entra ID, Okta or Google Workspace, and each application (the service provider). When a user opens an app, it redirects them to the IdP. The IdP authenticates the user, then returns a signed assertion or token that the app accepts as proof of identity. The two common standards are:
- SAML 2.0: widely used for enterprise web apps; the IdP sends an XML assertion.
- OpenID Connect (OIDC): built on OAuth 2.0 and common for modern web and mobile apps; the IdP issues JSON tokens.
Because every sign-in flows through the IdP, it becomes the single place to enforce password policy, MFA, device checks and conditional access. It is also the single most valuable account in your company, which is why protecting it matters so much.
Not all MFA is equal
MFA can stop the vast majority of automated account-takeover attempts, but the method matters. Roughly from weakest to strongest:
| Method | Strength | Notes |
|---|---|---|
| SMS or voice codes | Weak | Vulnerable to SIM swapping and interception; better than nothing |
| Email codes | Weak | Only as secure as the mailbox |
| Authenticator app codes (TOTP) | Moderate | Can still be phished by a fake login page |
| Push approval with number matching | Moderate to good | Resists simple push-fatigue attacks |
| Passkeys and FIDO2 security keys | Strong | Phishing-resistant: bound to the real website |
How attackers get around MFA
- MFA fatigue: bombarding a user with push requests until they approve one.
- Adversary-in-the-middle phishing: a proxy page captures the password and the one-time code in real time, then steals the session.
- SIM swapping: taking over a phone number to receive SMS codes.
- Help-desk social engineering: convincing support staff to reset a factor.
- Session token theft: malware stealing a logged-in browser session.
Defences include number-matching push, phishing-resistant factors for administrators, conditional access that checks device health, short session lifetimes for sensitive apps and strict identity verification for resets.
Which do you need first? A decision guide
| Your situation | Start with | Why |
|---|---|---|
| Under 10 people, a handful of SaaS apps | MFA on email, finance and admin accounts | Biggest risk reduction for least effort |
| 10–100 people, 15+ apps | SSO with MFA enforced at the IdP | Central control and simpler offboarding |
| Regulated data (health, finance) | SSO, MFA and conditional access together | Auditors expect strong authentication and access logging |
| Admins and developers | Phishing-resistant MFA (security keys or passkeys) | Highest-value accounts need the strongest factor |
A 30-60-90 day rollout plan
First 30 days
- Inventory applications and identify which support SAML or OIDC.
- Enable MFA for email, admin consoles and finance tools immediately.
- Choose an identity provider and set up break-glass admin accounts.
Days 31–60
- Connect the top 10 business-critical apps to SSO.
- Enforce MFA at the IdP and block legacy authentication.
- Roll out a company-wide registration campaign with clear instructions.
Days 61–90
- Add conditional access for risky sign-ins and unmanaged devices.
- Issue security keys or passkeys to administrators.
- Automate joiner, mover and leaver provisioning.
- Review remaining apps that sit outside SSO and record exceptions.
Common mistakes to avoid
- Enforcing MFA on the SSO portal but leaving apps reachable with local passwords
- Allowing SMS as the only fallback for everyone
- No tested recovery process when a user loses their phone
- Exempting executives “for convenience”
- Forgetting service accounts and shared mailboxes
- Skipping the “SSO tax”: some vendors charge extra for SSO, so check pricing before committing
What it costs and what to check in licensing
Costs vary by provider, but a few patterns are worth knowing before you commit. Most identity providers charge per user per month, with MFA included in business tiers and advanced conditional access, device posture and privileged features in higher tiers. Some SaaS vendors restrict SAML single sign-on to their most expensive plan, sometimes called the “SSO tax”, so build a list of your critical apps and check which plan each one needs before you promise an SSO-everywhere rollout. Hardware security keys cost a modest amount per person and are usually the best-value upgrade for administrators.
What auditors and insurers expect
SOC 2, ISO 27001, HIPAA and PCI DSS all expect strong authentication and timely removal of access. Cyber insurers increasingly make MFA on email, remote access and privileged accounts a condition of cover. SSO makes this much easier to evidence, because one configuration and one set of logs demonstrate enforcement across many applications. Keep a screenshot of your MFA enforcement policy, your list of applications behind SSO and your exception register for audit time.
Planning for the awkward cases
Real environments always contain a few systems that do not fit neatly into an SSO and MFA rollout, and planning for them early avoids last-minute exceptions that become permanent holes. Legacy applications that only support local usernames and passwords can often be placed behind a reverse proxy or access gateway that handles authentication on their behalf. Shared accounts, such as a social media login used by a marketing team, should be replaced with individual accounts or a password manager that supports shared credentials with MFA-protected access. Service accounts and API keys cannot answer an MFA prompt, so they need other controls: strong, rotated secrets, restricted network access and monitoring.
Another frequent challenge is the user who loses their phone or security key. A recovery process that is too easy becomes the attacker’s route in, while one that is too strict stalls the business. A good approach is to give every user at least two registered methods, issue single-use recovery codes that are stored securely, and require identity verification by a manager or a recorded video call before the help desk resets a factor for a privileged account. Document the process and test it before an emergency.
How to explain the change to staff
Technical rollouts succeed or fail on communication. Tell people why the change is happening in concrete terms: criminals regularly try to guess or steal passwords, and a second step makes that far harder. Give a clear date, short instructions with screenshots and a place to get help. Run drop-in sessions during the first week, and offer simple options such as a number-matching prompt on their phone for people who dislike carrying a separate device. When staff see that the sign-in experience actually improves with SSO, with fewer passwords and fewer prompts, support grows quickly.
Frequently Asked Questions
Does SSO replace MFA?
No. SSO is how people log in; MFA is how the login is verified. They complement each other.
Which should we do first?
If you have neither, turn on MFA for email and admin accounts immediately, then move to SSO as your app count grows.
Will this slow my team down?
Generally the reverse. SSO means fewer logins, and MFA prompts can be limited to higher-risk situations.
Is SSO more secure than separate passwords?
Generally yes, when paired with MFA. It reduces password reuse, centralises policy and makes offboarding faster. The trade-off is that the identity provider becomes a high-value target, so it needs the strongest protection.
What is the most secure type of MFA?
Phishing-resistant methods such as FIDO2 security keys and passkeys, because they cannot be tricked into working on a fake website.
Can we have SSO without MFA?
Technically yes, but it is risky: one stolen password would open every connected app. Always enforce MFA at the SSO login.
Want a single, secure front door?
We design and roll out SSO and MFA for teams of every size. Explore our SSO services →
