What I Didn’t Know About MFA—And Why You Don't Need SSO for Compliance

What I Didn’t Know About MFA

I was talking to my cofounder recently and said, “Not every company has an Israeli CTO who can argue with auditors about what a compliance requirement really means.” I was joking, but it captures a real problem: auditors often push for “SSO” as a blanket requirement, but that’s not always what’s actually needed for compliance.

Acronym Soup: Understanding MFA, SSO, and SAML

Many customers I talk to say, “We need to do SSO for compliance.” That always catches me off guard, because most companies already have something like “Login with Google” or “Login with Microsoft” in place. Isn’t that enough? It turns out the confusion comes from how these terms are used – often incorrectly. Let’s break it down:

• MFA (Multi-Factor Authentication): A requirement for many compliance standards (e.g., SOC 2, HIPAA, GDPR) that applies to business-critical applications. The key word here is business-critical – not every app needs MFA for compliance.
  
  
• SSO (Single Sign-On): An experience where users authenticate once and gain access to multiple applications without needing to re-enter credentials. This idea took off when SaaS apps exploded, and employees got tired of juggling dozens of passwords.
  
  
• SAML (Security Assertion Markup Language): An older, XML-based authentication protocol that allows identity providers (IdPs) like Okta, Ping, or Microsoft to handle login for apps. This is often required when using traditional enterprise apps.
  
  
• OIDC (OpenID Connect): A newer, JSON-based protocol built on OAuth 2.0, widely used by modern apps like Google Workspace, Microsoft, and most SaaS platforms. It’s faster, more flexible, and supports better user experiences.
  
  

The Real Compliance Requirement: MFA for Business-Critical Apps

Here’s the critical point: The compliance requirement is MFA for business-critical apps, not necessarily SSO. There are several ways to implement this:

Option 1: Use Login with Google or Microsoft (Widely Available, Easiest to Implement, Cheapest to Support)

• If the SaaS app supports “Login with Google” or “Login with Microsoft” and you have MFA turned on in those platforms, you’re covered. This approach is the easiest, most cost-effective, and often the quickest to pass an audit, since the identity provider (Google or Microsoft) handles the MFA.
  
  

Option 2: Use App-Specific MFA (Limited Availability, Easiest to Implement, Cheap to Support)

• Some apps, like HubSpot or GitHub, have built-in MFA options. This works similarly to consumer apps – you log in with a username, password, and a second factor like a code or app notification. It’s straightforward but relies on each app having solid MFA support.
  
  

Option 3: Use SAML with an IDP (Widely Available, Harder to Implement, Higher Ongoing Cost)

• If the app supports SAML ($$ Alert: probably involves you upgrading your app license tier), you can connect it to an IDP like Okta ($$), Ping ($$), or even the free IDPs provided by Google Workspace or Microsoft. This typically involves more upfront setup and ongoing maintenance, including configuring MFA within the IDP and managing complex trust relationships.
  
  

My Practical Advice for Getting MFA Right for Compliance Requirements

When I advise companies on MFA, my priority list looks like this:

1. Start with Option 1. It’s simple, quick, and effective for most modern SaaS apps.
   
   
2. Move to Option 2 for apps that don’t support federated login but have solid built-in MFA.
   
   
3. Consider Option 3 only when you need centralized control over identity and access across a large portfolio of apps, or when an auditor specifically calls for SAML.
   
   

You don’t need to over-engineer this. Start with the easiest, most broadly supported methods, and build from there. Most employees are used to different MFA methods from their personal apps and won’t be as thrown off by inconsistency as you might fear.

In short: Don’t let auditors or compliance checklists push you into expensive, over-complicated solutions. Prioritize what’s critical, and don’t be afraid to push back when it makes sense.

‍