SCIM vs. SFTP Provisioning: Practical Tradeoffs
SCIM is the right answer in theory. In practice, the platform's SCIM implementation usually has opinions about that.
The Problem With "We Support SCIM"
Every enterprise platform says they support SCIM. What that actually means varies significantly.
I've worked with platforms where the SCIM endpoint only handles user creation and read. Deprovisioning doesn't work. Group assignment doesn't work. You discover this during testing, not from the documentation, because the documentation says "SCIM 2.0 supported" and nothing else. Running a 10,000-user initial sync and watching it hit an undocumented rate limit at user 3,000 is the other version of this problem.
Before you commit an enterprise client to a SCIM integration, test the specific operations they need: provisioning, deprovisioning, attribute updates, group assignment. Not just create and read.
SCIM When It Actually Works
When the IdP and the platform both have solid SCIM implementations, it's close to invisible. Changes in Entra ID or Okta propagate in near real-time. An employee is terminated, their access is revoked within minutes. That's a real security and compliance win, and it's the version of SCIM that gets demoed.
The rough edges:
Entra ID sends SCIM updates as PATCH requests. Some platforms only handle PUT, which means attribute updates either fail silently or error out. Entra ID also has rate limits on outbound SCIM calls during large initial syncs. If the first provisioning run is 50,000 users, plan for it to take longer than expected and monitor for throttling errors.
SFTP When It's the Right Call
SFTP-based provisioning feels old. You export a CSV on a schedule, drop it on an SFTP server, and the platform picks it up. Hourly or nightly depending on what the platform supports.
It's not elegant, but it's remarkably easy to reason about when something goes wrong. Either the file got there or it didn't. Either the format was right or it wasn't. Compared to a SCIM sync that fails silently on a subset of operations, that clarity has real value.
The compliance concern is real though: if access revocation runs nightly, a terminated employee can have access for up to 24 hours after the event. For most orgs this is acceptable. For high-security environments it's not. Know this before you recommend it.
The operational trap with SFTP is monitoring. A missed file transfer at 2am on a Thursday is how security teams find out you didn't set up alerting. Build transfer verification into the pipeline from the start.
The Decision in Practice
One question drives most of this: what's the offboarding SLA? If access must be revoked within minutes, you need SCIM and you need to validate that the platform's deprovisioning endpoint works before go-live. If same-day is acceptable, SFTP is often simpler and more reliable in practice.
The other factor is IT team capacity. SCIM configuration requires more upfront work and more validation. SFTP is easier to set up but has higher ongoing maintenance if something drifts. Neither is free.
Don't let a platform's marketing material be your only source of truth on SCIM support. Test deprovisioning specifically. It's the operation most commonly broken.
Document the choice and the rationale. This comes up again during security reviews, and "we evaluated both and chose SFTP because the platform's SCIM endpoint doesn't handle deprovisioning" is a much better answer than "we went with SFTP because it was easier."