Synced iCloud Keychain passkey registration succeeds despite Device-Bound-only passkey profile

Thank you. 

I am noticing on the second tenant that we manage, we don't have SMS or voice enabled for all users. Passkey (FIDO2) is also not enabled on that tenant. But users are still getting nudged and I see the same message there as well for auto-enablement. 

Passkey auto-enablement will apply to this tenant
All users enabled for SMS or voice authentication are in scope for passkey auto-enablement. These users will be assigned to a system-managed passkey profile that allows all passkey types without restrictions.

--
Do I need to opt out on both the tenants? How do I get the passkey profiles that we have honored? It seems like system-managed is auto-enabling for all profiles, but we'd like to control this better. 

Your device-bound pilot profile can be correct while the same user is still allowed to register an iCloud-synced passkey through another applicable profile. Microsoft documents that overlapping passkey profiles are evaluated without priority: registration or authentication succeeds when the credential fully satisfies any one applicable profile. Microsoft also documents automatic passkey enablement for SMS/voice-enabled users from September 1, 2026, using a profile permitting all passkey types. That matches the additional profile described in your banner, rather than proving your AAGUID restrictions were ignored. Check the pilot user’s effective membership across every profile, including the migration-created profile, and confirm their SMS/voice policy scope. If you need to delay that rollout, evaluate Microsoft’s documented temporary Graph opt-out and verify the resulting profile assignments afterward; do not assume it removes existing credentials. Preserve an alternative authentication method, then test both fresh registration and sign-in with the restricted pilot account.

The banner suggests a second, more permissive registration path. Your restricted Default Passkey Profile may be correctly configured, while the same user also qualifies for the system-managed profile through SMS or voice enablement.

That is consistent with supplementing your configuration, but the successful registration alone doesn’t establish the exact precedence rules. It also doesn’t prove that the AAGUID restriction was ignored within your restricted profile.

Check these points first:

1. Confirm whether the pilot user is enabled for SMS or voice in the authentication methods policy, including group-based targeting. Not having a phone number registered doesn’t necessarily exclude them.
2. Review all passkey profiles assigned to that user, particularly the system-managed one.
3. If an auto-enablement scope or opt-out control is available, exclude a dedicated test account from that path while keeping it in the restricted pilot group. After policy propagation, test a new iCloud Keychain registration. Keep an alternative sign-in method available.

The precise question for Microsoft support is: “Which profile authorised this registration, and are overlapping passkey profiles evaluated as alternative allowed registration paths?” Include the registration time, relevant audit details, and both profile configurations.

Until Microsoft confirms the behaviour, don’t assume that restrictions on the Default profile apply to every other profile the user receives. Also distinguish registration from sign-in: Conditional Access authentication strengths can restrict what satisfies a sign-in requirement, but they don’t by themselves prevent registration of another method.