A town clerk opens a grant-portal SaaS app from a home browser that is not enrolled in MDM. Single sign-on still works. Which split of Workspace ONE products explains that?

When a town clerk opens a grant-portal SaaS app from a home browser that is not enrolled in MDM and single sign-on still works, the correct product split is that Workspace ONE Access is the identity broker for SSO while Workspace ONE UEM manages devices and is not required for every Access launch. Access federates and authenticates users to SaaS and other catalog resources; UEM enrolls phones and PCs, pushes profiles, and evaluates compliance. Identity and endpoint management are paired often in civic designs, but they remain different planes: a clerk can flash the Access badge at a SaaS door from an unmanaged home browser even when no Hub enrollment exists on that browser. Unified Endpoint Management fails here by concept when treated as the identity provider—UEM is not the IdP, and making enrollment optional for SaaS does not turn UEM into Access. Horizon Connection Server fails because it brokers virtual desktop and published-application sessions to entitled pools; it does not replace Access federation for an arbitrary grant-portal SaaS launch in a plain browser. Workspace ONE Assist fails because it is remote support for a managed endpoint, not an identity broker that silently remotes into the home PC so the clerk never authenticates. Exam caveat: organizations may still choose Access policies that require Hub enrollment or compliance before a sensitive SaaS launch; the exam point is that Access can perform SSO without UEM for every launch, not that conditional access is impossible. Operational check: from an unmanaged home browser, complete Access SSO to the grant portal, confirm no UEM enrollment is present on that browser, and contrast that path with a Hub-enrolled city phone where UEM compliance may still be evaluated by Access policy.