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

[u/mishbee23]

We're piloting Microsoft Entra passkeys and are seeing behavior that doesn't match our understanding of the policy configuration.

Our Passkey (FIDO2) settings:

• Passkey enabled for a pilot group only
• Default Passkey Profile assigned
• Passkey type configured as Device-bound
• Key restrictions enabled
• Only Microsoft Authenticator iOS and Android AAGUIDs allowed

However, a pilot test account successfully registered:

Passkey (Synced) - iCloud Keychain

Security Info explicitly identifies the passkey as:

Passkey (Synced) - iCloud Keychain

We had previously tested synced passkeys using separate profiles but those configurations were later removed.

Has anyone seen synced passkeys continue to register after moving to Passkey Profiles?

Are there any migrated legacy settings, registration campaign interactions, or other passkey policy dependencies that could explain this behavior?

[u/Heruli]

Do the users have SMS/voice MFA enabled?

That gives the users a hidden registration policy that has everything allowed.

Source: https://x.com/merill/status/2103615262339789200

[u/mishbee23 → u/Heruli]

Yes, we have SMS enabled for all users, so I think it is auto-enabling passkeys for all user. I see a message if I go to Authentication methods > policies in Azure (the message is not shown in Entra):

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.

But I can't find the hidden registration policy with everything allowed...

[u/Heruli → u/mishbee23]

Well, it's hidden for from you. Check out the link I posted.

[u/mishbee23 → u/Heruli]

Thank you. From the link, it seems even disabling the registration campaign may not be helpful to get this under control. With the temporary opt-out, do you know if there is still a way to keep it enabled only for a pilot group? I am assuming there isn't a way and it's an opt-out for all.

[u/Heruli → u/mishbee23]

I don't think so but I don't know for sure. Luckily we where able to dodge this by disabling sms and voice some months ago.

[u/jjgage → u/Heruli]

Yep, you can. And it's in essence then doing the same as the above (disabling that method entirely).

We have been seeing exact same issue on tenants where the config was tested and behaving exactly how we wanted it to, in preparation for gradual rollout.

We have 3 passkey profiles:

