Every separate application with its own username and password is another account to create, another password to reset, and another door someone forgets to close when an employee leaves. Single sign-on removes that duplication for a cloud SCADA by letting people log in with the corporate identity they already have. This guide explains how federated authentication through SAML or OIDC works, how the login flow hands off to a corporate identity provider, how groups map to roles, and why centralized access control matters for a multi-user hosted platform.
SSO in one line: Single sign-on lets a user log into a cloud SCADA using their existing corporate identity - authenticated by an identity provider such as Okta, Microsoft Entra, or Google through a protocol like SAML or OIDC - rather than a separate SCADA password. Access is managed centrally, so a person's group membership at the identity provider decides their SCADA role, and disabling them centrally cuts off their SCADA access immediately.
Under single sign-on the SCADA does not verify the user's password itself. Instead it delegates authentication to a trusted identity provider, the system the company already uses to manage employee logins. When a user tries to reach the SCADA, they are redirected to the identity provider, where they sign in the way they sign into everything else - including any multi-factor step the company enforces. The identity provider then sends the SCADA a signed assertion that says, in effect, this is a real, authenticated user and here is who they are.
SAML and OIDC are the two common protocols that carry that assertion. SAML is the long-established enterprise standard, exchanging a signed XML assertion between the identity provider and the application. OIDC is the more modern option built on OAuth, exchanging signed tokens and often used with the same identity providers. From the SCADA's point of view the outcome is the same: it trusts a cryptographically signed statement from the identity provider rather than storing and checking a password of its own. The user experiences a single login that carries them into the SCADA without a second set of credentials.
Because the SCADA never holds the user's corporate password, an entire class of risk moves off the platform. There is no separate SCADA password to be weak, reused, phished, or left in a shared note, and password policy, rotation, and multi-factor enforcement all stay with the identity provider where the company already manages them. The SCADA's job narrows to trusting the identity provider and deciding what an authenticated user is allowed to do once inside.
Authentication establishes who a person is; authorization decides what they can do, and single sign-on links the two through group mapping. The identity provider typically knows a user's group or role membership - operations, engineering, management, contractor - and includes that information in the signed assertion. The SCADA is configured to map those incoming groups to its own roles, so an engineer in the corporate directory lands in the SCADA with engineering permissions and an operator lands with operator permissions, all without a SCADA administrator setting each person up by hand.
This mapping is what makes centralized access practical rather than just convenient. Rather than maintaining a parallel list of who should have which SCADA role, the organization manages membership once, in the identity provider, and the SCADA follows. Moving a person between teams in the directory changes their SCADA role on their next login, and adding someone to the right group grants them appropriate access automatically. The SCADA becomes a consumer of the company's existing identity structure instead of a separate system to keep in sync.
Group-to-role mapping still leaves the SCADA in control of the specifics of each role - what an operator can see and touch versus an engineer - so the platform's own permission model does the fine-grained work. Single sign-on decides which role a person gets from their corporate identity; the SCADA's role definitions decide what that role means. The division keeps identity management in one place and process-specific permissions in another, which is the right home for each.
The strongest security argument for single sign-on is instant offboarding. When a person leaves or is removed, IT disables their account centrally, and because the SCADA relies on that same identity provider, their access to the SCADA ends immediately with no separate step to remember. The failure mode of a standalone SCADA login - a departed contractor whose account nobody thought to delete, still able to reach a live system - simply does not arise when authentication is federated. Access is granted and revoked in one place.
For a multi-user hosted platform this centralization scales far better than local accounts. A company running many sites, with operators, engineers, and outside integrators, would otherwise face a growing pile of individual SCADA credentials to provision, reset, and audit. Federating to the corporate identity provider collapses that into the account lifecycle the company already runs, so onboarding, role changes, password resets, and multi-factor policy all happen once and flow through to the SCADA. It also gives the company a single, authoritative answer to the question of who can reach the system.
Single sign-on complements rather than replaces the platform's other access controls. It handles federated authentication - proving identity through the corporate provider - while role-based permissions govern what an authenticated user may do, and any multi-factor requirement is enforced at the identity provider during login. Together these layers let a hosted SCADA meet enterprise access expectations: strong, centrally managed authentication up front, and least-privilege authorization inside, with the whole lifecycle tied to the company's existing identity system.
Single sign-on is about where authentication happens - it lets users log into the SCADA with their existing corporate identity through an identity provider instead of a separate password. Multi-factor authentication is about how strongly that login is verified, requiring a second factor beyond a password. They work together: with single sign-on the identity provider handles the login and enforces any multi-factor step, then tells the SCADA the user is authenticated.
Both are protocols that let an identity provider vouch for a user to the SCADA, so the SCADA never handles the corporate password itself. SAML is the older enterprise standard and exchanges a signed XML assertion, while OIDC is the newer option built on OAuth and exchanges signed tokens. Many identity providers support both, and from the SCADA's perspective the result is the same federated, single login.
Yes, and that is one of its main benefits. Because the SCADA relies on the corporate identity provider to authenticate users, disabling a person's account centrally cuts off their SCADA access immediately, with no separate SCADA credential left active. This eliminates the common risk of a departed employee or contractor retaining a standalone login that nobody remembered to remove.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.