SCIM webhooks vs. the new SET-based events model

If you've built or integrated with more than one SCIM provider, you've probably noticed that "real time provisioning updates" means something different depending on who you ask. Some providers fire a webhook on every user change. Others expose an events API you poll. The payload shapes never quite match, retries are inconsistent, and there's no standard way to know whether you've missed an event or received a duplicate.

That's the gap RFC 9967 was written to close. Published in May 2026 by authors from Cisco, SailPoint, and Workday, it defines a formal SCIM profile for Security Event Tokens, giving the industry a standardized shape for the exact problem every provider has been solving separately for years. It's worth understanding both what it fixes and, just as importantly, what it leaves for you to build yourself.

What ad hoc webhooks actually get wrong

Webhooks aren't a bad idea. They're just not a standard, and the gap between "works" and "standardized" shows up in a few predictable ways once you're integrating with more than one provider.

• ‍Payload shape. There's no shared schema for what a provisioning event looks like. One provider sends the full changed resource, another sends only the changed fields, a third sends an internal event type string you have to map yourself. Every new provider integration means reading their docs and writing bespoke parsing logic.‍
• Delivery guarantees. Most webhook implementations are fire and forget. If your endpoint is down for thirty seconds, whether that event is retried, queued, or silently dropped depends entirely on the provider's internal retry policy, which is rarely documented in detail and never consistent across vendors.‍
• Ordering and replay. Nothing about a webhook payload tells you whether it arrived out of order relative to another event for the same user, or whether you're seeing the same event twice after a retry. Handling both correctly means building your own deduplication and sequencing logic on top of whatever the provider hands you, and building it again for every provider with slightly different assumptions.‍
• Integrity. A typical webhook is an unsigned JSON POST, or signed with a provider specific HMAC scheme that isn't part of any shared standard. Verifying that an event actually came from who it claims to, rather than trusting the payload at face value, is left entirely up to you.

What RFC 9967 actually standardizes

RFC 9967 doesn't invent a new event format from scratch. It profiles an existing one: the Security Event Token, defined in RFC 8417, which is the same underlying format used across the broader shared signals ecosystem for standards like CAEP and RISC. A SET is a signed JWT, which means every event arrives with the integrity and verifiability guarantees that come from JWT signing, rather than a provider specific HMAC scheme you have to reverse engineer.

Structurally, a SET carries the standard JWT claims (issuer, issued at time, a unique token ID) plus an events claim that maps one or more event URIs to their event specific details. That event URI is the standardized part ad hoc webhooks never had: instead of every provider inventing its own string for "user deactivated," there's a registered, shared vocabulary for what happened.

A simplified illustration of the shape, not a literal spec quotation:

  
{
  "iss": "https://idp.example.com",
  "iat": 1717430400,
  "jti": "8b1e2f40-unique-event-id",
  "aud": "https://app.example.com/scim/events",
  "events": {
    "urn:ietf:params:scim:event:deactivate": {
      "id": "2819c223-user-id",
      "resourceType": "User",
      "ref": "https://idp.example.com/scim/v2/Users/2819c223"
    }
  }
}
  

The specification also updates the core SCIM schema in two concrete ways. It adds new attributes to the ServiceProviderConfig schema (from RFC 7643) so a service provider can formally advertise whether and how it supports SCIM events, rather than that being something you discover through documentation or trial and error. And it adds an optional asynchronous request mode to the core protocol (RFC 7644), so a service provider can acknowledge a SCIM request immediately and deliver the actual completion event separately, instead of holding the connection open until processing finishes.

It's worth noting this shipped as a standards track document, not an informational one, the same track RFC 7643 and RFC 7644 themselves are on. That's a stronger signal of intended long term adoption than most of the other recent SCIM RFCs.

Webhooks vs. the SET profile, side by side

What it doesn't fix

RFC 9967 standardizes the shape and integrity of the event. It doesn't hand you a transport, a message queue, or a guaranteed at-least-once delivery contract the way a system like Kafka or SQS would. You still need somewhere to receive these tokens, and you still need to decide how to handle a receiver that's temporarily unavailable. What changes is that the event you receive, once you do receive it, has a verifiable, standardized shape, rather than being whatever a given provider decided to send.

It also doesn't retroactively fix existing provider implementations. Adoption is opt in and depends on providers actually implementing the profile and advertising it, so for the near term, expect a mixed environment: some providers on SET based events, others still on their existing ad hoc webhook setup, for a while yet.

When it's actually worth adopting

If you're building or maintaining a SCIM service provider today, here's a reasonable way to think about it rather than adopting reflexively because a new RFC exists:

• If you're integrating with a specific provider that's already advertising SET support in its ServiceProviderConfig, it's worth building against the standard now rather than a bespoke integration, since you get signed integrity and a shared event vocabulary essentially for free.
• If you're maintaining your own SCIM service provider and want to reduce integration friction for the identity providers connecting to you, advertising SET support is a way to differentiate on interoperability rather than asking every IdP to conform to your bespoke webhook shape.
• If your current webhook setup already works reliably for the providers you actually integrate with, there's no urgency to migrate. This is additive, not a deprecation of anything.

The practical takeaway

This is the same pattern as the other recent SCIM RFCs: the standard is formalizing something several vendors had already been solving informally, which is exactly what standards are supposed to do once an ad hoc pattern proves durable enough to be worth agreeing on. If you've ever compared your own webhook or events API setup against a competitor's and found the two didn't quite match, RFC 9967 is the industry's answer to why that kept happening, and a path toward it not happening the next time.

This is also precisely the kind of standardization work that's easier to benefit from when someone else is tracking it for you. WorkOS Directory Sync delivers provisioning updates via both webhooks and an Events API today, and keeping pace with standards like RFC 9967 as provider adoption grows is exactly the maintenance burden Directory Sync is meant to absorb, so your integration code doesn't have to change every time the underlying standard does. See how WorkOS handles identity provisioning.