Updated: October 2026
Somewhere in your tenant there's an account that belongs to someone who left in the spring. Finding it by hand means opening a dozen admin consoles and hoping nothing was signed up under a personal login. Here's what IAM solutions do, how the main identity and access management tools fit a small IT team, and the order to roll them out in.
TL;DR
- IAM solutions answer three questions for every account: who is this, what can they reach, and should they still reach it.
- The building blocks are a directory, SSO, MFA, provisioning, access reviews and privileged access. A small team rarely needs all six on day one.
- In a Microsoft 365 tenant, Entra ID is already there. In Google Workspace, Cloud Identity is. Okta and JumpCloud earn their place in mixed or multi-platform estates.
- Roll out in this order: one directory, MFA everywhere, SSO for the apps that hold data, an automated leaver, then reviews.
- Phishing-resistant MFA for admins is the upgrade that pays off fastest.
What IAM Solutions Do
Identity and access management is the set of controls that decides who can sign in to what, with how much proof, and for how long. An IAM solution is any tool that runs part of that job centrally instead of app by app.
The job has three questions in it. Who is this person, and is it really them? What should they be able to reach? Is that still true today? The first is authentication, the second is authorization, and the third is governance.
Tools overlap, and vendors bundle the three differently. So the label on the box matters less than which question a product answers, and for which apps.
For a small IT team the payoff is plain. One place to create an account, one place to disable it, one place to see what it can reach. Without that, every SaaS app becomes its own island with its own password, its own admin page and its own forgotten users.
The Six Building Blocks of IAM
Directory. The source of truth for who exists: users, groups, devices and their attributes. Active Directory on-prem, or Microsoft Entra ID, Google Cloud Identity or JumpCloud in the cloud. Everything else reads from it.
Single sign-on (SSO). One sign-in, many apps. The directory vouches for the user to each app over SAML or OpenID Connect, so the app never stores its own password. Fewer passwords means fewer to phish, reuse and reset.
Multi-factor authentication (MFA). Proof beyond a password: an authenticator app, a hardware key, a passkey. With SSO in place, MFA only has to be enforced in one spot instead of in every app.
Provisioning. Creating, changing and removing accounts in each app automatically when something changes in the directory. The standard here is SCIM, the System for Cross-domain Identity Management, defined in RFC 7644 in 2015. If an app speaks SCIM, disabling a user in the directory disables them in the app too.
Access reviews and governance (IGA). Scheduled checks that people still need what they have, plus request and approval flows for new access. Our roundup of access request management tools covers this layer in detail.
Privileged access management (PAM). Extra controls for admin accounts: just-in-time elevation, vaulted credentials, session recording. It's the smallest group of accounts and the most dangerous one, which is why privileged access management gets its own tooling.
Roles tie the six together. Access granted to a role instead of a person is what keeps the rest manageable, and our guide to role-based access control shows how to design roles without drowning in exceptions.
Where IAM Pays Off: Joiners, Movers and Leavers
Every identity goes through three events. A joiner needs accounts on day one. A mover changes team, needs new access and should lose the old. A leaver needs everything switched off at a known time, with their data handed to someone.
Joiners get attention because someone complains when access is missing. Movers and leavers don't, because nobody complains about access they still have. That's how a sales rep who moved to finance still has the CRM export button a year later.
Here's what a mover looks like with groups doing the work. Priya moves from Sales to Finance. HR changes her department in the HR system, which is the source of truth. The directory moves her from the Sales group to the Finance group overnight. SCIM removes her CRM seat and adds her to the accounting app, and her shared-drive access follows the groups. Nobody opens a ticket, and nothing from Sales comes with her.
Without that chain, the same move is four tickets, two of which get done. The access she no longer needs is the part nobody asks for, so it's the part that stays.
Automating the leaver is where IAM tools earn their cost first. With the directory as the source of truth and SCIM connected, disabling one account can block sign-in, revoke sessions, strip group memberships and remove SaaS seats in one step. What's left is the human part: who gets the mailbox, who owns the files, which devices come back.
This r/sysadmin thread from July 2026 shows where offboarding stalls in practice. The replies spend as much time on mailbox and OneDrive handover as on the account switch itself.
A usable leaver process has five parts. The trigger: who tells IT, and when. The switch-off: disable sign-in, revoke sessions and tokens, reset MFA methods. The handover: mailbox, files and any shared credentials. The hardware: devices wiped or returned. The record: what was done, by whom and when.
Write those human rules down first. The tooling only automates what's already agreed, and a script can't decide who inherits the finance mailbox. For the device side, our guide to changing the administrator on Windows 11 walks through a clean handover.
Common IAM Gaps in Small Environments
The gaps that hurt small teams are rarely exotic. They're the accounts nobody owns.
Shared admin accounts come first. When four people use one "admin@" login, the audit log can't say who did what, and nobody can be offboarded from it without changing the password for everyone.
MFA exceptions are next. One executive's exemption, granted for a trip in 2023, is still in place. Exceptions need an owner and an end date, or they become policy by accident.
Guest accounts pile up quietly. Contractors and partners invited for one project keep their access long after it ends, because guest users rarely sit in any leaver process.
Service accounts are the fourth gap. A scheduled task or integration runs under a password that hasn't changed since it was created, often with more rights than it needs.
The last one is shadow SaaS. Someone signed up for a design tool or a file-sharing app with their work email and a personal password. It never went through the directory, so no leaver process will ever find it. An IAM tool can't govern an app it doesn't know about, which is why the app inventory comes before the tool choice.
How the Main IAM Tools Fit a Small Business
There's no single right pick. The directory you already pay for sets the starting point, and the reason to add a second tool is almost always a gap the first one can't close.
Microsoft Entra ID. If you run Microsoft 365, you already have it. The Free tier includes MFA through security defaults and automated user provisioning to SaaS apps. Conditional Access needs Entra ID P1, which Microsoft 365 Business Premium includes. Access reviews and privileged identity management sit in P2 and the ID Governance add-on, according to Microsoft's Entra licensing page (updated June 2026).
Google Workspace and Cloud Identity. A Google tenant already gives you the directory, SAML-based SSO to other apps and 2-step verification. Cloud Identity brings the same identity layer to people who don't need a full Workspace licence.
Okta. A standalone identity provider that sits above whichever productivity suite you run. Its pull is breadth: a large catalogue of pre-built app integrations and lifecycle automation that can take an HR system as the source of truth.
JumpCloud. A cloud directory that also manages devices across Windows, macOS and Linux, with SSO, MFA, and LDAP and RADIUS for older systems. It suits small teams without Active Directory who want identity and device policy in one console.
Hybrid Active Directory. If you still run a domain controller for file shares, printers and older line-of-business apps, that's fine. Sync the on-prem directory to the cloud identity provider, treat one side as the source of truth for users, and plan to shrink what depends on the domain over time rather than in one weekend.
Point tools. Duo adds MFA in front of VPNs and on-prem apps. Password managers cover the apps that will never support SSO. They fill gaps rather than replace a directory.
This thread asked why Okta appears in so many job postings when Microsoft and Google both do SSO. The replies land on the same split: single-suite shops use the suite's own identity layer, while mixed estates and HR-driven provisioning are where a separate identity provider pays for itself. The original poster's update adds the other reason: migrations are painful enough that teams keep paying rather than move.
Here's a shortlist by situation. It's a starting point, not a ranking.
| Situation | Start with | Add when |
|---|---|---|
| Microsoft 365 and a Windows fleet | Entra ID (P1 comes with Business Premium) | The ID Governance add-on, once access reviews become an audit requirement |
| Google Workspace, Chromebooks and Macs | Google Workspace or Cloud Identity | A device management tool for Windows and macOS policy |
| Microsoft and Google both in use | A standalone identity provider such as Okta | HR-driven provisioning, once joiners and leavers happen every week |
| No on-prem AD, mixed Windows, macOS and Linux | A cloud directory such as JumpCloud | LDAP or RADIUS for Wi-Fi, NAS boxes and legacy apps |
| A handful of admins with broad rights | Your directory's privileged identity features or a PAM tool | Session recording for regulated work |
MFA: The Kind Matters More Than the Checkbox
Turning on MFA stops password spraying and reused-password logins. It doesn't stop every attack. CISA's phishing-resistant MFA fact sheet (October 2022) lists phishing, push bombing, SMS interception and SIM swaps as the ways attackers get around weaker factors, and calls phishing-resistant MFA "the gold standard."
Phishing-resistant means the factor is bound to the real site, so a fake login page can't relay it. In practice that's FIDO2 security keys, passkeys and Windows Hello for Business. Number matching in an authenticator app is a solid middle step. SMS codes sit at the bottom.
Credentials still matter as other ways in grow. Verizon's 2026 DBIR found that software vulnerabilities, at 31% of breaches, overtook stolen passwords as the top way attackers get in, and it still lists stolen credentials among the most frequent causes. That's a reason to patch faster, not to relax on MFA. Our look at the most common passwords shows what attackers try first when MFA is missing.
Professor Messer's walkthrough covers the identity concepts this section builds on: provisioning, SSO, federation and the factors behind MFA.
A Rollout Order for a Small IT Team
You don't need the whole stack before any of it pays off. Each step below closes a gap on its own.
- One directory. Pick the source of truth and get every person into it, with groups that match real roles. Retire local accounts on SaaS apps where you can.
- MFA for everyone. Admins first, then everyone else, through security defaults or a Conditional Access baseline. Set up two break-glass accounts before you enforce anything.
- SSO for the apps that hold data. Email, file storage, CRM, finance and HR first. Every app moved behind SSO is one less password to reset.
- Provisioning and the leaver switch. Connect SCIM where apps support it and script the rest. Test the leaver flow on a dummy account before a real one depends on it.
- Phishing-resistant MFA for admins. Hardware keys or passkeys for anyone with admin rights, then finance and leadership.
- Reviews. Quarterly for admin roles and sensitive apps, twice a year for the rest. Record who approved what.
The device side needs the same sweep. Leftover local admin accounts and cached credentials on laptops sit outside the directory entirely. OpenFrame can run a script across a client's devices and collect the output in one place, so a stray local admin shows up as one row in a report instead of fifty remote sessions.
What to Check Before You Buy an IAM Tool
Start with the apps. List every system people sign in to, then check which support SAML or OpenID Connect for SSO and SCIM for provisioning. An IAM tool can only automate the apps that talk to it. The rest stay manual, and they're usually the ones nobody remembers.
Then check the licence tier behind each feature. Conditional access, access reviews and privileged identity features often sit a tier or two above the entry plan. The bill scales per user, not per admin, so a feature you need for five admins can cost you for fifty staff.
Ask about outages and break-glass access. If the identity provider is down, what still works, and how does an admin get in? Two emergency accounts, excluded from the usual policies and monitored closely, are the standard answer.
Check the exit before you sign. How hard is it to export users, groups and app assignments if you switch later? Identity migrations touch every sign-in in the company, which is why teams tend to stay put once they've picked.
Finally, look at the logs. Sign-in logs, audit logs and how long they're kept decide whether you can answer "who had access to what, and when" after an incident. Retention differs by tier, so check it before you commit.
IAM Solutions, in Short
IAM solutions give every account one front door, one set of rules and one off switch. Start with the directory you already own, put MFA in front of everything, move data-heavy apps behind SSO, and automate the leaver before you worry about governance. Add a separate identity provider or PAM tool when a real gap shows up, not because a feature list says so.
Next, design the roles your IAM tool will enforce with our guide to role-based access control.
Conrad Lunderstedt
Solution Architect
I'm Conrad, Solution Architect at Flamingo. I've spent about 26 years in IT, roughly half of it inside MSPs and the rest in enterprise environments, so I've watched vendor decisions get made on both sides of that line. Now I spend my days talking with MSPs about the stack they already run, and helping them work through the requests and issues that come with it.
