Samuel Aspnes

Good news folks 👏 You don't need Active Directory for FSLogix in AVD anymore. youtube.com/watch?v=cP-2liCp… Did you know Active Direcotry was the #1 support ticket generator in AVD! Who would have guessed 🤯 Another one bites the dust @techspence 💨

Folks, you might have been caught out by this but it's what Microsoft said they would do, according to the docs. Since Sept 1, tenants with an attestation-enforced or AAGUID-restricted passkey policy are suddenly seeing users register synced and browser passkeys. Admins are asking "why isn't Microsoft respecting my FIDO2 policy?" Here's what's going on. The "Passkeys by default" retirement page on Learn (published July 14) says this in its Important box: "Users enabled for SMS or Voice ... will be auto-enabled for passkeys in AMP. These in scope users will be put into a passkey profile allowing ALL types of passkeys. Your Registration Campaign settings will be set to Microsoft Managed state targeting passkeys." Two important notes: 1. Passkey profiles are a union. If a user is in more than one profile, a passkey only has to satisfy ONE of them. So your attestation-enforced profile is still there. Microsoft just added a second, unrestricted profile next to it for every SMS/voice user, and that one wins for registration. 2. Your registration campaign state doesn't protect you. Disabled, Enabled, doesn't matter. The doc says it gets set to Microsoft Managed regardless, which is why some of you saw your campaign config wiped with Microsoft in the audit log. Even with the campaign off, the new profile lets users self-register a non-attested passkey from My Security Info. The ONLY way to avoid this was the opt-out flag on the authentication methods policy: PATCH graph.microsoft.com/beta/pol… { "optOutSettings": { "passkeyDynamicMigration": true } } Or moving users out of SMS and voice before Sept 1. Where Microsoft dropped the ball: the Message Center post (MC1426371) only says "passkeys will be automatically enabled for users currently enabled for SMS or voice." It never mentions a new unrestricted profile or that your attestation/AAGUID restrictions would be bypassed. And MC1469555 says the campaign "does not override configured passkey policies", which is technically true and practically misleading. The passkey profile part is only on Learn. So: not a bug, but a really important detail buried in one paragraph on a docs page. What to do now: - Look at your passkey profiles for a Microsoft-created one with both passkey types and no restrictions, and check who's targeted. - Set the opt-out flag if you need attestation to hold, then clean up that profile. Note the doc says the flag stops working Feb 1, 2027. - If you already had the flag set and it still changed, that IS a bug. Open a case. Docs: learn.microsoft.com/entra/id…