I'm currently getting myself up to speed with regards to the SMS/voice retirement and auto-migration to passkeys. I think I've now got a good understanding of the basics, but I still have some questions that I can't find clear answers to - particularly around the auto-migration to passkeys aspect. Some are quite specific, so maybe one for the Microsoft PMs that I know lurk in this subreddit can chip in!

As far as I understand it, part of the auto-migration is a "system-managed" passkey profile that:

1. Is not visible or modifiable by admins.
2. Overrides (or at least applies in addition to) any passkey profiles you have defined.
3. Applies to any user that is enabled for either the SMS or voice auth methods (regardless of whether they actually have those methods registered or use them).
4. Allows registration of any type of passkey (device-bound or syncable) with no AAGUID restrictions.

This system-managed profile works in conjunction with the registration campaign (which gets auto-enabled in many cases) to nudge users to register a passkey during qualifying interactive sign-ins.

The above changes are starting to roll out on 1st Sept, but the exact date each tenant gets them will vary. For simplicity, I'm going to call these the "phase 1" changes.

Am I correct with all of the above?

Is the system-managed profile always created, or only if the tenant had either the SMS or voice auth methods enabled at the time the checks for the phase 1 changes occurred on that tenant?

What happens if your tenant had both the SMS and voice auth methods disabled when Microsoft did its "pass" for the phase 1 changes, but you subsequently enable them later on? Will the system-managed passkey profile then apply, or is that a one-time decision taken when the phase 1 changes were rolled out to the tenant? I think it's probably a one-time thing, but would be good to confirm. Not an issue as you'd obviously just create your own passkey profile for it - it's just for my knowledge.

What's the easiest way to tell:

1. If a tenant has been "processed" with regards to the phase 1 changes (regardless of whether any changes were actually made)?
2. If it has been processed, whether the system-managed passkey profile was enabled?

When I inspect the Graph API traffic using DevTools while opening the Authentication Methods blade in the Entra admin center, I noticed the following features value in the response:

Some tenants have it set toenableDynamicPasskeyPolicyMigration and some to none. Is this telling me whether or not the system-managed passkey profile has been activated in the tenant? In the tenants I've checked so far, those that had either SMS or voiced turned on had features set to enableDynamicPasskeyPolicyMigration and those that didn't had it set to none. This makes me think this value is saying what I think it is, and MS are calling this process "passkey dynamic migration" internally. Is there a better / less hacky way to get the same information? Initially, I thought the below banner would be it, but it seems to appear regardless of the value of the features value in the auth methods policy.

If it appears regardless of the state of the system-managed passkey profile, what exactly is this banner telling me? What is the specific logic that determines whether or not it appears?

If I apply the Graph API opt-out after the phase 1 changes have applied, will it disable the system-managed passkey profile? I think I've seen people say the answer to this is yes, but would like to confirm.

Lastly, is there anything else that's "special" about this system-managed passkey profile, or can you effectively just think of it as exactly the same as having the default profile with no restrictions enabled?

Thanks in advance!

Hi everyone,

I'm enforcing Phishing-Resistant MFA through Entra Conditional Access for our privileged accounts.

Our users have Windows Hello for Business on their Windows 11 workstations and FIDO2 passkeys in Microsoft Authenticator.

Everything works fine locally, but we're running into issues when users RDP into Windows Server 2019 and try to access Azure Portal through Edge or run "az login".

The server doesn't seem to support redirecting passkey authentication to the user's local Windows Hello or Microsoft Authenticator on their phone.

Currently, I'm excluding certain cloud resources from our Conditional Access policies, but I'd prefer to avoid these exceptions.

Has anyone successfully configured WebAuthn/passkey redirection on Windows Server 2019 over RDP, or is this a limitation that requires Server 2022/2025?

Thanks!