Reaching Deskless Workers Without SSO Accounts: Identity Patterns and What They Mean for Agent Distribution

The question

"What are the dominant enterprise identity and agent-distribution patterns for reaching deskless workers who lack corporate SSO/Okta accounts (retail, logistics, food service), and what does this mean for how phData clients can deploy AI agents to frontline staff?"

Surfaced from the 2026-07-13 Kwik Trip engagement, where frontline staff may not exist in the corporate IdP at all — making agent distribution a discovery problem before it is an architecture problem.

What we already know (from the vault)

• [[2026-07-13-kwik-trip-deskless-agent-distribution]] is the orphan doc this question came from. It already establishes the core architecture map: per-seat M365 Copilot is the wrong tool at frontline scale; Copilot Studio agents published to non-Teams channels (Direct Line) with manual OAuth2 auth against Okta are the right Microsoft answer, because end users of a published Copilot Studio agent need no license — billing is capacity-based, not per-seat.
• That same doc already names the discovery precheck that this brief confirms is the load-bearing one: "Okta is the IdP" does not mean deskless workers are IN Okta. If frontline exists only in Workday/UKG, HR→IdP provisioning is step 0 for every downstream path.
• It also flags the non-technical constraint most architects miss: FLSA/wage-hour exposure when work agents are pushed to hourly employees' personal phones. Retail norm is to gate access to on-shift/on-network or use in-store shared devices.
• [[2026-07-17-kwik-trip-engagement-notes-stakeholders-and-priorities]] records a founder correction worth preserving as a general discovery lesson: the flagship agent's users turned out to be remote workers, not deskless — they have Microsoft identities and reach the agent through Teams on their phones. The deskless problem is a separate thread for later agents in the portfolio. Populations get conflated in discovery by default.
• [[2026-05-21-enterprise-ai-agent-deployment-paths]] frames the general deployment shape: hybrid is dominant, with governance in-house and execution via specialist partner. Distribution channel is a port, not a product choice.

What the web says

• Every documented Microsoft frontline pattern still requires an individual Entra ID account per worker. Microsoft Learn's frontline worker management doc is explicit that Microsoft 365 for frontline workers uses Entra ID as the underlying identity service and "users must have an identity that exists in Microsoft Entra ID to access Microsoft 365 apps." The simplified sign-in methods reduce credential friction; they do not remove the identity object.
• QR code authentication (still labeled preview) uses a printed QR plus a user-defined 8-digit PIN. Per the same doc, the QR code encodes "a User Principal Name (UPN), tenant ID, and a secret key," and the PIN "works only with the QR code and not with other identifiers." Attribution is preserved because the UPN is embedded. Microsoft's stated rationale is cost: printing QR codes is cheaper than hardware keys, and codes can be attached to a badge or wearable — explicitly framed around high-turnover temporary staff.
• SMS sign-in is phone-number-as-identity mapped onto a real directory account. Workers "sign in with SSO for Microsoft Teams and other applications using just their phone number and a one-time passcode." The phone number is an identifier for an Entra account, not a substitute for one.
• Shared Device Mode is not a shared account. Microsoft's frontline security best-practices doc describes SDM as: workers "pick a device from the shared pool, sign in once," gain SSO across SDM-supported apps, and on shift end "sign out globally on the device, which removes their personal and company information from all SDM-supported applications." This is per-user attribution on shared hardware — architecturally very different from a generic store login.
• My Staff pushes identity administration to the store manager. Frontline managers can perform password resets and register team phone numbers "directly from the store or factory floor... without routing the request through the help-desk, IT, or operations." This is the pattern that makes per-worker identity survive 100%+ annual turnover.
• Frontline licensing got materially more expensive in July 2026. Multiple licensing-analyst sources report F1 moving from $2.25 to $3.00/user/month (+33%) and F3 from $8.00 to $10.00 (+25%), described as the steepest percentage increases in the July 2026 update and falling hardest on large deskless populations (2Data, Redress).
• Copilot Chat capability is reported as included at F1/F3 tier, per the same analyst sources — but this is exactly the class of claim to verify against a Microsoft product-terms document before repeating it to a client. Analyst licensing blogs are secondary sources with a consulting-lead incentive.

Convergences and contradictions

