A login claim refreshes at login. A leaver never logs in again—so nothing ever re-checks, and nothing gets revoked.
Every enterprise PAM buyer has offloaded the same thing to their identity provider: SSO, MFA, directory sync. Okta or Auth0 or Entra ID handles who this person is and whether they proved it. That part is solved, and it's not where a PAM earns its evaluation.
What the IdP hands off is a claim—a token that says "this user authenticated, and here is their group membership." A claim is not an authorization. It's not a role. It's definitely not a Linux account on server db-prod-04. Somewhere between the IdP's assertion and a session actually opening on a host, four things have to happen, in order, and every one of them is the PAM's job, not the IdP's. This is identity mapping: the chain that resolves a login into a specific host account.
- Claim → internal principal. The IdP's assertion becomes a user record inside the PAM.
- Principal → RBAC role. The user's group membership resolves into an actual permission set.
- Role → host account. The permission set determines which OS-local accounts this person may reach, and where.
- Lifecycle event → all of the above, reversed. When the person leaves, every downstream grant has to unwind.
Buyers rarely ask about this chain directly, because "do you support SSO" is the wrong question—everyone does. The right question is whether the four handoffs are wired together, or whether step one lights up a green checkmark while steps two through four quietly assume someone will handle it by hand.
Two claim shapes, two failure modes
The industry solves the first handoff two ways, and the choice matters for what breaks later.
Okta's approach is a raw groups claim: a JSON array of group names riding the ID token, capped in most flows at 100 groups per user—go over that and the request fails outright, though the authorization-code flow a PAM would actually use is exempt from the limit. Entra ID's raw groups claim runs into the same kind of wall from the other side: it caps emission at 200 groups per JWT, 150 per SAML assertion, and going over doesn't truncate the list—it swaps the claim for an overage marker that sends the app to look membership up in Microsoft Graph instead. Entra's cleaner pattern, App Roles, is Microsoft's documented way to avoid that group-overage path: the application declares its roles in its own registration, the customer assigns directory groups to them inside Entra, and the token carries a roles claim of values resolved upstream. Group assignment to an app role takes Entra ID P1—a free tenant cannot do it. Group claims force the receiving app to do its own group→role resolution at scale, and can run into a size limit doing it; role claims push that resolution into the IdP, where the customer's own admins already govern it.
The second axis is timing, and it's the one that determines whether offboarding is even possible. A claim on a login token only updates when the user logs in again—SCIM provisioning is different: the IdP writes membership changes to the application out of band of login, on its own schedule, so a termination propagates without waiting for the person to come back. A login-time-only consumer can provision a new hire fine. It structurally cannot deprovision someone who never logs in again—there's no event to trigger it. Mature identity stacks run both: SCIM for the lifecycle, the token claim for at-login resolution.
The offboarding half fails silently, not loudly
Handoff four is really two chains layered on top of each other: onboarding (grant access when someone joins or moves) and offboarding (revoke it completely when they leave). They fail in different ways. A broken RBAC mapping on the onboarding side shows up as a support ticket the same day—someone can't reach the server they need, and it gets fixed because someone is standing there asking for it.
A properly wired leaver cascade doesn't just flip a status flag on the account—it terminates every live session tied to that identity and blocks reuse of any credential already issued, the moment the trigger fires. That's the actual shape of "offboarded": not "marked inactive," but "killed and locked." A broken leaver cascade shows up as nothing. For months, an account can sit there, unused and unrevoked, until a SOC 2 access review or an incident postmortem asks for the list of terminated employees and cross-references it against who still has a live account. HIPAA's own rule illustrates the gap: it requires a periodic evaluation (§164.308(a)(8)) but names no interval, and its termination-procedures spec (§164.308(a)(3)(ii)(C)) is addressable—the entity picks the mechanism. Neither sets a clock, which is exactly how a stale account lingers long enough to matter. Loud on the way in, silent on the way out: that's the actual shape of the fourth handoff's failure mode.
That failure mode narrows to two concrete things once every action requires re-authenticating into a fresh session rather than reusing standing access: whatever session was already live the moment someone left, and whatever credential never went through a session at all. A stale role or host-account mapping grants nothing by itself if getting back in means re-proving identity against an IdP that already knows the person is gone—which, unlike the downstream PAM cleanup, is usually the one offboarding step organizations actually get right on day one. What the leaver trigger has to kill immediately is narrower than "clean up every downstream record": it's the sessions already open at that instant, plus any service token or long-lived credential that was never gated by a session to begin with.
Where this leaves the binding layer itself
There's a fifth thing buried inside handoff three that's worth separating out, because it's genuinely under-discussed: once a role resolves, what does it actually bind to on the host? A role saying "this person can reach db-prod-04" isn't the same as a decision about which OS-local account they land in when they get there—and most infrastructure has accounts nobody remembers creating: ubuntu, ec2-user, a service account three people share.
Alpacon treats this as a governance question rather than an afterthought: a shared account like ubuntu or ec2-user, reached through Alpacon, is RBAC-gated, attributed to the actual person behind the login, and recorded on the session—not written off as unmanaged just because nobody remembers who set it up.
Table stakes, not the moat
The first three handoffs—claim, principal, role—aren't where Alpacon wins an evaluation. They're where a PAM cannot afford to lose one: every legacy and modern PAM vendor has some version of claim-to-role-to-host mapping, and buyers correctly expect it to just work. The interesting, defensible layer sits one step further down: once an identity has actually resolved onto a host account, what happens to the commands that account runs. That's a separate question from who this person is—it's what they're allowed to execute once they're in—a command an agent sends through Alpacon's command API is risk-scored, and one that lands in the grey zone is matched against the session's declared purpose, not just against command text.
If your last access review took longer than it should have because nobody could say with confidence who still had a live account three months after they left, that's the identity-mapping chain failing at exactly the handoff this piece named. Identity mapping gets someone to the door; what happens after they walk through it is a different problem.
