Identity and access management

What this actually solves

Two very different companies buy this, and they describe the problem in opposite ways.

The first describes friction. A forty-person business where every new starter has to be added by hand to eighteen separate tools, where that takes most of a day and something is always missed, and where accounts belonging to people who left last year are still alive because nobody kept a list of what they had. It is a slow, invisible cost that everybody has agreed to tolerate.

The second describes an obligation. An auditor, an insurer or an enterprise customer has asked for evidence of access control — who can reach what, on what basis, reviewed how often, and removed how quickly when someone leaves. The company does not have that evidence because the arrangement was never designed, it accumulated.

Underneath both there is usually a third reason nobody says out loud on the first call. The owner is not certain that a member of staff who left on bad terms has actually lost access, and cannot find out without asking eighteen questions of eighteen systems. That anxiety is what actually gets the budget signed, and it is fixed by the inventory long before anything sophisticated is built.

What this work is not is an excuse to buy an expensive identity platform. Most small companies already own everything they need inside Google Workspace or Microsoft Entra ID, and the value is in the design and the sequencing rather than the licence.

How the rollout runs

1. Inventory. Every tool, every account, every administrator, in one place — including the ones bought on someone's card and never mentioned. Expect surprises; this is the stage that finds them. Three to five days.
2. Access review. Each person's current rights put in front of their manager with one question — is all of this still needed. Managers answer this quickly and accurately when shown a specific list, and not at all when asked in the abstract. Three to five days.
3. Role design and the break-glass account. Five to eight roles, each mapped to the systems it needs at the lowest level that lets the work happen, with a written justification recorded against every single administrator grant. At the same time, the break-glass account is created, tested and its credentials handed over for physical storage. Two to four days.
4. Identity provider setup, then tools connected one at a time. Usually the provider already in place. Systems are connected starting with the least business-critical, each one verified before the next, each with a documented way back. One to four weeks, depending on how many tools are in scope.
5. Phased multi-factor rollout. IT and management first, then team by team. Every person gets advance notice and a one-page guide, recovery codes are generated and stored before the switch rather than after, and each phase closes with a check that the break-glass account still works. One to three weeks.
6. Joiner, mover and leaver runbook. The ordered steps for each of the three events, who performs each step, the maximum acceptable time for it, and how completion is evidenced — because an auditor will ask for the evidence, not the intention. Automated where the tooling supports it. Two to four days.

What moves the price

$1,000–$15,000 across 2–8 weeks, and the distance between those two ends is mostly a question of how many systems are involved.

How many tools are connected. This is the main driver. Connecting six systems to single sign-on is a different engagement from connecting twenty-five, because each one has its own configuration, its own failure modes and its own verification step, and none of them can be done in a batch.

Whether an identity provider already exists. A company already on Google Workspace or Microsoft 365 with an admin who knows where things are starts a long way ahead. One running on individual accounts, personal email addresses and shared logins needs that foundation built first, and that is the bulk of the difference between the two ends of the range.

Headcount and how much change there is. Fifteen people with stable roles is a short design exercise. A hundred people across several teams, with contractors, people in several locations and frequent movement, means more roles, more edge cases, more communication, and a rollout that has to be staged carefully enough that nobody's week is destroyed by it.

What usually goes wrong

Multi-factor authentication is switched on for everyone in a single day. It looks decisive and it is the most reliable way to shut a company. The next morning twenty people are locked out, many of them never saved a recovery code, the owner's phone number changed last year and the recovery route points at it, and the support burden lands on whoever suggested it. Phased rollout, advance notice, recovery codes stored first, break-glass verified last — in that order, every time.

Roles are cloned from what people currently have. It is the fastest way to produce a role matrix and it preserves exactly the over-provisioning the exercise was meant to remove. Every administrator grant that existed because someone needed it once in 2022 gets baked into a permanent role definition, and the audit finding that prompted the project is still there afterwards, now with documentation.

Offboarding stops at email. The leaver's mailbox is suspended, everyone feels the job is done, and the person retains access to the design tool, the analytics account, the CRM, the support inbox and the shared drive because those were never on anyone's list. This is precisely why the inventory comes first and why the leaver runbook names systems individually rather than saying to remove access.