What single sign-on does for a small business

Single sign-on usually gets pitched as a convenience. Your team signs in to your business software with the account they already have, usually the Microsoft 365 or Google Workspace login they use for email, and there's one less password to forget. That's true, and it's the least interesting thing about it.

Where it really pays off is the day someone leaves the company, and in how much less time everyone spends dealing with forgotten passwords.

What happens the day someone leaves

Think about what happens now when an employee resigns. Somebody has to remember every system that person could get into and shut each one off. There's payroll, the customer database, the scheduling tool, the shared drive, and the app the operations team started using last year that IT never heard about.

Most businesses do a decent job with the first few and a patchy job with the rest. So accounts stay open for months, belonging to someone who no longer works there and no longer feels they owe the company anything.

With single sign-on, all of those systems rely on that one company account. Switch it off and the person is locked out of everything at once. That's the main reason to do it, and everything else is a bonus.

Far fewer password resets

For most small businesses, password resets are the most common support request there is. Every separate login is another password someone can forget, and every reset interrupts whoever handles it and leaves somebody unable to work for a few minutes.

Going from five logins to one doesn't cut that by 80%. It brings it down to almost nothing, because the one password left is the one people type every morning, and nobody forgets that one.

Security settings you only have to sort out once

Getting people to accept a second step when they sign in, like approving a prompt or typing in a code from their phone, takes some persuading. IT people call this multi-factor authentication. Having that argument once, for the one account everyone uses, is manageable. Having it separately for six different applications is how you end up with it switched on for two of them and a policy nobody follows.

The same goes for password rules, how long someone can stay signed in, and blocking sign-ins from countries you don't do business in. You set them up in one place, and every application connected to it follows the same rules, including the ones you add next year.

What it costs

Usually nothing beyond what you already pay. If you use Microsoft 365, you already have the sign-in service it needs. Connecting a custom application to it is a small job while the software is being built, and it costs next to nothing to run after that.

That's why we include it in every platform we build instead of selling it as an upgrade. It takes us a day, and it takes a whole category of problems off your plate.

When it isn't worth it

In fairness, there are two situations where it doesn't fit, or at least isn't so simple.

If the application is for people outside your company, such as customers using a portal, contractors, or residents signing up for a program, they don't have accounts in your company's Microsoft 365 or Google Workspace, so single sign-on doesn't apply. They'll need their own logins, and the more useful question there is whether they need logins at all.

And if your company doesn't have one central set of accounts (no Microsoft 365, no Google Workspace, nothing), single sign-on means setting that up first. It's still usually worth doing, but it's a bigger conversation than ticking a box during the build.

A question to ask about any new software

The next time someone suggests new software for the business, ask whether people can sign in to it with their existing company account. A no doesn't automatically rule it out. It does mean you're taking on another set of logins to manage, more password resets to handle, and one more account somebody will forget to close when a person leaves.