Solutions / IT foundations

Single sign-on

One login for every company app, with multi-factor authentication, and one place to switch someone off when they leave.

How we deliver it

• We list every app your team signs into.
• We connect each one to a single identity provider and turn on multi-factor authentication.
• Offboarding becomes one action instead of a checklist.

How it works

Each app stops keeping its own passwords and trusts one identity provider instead. People sign in there, with multi-factor authentication, and every connected app accepts the result. Behind that one provider sit whatever account sources the business needs: usually the office suite accounts staff already have, plus partner or contractor accounts where required. The same identity also decides who can join the private network.

Signing in

The first app of the day sends people to the identity provider. They sign in once, and the provider vouches for them to that app and to every app they open after it, with no further prompt until the session ends.

When someone leaves

Disabling the person once refuses every new login, everywhere. Two things take longer, and we say so up front: a session already open lasts until it expires, and accounts an app created on its own are removed only where that removal is automated. We automate it wherever the app allows, and list the rest.

Groups decide what people get

Access is granted to groups, not to people one app at a time. Putting a new hire in the right groups gives them the right access in every app on their first day; moving teams is a change of group, not a round of tickets.

Apps that cannot do single sign-on

Some apps cannot. An internal web app gets a sign-in gate in front of it, so it uses the same login and the same multi-factor authentication. A vendor tool with no single sign-on gets its passwords from a shared password manager, so every password is unique and goes away with the person.

Multi-factor authentication, and losing a phone

Passkeys are preferred: they cannot be phished, because they only work on the real sign-in page. An authenticator app is accepted. Text messages are not. Everyone registers two methods, so losing one is an inconvenience rather than a lockout.

When both are lost, recovery follows the same steps every time:

1. The person asks an administrator, never a help form or an email.
2. The administrator confirms who they are on a channel already known, such as a video call or in person, not on the request itself.
3. The administrator resets their methods, and the old ones stop working.
4. The person registers new methods at their next sign-in.
5. The reset is logged, and the person is notified on a channel they already had.

How we roll it out

1. Inventory. Every app the team signs into, whether it supports single sign-on, and on which plan.
2. Sources and policy. Where identities come from, the multi-factor rules and the emergency admin accounts, before any app is connected.
3. Riskiest apps first. Email, admin consoles and finance, then everything else, one app at a time.
4. Turn off the old passwords. Where an app allows it, local logins are disabled, so the provider is the only way in.
5. Automate removal. Wherever the app supports it, so leaving is one action.

Decisions to settle first

Where identities come from

Decided per client. Office suite accounts usually stay the source for staff; partners and contractors can sign in with their own accounts or get local ones. When there are several sources, settle which one is authoritative for each group of people.

The single sign-on surcharge

Many software tools only offer single sign-on on their more expensive plans. List your tools and check their plans before committing: it can change the budget more than the setup does.

When the identity provider is down

Nobody can start a new login anywhere, so treat it as critical: run it with redundancy, watch it, and keep two emergency admin accounts, sealed and outside the normal sign-in, for getting back in.

Session length

Longer sessions mean fewer prompts but a longer tail after offboarding. Shorter for admin access and sensitive tools, longer for everyday ones.

Automatic account removal

Not every app supports it. Where an app does not, its accounts go on the offboarding checklist until it does.

Your stack or ours

Hand over or run

Your choice, per solution. We hand it over with documentation your team can work from, or we keep it running: upgrades, monitoring and incidents, with one of us on call 24/7.

Proof

We run our own self-hosted identity provider in production, and set yours up the same way.