Single sign-on solves how a person logs in, but it does not, by itself, create their account or clean it up when they leave. SCIM user provisioning fills that gap by keeping SCADA accounts in step with a corporate directory automatically. This guide explains how SCIM synchronizes user accounts from an identity source, why it means new hires arrive with the right role and departed staff lose access the moment IT disables them, and how that lifecycle automation supports audit and compliance on a multi-tenant platform.
SCIM Provisioning in one line: SCIM user provisioning automatically creates, updates, and disables SCADA user accounts by syncing them from a corporate directory. When IT adds, changes, or removes a person centrally, SCIM pushes that change into the SCADA, so accounts and roles stay in step with the directory without an administrator managing SCADA users by hand.
SCIM is a standard for provisioning user accounts between an identity source, such as a corporate directory or identity provider, and an application that consumes it. Instead of an administrator creating a SCADA account for each new person, the directory is the single source of truth and SCIM keeps the SCADA's copy synchronized with it. The whole lifecycle is covered: creating an account when a person is added, updating it when their name, group, or role changes, and disabling it when they are removed. The SCADA becomes a mirror of the relevant slice of the directory.
The four verbs of that lifecycle are create, read, update, and deactivate. When HR onboards someone and IT places them in the right directory group, SCIM creates a matching SCADA account with the role that group implies. When the person moves teams, SCIM updates their SCADA role to match. When they leave and IT disables them centrally, SCIM deactivates their SCADA account. Each of these happens as a consequence of a change made once in the directory, so the SCADA never drifts out of alignment with who actually works there.
It is worth distinguishing this human-account provisioning from provisioning of hardware. Bringing a new field gateway or device online is a separate discipline concerned with equipment, certificates, and connectivity. SCIM provisioning is entirely about people: the accounts, roles, and access rights of the humans who use the SCADA. The two share the word provisioning but solve different problems, and SCIM's domain is strictly the user directory and the accounts derived from it.
The onboarding payoff is that access is correct from day one without manual setup. Because SCIM carries a user's group or role membership from the directory, a new engineer arrives in the SCADA already in the engineering role and a new operator already in the operator role. Nobody has to remember to create the account, pick the right permissions, or follow up when the new hire finds they cannot see what they need. Provisioning happens as a byproduct of the directory change that HR and IT would make anyway.
The offboarding payoff is even more important for security. Deprovisioning - disabling the account - is the step most likely to be forgotten when it is manual, which is how ex-employees and finished contractors end up retaining access to live systems for weeks. With SCIM, the moment IT disables a person centrally, the deactivation propagates to the SCADA and their access ends. There is no separate SCADA cleanup task and no window in which a departed person can still reach the platform, because the same action that removes them everywhere removes them from the SCADA.
Between those two ends, SCIM keeps roles honest as people move. A promotion, a transfer, or a change of responsibility that updates someone's directory group flows through to their SCADA role automatically, so permissions track the person's actual job rather than lagging behind it. This continuous alignment is what turns access management from a series of one-off tickets into a governed, self-maintaining state where the SCADA always reflects the current org.
SCIM pairs naturally with single sign-on: sign-on handles authentication at login time, while SCIM handles the account and role lifecycle behind it. Sign-on alone can authenticate a user, but SCIM ensures the account, the correct role, and the eventual deactivation are all maintained from the directory rather than assembled by hand. Together they let an organization manage SCADA access entirely from the identity source it already runs, which is the model enterprise IT and security teams expect.
On a multi-tenant hosted platform, this lifecycle automation is also a governance and audit story. Because every account's existence and role trace back to a directory change, the organization can demonstrate that access is granted and removed through a controlled process rather than ad hoc. When an auditor asks how a person got their permissions or how promptly a leaver was cut off, the answer is a directory-driven, timestamped sync rather than a hope that someone remembered. Identity governance becomes provable instead of anecdotal.
For a company running many sites and a mix of employees and integrators, provisioning at scale is where SCIM earns its place. Managing SCADA accounts one at a time does not scale and inevitably leaves stale accounts behind; syncing them from the directory collapses the whole population into the lifecycle the company already governs. New sites, new teams, and departures all flow through the same automated path, so access stays least-privilege and current without a growing manual burden on whoever administers the platform.
Single sign-on handles authentication - it lets a user log into the SCADA with their corporate identity at the moment they sign in. SCIM handles the account lifecycle behind that login - creating the account, setting the right role, updating it, and deactivating it, all synced from the corporate directory. Sign-on proves who someone is; SCIM makes sure the account and permissions exist and are removed correctly.
Yes, and that is one of its main benefits. When IT disables a person in the corporate directory, SCIM propagates that deactivation to the SCADA and their access ends automatically. This closes the common gap where a manual offboarding step is forgotten and a departed employee or finished contractor keeps a working login to a live system for weeks.
No. SCIM provisioning is entirely about human user accounts - creating, updating, and disabling the logins and roles of the people who use the SCADA, synced from a corporate directory. Device provisioning is a separate discipline concerned with bringing hardware such as field gateways online, including certificates and connectivity. They share the word but solve different problems.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.