SSO or native login? Your platform should support both

Every platform we build eventually faces the same question on the security review: "How do users log in?" And the wrong answer — picking a single login model — quietly costs you either enterprise deals or your compliance posture. The right answer is almost always: support both, and apply the right one automatically.

Two buyers, two very different expectations

A 2,000-person enterprise and a 12-person team want opposite things from a login screen.

The enterprise runs an identity provider — Okta, Microsoft Entra ID, Ping, Google Workspace — and their security team will not approve yet another standalone password store. They expect single sign-on, directory-based provisioning (SCIM), enforced multi-factor authentication, and instant offboarding when someone leaves.

The small team has none of that. Asking them to stand up federated SSO before they can try your product is how you lose them in the first five minutes. They want to enter an email address and be in.

Design for only one of these buyers and you've quietly disqualified the other.

When SSO is non-negotiable

For regulated workloads, this stops being a preference. HIPAA and FedRAMP don't name "SSO" in the text — but they mandate the controls that SSO is the cleanest way to satisfy:

• Enforced multi-factor authentication on every account.
• Centralized identity, so there's a single source of truth for who has access.
• Automatic deprovisioning — access ends the moment HR offboards someone, not whenever an admin remembers.
• Auditable, attributable access for every user.

Try to meet those with self-managed passwords and you'll be patching the gaps forever. With enterprise SSO, the customer's existing identity provider already enforces them. So for any customer handling protected health information or pursuing a federal authorization, we make SSO mandatory and turn native login off — compliance becomes the default, not a checklist item bolted on later.

When native login wins

For everyone else, friction is the enemy. A team that just wants to evaluate the platform should be productive in minutes, not waiting on an SSO integration ticket. Native login (email plus, ideally, social sign-in and optional MFA) is the right call — with a clean upgrade path to SSO later, so nothing has to be rebuilt as they grow.

The architecture mistake to avoid

The failure mode we see most often is treating auth as a one-time decision baked deep into the application. Then the first enterprise deal arrives demanding SAML and SCIM, and retrofitting it touches every corner of the codebase.

Build the seam early. Authentication should be a layer the rest of the system trusts — it verifies who the user is and hands the application a stable identity, whether that identity came from a corporate IdP or a native account. With that seam in place, supporting both models, and switching a given customer between them based on their compliance needs, is a configuration decision — not a re-architecture.

That's the standard we hold the platforms we build to: meet the enterprise where their security team lives, meet the small team where they are, and let compliance requirements decide which door a given customer walks through — automatically.

If you're choosing or building an integration platform and want a second opinion on getting auth and tenancy right the first time, let's talk.