SCIM & SSO Provisioning for Cloud Access Control

Overview

• SSO (Single Sign-On) controls authentication. It decides who can log in, usually through a SAML 2.0 identity provider like Okta or Microsoft Entra ID.
• SCIM (System for Cross-domain Identity Management) controls provisioning. It creates, updates, and deactivates accounts automatically when your identity provider changes.
• Pairing both gives multi-site access control full lifecycle management. New hires get door access on day one, and terminated employees lose it the moment offboarding runs.
• Rhombus supports both natively, including SAML SSO for any SAML 2.0 provider.
• Rhombus offers native SCIM 2.0 lifecycle automation with Okta and Entra ID, covering automated user creation, updates, and deactivation.

What Is SSO and What Is SCIM?

Single sign-on (SSO) is an authentication standard that lets a person use one set of credentials to log into multiple applications. When you sign into your identity provider once, SSO answers a single question for every connected system. Who is this person, and are they allowed to log in? A physical security platform that supports SSO trusts your identity provider to verify the user instead of maintaining its own separate password.

Most enterprise SSO runs on SAML 2.0, a protocol that passes a signed assertion from your identity provider to the application confirming the user’s identity. Okta and Microsoft Entra ID (formerly Azure AD) are two of the most common identity providers, and both speak SAML 2.0. The rest of this page uses SAML 2.0 as the reference point when discussing SSO, because it is the standard nearly every access control platform integrates against.

System for Cross-domain Identity Management (SCIM) is a provisioning standard that governs what happens to a user’s account across connected systems. Where SSO answers who can log in, SCIM handles account lifecycle. It creates the account when someone joins, updates it when their role changes, and deactivates it when they leave. SCIM works in the background without a person logging in at all, syncing user records from your identity provider to each connected application automatically.

The two standards solve different problems and depend on each other in practice. SSO controls the moment of access, confirming identity at login. SCIM controls the account itself, keeping it accurate from the day someone is hired to the day they are removed. An access control platform that supports only SSO can verify a user but has no automated way to remove that user’s account when they are offboarded. A platform that supports both can authenticate people at the door and keep every account current across your locations without manual work.

SCIM vs SSO: How They Differ and Work Together

SSO and SCIM operate on two different layers of identity management, and enterprises need both for access control that keeps up with staffing changes. SSO governs authentication, the moment a person logs in and proves who they are. SCIM governs lifecycle management, the ongoing state of that person’s account as their role, permissions, and employment status change. SSO decides whether someone can get in, while SCIM decides whether their account should exist at all and what it can reach.

The distinction matters most at the edges of employment. SAML 2.0 SSO validates a login against your identity provider in real time, so it enforces the rules that exist right now. SCIM does the background work of creating an account when someone joins, updating it when their role shifts, and deactivating it when they leave. Without SCIM, those changes depend on an administrator remembering to make them by hand in each system.

Running SSO without SCIM creates a predictable failure. When you offboard an employee in your identity provider, SSO stops them from logging in through that provider. The account itself often persists inside the access control platform, along with any door permissions or badge credentials tied to it. If that platform has any path to authenticate outside your identity provider, or if the credential was cached, the stale account becomes a live security gap.

The two standards belong together. SSO handles the front door of authentication, and SCIM makes sure accounts and permissions actually match your current roster across every site.

How SCIM Provisioning Works: The Token and the Flow

A SCIM token is a bearer credential your identity provider (IdP) uses to authenticate its calls to the access control platform. When you configure SCIM provisioning in Okta or Microsoft Entra ID, you generate a token inside the target platform and paste it into the IdP’s provisioning settings. From that point on, the IdP includes the token in every request it sends. The platform checks the token before it acts on any create, update, or deactivate instruction, so no unauthenticated system can push account changes.

The token authorizes a one-way handshake. Your IdP is the source of truth for identity, and the access control platform trusts changes that arrive with a valid token. This trust model removes the manual step of an administrator logging into the access platform to mirror what already happened in the directory. The directory acts, and the platform follows.

The provisioning flow, step by step

Once the token is in place, the sequence runs automatically whenever an identity changes in your directory.

1. A change happens in the IdP. An administrator adds a new hire to a group, updates a job title, or disables a departing employee’s account in Okta or Entra ID.
2. The IdP sends a SCIM call. The directory detects the change and issues a SCIM 2.0 request to the access control platform, carrying the token and the updated user attributes in a standard format.
3. The platform verifies and acts. The platform validates the token, then applies the change. A new user gets an account and the access group its attributes map to. An updated user has role or profile fields synced. A deactivated user loses account access without an administrator touching the access platform.

The three call types map directly to the identity lifecycle. Creation provisions the account. Update keeps attributes and role assignments current as people change teams or locations. Deactivation removes access the moment the IdP disables the source account, which closes the window between an offboarding decision and the loss of physical access.

Because the flow uses the SCIM 2.0 standard, you configure it the same way regardless of how many sites the platform manages. One token and one connection between your IdP and the platform govern account lifecycle everywhere, rather than a separate manual process at each location. Rhombus supports this flow natively with both Okta and Entra ID.

Why Automated Provisioning and Deprovisioning Matter for Multi-Site Access Control

