Use mediation when the target application cannot speak SCIM natively, when policy must be evaluated before the change lands, or when multiple repositories need one consistent lifecycle process. Direct provisioning only makes sense where equivalent governance already exists.
When does mediation become the better lifecycle control?
Workflow mediation belongs in the gap between business intent and system change. It is the right pattern when the application cannot receive SCIM directly, when a change must be checked against policy before execution, or when one lifecycle event has to update more than one system with the same decision. Direct SCIM is better only when the destination can accept the action cleanly and governance is already enforced elsewhere.
In practice, mediation turns provisioning into a controlled workflow rather than a simple API call. That matters when the source of truth, approval logic, entitlement mapping, or downstream orchestration would otherwise be split across scripts and tickets. It is less about adding indirection for its own sake and more about preserving consistency when the lifecycle process is broader than one target connector.
Teams also use mediation when the provisioning decision itself is the control point. If a request needs to be enriched, approved, delayed, or denied before the account is created, the workflow is doing real security work. In that case, the mediator is not a wrapper around SCIM, it is the place where policy, ownership, and lifecycle state are reconciled before any change becomes effective.
What direct SCIM is good at, and where it breaks down
Direct SCIM works best when the target system already supports standard create, update, and delete operations in a predictable way. It is efficient for straightforward onboarding and offboarding, especially where the same authoritative attributes can be mapped cleanly into one application. When that is true, mediation can be unnecessary overhead and can slow down routine lifecycle changes.
The break point is usually governance or integration complexity, not just technical capability. If the destination lacks SCIM, has partial SCIM support, or requires extra business rules that the protocol does not represent well, direct provisioning becomes brittle. The same is true when the lifecycle event must fan out to multiple repositories, because one successful API call does not guarantee the whole identity state is consistent.
Mediation is also useful when the organisation wants one lifecycle decision to drive several outcomes, such as account creation, role assignment, group membership, license allocation, and deprovisioning. That orchestration keeps the process coherent, but it also means the workflow now owns error handling, retries, and state reconciliation. Teams should treat that as a governed integration layer, not a convenience script.
How to decide between mediation and direct provisioning
The choice should follow the control boundary. If the target is SCIM-capable, the attributes are stable, and the organisation already has equivalent approval and entitlement controls elsewhere, direct provisioning is usually sufficient. If any of those conditions fail, mediation is usually the safer design because it preserves a single decision point for policy, sequencing, and rollback.
Use mediation when the process needs human approval, conditional routing, or non-technical checks before the account lands. Use direct provisioning when the goal is only to transmit an already-approved lifecycle event to a compliant system. The common mistake is to choose direct SCIM because it is simpler to operate, then discover that exceptions, multi-system dependencies, and reconciliation have been pushed into ad hoc manual work.
For identity lifecycle programs, the deciding question is whether a failure in one target can be tolerated without leaving the broader access picture inconsistent. If the answer is no, mediation gives you a place to coordinate retries, exception handling, and auditability across the full workflow. If the answer is yes, direct SCIM is usually the leaner and easier control surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SCIM and mediated provisioning both depend on controlled credential and token lifecycle. |
| AC-2 — Account Management | The question is about lifecycle control over account creation, change, and removal. | |
| AC-6 — Least Privilege | Provisioning choice affects how much access is granted and whether excess access is avoided. | |
| Recommendation — Manage provisioning tokens and related secrets with explicit issuance, rotation, and revocation rules. Centralize account lifecycle decisions and keep changes auditable across target systems. Grant only the access needed at each lifecycle stage and avoid standing excess entitlements. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Provisioning vs mediation determines how access rights are granted, changed, and removed. |
| Recommendation — Define a controlled process for granting, modifying, and removing access rights. | ||
| CIS Controls v8 | CIS-5 — Account Management | Lifecycle automation and deprovisioning are core account management concerns. |
| Recommendation — Standardize account provisioning and deprovisioning so changes remain consistent and reviewable. | ||
Practitioner Guidance
What to verify: Confirm whether the destination supports the full lifecycle action set you need, not just create. Partial support often looks workable in pilots but breaks at offboarding, role change, or attribute synchronization.
Decision rule: If the request requires policy evaluation, multi-system fan-out, or approval before activation, route it through mediation. If it is a single, approved change to one SCIM-capable target, prefer direct provisioning and keep the control path simple.
What good looks like: The lifecycle decision is made once, the same decision is applied consistently everywhere it matters, and failures leave a visible reconciliation trail rather than silent drift.
Practitioner takeaway: Choose the lightest control that still preserves a single, governable lifecycle decision. SCIM is the transport; mediation is the control layer when consistency, policy, or orchestration is the real problem.
Related resources from NHI Mgmt Group
- How do security teams decide when to use API keys, SCIM provisioning, or email logs for operational control?
- When should teams use a record widget instead of a report widget in a security operations workflow?
- What happens when teams use a proxy for the Realtime API instead of a direct connection?
- When should organisations use webhooks instead of direct provisioning for access requests?