Identity and access management for a growing team

Access control that worked fine at 10 people becomes a real liability at 50 — and the transition point is more predictable, and more manageable, than most growing teams expect.

Why informal access management breaks down at scale

At small scale, access decisions are often made informally — someone asks for access to a system, someone with admin rights grants it, and there's enough shared context across a small team that over-permissioning rarely causes real problems because everyone roughly knows what everyone else is doing. Past a certain size, that shared context disappears: nobody has full visibility into who has access to what, offboarding gets inconsistent, and the gap between "who should have access" and "who actually has access" grows quietly until an audit or incident exposes it.

The core structural fix: role-based access control

Rather than granting access permission-by-permission on request, we build role-based access control (RBAC): defined roles (e.g., "sales rep," "finance admin," "engineering lead") with a documented, pre-approved set of system permissions attached to each role. Onboarding someone becomes assigning them a role, not an ad-hoc series of individual access grants — which is both faster for the new hire and inherently auditable, because the permission set for any role is defined and reviewable, rather than being an accumulation of individual historical decisions nobody remembers the reasoning for.

SSO and MFA as the foundation, not optional extras

Single sign-on (via Okta, Azure AD, or similar) centralizes authentication, which does two critical things: it makes offboarding actually complete (disable one central account rather than hunting down access across a dozen separate systems, where the seventh one always gets missed), and it enables consistent multi-factor authentication enforcement across every connected system rather than MFA being inconsistently applied system by system. We treat SSO plus enforced MFA as baseline infrastructure for any team past roughly 15-20 people, not an advanced security upgrade.

The offboarding gap that causes the most real incidents

In our access audits, the single most common finding is departed employees retaining active access weeks or months after leaving — not through malicious intent, just process gaps, especially for systems that weren't connected to central SSO and required a separate manual deprovisioning step someone forgot. We build automated deprovisioning tied directly to HR systems: when someone's employment status changes, connected system access gets revoked automatically, without depending on IT remembering a manual checklist item.

A concrete example

A professional services firm growing from 22 to 60 people over a year came to us after an access audit (prompted by a client security questionnaire) found 11 former employees, some departed over 8 months prior, with still-active access to at least one connected system. We implemented Okta as a central identity provider, migrated their core systems to SSO, built RBAC-defined roles for their main job functions, and connected deprovisioning to their HR system's offboarding workflow. A follow-up audit six months later found zero instances of access surviving employment termination by more than 24 hours.

How Ndakum approaches it

Identity and access management is foundational to our Cybersecurity work — we typically build this on Okta or Azure AD, with RBAC design and automated offboarding as standard, not optional, components.