• Convergence, and it is the whole finding: the vault's "identity precheck" instinct and the Microsoft documentation land in the same place from opposite directions. The vault says ask whether a store associate can log into anything corporate today; Microsoft's docs say every path requires an Entra identity to exist. Both reduce to: the hard part is provisioning an identity object per worker and keeping it alive through turnover, not choosing a login method. Sign-in UX (QR, SMS, SDM) is the easy, solved, well-documented layer.
• Contradiction / update to the vault: [[2026-07-13-kwik-trip-deskless-agent-distribution]] cites F-series SKUs at "~$2.25-8/user." That range is now stale post-July-2026 ($3.00-$10.00). The doc's headline conclusion is unaffected — its $8-9M/yr figure was the per-seat Copilot math at $30/user/mo, not F-series — but any base-license floor quoted to a client should use the new numbers. At a hypothetical 24k deskless population, F1 base alone is roughly $860k/yr and F3 roughly $2.9M/yr before any agent capacity spend.
• Marketing vs. documented capability: "frontline worker" is used by vendors to mean both "worker with a cheap license" and "worker with no license." These are different architectures with different cost curves. Microsoft's documented position is the former. The genuinely license-free path for end users is Copilot Studio's published-agent model, which is a different product line with capacity-based billing — a distinction worth making explicitly in the room, because it is where the cost argument actually turns.

Synthesis for RDCO

The architectural options, with what each actually costs you. There are five live patterns and they trade off along different axes than clients expect. (1) Per-worker directory identity with simplified credentials — QR+PIN, SMS OTP, or Shared Device Mode on pooled hardware. Full attribution, full Conditional Access, full audit. Cost is a license per worker (now $3-10/user/mo at F-tier) plus the provisioning pipeline. Breaks at scale not on cost but on lifecycle: at retail turnover rates, someone must create and deprovision tens of thousands of accounts a year, which is why My Staff-style manager-delegated administration is a requirement rather than a nicety. (2) Published agent on a custom channel with third-party OAuth — the Copilot Studio Direct Line pattern from the vault doc, or an equivalent PWA against Okta OIDC. End users need no M365 license; billing is capacity. Attribution is as good as the OAuth identity behind it, which loops back to option 1's provisioning question. (3) Embed in the existing frontline app — whatever scheduling/comms app staff already open every shift. Best adoption by a wide margin, and it inherits an identity system that already solved the turnover problem. Weakest control over the agent surface. (4) Shared in-store kiosk with a generic login — cheapest and fastest, sidesteps BYOD and FLSA entirely, and is the one option that genuinely destroys attribution. (5) SMS/voice line — zero install, works on any phone, weak auth, no rich UI; viable only for narrow low-sensitivity use cases like policy Q&A.

Attribution is the axis that matters most for agents specifically, and it is where option 4 fails. For a conventional frontline app, a shared kiosk login is a tolerable compromise — the app's actions are constrained by design. An AI agent is different in kind. It takes open-ended natural-language input, may take actions on systems of record, and produces output a worker may act on. If five associates share one store login, then every prompt, every retrieved document, and every agent action is attributable only to "Store 412." That breaks four things at once: you cannot investigate misuse or prompt-injection attempts back to a person; you cannot apply per-user data scoping, so the agent's retrieval corpus collapses to the least-privileged common denominator; you cannot build the feedback loop that makes the agent better, because you can't tell whether one power user or forty occasional users generated the traffic; and you inherit an audit finding waiting to happen the moment the agent touches anything regulated (PII, payment, safety, wage-hour). Note the sharp architectural line here: Shared Device Mode is shared hardware with individual identity — it is option 1, not option 4. Clients routinely conflate the two, and clarifying it in the room is high-value, because it reframes "we can't give everyone an account" into "you can share the tablet and still keep the audit trail." The honest framing for a client: attribution is a design decision with a price tag, and the right answer may legitimately be "no attribution, and therefore only low-sensitivity read-only use cases on that surface."

What this means for the engagement shape. The sequencing insight is that identity provisioning is a prerequisite project, not a workstream inside the agent project — and it is frequently larger than the agent build. A DSA who scopes an agent for a deskless population without first confirming the identity substrate is scoping a project with an unpriced dependency underneath it. The commercially useful move is to make the identity precheck a gate in discovery and, where the substrate doesn't exist, scope the HR→IdP provisioning path as its own phase. That is a real, defensible, sellable piece of work rather than a surprise that surfaces mid-delivery. It also protects the agent roadmap: a portfolio target like "six additional agents" should be triaged early by which use cases are deskless-reachable at all, because that classification changes the value math on a heavily store-facing workforce.

