IAM cycle in action: a cashback-app startup

Same lifecycle, opposite battlefield

After the hospital, we swing to the other extreme. The operational cycle and JML lifecycle are the same — but here the obstacle isn’t regulatory complexity or life-safety. It’s speed. A startup builds product faster than it builds process, adopts tools faster than it governs them, and treats every control as friction standing between it and the next release.

Meet Rebate — a cashback app that pays users a slice of what they spend at partner merchants. Eighteen months ago it was twelve people in one room. Today it’s 95 across three time zones, having raised a Series B, and it now touches card data, bank connections, and millions of consumer accounts. The IAM question isn’t “how do we handle our regulatory maze” — it’s “how do we keep access sane while doubling headcount every nine months without hiring a single dedicated IAM engineer.”

The organization and its identity populations

Rebate’s populations are simpler than the hospital’s in number but messier in behavior:

Two things stand out. First, the consumer population dwarfs the workforce — but consumer identity (CIAM) is a separate problem governed by the app itself; this article stays on the workforce JML, which is where the operational cycle lives. Second, service accounts and CI tokens are a population nobody manages: engineers spin them up to ship, and they outlive the feature, the project, and sometimes the engineer. They’re orphans waiting to happen.

The identity provider is the whole control plane

Rebate has no IGA suite. What it has — and all it needs at this size — is an identity provider (Okta) wired as the single front door, with SCIM provisioning out to every SaaS app that supports it. The IdP holds the group-to-app mappings, so group membership is access: add someone to the “Engineering” group and they’re provisioned into GitHub, the cloud console, the observability stack, and the on-call tool; remove them and it all deprovisions.

flowchart LR
  accTitle: The startup identity control plane and its blind spot
  accDescr: The HRIS sends hire, change, and termination events to the identity provider, which assigns users to squad-based groups. Those groups provision SaaS apps automatically over SCIM. Outside this loop sits shadow IT — SaaS tools adopted by teams without SSO — which the provisioning loop does not reach and which become orphan accounts on departure.
  HRIS[HRIS<br/>Rippling] -->|hire / change / term| IDP[Identity provider<br/>Okta]
  IDP --> GROUPS[Squad-based groups]
  GROUPS -->|SCIM| SAAS[SSO-connected SaaS]
  SHADOW[Shadow IT<br/>SaaS without SSO]:::danger -.outside the loop.-> ORPHAN[Orphan accounts<br/>on departure]
  classDef danger stroke-dasharray: 5 5

This is a deliberately lightweight version of the operational cycle: the HRIS is the authoritative source, the IdP is the master record and the provisioning engine, and groups are the role model. It delivers automated joiner and leaver and a group-driven mover — the core JML loop — without a dollar spent on IGA tooling. The blind spot, drawn dashed, is everything outside the loop: tools a team signed up for with a credit card and a shared password, never connected to SSO. That shadow IT is where orphan accounts breed.

Joiner: productive on day one, scoped by squad

Rebate’s joiner has to be fast — a new engineer who can’t ship on day one is a visible cost in a company measuring everything in velocity. The flow:

• HRIS fires the hire event the moment the offer is signed, with a start date and a squad.
• The IdP creates the identity and, by squad-based group templates, assigns birthright (email, Slack, docs, the HR portal) plus the squad’s role access (an engineer gets the eng group; a support agent gets the support stack).
• SCIM provisions every connected app before the start date; accounts are enabled on day one.
• Sensitive access — production, the payments dashboard, customer PII exports — is not birthright. It’s requestable, with approval, and increasingly time-boxed.

The discipline that saves Rebate later is computing birthright from the squad attribute, not cloning a teammate. “Set up the new hire like the last one” feels fast, but the last one was a founder-era employee carrying two years of accumulated grants. Template from the role, not from a person.

Mover: the role-blur problem

In a startup the Mover is dangerous for a reason specific to small, fast companies: roles blur constantly and nobody sheds anything. The same person who shipped the payments feature is now on-call for it, helps support debug it, and pulls analytics on it. Every pivot adds access; no pivot ever removes it. By the time Rebate is 95 people, its earliest engineers hold sprawling permissions that map to no current role — pure sediment, accumulated one reasonable-seeming grant at a time.

The fix doesn’t require an IGA suite, just a discipline and a cadence:

• Group-driven moves: when someone changes squad in the HRIS, their old squad group is removed and the new one added — and because access is group membership, the removal actually happens.
• Quarterly access reviews: managers confirm their team’s group memberships. Lightweight, but it catches the access that group changes missed.
• JIT for the dangerous tail: rather than fight privilege creep on sensitive systems, remove standing access to them entirely (see below) so there’s nothing to creep.

The honest test from the JML article applies brutally here: if changing squads removes the old access automatically, Rebate is at maturity level 3; if it only adds, every reorg is making the sprawl worse.

The distinctive challenge: JIT production access

