IAM cycle in action: a cashback-app startup

A Friday resignation

Daniel, a growth engineer at Rebate, resigns on a Friday. The moment HR marks him as terminated, the identity provider disables his identity and every connected application, GitHub, the cloud console, Slack, the observability stack, removes his account within seconds. Textbook. Then, on Monday, someone notices that Daniel can still sign into four tools: an email-outreach platform, an A/B testing service, a heatmap tool and a no-code automation app that holds API keys to production data. The growth team had signed up for all four on a company card. None of them were ever connected to single sign-on, so none of them heard that Daniel had left.

After the hospital, this is the other extreme. The operational cycle and the JML lifecycle are the same, but the obstacle here isn’t regulation or life-or-death urgency. It’s speed. A startup builds product faster than process, adopts tools faster than it governs them and treats every control as friction between it and the next release.

Rebate is a cashback app that pays users a share 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, it has raised a Series B, and it touches card data, bank connections and millions of consumer accounts. Its IAM question isn’t “how do we handle a regulatory maze?” but “how do we keep access sane while doubling headcount every nine months, without hiring a single dedicated IAM engineer?” The honest answer is that you don’t build a full IGA program at 95 people, and you shouldn’t try. The goal is the minimum viable JML loop: automated joiners and leavers through the identity provider, access driven by groups, and just-in-time elevation for the dangerous things. Get those three right and you’ve covered most of the risk for a fraction of the cost.

Four populations

Rebate has fewer kinds of identity than the hospital, but they behave more messily. About 80 full-time employees are hired fast and reorganized often, with Rippling as their HR system. About 15 contractors and agencies work on short projects and live in the same HR system’s contractor records. About 3.1 million consumers sign themselves up through the app’s own customer identity system. And about 250 service accounts and CI tokens are created by engineers in the cloud and the secrets manager and almost never retired.

Two things stand out. The consumers dwarf the workforce, but customer identity is a separate problem handled by the app itself; this article stays with workforce JML, where the operational cycle lives. And the service accounts and CI tokens are a population nobody manages: engineers create them to ship, and they outlive the feature, the project and sometimes the engineer. They’re orphans waiting to happen.

The identity provider is the control plane

Rebate has no IGA suite. What it has, and all it needs at this size, is an identity provider, Okta, set up as the single front door, with SCIM provisioning out to every SaaS application that supports it. The identity provider holds the mapping from groups to applications, 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 goes away.

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

It’s a deliberately light version of the operational cycle. HR is the authoritative source, the identity provider is both the master record and the provisioning engine, and groups are the role model. That gives automated joiners and leavers and group-driven movers, the core JML loop, without spending anything on IGA tools. The blind spot, drawn dashed, is everything outside the loop: tools a team signed up for with a credit card and a shared password and never connected to single sign-on. That shadow IT is where orphan accounts breed, and it’s where Daniel’s four tools lived.

Joiners: productive on day one, scoped by squad

Rebate’s joiner flow has to be fast, because a new engineer who can’t ship on day one is a visible cost in a company that measures everything in velocity. HR fires the hire event the moment the offer is signed, with a start date and a squad. The identity provider creates the identity and, using group templates per squad, assigns birthright access, email, Slack, documents and the HR portal, plus the squad’s role access, so an engineer gets the engineering group and a support agent gets the support tools. SCIM provisions every connected application before the start date, and the accounts switch on on day one. Sensitive access, production, the payments dashboard, exports of customer personal data, is not birthright. It has to be requested and approved, and more and more of it is time-limited.

The habit that saves Rebate later is calculating birthright from the squad attribute rather than copying a teammate. “Set the new person up like the last one” feels fast, but the last one may be an early employee carrying two years of accumulated grants. Use the role as the template, not a person.

Service accounts are joiners too, and nobody offboards them. Every CI pipeline, integration and cron job runs as an identity, and at Rebate they’re created in a hurry and never enter any lifecycle. Unless they’re treated as real identities with an owner and an expiry date, they become the largest pool of standing, unattended access in the company, exactly the kind of credential that turns up in breach post-mortems.

Movers: roles that blur

In a startup the mover is dangerous for a reason specific to small, fast companies: roles blur all the time and nobody drops anything. The person who shipped the payments feature is now on call for it, helps support debug it and pulls analytics about it. Every pivot adds access and no pivot removes any. By 95 people, Rebate’s earliest engineers hold sprawling permissions that match no current role, sediment accumulated one reasonable-looking grant at a time.

