Toro Labs

Designing Identity Systems at Scale: Lessons from Supporting 50,000 Users

Identity and Access Management is often treated as a supporting function—something that sits behind the scenes and “just works.”

In reality, IAM is one of the most critical pieces of infrastructure in any organization. When identity systems are well-designed, everything else operates smoothly. When they are not, the result is constant friction, inconsistent access, and increased operational risk.

Over the past decade, I’ve led the architecture and development of an IAM platform supporting approximately 50,000 users across faculty, staff, students, and alumni. The most important lessons learned had very little to do with specific tools or vendors.

They came from dealing with real-world complexity.

Identity Is Not Static — It’s a Lifecycle

The most common mistake in IAM design is treating identity as a static object.

In reality, identity is a continuously evolving lifecycle.

Users:

  • Join the organization
  • Change roles
  • Gain and lose affiliations
  • Move across departments
  • Eventually leave

Each transition has implications for access, permissions, and system state.

If your system doesn’t model these transitions explicitly, you end up with:

  • Access drift
  • Orphaned accounts
  • Inconsistent permissions across systems

The key is not just provisioning—it’s lifecycle orchestration.

This means:

  • Clearly defined states (e.g., applicant → active → inactive → terminated)
  • Deterministic transitions
  • Automated enforcement of access changes

Without this, IAM becomes reactive instead of authoritative.

The Real System Is the Integration Layer

Most IAM discussions focus on:

  • Directories
  • Authentication systems
  • Provisioning tools

But in practice, the real system is the integration layer.

Your IAM platform doesn’t exist in isolation—it sits at the center of:

  • Active Directory
  • LDAP
  • SSO systems (e.g., Shibboleth)
  • MFA providers (e.g., Duo)
  • Email systems
  • Learning platforms
  • HR and source-of-truth systems

Each of these has:

  • Different data models
  • Different availability characteristics
  • Different failure modes

The challenge is not connecting them—it’s normalizing and controlling the interactions between them.

A well-designed integration layer should:

  • Abstract system-specific differences
  • Enforce consistent data contracts
  • Isolate failures
  • Support retries and idempotency

Without this, every new integration increases fragility.

Reliability Is the Feature

IAM systems are often evaluated based on features:

  • Provisioning capabilities
  • SSO integrations
  • MFA options

In practice, none of that matters if the system is not reliable.

When IAM fails:

  • Users can’t log in
  • Systems become inaccessible
  • Business operations stop

Reliability must be treated as a first-class requirement.

This includes:

  • End-to-end observability
  • Structured logging across systems
  • Proactive validation
  • Rollback strategies

One of the most impactful improvements we implemented was testing authentication changes against real integrations before production.

This surfaced issues that synthetic or isolated tests never would have caught.

Define a Single Source of Truth (and Enforce It)

In multi-system environments, one of the fastest ways to introduce inconsistency is to allow multiple systems to act as authorities.

For example:

  • HR system defines employment status
  • Directory defines group membership
  • Application defines role assignments

If ownership is not clearly defined, conflicts become inevitable.

A robust IAM design requires:

  • explicit ownership of each data domain
  • controlled synchronization flows
  • clear precedence rules

Without this, systems begin to diverge, and reconciliation becomes a constant burden.

Design for Failure, Not Just Success

In ideal conditions, everything works:

  • Systems are available
  • Data is consistent
  • Operations succeed

But real systems operate under non-ideal conditions:

  • APIs fail
  • Network latency increases
  • Downstream systems return partial data

If your design assumes success, it will fail under load.

Instead, systems should be designed to:

  • Tolerate partial failure
  • Retry safely (idempotently)
  • Queue and replay operations
  • Degrade gracefully when dependencies are unavailable

Introducing asynchronous processing (e.g., message queues) can significantly improve resilience in these scenarios.

Simplicity Scales — Complexity Breaks

There is a strong temptation to over-engineer IAM systems:

  • Overly flexible policy engines
  • Deeply nested role hierarchies
  • Excessive abstraction layers

While these may seem powerful, they often introduce fragility and make systems harder to reason about.

The most resilient systems tend to have:

  • Clear boundaries
  • Predictable behavior
  • Minimal implicit logic

Simplicity is not a lack of capability—it is a design choice that enables long-term stability.

IAM Is Foundational Infrastructure

Identity systems are often categorized as supporting services.

In reality, they are foundational infrastructure.

They determine:

  • Who can access systems
  • How systems trust each other
  • How data flows across the organization

When designed well, they enable:

  • Secure collaboration
  • Efficient onboarding
  • Consistent user experiences

When designed poorly, they become a constant source of operational friction.

Final Thought

Most IAM challenges are not caused by missing features.

They are caused by:

  • Unclear ownership
  • Inconsistent data models
  • Fragile integrations
  • Lack of lifecycle design

The goal is not to build a system that works.

It’s to build a system that continues to work as complexity grows.

That’s where real engineering begins.

Derek Toro