What's new in SCIM 2.0: Pagination, events, and device schema

SCIM 2.0 shipped as RFC 7643 and RFC 7644 back in September 2015, and for most of the last decade it looked frozen. If you built a SCIM integration any time in the last few years, you built it against those two documents and never had a reason to look again.

That's changed. The IETF SCIM working group has shipped three new RFCs in the last year: cursor based pagination, a standard events profile, and a device schema extension. None of them break your existing implementation, but each one addresses a real limitation that anyone running SCIM at scale has probably already hit. Here's what each one actually does, and what to do about it.

RFC 9865: cursor based pagination

The problem. SCIM 2.0 paginates with startIndex and count. To get page three, you tell the server "skip 200, give me 100 more." That's fine for a directory of a few hundred users. It falls apart once you're syncing tens of thousands.

Two things go wrong at scale. First, offset pagination is slow for the server to compute on large result sets, since many backends have to walk through every skipped record to figure out where page three actually starts. Second, and more dangerous, offsets aren't stable. If a user is added or removed while you're paging through results, every subsequent offset shifts, and you can silently skip or double count records. For something as security sensitive as user provisioning, that's not a cosmetic bug.

The fix. RFC 9865 adds an opaque cursor: instead of asking for "items 101 to 200," the server hands you a nextCursor token in the response, and you pass that token back to get the next page. The server decides what the token encodes and how to resolve it, so it can point directly to the right spot in the result set instead of recomputing an offset. It's the same shift most modern REST APIs already made years ago.

What it costs you. This isn't free. A cursor usually represents server side state, whether that's a snapshot, a keyset position, or a short lived query plan, and that state needs a lifecycle: something like a five to thirty minute expiry is typical, after which the cursor should be treated as invalid. The RFC is also explicit that authorization has to be rechecked on every cursor request rather than cached from the first page, since a user's permissions can change mid pagination. And it explicitly allows a server to omit totalResults entirely if computing it efficiently isn't practical with the underlying storage. If any of your client code assumes totalResults is always present, this is worth checking before you rely on it.

Should you build it now? Cursor pagination is additive and optional. A server can keep offset pagination and never touch this. It's worth prioritizing if you're paginating directory syncs in the tens of thousands of users or higher, or if you've seen inconsistent results on large syncs. For most small to mid sized directories, offset pagination remains perfectly adequate.

RFC 9967: a SCIM profile for security event tokens

The problem. Today, if you want to know about provisioning changes as they happen rather than by polling, you're on your own. Most SCIM providers bolt on webhooks, but webhooks aren't part of the SCIM spec, so every IdP does it differently: different payload shapes, different retry behavior, no shared guarantee about delivery or ordering. Miss one event and there's no standard way to even know you missed it.

The fix. RFC 9967 defines a standard way to represent SCIM lifecycle changes (create, update, deactivate, delete) as Security Event Tokens, the same token format used by CAEP and RISC in the broader shared signals ecosystem (RFC 8417). It also adds an optional asynchronous request mode, so a service provider can acknowledge a SCIM request immediately and deliver the actual event separately once processing finishes, rather than blocking the response.

Why this matters more than it sounds. This is effectively the industry standardizing something several vendors already built ad hoc. If you've ever compared "webhooks vs. an events API" for SCIM, you've already been living the exact tradeoff this RFC formalizes: webhooks are simple and familiar, but fire and forget, with no built in ordering or replay guarantee. A structured events profile with defined subject identifiers and transaction ordering is what makes a reliable events API possible in the first place, rather than something each provider reinvents.

What to watch for. SET based delivery still needs a receiver and a transport, so this doesn't replace your existing webhook or events infrastructure overnight. Where it matters is IdP interoperability: if identity providers start emitting SCIM events in this format natively, service providers get a consistent shape to build against instead of a different one per vendor.

RFC 9944: device schema extensions

The problem. SCIM's core schema covers exactly two resource types: Users and Groups. There's never been a standard way to represent a managed device in SCIM, even though device state (is it managed, is it compliant, what's its posture) increasingly factors into access decisions alongside identity.

The fix. RFC 9944 defines a device resource type and schema, giving identity providers and service providers a shared vocabulary for representing managed devices the same way they already represent users: standard attributes, standard endpoints, extensible for vendor specific fields.

Who this actually affects. If you're building a typical B2B SaaS product and provisioning human users, this one is mostly background noise. It matters more directly to MDM and UEM vendors, and to any product that ties access decisions to device compliance (conditional access style policies, where "this user is valid but this device isn't managed" should block access). If that's not a pattern you support today, there's no urgency to act on this one.

What's still in draft (and not ready to build against)

A few other proposals are moving through the SCIM working group but haven't shipped as RFCs, so treat these as directional rather than something to implement:

• Contextual roles. SCIM 2.0's roles attribute is flat: a user has a role, full stop. Two competing drafts (scim-role-assignment and scim-roles-entitlements) are trying to solve the much more common real world case of a user having different roles in different projects or tenants.
• Agentic identity. As AI agents get provisioned and deprovisioned like any other identity, multiple drafts are competing to define how SCIM represents them, with discussion converging at recent IETF meetings but no single agreed shape yet.

Both are worth tracking if you're designing schema decisions today that might need to accommodate them later, but neither is stable enough to build against.

The practical takeaway

None of these three RFCs require you to do anything today. If you're on a managed provider, this kind of spec evolution is exactly the maintenance burden you're paying to avoid, and it's worth confirming your provider tracks working group output rather than freezing on the 2015 baseline. If you're running a homegrown SCIM endpoint, cursor based pagination is the one item on this list worth actually planning for, especially if you've already felt the pain of large directory syncs drifting or timing out. The other two are worth knowing about, but not worth interrupting a roadmap for.

This is also exactly the kind of spec churn that makes building SCIM in house a moving target rather than a one time project. WorkOS Directory Sync keeps pace with working group output like this so you don't have to track IETF drafts alongside your own roadmap. It supports both webhooks and an Events API for real time provisioning updates, handles the pagination and attribute quirks that differ across Okta, Entra ID, Google Workspace, and every other major IdP, and lets you ship a production ready SCIM integration in days instead of months.

‍Get started with WorkOS Directory Sync.