Discovery questions to bring into the room:

1. Can a store associate log into anything corporate today? If yes, what — and what is the identity behind it?
2. Where do frontline workers exist as records — HR system only (Workday/UKG), the IdP, or both? Is there an automated provisioning path between them, and what is its lag on hire and on termination?
3. What is annual turnover in the frontline population, and who creates and deprovisions those accounts today? Is there any manager-delegated administration, or does every reset go to a central help desk?
4. What app do store staff already open every shift? Who owns it, and does it have an extension or embed point?
5. Company-owned shared devices, BYOD, or both? If shared devices exist, are they MDM-enrolled, and are they in Entra Shared Device Mode or running a generic login?
6. For the candidate use cases: does the agent need to know who is asking — for data scoping, for personalization, or for audit? If yes, option 4 is off the table for that use case.
7. What data will the agent retrieve, and does any of it require per-user access scoping? What would the corpus look like restricted to the least-privileged common denominator?
8. Is frontline agent access intended for on-shift only? Have Legal/HR been consulted on hourly staff accessing work tools on personal devices off-shift?
9. What is the expected message volume per worker per month? (Capacity-based billing makes this the real cost line, not seats.)
10. Who owns the audit trail for agent interactions, and what retention and review obligations attach to it?

Why this is in the vault

This brief converts the orphaned [[2026-07-13-kwik-trip-deskless-agent-distribution]] analysis into a reusable discovery instrument for the founder's Deal Solutions Architect role at phData, where he is R on discovery and scoping. It directly informs how deskless-population agent work gets scoped across the multi-agent portfolio — specifically, the argument that identity provisioning is a priced prerequisite phase rather than an assumption, and the attribution test that determines which use cases a shared-login surface can legitimately serve.

Open follow-ups

• Verify the "Copilot Chat included at F1/F3" claim against Microsoft product terms rather than analyst blogs before using it in any client-facing cost argument.
• Confirm current GA/preview status of Entra QR code authentication — the Learn doc still labels it preview, and preview status is a real objection in a risk-averse enterprise.
• Map the equivalent pattern set on the Okta side (Okta workforce identity tiers for frontline populations) — this brief is Microsoft-heavy because the documentation is richer there, which is itself a sourcing bias worth correcting.
• Research the frontline-app embed path (UKG/Workday/WorkJam class) for documented agent/extension surfaces — option 3 has the best adoption story and the thinnest research coverage here.
• Determine whether Copilot Studio capacity billing has documented per-user metering that would preserve attribution independent of the auth layer.

Related

• [[2026-07-13-kwik-trip-deskless-agent-distribution]] — the orphan doc this brief extends; original five-path architecture map and the identity-precheck caveat
• [[2026-07-17-kwik-trip-engagement-notes-stakeholders-and-priorities]] — records the remote-vs-deskless population correction and the separate deskless thread
• [[2026-05-21-enterprise-ai-agent-deployment-paths]] — enterprise agent deployment shapes; distribution channel as a port
• [[2026-07-07-snowflake-intelligence-vs-cortex-ai-boundary]] — companion DSA discovery-framing brief; same "translate the client's product name, then move one layer down" move
• [[2026-05-20-phdata-cortex-agents-practice]] — phData engagement shapes and what the practice actually ships

Sources

Vault

• [[2026-07-13-kwik-trip-deskless-agent-distribution]]
• [[2026-07-17-kwik-trip-engagement-notes-stakeholders-and-priorities]]
• [[2026-05-21-enterprise-ai-agent-deployment-paths]]
• [[2026-07-07-snowflake-intelligence-vs-cortex-ai-boundary]]
• [[2026-05-20-phdata-cortex-agents-practice]]

Web

• Frontline worker management — Microsoft Entra — QR+PIN mechanics, SMS sign-in, My Staff delegation, shared device sign-out
• Best practices to protect frontline workers — Microsoft identity platform — Shared Device Mode semantics, on-shift vs off-shift access model, device-type taxonomy
• Manage shared devices for frontline workers — Microsoft 365 — shared device management guidance
• Shared device mode overview — Microsoft identity platform — SDM technical overview
• Microsoft 365 Frontline Licensing in 2026 — 2Data — July 2026 F1/F3 price changes (analyst source, not vendor-confirmed)
• Microsoft 365 F SKU Licensing: Frontline Guide 2026 — Redress — F1 vs F3 feature split, shared-device licensing commentary (analyst source, not vendor-confirmed)