Microsoft has marked Microsoft 365 Roadmap item 561652, “Microsoft Edge: Passkey Sync for Enterprise Users,” as launched for worldwide standard multi-tenant tenants, with general availability dated July 2026. The practical change is that a passkey created in a signed-in work profile in Edge can follow the user to another device rather than requiring a fresh enrollment on every machine—provided the tenant, the Edge profile, and the organization’s sync controls permit it. The important qualifier is that this is enterprise browser sync, not a blanket promise that every existing Windows Hello credential or every passkey stored by a third-party provider will suddenly roam through Edge. Microsoft’s roadmap description is terse: it says passkeys created in Edge can be synchronized for enterprise users. It does not identify a required Edge build, a supported operating-system matrix, the exact passkey data type exposed in sync policy, or whether the rollout is complete for every eligible tenant.
That lack of build information matters because the feature is being described as “v.151” in some tracking, while Microsoft’s own Roadmap entry does not name Edge 151 at all. Microsoft’s Edge 151 Beta release notes list the build series and its new policies, but do not list enterprise passkey sync as a version-specific browser feature. The evidence points to a service-backed enterprise capability becoming available around the Edge 151 cycle, rather than a clean, client-only feature switch that admins can verify simply by seeing version 151 in edge://settings/help.

Cybersecurity dashboard showing cloud identity protection, biometric laptop access, and security hardware.The feature sits on top of Edge Enterprise Sync​

Microsoft already had the underlying plumbing. Edge Enterprise Sync lets users signed in with Microsoft Entra work or school accounts sync browser data across devices, with controls for which data categories are allowed and whether users may opt out. Microsoft’s documentation says Edge sync data is encrypted in transit and at rest, and that most synced data is additionally encrypted before it leaves the client device. It also says Entra-account sync data is stored according to the tenant’s geographic region.
Passkeys make that existing synchronization service more consequential. Favorites and open tabs are useful convenience data; a roaming credential can be used to prove a user’s identity to a website or service. The data itself remains a cryptographic credential rather than a reusable password, so a relying party does not receive the secret private key during authentication. But the recovery and availability characteristics change when a credential can reach a second endpoint through the user’s managed browser profile.
Microsoft’s updated Edge policy documentation provides a clue to the intended deployment model. The PasswordManagerPasskeysEnabled policy, supported on Windows and macOS beginning with Edge 145, controls whether users may save new passkeys in the built-in password manager while signed in to Edge. If that policy is disabled, users cannot save new passkeys there; existing saved passkeys continue to function. In other words, enabling passkey synchronization does not override an organization’s decision to prevent Edge from becoming a credential store in the first place.
This is also why an administrator who has broadly disabled Edge sync should not expect this launch to change anything by itself. Microsoft’s SyncDisabled policy turns off cloud synchronization, while ForceSync can require synchronization and prevent the user from switching it off. The latter only works when browser sign-in remains enabled and SyncDisabled is not set. The normal administrative question is therefore not “Has Edge updated?” but “Does this work profile have sign-in, password-manager passkeys, and the applicable sync types permitted?”

“Passkey sync” does not mean all passkeys are the same​

The terminology is easy to flatten, and doing so would be a mistake. A passkey saved through Edge’s password manager is a browser-managed credential experience. A Windows Hello credential can be device-bound to its local Windows Hello container. A FIDO2 hardware security key is portable but physically controlled. Apple iCloud Keychain, Google Password Manager, 1Password, and Bitwarden can each operate as passkey providers with their own synchronization and recovery models.
Microsoft Entra’s current documentation explicitly separates synced passkeys from device-bound passkeys. A synced passkey’s private key is created in hardware-backed storage, encrypted on the device, and then synchronized through the selected cloud passkey provider. A device-bound passkey remains tied to one physical authenticator or endpoint. Microsoft says synced passkeys do not support attestation, the mechanism a relying party can use to verify the authenticator model and apply hardware-specific policy decisions.
For ordinary employees, that trade-off is usually intentional. Synchronization reduces the classic passwordless deployment problem: a worker loses a laptop, gets a replacement, and suddenly needs help desk intervention because the authenticator was tied to the old device. Microsoft describes synced passkeys as a lower-cost, easier-to-recover alternative for most non-privileged users.
For administrators, break-glass operators, finance approvers, developers with production access, and other high-value accounts, the answer should remain more restrictive. Microsoft’s own Entra guidance recommends device-bound passkeys, including FIDO2 security keys or Microsoft Authenticator-based options, for highly privileged users and regulated scenarios. Those credentials can provide provenance and attestation that synced credentials cannot. Edge passkey sync should expand passwordless access for the workforce; it should not become the default credential posture for privileged administration.

Existing policies can permit, block, or narrow the rollout​

