SSO and identity federation: consolidate your accounts, do not multiply them
The more systems a company runs, the more expensive the chaos in user accounts becomes. How centralising authentication reduces both operational costs and attack surface.
Most mid-sized companies have no single picture of who has access to what. There is Active Directory for corporate email, separate logins in the CRM, separate ones in the ERP, several SaaS tools with their own accounts, and a couple of in-house systems with a users table in a database somewhere.
Each of these systems lives its own life. When an employee leaves, they are disabled wherever someone remembers to do it. When someone joins, accounts are created wherever someone asks. This is not negligence - it is just how things grow when left alone.
What lies behind this chaos
Fragmented identity is not just an inconvenience for IT. It is a real operational and security risk.
A few concrete problems I see in these environments:
- A former employee retains access to one or more systems because that account was forgotten during offboarding. The same problem extends to remote contractors, who form a separate access perimeter.
- Passwords are informally synchronised across systems - people reuse them because there is no other way to remember them all. If one system is compromised, the risk spreads.
- A full audit of who did what is not possible - logs are scattered across different systems and never aggregated.
- Onboarding new employees becomes a manual checklist of fifteen steps, half of which get skipped.
What SSO and federation actually are
Single Sign-On means a user authenticates once in one place, and all other systems trust that authentication. There are several implementation options - SAML, OAuth, OpenID Connect - but the idea is the same: one source of truth about identity, with all other systems connected to it.
Federation goes a step further: it is the ability of multiple independent identity domains to trust each other. For example, a contractor's employees can work in a client's systems without separate accounts being created - their organisation vouches for their identity, and your system accepts that.
For most companies, "mature federation" is still on the horizon. But basic SSO within your own infrastructure is a practical problem that can be solved today.
What changes when identity is centralised
The effect goes beyond the convenience of a single login. Centralising identity changes several things at once.
Offboarding an employee becomes a single action. Disable the central account and access is revoked everywhere that uses SSO. This is not zero risk, but it is radically better than manually working through twelve systems.
Password policy and multi-factor authentication are enforced in one place and apply everywhere. You do not have to negotiate with each system individually to get the settings you need.
Authentication logs are consolidated. When something happens, you have a single history of who logged in, when, and from what device.
Onboarding is simpler: adding a user to groups in the central directory is one operation with a predictable outcome.
Where to start
Migrating everything at once is not realistic. A sensible order:
- Identify which systems already support SAML or OAuth - most corporate SaaS tools do.
- Set up or confirm your Identity Provider - Microsoft AD FS, Google Workspace, or one of the dedicated solutions.
- Connect systems one by one, starting with the most critical and most frequently used.
- Document procedures: what happens at hire, at departure, at role change.
Questions for auditing your own situation
- How many systems in your company have their own user database?
- Do you have an up-to-date list of what each employee has access to?
- How long does it take to fully revoke a departed employee's access across all systems?
- When did someone last look at dormant accounts - ones that have not been used for several months?
If the answers are uncomfortable, that is not a reason to panic. It is a reason to make a plan.