Supported Microsoft app sign-ins can now use passkeys and FIDO2 security keys registered with an external identity provider through a system-browser handoff. Microsoft’s September 29, 2026 announcement covers eligible Android, iOS, and managed macOS scenarios. It does not establish universal compatibility for every app, browser, or security-key model. Microsoft announcement

For organizations using federated authentication, this addresses an important practical question: why can a credential work on the identity provider’s website but fail when the employee starts inside an application?

Why the browser handoff matters

Microsoft describes a limitation in some earlier app sign-ins: an embedded web view could not provide the capabilities needed for external-provider passkeys. The updated experience opens the provider’s authentication step in the system browser, then returns the user through the Microsoft identity broker to the originating app. Supported apps include Outlook, Teams, OneDrive, Word, Excel, PowerPoint, and Microsoft To Do. Announcement and supported applications

The distinction is about where authentication happens. It should not be interpreted as Microsoft’s broker directly adding support for every third-party hardware authenticator. Microsoft explicitly makes that distinction in its implementation guidance. Browser authentication documentation

Our editorial takeaway is that a passkey deployment needs an application-level test. Testing only the provider’s website leaves part of the employee’s actual journey unexamined.

Which environments are in scope?

Microsoft’s documentation identifies general availability in the Entra public cloud, with national clouds remaining in preview. The supported experience requires brokered authentication and WS-Fed or SAML 2.0 federation.

Android requires Chrome, configured as the default browser for the standard scenario. iOS uses Safari with Microsoft Authenticator; managed macOS uses Safari with Company Portal. Minimum component versions vary, so administrators should use the current support matrix.

Linux, unmanaged macOS, and OAuth/OIDC social-provider flows are outside this capability’s supported scope. Direct Android Company Portal sign-in still uses an embedded web view. Windows already has a separate native third-party FIDO experience. Current scope and prerequisites

These boundaries make a useful purchasing discipline clear: identify the supported workflow before choosing the quantity of hardware to order. An announcement about a platform family should not replace a check of the specific environment.

What does the administrator control?

The feature is off by default. Microsoft documents enablement through the federation configuration’s systemBrowserEnabledOn property. Its Graph resource describes the platform setting for browser-based authentication. This is an administrator-controlled federation change, rather than a switch employees can assume is already enabled. Microsoft Graph federation resource

Our recommendation is to give this change an owner and a small pilot. The owner should coordinate the identity team, endpoint management, and application support, since each team sees a different part of the experience.

Test the journey employees actually use

Consider a hypothetical employee who signs in successfully on a provider’s website but cannot complete a Teams sign-in. That observation narrows the investigation; it does not, by itself, prove a defective key. The next useful question is where the app-initiated journey diverges.

For a pilot, we recommend a short acceptance checklist:

• Start from the employee’s normal application, not a bookmarked identity-provider page.
• Confirm the expected browser opens at the provider’s legitimate domain.
• Use the approved credential and verify that the application completes sign-in.
• Repeat on each intended device category, including shared devices where relevant.
• Check both a fresh session and a normal returning-user session.
• Test the approved backup method and the support process for an interrupted return to the app.

Keep a non-sensitive results table showing the application, platform, approved configuration, and outcome. Do not put tokens, passkey material, or personal authentication details into a general rollout spreadsheet.

We also recommend separating “credential unavailable,” “authentication failed,” and “return to application failed” in support intake. Those descriptions are more actionable than a single report that the security key does not work.

Where Thetis security keys fit

A physical authenticator is worth evaluating when users need a separate device for supported account access. Browse Thetis FIDO2 security keys, then confirm the chosen model against the external provider’s policies and the complete device-and-application workflow.

This article does not report a Thetis compatibility test or certify a model for the new experience. The practical opportunity is to run a focused pilot against a newly documented authentication path.

Treat the September announcement as a reason to revisit previously blocked app journeys. The success criterion is an employee completing the intended sign-in reliably, with the approved authentication method and a workable recovery process.

Announcement published September 29, 2026; sources checked September 30, 2026. Recommendations and the hypothetical example are editorial analysis.