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

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.