The rollout is approved, the sensors are installed, and then the email arrives from IT security: "All third-party dashboards must authenticate through Entra ID before go-live." If you manage a people counting or retail analytics deployment, you have probably lived some version of this moment. Shared logins taped to the back-office monitor are no longer acceptable to any security team, and single sign-on has moved from a nice-to-have to a procurement gate. This FAQ collects the questions our support teams, partners and buyers actually ask when connecting an analytics platform to Microsoft Entra ID — including the ones that only surface three weeks after go-live.
Practically, three things. First, store managers and regional teams stop maintaining a separate password for their analytics dashboard — they sign in with the same corporate identity they use for Outlook and Teams. Second, offboarding becomes automatic: when HR disables an account in Entra ID, access to footfall data ends at the same moment, which auditors love. Third, your existing multi-factor authentication and device policies apply to the analytics platform without any extra configuration on the vendor side. For a retailer with hundreds of store-level users and seasonal staff turnover, the offboarding point alone usually justifies the setup effort.
Both are supported by Entra ID, and both deliver the same end-user experience. The honest answer is: use whatever your identity team already standardises on. SAML remains the most common request from enterprise retail IT departments because their app gallery and review processes are built around it. OpenID Connect tends to be preferred by teams that manage everything as code. What matters more than the protocol choice is agreeing early on which claims will be sent — typically UPN or email as the identifier, plus group claims if you plan to map roles automatically. Confirm the exact protocol and claim support for your specific platform version with your vendor contact before the security review, not during it.
This is where most of the real design work sits. A typical retail structure looks like this:
You can pass Entra ID group memberships as claims and let the platform assign roles automatically, or provision users with roles via SCIM. Automatic mapping is elegant but demands disciplined group hygiene on your side; if your Entra tenant has 4,000 legacy groups with inconsistent naming, start with manual role assignment and automate later.
Yes, through Entra External ID (B2B guest accounts). This is the standard pattern for franchise networks and shopping centres where the property owner runs the tenant but individual tenants' staff need dashboard access. Two caveats. Guest users must actually redeem their invitation before SSO works — unredeemed invitations are the single most common "SSO is broken" ticket in multi-organisation deployments. And if the guest's home tenant enforces its own conditional access policies, those apply on top of yours, which occasionally produces sign-in loops that neither party can diagnose alone. When that happens, the Entra sign-in logs on both tenants, correlated by timestamp, resolve it in minutes.
It is worth separating two things that buyers often merge. The footfall data itself — the counts flowing from the sensors — contains no personal identification in a GDPR-compliant people counting setup: visitors are counted as aggregate numbers, staff can be excluded, and no individual is identifiable. SSO does not change that. What SSO does introduce is the exchange of user identity data (name, email, group membership) between your Entra tenant and the analytics platform for authentication purposes. That exchange should be covered in your data processing agreement, and your DPO will want to know where authentication logs are stored — particularly relevant if you have chosen a private cloud deployment precisely to keep everything within your own infrastructure. Confirm data-residency specifics for your deployment model in writing before sign-off.
Here is the observation any implementer who has done more than two of these projects will recognise. Group-based role claims are evaluated at sign-in, not continuously. Promote a store manager to regional manager on Monday morning, and they will still see only their old store until their session token expires or they sign out and back in. The reverse is worse: revoke a group membership and the user keeps their old permissions for the lifetime of the token. Budget an hour during implementation to agree token lifetimes with your identity team, and put "sign out and sign back in" at the top of your internal support script for permission complaints. It resolves roughly half of them before anyone opens a ticket with the vendor.
Three questions separate a smooth deployment from a painful one. Ask whether SSO can be enforced (not just offered) so local password logins are disabled tenant-wide. Ask whether user provisioning is automated via SCIM or handled manually, because manual provisioning across 300 stores becomes someone's part-time job. And ask how the platform behaves during an identity-provider outage — a documented break-glass access procedure is a sign the vendor has actually run enterprise deployments rather than just passed a checkbox review. A platform designed to integrate with your existing IT systems, whether hosted or in your private cloud, should have concrete answers to all three within a day.
Planning an Entra ID SSO integration for your people counting or retail analytics deployment — or stuck on a sign-in issue your identity team cannot reproduce? Talk to the Vemco Group team about your tenant setup, provisioning model and rollout plan at vemcogroup.com/contact-us.