Rebate’s sharpest move is refusing to let engineers hold standing production access at all. Standing access to prod is the single largest pool of dangerous privilege in any engineering org, and it’s the privilege most likely to creep. So Rebate eliminates it: nobody has prod access by default, and engineers request it just in time, scoped and time-boxed, usually tied to an on-call shift or an active incident.

sequenceDiagram
  accTitle: Just-in-time production access for an on-call engineer
  accDescr: An on-call engineer requests elevated production access for an incident. The access broker checks they are on the active on-call rotation, grants a time-boxed role, logs the grant with the incident reference, and automatically revokes the access when the window expires.
  participant ENG as On-call engineer
  participant BROKER as Access broker
  participant ONCALL as On-call schedule
  participant PROD as Production
  ENG->>BROKER: Request prod access (incident #4821)
  BROKER->>ONCALL: Confirm active on-call shift
  ONCALL-->>BROKER: Confirmed
  BROKER->>PROD: Grant time-boxed role (2h)
  Note over BROKER,PROD: Logged with incident ref
  PROD->>PROD: Window expires → access auto-revoked

This single pattern does enormous work. It removes the creep problem at the source — there’s no standing prod access to accumulate. It produces a clean audit trail that maps every production touch to a person, a time window, and a reason, which is precisely what a SOC 2 or PCI auditor wants to see. And it scales: as the team grows, the broker enforces the rule uniformly instead of relying on everyone remembering who should have what.

Compliance without a compliance department

Rebate can’t ignore regulation just because it’s small. It touches card and bank data, so PCI-DSS applies from day one, and its enterprise merchant partners and investors demand a SOC 2 report. Both frameworks care about the same JML fundamentals: access granted by role, terminated users deprovisioned promptly, and periodic access reviews with evidence.

The lightweight stack — IdP as control plane, SCIM provisioning, group-driven access, JIT for prod, quarterly reviews — happens to produce exactly the evidence those audits demand. That’s not a coincidence: the frameworks encode the same access hygiene that keeps a fast-growing company from drowning in its own sprawl. Building JML early is cheaper than retrofitting it under audit pressure with auditors billing by the hour.

A leaver walkthrough: SaaS sprawl in practice

Theory meets reality when someone leaves. Daniel, a growth engineer, resigns on a Friday. The moment HR marks him terminated, the IdP disables his identity and SCIM deprovisions every connected app — GitHub, the cloud console, Slack, the observability stack — in seconds. So far, textbook.

Then the gaps show. The growth team adopted four tools on a company card that were never wired to SSO: an email-outreach platform, an A/B-testing service, a heatmap tool, and a no-code automation app holding API keys to production data. None are in the IdP, so none deprovision. Daniel still has standing logins to all four on Monday — and the automation app’s keys would let him reach live data long after his laptop is returned.

What practitioners do about this is concrete and worth copying:

• “SSO or it doesn’t get company data” as written policy. Any tool touching customer or production data must be behind the IdP before it’s adopted — pushing back on the so-called “SSO tax” some vendors charge, or accepting that risk consciously and in writing.
• A SaaS discovery capability — a SaaS-management platform or CASB, or at minimum expense-report and DNS log review — to surface the shadow apps the provisioning loop never sees.
• A per-app system-of-record owner, so every tool has a human accountable for offboarding the accounts SCIM can’t reach.
• A written leaver runbook for the non-SSO tail, executed and checked off the same day, not whenever someone remembers.

The uncomfortable truth is that the startup’s biggest offboarding risk isn’t the systems it manages well — it’s the ones it doesn’t manage at all.

What practitioners actually run at this scale

Before a company can justify a full IGA suite, real teams assemble a recognizable best-practice stack that delivers the JML loop cheaply:

• IdP-native lifecycle management as the engine — Okta Lifecycle Management or Microsoft Entra ID Governance drive joiner/mover/leaver straight from the HRIS feed.
• Access as code: groups and role templates defined in Terraform or similar, so every change to who-gets-what is reviewed in a pull request and has a git history — the lightweight stand-in for formal access governance.
• Purpose-built JIT for privileged access — tools like Teleport or StrongDM, or cloud-native patterns (AWS IAM Identity Center permission sets with bounded session duration) — wired to the on-call schedule so elevation maps to a real need.
• A Zero Trust direction of travel: minimizing standing access and verifying per request is exactly what NIST SP 800-207 describes and what CISA’s Zero Trust Maturity Model lays out as a path — a startup can adopt the posture long before it has the budget for the full toolset.
• Quarterly user access reviews, exported straight from the IdP, producing the evidence a SOC 2 auditor expects under its access-control criteria.
• A secrets manager (HashiCorp Vault or a cloud-native equivalent) giving every service account and CI token an owner, rotation, and expiry — closing the non-human-identity gap.

None of this is enterprise-grade IGA, and it doesn’t need to be. The skill is assembling a coherent loop from tools the company already pays for, pointed in the direction the frameworks endorse, so that “good enough today” is also “ready to grow tomorrow.”

Workforce and consumer identity: one company, two planes

Rebate has 3.1 million consumer accounts and 95 staff, and the single most important architectural decision is to keep those two populations on separate identity planes — separate stores, separate threat models, separate teams of record. The operational cycle and JML in this article govern the workforce; the consumers are a CIAM problem with its own domain later in the program.

Practitioners are emphatic about not blurring the line, because conflating them is how a workforce compromise becomes a customer-data breach. The seam that demands the most care is the set of internal admin tools that act on consumer data — the support console that can read a user’s wallet, the ops dashboard that can issue refunds. Those are workforce-governed but consumer-impacting, so best practice gives them the strictest treatment in the whole company: no standing access, JIT elevation only, full audit of every consumer record an employee touches — the same break-glass-style accountability the hospital applies to patient charts. A cashback app’s “celebrity record” is a high-value user’s balance, and the controls rhyme.

The maturity journey: 12 to 95 to 500

IAM at a startup isn’t a fixed design — it’s a sequence of “good enough for now” decisions, each of which should anticipate the next stage rather than paint into a corner. Rebate’s arc is the one practitioners recommend deliberately walking:

The founding stage is forgivable — twelve people who trust each other don’t need entitlement management. The danger is carrying founding-era habits into the scaling stage: the early engineers who were all admins quietly stay admins, and that standing access becomes the privilege creep that the company will spend its consolidating stage untangling. The single highest-leverage move at the scaling transition is to make the IdP authoritative and put the founders’ own access through the same lifecycle as everyone else’s — leadership exempting itself from the model is how the model dies.

Anticipating the consolidating stage shapes today’s choices too. Defining access as code now means that when Rebate buys a real IGA platform, it already has clean, reviewable role definitions to import rather than a decade of ad-hoc grants to reverse-engineer. The cheapest time to get the data right is before there’s a lot of it.

Metrics a startup should actually track

A startup won’t run an enterprise metrics program, but a handful of numbers tell it whether the lightweight loop is holding as headcount climbs:

• Time-to-deprovision on departure — the single number that matters most, and the one a SOC 2 auditor will ask for first. Behind SSO it should be minutes; the gap between that and full removal including the non-SSO tail is your real exposure.
• Provisioning automation rate — the share of access changes the IdP executes without a ticket. If this falls as you grow, your “automated” program is quietly reverting to manual.
• Standing privileged access count — how many people hold permanent prod or admin access. The goal is a number near zero, with everything else flowing through JIT.
• Shadow-IT discovery count — apps found outside the IdP per quarter. A rising number isn’t failure; not measuring it is.

The honest test from the JML article restates cleanly for a startup: if a departure removes access everywhere within minutes, and a reorg removes old access as reliably as it grants new, the lightweight loop is real. If either depends on someone remembering, the company has confused moving fast with not looking.

When a layoff hits: the mass-leaver stress test

Startups don’t only grow — they correct. A funding round that doesn’t close, a pivot, or a restructuring can turn into a layoff that offboards twenty people in a single hour. The mass leaver is where a JML loop proves itself or fails publicly, because every weakness that’s tolerable one-at-a-time becomes acute at scale and under emotional pressure.

The best practice practitioners follow is to rehearse it before it’s real:

• A single trigger, executed simultaneously. HR marks the cohort terminated at a precise time, and the IdP disables and deprovisions them all at once — not a manager working down a list while the first people offboarded warn the rest.
• Sessions and tokens revoked, not just logins disabled. Someone mid-session keeps working until their token expires unless you actively kill sessions — exactly the gap that matters most when a departure is involuntary.
• The non-SSO tail handled by runbook, the same shadow-IT problem from the leaver walkthrough, now multiplied across twenty people simultaneously.
• Disable, don’t delete. Retain the accounts for handover and any investigation; a layoff is precisely when you may later need to know what someone accessed in their final hours.

A company that can offboard one person cleanly but melts down offboarding twenty has a loop that only looks automated. The mass leaver is the honest stress test, and a startup is far more likely to face it than a hospital is — which is exactly why building the loop properly while small pays off when the hard day comes.

What this case teaches

Rebate generalizes to every fast-scaling, lightly-governed organization:

The deepest lesson is that good IAM at startup scale isn’t a smaller version of enterprise IGA — it’s a different shape. You lean on the identity provider, you prefer eliminating access over governing it, and you accept a lightweight loop that’s “good enough” today and ready to grow. The failure mode isn’t doing too little; it’s doing nothing and calling the resulting sprawl “moving fast.”

Three questions to test yourself

1. Rebate cuts SSO-connected accounts instantly when someone leaves, yet a departing engineer still had access to an analytics tool a week later. Explain how that happened and what one process would have caught it.
2. An engineer says JIT production access “slows down incident response.” How do you design the JIT flow so it adds seconds, not minutes — while keeping the audit trail intact?
3. Rebate’s first five employees each hold access mapping to no current role. Which JML step failed over two years, why does this happen fastest in startups, and what cadence would stop it without hiring an IAM team?