The watch never had a good reason to make people type a password. It has no keyboard worth the name, a screen the size of a stamp, and a customer who is usually mid-run. Yet for years the honest answer to “why does the companion Watch app throw a sign-in prompt” was “because the token lived on the phone and nobody built the plumbing to move it.” That plumbing is now shipped.
Microsoft has taken native authentication refresh-token transfer to general availability for Entra External ID — the customer-facing CIAM product, not workforce Entra ID. Read that line twice before you file a ticket. If you run staff sign-in, Conditional Access, and corporate MFA, this changes nothing for you. This is for the tenants that sit behind consumer and customer apps, where the “user” is someone who bought your thing, not someone on your payroll.
The mechanism, as far as the announcement spells it out: your iOS app authenticates through the native-auth SDK and holds a refresh token, and the companion watchOS app can reuse that session instead of running its own interactive login. The word “transfer” is doing the work in the headline — the token from the phone becomes the basis for the watch’s session rather than the watch minting a brand-new grant from a fresh password prompt. What the announcement doesn’t lay out is the wire-level detail: exactly how the refresh-token state crosses the paired-device channel, whether the watch redeems its own access tokens locally, and what the token scoping looks like on the watch side. If someone tells you they know precisely how the relay works down to the byte, ask them where the source says so. It doesn’t.
The second half of the announcement is quieter and arguably more useful day to day: SSO from a native app into an embedded web view. If your app is native but drops the user into a webview for, say, a profile page or a payment flow, that webview can now inherit the native session instead of demanding a second sign-in. That’s the paper cut everyone ignored because it was “only one extra login.” One extra login, times a few million monthly active users, is a support queue.
Licensing, because it matters: native auth in External ID rides on the monthly-active-user billing model, not on a workforce Entra ID P1/P2 SKU — buying Entra ID Premium for your staff does not unlock anything for your customer app, because it’s a different product entirely. Beyond that, Microsoft hasn’t specified tier requirements for this feature in the announcement. Don’t assume it’s gated behind a premium CIAM add-on, and don’t assume it isn’t. Confirm your current tier and MAU billing in the tenant before you promise anything to product.
Where you “enable” it is mostly a lie of convenience. This is a developer feature, not a tenant switch you flip in the portal. You’ll configure your native-auth app registration and native-auth settings under External ID in the Entra admin center, but the behaviour lives in the SDK version your mobile team ships. And here’s the part your standup won’t like: the announcement doesn’t include minimum SDK version numbers, new API method names, or sample Swift for the watch-transfer path. I’m not going to invent a build number, and there isn’t one in the source to quote. Treat that as an open question for your mobile team to pin down against the shipping SDK, not a settled fact.
Two things the announcement doesn’t shout. First: Apple Watch and embedded webviews are what’s named — there’s no mention of Android Wear OS, so if your customer base skews Android, assume you’re still writing that ticket until Microsoft says otherwise. Second: a reused refresh token is still a refresh token. Whatever your revocation, session-lifetime, and device-loss story is on the phone, the watch now inherits it — plan the 2 a.m. “customer lost their phone, watch still has a live session” conversation now, not during the incident.
Small feature. Real one. And for once the seamless bit is actually the point.