The Roadmap item says “General Availability,” but general availability does not mean automatic activation within every business. Edge Enterprise Sync has licensing, cloud, tenant-configuration, and policy dependencies that predate this launch. Microsoft lists supported Entra subscriptions and Microsoft 365 plans, and says that older Business Basic and Business Standard tenants may need Microsoft Purview Rights Management Service enabled before sync functions work reliably.
Microsoft also documents regional and sovereign-cloud limits that the Roadmap’s “Worldwide (Standard Multi-Tenant)” label leaves out. Edge Enterprise Sync is not supported for GCC High or Azure Government DoD tenants, and it is not supported for the Azure service operated by 21Vianet. Organizations in those environments should not read the Roadmap item’s worldwide designation as a commitment that enterprise passkey synchronization is available to them.
The policy framework itself deserves inspection before a broad rollout:
  • PasswordManagerPasskeysEnabled determines whether users can save new passkeys in the Edge password manager.
  • SyncDisabled prevents cloud browser synchronization, including any passkey capability that depends on it.
  • ForceSync can require Edge sync for Entra profiles, but it cannot function if browser sign-in is disabled or sync is globally disabled.
  • ForceSyncTypes can mandate only named data categories, but Microsoft’s currently documented list names “passwords” rather than a separate “passkeys” category.
That final point is an operational gap, not a minor documentation quibble. Microsoft has not publicly documented whether Edge treats enterprise-synced passkeys as part of the existing passwords sync type for all policy and reporting purposes, or whether it uses another internal classification. Admins using allowlists or forced sync types should test this on a pilot group instead of assuming that a configuration permitting password sync necessarily permits passkey sync—or the reverse.

The security benefit depends on the relying service, not Edge alone​

A passkey helps only where a site, SaaS platform, or identity provider supports WebAuthn/FIDO2 sign-in. It can remove the shared secret that phishing kits traditionally capture, but it does not retrofit passwordless sign-in into legacy applications, old VPN portals, or services that still demand passwords and SMS codes. For mixed estates, Edge synchronization reduces friction at supported services; it does not eliminate the need to inventory authentication paths.
Microsoft Entra’s recent synchronized-passkey rollout provides relevant context. Entra ID now supports both device-bound and synced passkeys as generally available authentication methods, with administrators able to create profiles targeting synced credentials to selected groups. That means Edge’s new enterprise passkey sync arrives as Microsoft is broadening the identity side of the policy model as well. The browser and Entra announcements are complementary, but they are not the same deployment: enabling an Entra synced-passkey profile does not automatically authorize Edge browser sync, and enabling Edge sync does not automatically make a user eligible for Entra passkey authentication.
Cross-device use can introduce another constraint that help desks should anticipate. Microsoft’s Entra sign-in instructions say that using a passkey from another device through the QR-code flow requires Bluetooth and an internet connection on both devices. Organizations that restrict Bluetooth often do so deliberately. Microsoft documents a path for permitting Bluetooth pairing only for passkey-capable FIDO2 authenticators, but that design work should precede a company-wide passwordless mandate.

What administrators should verify now​

The useful immediate action is a controlled validation, not a fleet-wide policy change. Pick a non-privileged Entra group with two managed devices per user, confirm they have the appropriate Edge work profile, and test a new passkey registration and recovery flow at a supported service. Include a replacement-device scenario, because that is the business case synchronization is meant to improve.
During that test, review Edge policy state at edge://policy, sync status in the work profile, and the tenant’s Enterprise Sync prerequisites. Confirm whether any existing SyncTypesListDisabled or ForceSyncTypes configuration limits credentials. Test what happens when a user is removed from the target group, when Edge sync is disabled, and when the passkey is deleted from either the service account or the browser’s password manager.
Microsoft’s August 4 Roadmap update establishes that Roadmap item 561652 has moved from planned work to launched availability. What it does not establish is a universal Edge 151 cutoff, a separate administrator policy for passkeys, availability in sovereign clouds, or a safe configuration for privileged accounts. For most organizations, the immediate result should be a narrowly scoped Edge Enterprise Sync pilot; for privileged roles, retain device-bound, attestable authenticators until the organization has a reasoned exception policy.

References​

  1. Primary source: Microsoft 365 Roadmap
    Published: 2026-08-04T22:45:42.5590566Z
  2. Related coverage: microsoft.com
  3. Related coverage: learn.microsoft.com
  4. Related coverage: learn.microsoft.com
  5. Related coverage: cdn-dynmedia-1.microsoft.com
  6. Related coverage: cdn-dynmedia-1.microsoft.com
  7. Related coverage: windowscentral.com
  8. Related coverage: windowscentral.com
  9. Related coverage: techradar.com
  10. Related coverage: itpro.com
  11. Related coverage: fidoalliance.org