The 5 IAM Mistakes Growing Companies Make (and How to Fix Them)

Identity and Access Management (IAM) is one of those things every growing company gets wrong in roughly the same ways. By the time you have 50+ employees, a half-dozen SaaS apps, and your first SOC 2 conversation, the cracks start to show: ex-employees with active Slack accounts, contractors with admin privileges nobody remembers granting, and a spreadsheet labeled "access matrix v3 FINAL" that hasn't been updated in eight months.

Here are the five patterns we see most often during IT stack audits — and the practical fixes that don't require a six-figure IAM platform.

1. Offboarding is manual (and incomplete)

When someone leaves, the typical process is: HR pings IT, IT disables Google Workspace, and… that's it. The departed employee still has access to Notion, GitHub, the marketing CRM, three AWS root keys, and the shared 1Password vault.

Fix: Build a written offboarding checklist that lists every SaaS app and the exact step to revoke access. Better: connect your identity provider (Google Workspace, Okta, Entra) via SCIM to every app that supports it, so disabling the user account auto-deprovisions everywhere. For apps without SCIM, automate the checklist in Jira or Linear so nothing slips.

2. Everyone is an admin "just in case"

It's faster to grant admin than to figure out the right scoped role, so admin counts creep up. Six months later, half your engineers have production database access they don't need, and your security questionnaire response is awkward.

Fix: Run a quarterly access review. Pull the admin list from each critical app, send it to the relevant manager, and require explicit confirmation that each person still needs the role. Default new hires to least-privilege roles and grant elevation only when asked.

3. Shared accounts and shared passwords

The "marketing@" Gmail with the password in a Slack channel. The billing portal that only allows one user. The legacy vendor that charges per seat so the team rotates one login.

Fix: Audit every shared credential. For apps that support it, move to individual accounts (the per-seat cost is almost always worth it). For the rest, store the credential in a password manager with audit logging and restrict the vault to people who currently need it.

4. No MFA enforcement on the apps that matter

Google Workspace MFA is on. Great. But your code repository, your cloud console, your customer database, and your finance tools? Often optional, often skipped.

Fix: Make a short list of "tier 1" apps — anything with customer data, source code, money movement, or production infrastructure — and enforce MFA at the app level, not just at the SSO level. Where SSO is available, route everything through it so MFA is enforced once and consistently.

5. No source of truth for "who has access to what"

When an auditor asks "show me the list of people with production database access as of last quarter," the answer is usually a scramble. There's no single place to look.

Fix: Pick one source of truth — usually your identity provider — and document it. Every app should be either (a) provisioned through SSO/SCIM, or (b) listed in a tracked manual process with a named owner. The goal isn't perfect tooling; it's being able to answer the question in under five minutes.

The pattern

Notice that none of these fixes require buying new software. Most IAM problems at growth-stage companies are process problems masquerading as tooling problems. The companies that get this right treat access like inventory: tracked, reviewed on a schedule, and owned by someone specific.

If any of these patterns sounded familiar, an IT stack audit is the fastest way to find every instance and prioritize the fixes that matter most for your next security review.