Fixing it doesn’t take an IGA suite, just a habit and a rhythm. Moves are driven by groups: when someone changes squad in HR, their old squad group is removed and the new one added, and because access is group membership, the removal really happens. Quarterly access reviews ask managers to confirm their team’s group memberships, which is light but catches what group changes missed. And for the dangerous tail, just-in-time access removes standing access to sensitive systems altogether, so there’s nothing left to creep. The honest test from the JML article applies harshly here: if changing squad removes the old access automatically, Rebate is at maturity level 3; if it only adds, every reorganization makes the sprawl worse.

Just-in-time production access

Rebate’s sharpest decision is not letting engineers hold standing production access at all. Standing access to production is the largest pool of dangerous privilege in any engineering organization and the one most likely to creep. So Rebate gets rid of it. Nobody has production access by default, and engineers ask for it just in time, limited in scope and duration, usually tied to an on-call shift or an open 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 Engineer
  participant BROKER as Broker
  participant ONCALL as On-call
  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)
  BROKER->>BROKER: Log grant with incident reference
  PROD->>PROD: Window expires, access revoked

That one pattern does a lot of work. It removes creep at the source, because there’s no standing production access to accumulate. It leaves a clean trail linking every touch of production to a person, a time window and a reason, which is exactly what a SOC 2 or PCI auditor wants to see. And it scales: as the team grows, the broker applies the rule to everyone the same way, instead of relying on people remembering who should have what.

Compliance without a compliance department

Being small doesn’t let Rebate ignore regulation. It touches card and bank data, so PCI DSS applies from day one, and its enterprise merchant partners and its investors want a SOC 2 report. Both care about the same JML basics: access granted by role, access removed promptly when people leave and periodic access reviews with evidence. The light stack, the identity provider as control plane, SCIM provisioning, group-driven access, just-in-time production access and quarterly reviews, happens to produce exactly the evidence those audits ask for. That’s no coincidence: the frameworks describe the same access hygiene that keeps a fast-growing company from drowning in its own sprawl, and building it early is cheaper than retrofitting it with auditors billing by the hour.

Back to Daniel’s four tools

Daniel’s departure shows where the light stack runs out. Everything behind single sign-on was gone in seconds. The four tools outside it were still open on Monday, and the automation app’s keys would have let him reach live data long after he’d returned his laptop.

What teams do about this is concrete and worth copying. They write down a rule, “single sign-on or it doesn’t get company data”: any tool that touches customer or production data has to sit behind the identity provider before anyone adopts it, which means pushing back on vendors who charge extra for single sign-on, or accepting that risk consciously and in writing. They add a way to discover SaaS, a SaaS-management platform or CASB, or at least a look through expense reports and DNS logs, to find the shadow tools the provisioning loop never sees. They give every application a named owner who is responsible for offboarding the accounts SCIM can’t reach. And they keep a written leaver runbook for the tail outside single sign-on, carried out and ticked off the same day rather than whenever someone remembers. The one process startups always skip is reconciliation, periodically listing the accounts in every application and flagging the ones with no matching identity. Even a manual quarterly sweep would have found Daniel’s four accounts, and it beats finding them in a breach report. The uncomfortable truth is that a startup’s biggest offboarding risk isn’t the systems it manages well, it’s the ones it doesn’t manage at all.

What teams actually run at this size

Before a company can justify a full IGA suite, real teams assemble a recognizable stack that delivers the JML loop cheaply. Lifecycle management built into the identity provider, such as Okta Lifecycle Management or Microsoft Entra ID Governance, drives joiners, movers and leavers straight from the HR feed. Access as code defines groups and role templates in Terraform or similar, so every change to who gets what is reviewed in a pull request and has a history, a light stand-in for formal access governance. Dedicated just-in-time tools for privileged access, such as Teleport or StrongDM, or cloud-native patterns like AWS IAM Identity Center permission sets with limited session lengths, are wired to the on-call schedule so elevation matches a real need. Quarterly access reviews, exported straight from the identity provider, produce the evidence a SOC 2 auditor expects. And a secrets manager, HashiCorp Vault or a cloud equivalent, gives every service account and CI token an owner, rotation and an expiry date, closing the gap for non-human identities.

Behind all of it is a direction rather than a product: keeping standing access to a minimum and checking every request is what NIST SP 800-207 describes as Zero Trust and what CISA’s Zero Trust Maturity Model lays out as a path, and a startup can adopt that stance long before it can afford the full toolset. None of this is enterprise IGA, and it doesn’t need to be. The skill is putting together 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”.