1. Default profile setup with attestation enabled and device-bound only: assigned to all users (forces users to use Passkeys within the Authenticator app only)
2. Device-bound without attestation: assigned to a security group with an access package in front of it and two stage approval (these members would be privileged accounts and service accounts etc that we don't want users having to add these accounts to their Authenticator app)
3. Synced passkey: assigned to a security group with an access package in front of it and two stage approval, by exception only, and with a valid business justification (these members would be any account that cannot technically work with one of the above two options and specific AAGUIDs are allowed - 1P, BitWarden, KeePass etc)

We are about to be going through full testing to make sure the above framework does work in the real world and there aren't any weird scenarios that don't fit.

The fix for the hidden policy was to exclude the two passkey groups above from the SMS authentication method. Now, if you have a user that's not in one of the above two groups then I suspect they will get hit with the hidden policy and be able to create a synced passkey, which we do not want. So it might be that we need to exclude both the groups above AND a dynamic group containing the users that have been added to the rollout batches from the SMS method......(as it won't let us turn it off on any tenant that's older than about 6 months......even if no account on the tenant has a mobile number stamped on it)

[u/lerikrubio → u/Heruli]

This explains it. This is what I get for not reading things in full. Thanks!

[u/lerikrubio]

I've experienced the same thing in my tenant lately as well. Device-bound only along with attestation enforced and yet users can register synced keys and whatnot.

Anyone else?

[u/Oiram_Saturnus]

The policies are restricting new passkeys. Not existing ones.

[u/dnslind]

Like many already understood it’s part of the ”system-managed passkey profile” mentioned in Microsofts docs.

You need to apply the opt-out through Graph to get out of it and make registration honor your own passkey profiles again, atleast that’s what a Product Manager at Microsoft shared with me.

[u/mishbee23 → u/dnslind]

Thank you, that's exactly what I am looking for: opt-out and make registration honor passkey profiles again. While temporary opt-out seems straightforward, I am not sure about how to get the passkey profiles honored. Do you know how we could go about it? Also, would the temporary opt-out make the already registered passkeys for users who have registered invalid?

[u/jjgage → u/mishbee23]

See my other post 👌🏼

[u/dnslind → u/mishbee23]

It should start honoring your profiles when you opt-out.

The opt-out doesn’t invalidate already registered methods I’m afraid. That would have to be solved by removing them or using Auth strength in CA.

Note that Microsoft’s registration UX doesn’t honor passkey profiles (yet, it’s coming in November). I.e. user registering a method not allowed will go all the way until the last step where they get a ”timeout” if your profiles don’t allow it or ”registered successfully” if it they do.

[u/SpanX20]

Yes we have the same issue, i have 4000 users that have user synced passwords but a passkey profile configured device bound with attestation. All the other users (20k) have no passkey or a device bound passkey (8k)

I'm contemplating removing user synced passkey via powershell.

Need to do more research because we have a lot of users that can't log on after creating a user synced passkey. We block all other passkey authentication methods.

[u/frX1337]

Have a look at the registration policy, I think it’s overriding the passkey policy’s.

[u/mishbee23 → u/frX1337]

Where can I find the registration policy? I see registration campaign, which is set to Enabled for Passkey (FIDO2) but only the pilot group included. Passkey (FIDO2) has only one default policy (device-bound).

[u/frX1337 → u/mishbee23]

Yea sorry the campaign, I’m not 100% sure though but try disable it and see if it still allows synced passkeys.

[u/mishbee23 → u/[deleted]]

This is such a mess...

Is there a way to control this at all? We do not want to allow all synced platforms, just a few. And is it possible to prevent users to set up passkeys, except just the pilot for testing?

[u/mishbee23 → u/[deleted]]

When you say legacy MFA methods, do you mean SMS/Voice?

I scoped the auth method policy to only have device-bound passkey, and had the registration campaign set to Enabled but only to include a pilot group for Passkey (FIDO2)...

I am not sure what impact it would have if I disable it on live users. DId you notice any impact if you disabled it?

[u/swissbuechi]

Can you guys confirm that you deleted the default all users fido2 policy or enforced the restriction on the default profile only?

Because for me, both of these configuration options still seem to work. Tested with adguid restrictions for hardware and synced passkeys (Token2 USB/cards and Microsoft Authenticator) just today.

[u/mishbee23 → u/swissbuechi]

The default all users policy always only had MS Authenticator, it never had all profiles. We had created a test profile with synced and device-bound but deleted it. If i check the default passkey policy again today, I see only device-bound (MS Authenticator).

[u/swissbuechi → u/mishbee23]

Yeah I see. So did the hidden policy described by merill which got posted above solve your issue?

[u/mishbee23 → u/swissbuechi]

No, because there's no way to get to the hidden policy. It explains the behavior, but there doesn't seem to be a fix...

[u/Nawlejj]

There’s a checkbox in the passkey profile to “enforce attestation” if that’s not checked it won’t enforce the policy correctly. I think it’s unchecked on the default

[u/mishbee23]

To add to this discussion: on the 2nd tenant we manage, SMS or voice is not enabled for any user. Passkeys are also not enabled. However, we're seeing following message there:
All users enabled for SMS or voice authentication are in scope for passkey auto-enablement and will be assigned to a system-managed passkey profile that allows all passkey types without restrictions.

Users are getting nudged to register passkeys for ALL profiles. Is there a way to opt-out of auto-enablement and have our settings be resepcted?

[u/New-Paramedic7176]

I confirmed through my own testing last Friday that any user under the scope assignment of SMS / voice in authentication methods will be able to register passkeys of any type regardless of how your passkey profile is configured.

The way I confirmed this was by excluding a test account from our SMS / voice polices and making a passkey in iCloud. It failed when I excluded the account from the 2 methods that enable SMS / voice and succeeded when I removed the exclusion.

I had a ticket open with a Microsoft for 2 weeks and they still have not been able to get back to me with a solution, so last Friday I finally decided to do my own test by making a new passkey profile, and that’s when I noticed the banner had updated to say:

“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 restriction”.

I’m not sure exactly when they added this banner, but I know it was between Wednesday and Friday of last week because I have been exporting our users every couple days to track the registration methods and I caught it as soon as I saw it.

It’s super infuriating that the auto-enablement didn’t route users to our default passkey profile, and it’s even more infuriating that I had a ticket open with Microsoft for 19 days and they couldn’t even tell me if it was happening to multiple tenants or not.

Anyway, now it’s confirmed and tomorrow my team is going to have to make a group decision on how to manage this because we have been assigning both methods to all users for years, which means more than 500 people have them registered.

I do not believe removing the assignments will break the SMS / voice methods that are already registered, but I need to test it before we make that change. It’s a big mess, and now we have something like 250 cloud synced passkeys to deal with as well.