Single sign-on (SSO) and why it matters as you grow

Single sign-on (SSO) lets your team sign in to many work apps using one company account, usually the one they already use for email. Instead of a separate password for the CRM, the project tool, the accounting app, and the file share, they sign in once with their Google Workspace or Microsoft 365 account and the other apps trust that sign-in.

For a five-person company, SSO is a convenience. For a 30-person company with staff turnover, it becomes one of the most useful security controls you have.

How SSO works, in plain English

There are two parties:

The identity provider (IdP) holds your staff accounts and checks who is signing in. For most small companies this is Google Workspace or Microsoft Entra ID. Dedicated identity services such as Okta and JumpCloud do the same job.
The app (often called the service provider) is the tool your team wants to use, such as a CRM or project manager.

When someone opens the app, it sends them to the identity provider. The identity provider checks their password and second factor, then tells the app "this is Sam from your company." The app never sees Sam's password.

The technical standards behind this are called SAML and OpenID Connect (OIDC). You don't need to understand them, but you'll see the names in app settings.

Many apps offer a "Sign in with Google" or "Sign in with Microsoft" button. That's a lighter version of the same idea and is better than a separate password. Full SSO goes further: an admin can require that everyone from your domain signs in through the company identity provider, and can often control which staff are allowed into the app at all.

"Sign in with Google" or Microsoft

What it is - a button many apps offer
How it compares - a lighter version of the same idea, and better than a separate password

✓

Full SSO

Who decides - an admin can require everyone from your domain to sign in through the company identity provider
Who gets in - an admin can often control which staff are allowed into the app at all

Automatic provisioning (SCIM)

Some apps also support SCIM, a standard that creates and removes user accounts automatically when you add or remove someone in your identity provider. SSO controls sign-in. SCIM controls whether the account exists. Together, they make offboarding close to a single click.

Why it matters as you grow

One switch for leavers. When someone leaves, you suspend their Google or Microsoft account and they lose access to every SSO-connected app at once. Without SSO, you're relying on a checklist of every app they ever used. See security steps when someone leaves for the full process.

Two-factor in one place. You enforce two-factor authentication or passkeys at the identity provider, and every connected app inherits it, including apps with weak sign-in options of their own.

Fewer passwords to steal. Each separate password is another thing that can be reused, phished, or leaked. SSO cuts the number down.

A record of who has what. Your identity provider shows which apps are connected and who signed in. That helps with access reviews, security questionnaires, and cyber insurance applications.

Faster onboarding. New staff get access to their apps through group membership instead of a dozen separate invitations.

The catch: the "SSO tax"

Many software vendors include SSO only on their business or enterprise plans, which can cost noticeably more per user. People in the industry call this the SSO tax. Before you plan a rollout, check the current plans for each app you want to connect. Vendors change this often, so look at the pricing page rather than relying on memory.

This is why most companies roll SSO out gradually, starting with the apps that matter most.

Rolling it out

Get your identity provider in order. Every staff member needs their own account in Google Workspace or Microsoft 365, with two-factor turned on. No shared logins. See Key security settings in Google Workspace or Security defaults & key settings in Microsoft 365.

List your apps and rank them. Put apps holding customer data, financial data, or admin access to other systems at the top. Note which ones support SSO on your current plan.

Start with one app. Follow the app's SSO setup guide and your identity provider's instructions. Test with one or two people before switching everyone over.

Keep a break-glass account. Keep one emergency admin login per critical app that doesn't depend on SSO, stored securely in your password manager. If your identity provider has an outage or is misconfigured, you can still get in.

Enforce it. Once it works, turn on the setting that requires SSO for your domain, and remove old passwords from the app where possible.

Add SCIM where it's offered, so accounts are created and removed automatically.

Common mistakes

Protecting the identity provider poorly. SSO concentrates access. If the identity provider account is compromised, everything behind it is too. Use strong two-factor (ideally passkeys or security keys) for admins.
Leaving local passwords active. If people can still sign in to the app with an old password, SSO isn't really protecting it.
Forgetting contractors and shared mailboxes. Decide how non-employees get access before you enforce SSO.
No break-glass access. A misconfigured SSO setting can lock everyone out, including you.

Frequently asked questions

Do we need Okta, or is Google or Microsoft enough?

For most small companies, Google Workspace or Microsoft Entra ID is enough to start. Dedicated identity services become useful when you have many apps, mixed Google and Microsoft environments, or need more advanced access rules. Check what your current plan includes first.

Is SSO the same as a password manager?

No. They work together. SSO covers apps that support it. A password manager covers everything else, including the break-glass accounts.

At what size should we set up SSO?

There's no fixed number. Good triggers are regular staff turnover, a client asking whether you use SSO, or the moment offboarding someone takes more than an hour because of all the separate accounts.