Two identity planes

Rebate has 3.1 million consumer accounts and 95 staff, and its most important architectural decision is keeping those two populations on separate identity planes: separate stores, separate threat models, separate teams responsible for them. The operational cycle and JML in this article govern the workforce; consumers are a customer IAM problem with their own domain later in the program.

Practitioners are firm about not blurring that line, because mixing them is how a compromised employee account becomes a customer data breach. The seam that needs 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 operations dashboard that can issue refunds. They’re governed as workforce tools but affect customers, so good practice gives them the strictest treatment in the company: no standing access, just-in-time elevation only and a full record of every consumer account an employee touches, the same kind of accountability the hospital applies to patient charts. A cashback app’s equivalent of a celebrity’s medical record is a high-value user’s balance, and the controls rhyme.

From 12 to 95 to 500

IAM at a startup isn’t a fixed design; it’s a series of “good enough for now” decisions, each of which should anticipate the next stage rather than paint the company into a corner. At about 12 people, Rebate ran on a shared Google Workspace where everyone was an admin, and the trap was letting “everyone’s an admin” harden into permanent god mode. At about 95, today, it runs on the identity provider with SCIM, groups, just-in-time production access and quarterly reviews, and the trap is believing that automated joiners mean you’re done. At about 500, it will need real IGA, role mining, automated certifications and separation-of-duties rules, and the trap will be buying enterprise tools before the data is clean enough to use them.

The founding stage is forgivable: twelve people who trust each other don’t need entitlement management. The danger is carrying founding habits into the scaling stage. The early engineers who were all admins quietly stay admins, and that standing access becomes the privilege creep the company will spend its next stage untangling. The single most useful move at that transition is making the identity provider authoritative and putting the founders’ own access through the same lifecycle as everyone else’s. Leadership exempting itself is how the model dies.

Thinking ahead also shapes today’s choices. Defining access as code now means that when Rebate buys a real IGA platform, it will have clean, reviewable role definitions to import rather than years of one-off grants to reverse-engineer. The cheapest time to get the data right is before there’s a lot of it.

What a startup should measure

A startup won’t run an enterprise metrics program, but a handful of numbers show whether the light loop is holding as headcount rises. Time to remove access on departure matters most, and it’s the first thing a SOC 2 auditor will ask for. Behind single sign-on it should be minutes; the gap between that and full removal including the tools outside single sign-on, Daniel’s four, is your real exposure. The automation rate, the share of access changes the identity provider makes without a ticket, should hold steady; if it falls as you grow, your “automated” program is quietly going back to manual. The number of people with standing privileged access, permanent production or admin rights, should be close to zero, with everything else going through just-in-time access. And the number of shadow tools discovered each quarter isn’t a failure if it rises; not measuring it is.

The honest test from the JML article fits a startup neatly. If a departure removes access everywhere within minutes, and a reorganization removes old access as reliably as it grants new, the light loop is real. If either depends on someone remembering, the company has confused moving fast with not looking.

When a layoff comes

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

The good practice is to rehearse it before it’s real. HR marks the whole group as terminated at a precise time and the identity provider 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 are revoked, not just sign-ins disabled, because someone mid-session keeps working until their token expires unless you actively end the session, exactly the gap that matters most when a departure is involuntary. The tail outside single sign-on is handled by the runbook, the same problem as Daniel’s four tools multiplied by twenty. And accounts are disabled, not deleted, and kept for handover and any investigation, because a layoff is precisely when you might later need to know what someone accessed in their last hours. A company that can offboard one person cleanly but falls apart offboarding twenty has a loop that only looks automated, and a startup is far more likely to face that day than a hospital.

What Rebate teaches

Rebate’s lessons apply to any fast-growing, lightly governed organization. Make the identity provider the control plane, because one front door beats fifty separately managed ones. Treat group membership as access, because if leaving a group removes access, your mover works. Get rid of standing privilege, because you can’t accumulate what doesn’t exist. Reconcile, because shadow IT breeds orphans and your provisioning loop has a blind spot, as Daniel’s Monday showed. And give service accounts owners and expiry dates, or they’ll outlive everyone.

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 removing access to governing it, and you accept a light loop that’s good enough today and ready to grow. The failure isn’t doing too little; it’s doing nothing and calling the resulting sprawl “moving fast”.

Three questions to test yourself

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