The real SSO tax

We’re preparing for our upcoming SOC 2 audit here at Oblique. And it’s maddening to realize that it’s 2025, and you still can’t reasonably ensure that your employees are using strong authentication.

What your security team really wants is to understand what applications your employees have access to, and enforce that they use strong authentication to access those applications. That’s why SSO exists in the first place! Since we use Google as our IdP and Apple Business Manager as our MDM, our ideal setup would be: use (and enforce) Google SSO everywhere we can — which can prompt for multi factor authentication — and use a passkey bound to the company-managed device where we can’t.

That sounds reasonable, but it's not what happens in reality.

Where apps do support SSO, you often can't enforce that it's being used. And where they don't support SSO, you often can't ensure strong auth. This gap is the real frustration. The SSO tax shouldn't be about having SSO — it should be about enforcing it. Why did I just spend 15 minutes configuring SAML SSO for our HRIS, if a user can still log in with a username and password? Why did I set up an authenticator app for this login if the app is just going to email me a magic link anyway? We recently had an automated compliance check fail because a user only used a passkey — which doesn’t count as MFA. What is this security theater where we constantly weaken security?

I don't want to pay to have SSO. But I’m willing to pay to enforce the use of SSO.

I understand where this comes from. Password resets and account recovery are huge pains for consumer apps, wasting support teams' time. For both consumer and enterprise apps, you usually want the user to be able to log back in (otherwise, how are you going to hit your growth targets?). In an organization, account recovery also wastes your IT team's time. But the usability of SSO means this shouldn't be a problem, unless a user locks themselves out of their main account. In which case, yes, your IT team really should talk to them before resetting anything.

If you're building an enterprise application, please support SSO — and only SSO — so that it's easy for your customers' IT teams to enforce it (because it's the only option) and rely on MFA controls in their identity provider. You can skip building:

• MFA that only supports an authenticator app, not a hardware token or TouchID
• MFA that only supports SMS or email-based codes
• Strong MFA support that allows downgrading to weaker options
• Strong MFA support that isn't required
• Username/password login that requires MFA, but doesn't support passkeys

Not only is this complicated to build and maintain, it's actively unhelpful for your customers' security posture.

There's one notable exception: enterprise apps that require employees to use a personal email for continuity, so they can still access the account after leaving the company — like payroll providers or equity management tools. In those cases, please do provide (and require) strong MFA — and only strong MFA. This is exactly the kind of data that most needs to be protected.

These identity frustrations aren't exciting. But they're real, and they're exactly the kind of problems we're working on at Oblique.