Ask a business of thirty people who has access to their finance system and you usually get a confident answer that turns out to be wrong. Ask whether anyone who left last year still has an account somewhere and the answer is a pause.
Neither of those is negligence. Both are the predictable outcome of managing access one system at a time, by hand, while the number of systems grows and nobody owns the total picture.
This article covers what single sign-on actually fixes, why the multi-factor authentication you probably have is weaker than you think, and how to get access under control without a project that never finishes.
The problem is leavers, not passwords
Single sign-on is usually sold on convenience: one login instead of twelve, fewer password resets, happier staff. That benefit is real and it is not the reason to do it.
The reason is that you get one place to grant and remove access across every connected system.
Consider what removing a leaver looks like without it. Somebody works from memory or from a checklist written two years ago. They handle the obvious systems, email, the main platform, the shared drive. They miss the analytics tool the person used twice, the support platform, the invoicing system somebody set up during a busy quarter, the design tool on a personal-email account.
Those accounts stay active. Nobody notices, because nothing visible happens when a dormant account continues to exist.
With SSO, disabling one account in the identity provider removes access to everything connected, immediately and verifiably.
Test your own position rather than taking our word for it. Pick three people who left in the last twelve months and check every system for accounts in their name. Most businesses running that exercise for the first time find at least one still active. We are deliberately not quoting an industry statistic here, because the figures in circulation come from vendors selling identity products, and your own number is both obtainable and more useful.
When it starts being worth it
The threshold is lower than owners expect and it is not about headcount alone.
What matters is the number of systems multiplied by the rate at which people join and leave. A business with fifteen people and twenty tools has three hundred possible access relationships and no practical way to see them. A business with sixty people and four systems is in a much simpler position.
A rough test: if you cannot currently answer "who has access to what" from something written down, and you have more than a handful of access changes a year, you are past the point where manual management works.
In practice that arrives somewhere around fifteen people for most businesses, though the number of tools moves it in either direction.
Not all multi-factor authentication is equal
This is the most important technical point in the subject and the one most businesses have never encountered.
The US National Institute of Standards and Technology publishes digital identity guidelines that define authentication assurance levels and set out what different authenticator types actually protect against [1][2].
The distinction that matters: phishing-resistant multi-factor authentication versus the ordinary kind.
NIST's analysis is direct. All multi-factor processes using shared secrets are vulnerable to phishing attacks, including memorised secrets, look-up secrets, out-of-band authentication over SMS, push notifications and one-time passwords. Strong multi-factor authentication uses asymmetric key cryptography for protection from phishing [1].
That covers most of what businesses currently deploy. The six-digit code from an app, the SMS message, the push notification you approve on your phone: all of them are better than a password alone, and none of them stops the attack that actually happens now.
Why they fail. A modern phishing attack does not just capture your password. It puts up a convincing fake login page and relays what you type to the real site in real time. You enter your password, it is relayed. You are prompted for your code, you enter it, that is relayed too. The attacker is now signed in as you, and everything you did looked normal.
Why passkeys and security keys do not fail this way. The credential is bound cryptographically to the legitimate site. Presented with a lookalike domain, it simply does not work. There is nothing transferable for the user to be tricked into handing over.
So the honest summary is not that SMS codes are useless. They defeat an attacker who has only stolen a password, which is a real category. They do not defeat the attacker who has built a convincing relay, which is the category that is growing.
What an attack actually looks like now
Worth walking through, because the abstract argument about phishing resistance becomes concrete once you see the sequence.
A member of your finance team receives an email that appears to come from your accounting platform, saying a document needs review. The link goes to a page that looks exactly right, because it is a copy of the real one. They enter their email address and password.
Behind the scenes, the attacker's system immediately passes those credentials to the genuine site. The genuine site responds by asking for a second factor. The fake page, still in front of your colleague, asks for the same thing. They open their authenticator app, read the six-digit code, and type it in.
That code is relayed to the real site within seconds. The attacker is now signed in as your finance team member. Nothing looked wrong at any point, the second factor worked exactly as designed, and it protected nothing at all.
The same sequence works with an SMS code. It works with a push notification, where the user taps approve because they genuinely did just try to sign in.
Now run the same attack against a passkey. The credential is bound cryptographically to the real domain. Presented with the lookalike, the browser does not offer it, because as far as the credential is concerned this site is simply a different site. There is no code to read out and no secret to relay. The attack stops without the user having to notice anything.
That is the entire practical difference, and it is why the distinction between kinds of multi-factor authentication is worth understanding rather than treating them all as a single checkbox.
Where to apply the strongest protection first
Rolling passkeys out to everybody for everything tends to stall on awkward cases. Protecting the accounts where compromise would be catastrophic gets most of the benefit for a fraction of the effort.
Rank by what somebody could do with full control, not by how often the system is used:
| Priority | System | Why |
|---|---|---|
| 1 | Identity provider admin | Whoever holds it can grant themselves everything else |
| 2 | Email platform | It is the password reset path for most other systems |
| 3 | Domain registrar and DNS | Control here means control of everything that resolves to you |
| 4 | Hosting and infrastructure | Direct access to systems and data |
| 5 | Finance and payments | Direct financial loss |
Email deserves a note. It sits second on that list because it is the recovery route for nearly everything else. An attacker with your email does not need your other passwords; they can reset them. Businesses routinely apply strong authentication to their finance system and leave email on an SMS code, which secures the vault while leaving the key under the mat.
Roles, not permissions per person
Least privilege is a security principle that sounds like a project and does not have to be one.
The idea is that people get the access their job needs and no more. What actually happens in most businesses is that broad access is granted at the start, because working out what somebody needs is harder than giving them everything, and then it is never narrowed. Permissions ratchet upward for years and never come back down.
The practical fix is to define three or four roles rather than assigning permissions per person. Most businesses genuinely need: general staff, finance, technical, administrator. Perhaps one or two more.
Assign people to a role. Grant permissions to the role.
This is considerably less work than it sounds, and it converts an unanswerable question into an answerable one. "Who can see the finance system" becomes "who has the finance role", which is a list you can produce in seconds.
Temporary access needs one additional discipline. Grant it, record it, and set a date to remove it. Over-privilege accumulates one reasonable exception at a time, and the exception is almost never the problem. The problem is that nobody wrote down it was temporary, so a year later it is indistinguishable from a deliberate permanent grant.
The tools that will not connect
Here is the constraint that shapes every real implementation.
Many providers put SSO behind their enterprise tier. A tool you use happily on a mid-tier plan may require a substantial upgrade to connect it, and some vendors price that step steeply.
So build your tool list first and check, for each one, whether SSO is supported and at what price. The total frequently surprises people, and the surprise is almost always in the applications rather than in the identity platform itself, which is usually a modest per-user cost.
For anything priced out of reach, the answer is not to pretend it is covered. Put it on an explicit exceptions list with a named owner, so its accounts are reviewed and removed by hand.
An exception you have written down and assigned is manageable. An exception nobody recorded is exactly how a leaver keeps access to the one system that mattered.
Joiners, leavers, and the people in between
Joiners. Assign a role in the identity provider before the start date, which grants everything connected automatically, plus a written list of anything on the exceptions list needing manual setup. The test of a good joiner process is that a new starter can work on their first morning without anybody improvising access on the spot.
Leavers. Disable the identity provider account, which handles connected systems immediately. Work through the exceptions list. Reclaim devices. Check for anything registered to a personal account. Do it on the last day rather than when somebody remembers.
Contractors and agencies. The most commonly forgotten category and frequently the most over-privileged, because access was granted in a hurry at project start and never revisited. Give them roles with the same discipline as staff, set expiry dates matching the engagement, and include them in the same quarterly review.
On that note: if your supplier currently holds administrator accounts for your infrastructure, your domain or your hosting, that is worth fixing regardless of anything else in this article. Those accounts should be in your business's name with the supplier holding a scoped role inside them. Our guide on the accounts your business must own covers why, and it is considerably easier to arrange while the relationship is good than during a handover.
The quarterly review, and why it usually fails
Access reviews fail for one reason: without defined roles, the exercise is unbounded.
Reviewing several hundred individual permissions across twenty systems is a week of work that nobody has, so it gets deferred, and then it stops being scheduled.
With roles defined, the review is short. List who holds each role. Ask the relevant manager whether that is still correct. Remove whatever is not. The whole review should take under an hour once roles exist. Then check the exceptions list separately, because those are the accounts that will not clean themselves up.
Quarterly is right for most businesses. Attach it to something already in the calendar, such as a finance review, so that it does not depend on anybody remembering.
Two things that catch people out
Centralisation concentrates consequence. If somebody compromises your identity provider, they reach everything connected to it. That is a real consideration and it is exactly why those administrator accounts deserve the strongest authentication available to you, which is where this article started and where the practical work begins. On balance the trade is clearly favourable, because the alternative is a dozen separately managed credentials with inconsistent authentication and no central visibility, but it is worth understanding rather than glossing over.
Availability becomes a dependency. If your identity provider is unavailable, people cannot sign in to connected systems. Establish break-glass accounts that do not depend on the provider, store their credentials securely offline, and test that they work before you need them. Our guide on incident response covers arranging that in advance rather than during an outage.
Shared accounts and password policies
Shared logins are widespread and almost never acceptable. You cannot tell who did what, cannot remove one person's access without disrupting everybody, and cannot apply meaningful authentication. Where a system genuinely does not support multiple users, record it as an exception with a named owner, and change the credential whenever anybody with knowledge of it leaves.
Password policies are probably longer than they need to be. Modern guidance has moved away from forced periodic rotation and arbitrary complexity rules, which push people toward predictable patterns like a name and a number that increments. The emphasis now is on length, blocking known-breached passwords, and strong second factors. Check the current NIST guidance [1][2] rather than inheriting a policy written a decade ago on assumptions that have since been revised.
The archaeology is where the value is
The hardest part of implementing this is not the technology. The protocols are standard and the connections are usually straightforward.
It is cleaning up what already exists.
Most businesses starting this find duplicate accounts, accounts belonging to people who left, shared logins nobody will admit to creating, and permissions granted for reasons nobody now remembers. That work is unglamorous, it takes longer than the integrations, and it is where the actual security benefit comes from, because you are removing access rather than merely reorganising it.
Budget for the decisions and the cleanup rather than for the connections. For a business with mainstream tools, the whole thing is weeks rather than months, and most of those weeks are archaeology.
What it costs, honestly
Three cost lines, and businesses consistently misjudge which one dominates.
The identity provider is usually a modest per-user monthly charge, and for a business of twenty or thirty people it is rarely the deciding factor. Most owners assume this is the main expense. It generally is not.
Application upgrades are where the money actually goes. Vendors frequently place single sign-on on an enterprise tier, and the jump between the plan you are on and the plan that supports it can be several multiples rather than a small increment. Price this for every tool on your list before committing to anything, because the total is the number that determines whether the project is proportionate.
Implementation time, whether internal or external, covers the decisions, the connections and the cleanup. The connections are quick. The role definitions take a few days of somebody's attention spread across conversations with the people who know what each team actually needs. The cleanup takes as long as your accumulated mess deserves, which nobody can estimate until they have looked.
Two costs that never appear in a business case. The exceptions list is permanent overhead: every system that will not connect stays manual forever, and somebody has to work through it at every leaver. And the review cadence is a recurring commitment, small each quarter and only valuable if it actually happens.
Set against that, the cost of the current arrangement is invisible and real: access nobody can account for, leavers who retain entry, and no ability to answer a basic question about your own systems.
A realistic sequence for a business starting from nothing
Most guidance on this describes a destination rather than a route. Here is the order that works, roughly.
Week one, protect the crown jewels. Strongest available authentication on identity provider administrators, email, and the domain registrar. No project, no budget, no decisions about architecture. This is the single highest-return hour in the whole exercise and it can happen before you have decided anything else.
Week two, build the list. Every system in use, who administers it, whether it supports single sign-on, and at what plan tier. This is also the point where you discover tools nobody told you about, which our guide on shadow IT covers running properly.
Week three, check three leavers. The exercise described above. It produces both a cleanup task and, more usefully, the internal argument for doing the rest of the work.
Weeks four and five, define roles. Three or four, no more. Map each existing person to one. Note where somebody has access that their role would not grant, because those are either mistakes or evidence that your roles need adjusting.
Then connect systems, in order of risk. Not alphabetically, not by ease. Start where compromise would be worst and work down. You will get most of the benefit from the first handful.
Finally, write the exceptions list for everything that will not connect, with a named owner against each.
The whole sequence is weeks rather than months for a business with mainstream tools, and the parts that take longest are the decisions and the cleanup rather than any technical integration.
What to do this week
Two things, both free, both addressing real rather than theoretical exposure.
Check three leavers. Pick three people who left in the last twelve months and look for accounts in their name across every system you can think of.
Confirm the strongest available authentication is enabled on your identity provider administrator accounts, your email platform and your domain registrar. Those three are the routes that turn a minor incident into a serious one.
That is an afternoon and it removes more risk than most of what follows it.
If you want the fuller version, an access review covering what systems exist, who has access to each, what should be revoked, and a role structure that fits your business starts from around AED 4,000 with us. Implementing single sign-on across your tools is priced separately by scope. Final pricing depends on scope, and these are our own figures rather than a market survey.
Access control and knowing what software you have are the two foundations most security frameworks put first, on the reasoning that you cannot protect what you cannot see or control. Our guides on shadow IT and cybersecurity for small business cover the surrounding programme.
References
- NIST Special Publication 800-63B, digital identity guidelines, authentication and lifecycle management
- NIST Special Publication 800-63-4, digital identity guidelines
- NIST, authenticator assurance levels implementation resources
- CIS Critical Security Control 1, inventory and control of enterprise assets
- SKIMBOX, the accounts your business must own
- SKIMBOX, shadow IT: the tools your team bought
- SKIMBOX, cybersecurity for small business in the UAE
- SKIMBOX, it broke at 2am: who do you actually call
- SKIMBOX, security awareness training and phishing in the UAE
NIST digital identity guidelines are written for US federal agencies and are cited here for their technical analysis of authenticator types, which applies broadly. Whether your specific compliance obligations require particular controls is a question for a qualified adviser.
