Moving to a Hub-and-Spoke Identity Model – Best Practices?Solved

We just solved that issue using Just-In-Time (JIT) Provisioning. Instead of pre-syncing every single user, Hexnode only creates a record when someone actually authenticates via SAML or OIDC. It evaluates the claims in real-time, so dormant accounts never even materialize in the system. To your point about policy collisions, the architecture ensures distributed autonomy. Even though you have global visibility, the regional spokes maintain independent lifecycle control. Because there’s no cross-tenant attribute leakage, your London users stay isolated in their own regional bucket without picking up the wrong configurations.

That approach sounds great for keeping the database clean. But what happens when the lifecycle ends? If a technician in a regional spoke is terminated in Okta, I can’t wait for a manual sync to revoke their access. Also, once they are in the system, how do we automate their setup? I’d love to avoid manually moving users into the Finance or Technician groups once they sign in.

That’s where the SCIM 2.0 and Attribute Mapping fabric comes in. For the exit strategy, Hexnode listens for SCIM push events. If an IdP sends a DELETE or PATCH (active=false) signal, the response chain is instant, active sessions are halted immediately across all device layers. For the onboarding side, you should use the Attribute-to-Policy Mapping Engine. You can map an IdP attribute like Department = Finance directly to a Hexnode Organizational Unit. The moment they authenticate, they don’t just get an account; they get their specific apps, Wi-Fi certs, and RBAC roles automatically. It basically turns your directory events into security actions without you having to lift a finger.