A terminated employee who still holds active badge and door access across three sites is a physical security failure, not a routine IT ticket. When provisioning runs manually, a facilities admin at each location has to remember to revoke that access. Someone forgets, and a former staff member walks into a warehouse two weeks after their last day. Automated deprovisioning closes that window by tying door access to a single event in your identity provider. When HR deactivates the user in Okta or Microsoft Entra ID, the access control platform receives the deactivation call and pulls credentials at every site at once.

Onboarding speed matters for the same reason in reverse. A new hire starting at a multi-location enterprise often waits on a badge because access has to be configured site by site, role by role. With automated provisioning, adding the user to the right group in your identity provider creates their access profile everywhere their role applies. A regional manager assigned across four buildings gets the correct doors on day one without four separate manual entries.

Manual administration across sites also scales badly. Every location that manages its own access list produces its own errors, its own stale accounts, and its own version of who should have keys to what. Centralizing provisioning through one identity source removes the duplicated effort and gives you a single place to change a person’s access when they move teams or locations. Role-based mapping does the assignment, so you set the rule once instead of repeating the decision per building.

Compliance reviews depend on this audit trail. Auditors reviewing physical access for SOC 2, HIPAA, or internal policy want to see who had access to which doors, when it was granted, and when it was removed. When provisioning and deprovisioning flow through your identity provider, each change carries a timestamp and a source you can point to. That record answers the auditor’s question directly instead of forcing your security team to reconstruct months of manual badge edits from memory and spreadsheets.

The people who feel the gap most are security directors, not IT alone. IT owns the identity provider, but the risk of a door opening for the wrong person lands on the physical security team. Automated provisioning connects those two responsibilities so a single HR action governs both the login and the lock.

Rhombus Enterprise Identity Capabilities

Rhombus supports enterprise identity workflows natively, so you connect your existing identity provider without middleware or custom scripting. The platform handles both the authentication side and the lifecycle side, which means the same directory that governs your software logins can also govern physical door access across every location.

For authentication, Rhombus offers native SAML 2.0 single sign-on that works with any compliant identity provider, alongside dedicated integrations for Okta and Microsoft Entra ID (formerly Azure AD). If your organization already standardizes on one of those two providers, the setup follows a documented path rather than a generic SAML configuration. You can review the current list of supported systems on the integrations page.

On the provisioning side, Rhombus provides native SCIM 2.0 support with Okta and Entra ID. When you create, update, or deactivate a user in your directory, that change propagates to Rhombus automatically. A departing employee loses access on the same schedule as their email and other accounts, which removes the manual step where badge access outlives employment.

Rhombus also supports Just-In-Time SAML provisioning, which creates a user account the first time someone authenticates through your identity provider rather than requiring an administrator to build it in advance. That option suits organizations that prefer to provision on first login instead of syncing an entire directory upfront.

Role-based lifecycle management ties these pieces together. You map directory groups to Rhombus roles, so a person’s permissions reflect their job function and adjust as that function changes. A promotion or department transfer in your identity provider updates their access without a separate ticket to the security team.

To guard against lockouts, Rhombus maintains a Recovery User safeguard. If your identity provider becomes unreachable or a SCIM sync fails, the Recovery User retains a way into the platform, so an outage on the identity side never locks administrators out of their own access control system.

For teams evaluating how these capabilities fit into a broader security posture, the access control overview covers deployment, and the trust page documents Rhombus compliance and data handling.

What to Evaluate in an Enterprise Identity Integration

Use this checklist when you compare identity support across access control platforms. The difference between vendors usually shows up in these six areas.

Rhombus meets each of these with native SAML SSO, SCIM 2.0 lifecycle automation, and role-based access. You can read the full platform details on the access control page.

FAQs

Does Rhombus support SAML identity providers other than Okta and Entra ID? Rhombus natively supports SAML 2.0, the standard protocol used by most enterprise identity providers. Any provider that conforms to SAML 2.0 can connect to Rhombus for single sign-on, alongside the dedicated Okta and Microsoft Entra ID integrations. You get authenticated logins tied to your existing directory without building a custom bridge.

What happens if a SCIM sync fails or the connection drops? A failed SCIM call does not delete or corrupt existing accounts, so users keep the access they already hold until the sync recovers. Once the connection to your identity provider is restored, Rhombus processes the queued create, update, and deactivate calls to bring accounts back in line with your directory. You can review sync activity in the audit logs to confirm which changes applied and when.

How does the Recovery User prevent an accidental lockout? The Recovery User is a safeguard account that stays outside your identity provider’s control, so a misconfigured SSO or SCIM setup cannot lock every administrator out of the platform. If your identity provider goes offline or a sync removes the wrong permissions, you sign in through the Recovery User to fix the configuration. That fallback matters most during initial setup, when integration errors are most likely.

Can Rhombus assign roles automatically during provisioning? Yes. Rhombus maps identity provider attributes to roles through Just-In-Time provisioning and SCIM, so a new user lands with the correct permissions on first login. Role-based lifecycle management keeps those permissions accurate as a person changes teams or leaves.

Get Started with Rhombus

Automated provisioning removes the manual work that slows enterprise access control, and it closes the offboarding gaps that leave doors open after someone leaves. Rhombus pairs native SAML SSO and SCIM 2.0 lifecycle automation with hardware and software you can deploy across every site from one console.

See how identity integration fits into the wider platform on our access control overview, and review our security and compliance posture on the Rhombus trust page.

Ready to see it in your environment? Request a demo and we will walk through SSO, SCIM provisioning, and role-based lifecycle management with your identity provider.