Forum Discussion
mysignins.microsoft.com failing to save passkeys
Morning. Trying to add passkeys to accounts via mysignins.microsoft.com, it almost universally fails. The failing step is when I go to name it - it just never completes. Same result using BitWarden, Yubikeys, etc. Doing this in Edge, because in Firefox - my existing security methods don't even show up.
If I check the audit logs, it will give me two entries - one stating that I failed to register security info, and another about a group management query. NO idea what this is, the only identifier within the logs is my own object ID. Possibly it's related to the group I have assigned to the Passkeys Authentication Methods policy. (which doesn't have any restrictions, but does enforce attestation)
CoPilot suggested it may be that the token is expiring, or something with my Edge profile - and to try in private browsing. No change. Doing a review of our conditional access policies to see if Registering Security info is locked down - it WAS locked down to only my region (Canada). This has since been made Report-Only, just in case.
Looking at the audit log entry for the failure, there's a correlation ID 9c269291-737f-4c17-b178-b1040834fb3f and performedBy {"AppId":"19db86c3-b2b9-44cc-b339-36da233a3be2","AgentType":0,"BlueprintId":null}. If I try to filter non-int sign-ins based on that Correlation ID, I get nothing. If I use AppId as the RESOURCEId, I get a FAILURE entry with the following error - yet no conditional access policies are applied.
The authentication details shows this, which is weird - per=user MFA shouldn't be applied. We don't use this.
But there are sign-ins at the exact same moment to the same resource, WITH MFA successful.
I can register other methods wiithout issue. I tried creating an explicit CA policy GRANTING access to register sec info, with a TAP. That is the above sign-in. TAP worked.. just NOT for passkey registration.
Other weird behaviours:
1. This portal times out so quick. Like... constantly. I have not configured anything to do this, as far as I know.
2. Opening the same portal in Firefox returns no MFA methods. None. No error, of course - it's just blank.
1 Reply
Short version: this is the attestation enforcement on your passkey profile, and the fix is a config decision rather than a workaround. A passkey that can't prove its make and model gets rejected when Entra commits it, and that commit is the save-after-naming step. That's why it dies exactly where it does.
What you do about it depends on what you actually want from passkeys.
Say the goal is letting people use password-manager passkeys, Bitwarden and the like. Then attestation has to come off. Synced providers can't produce hardware attestation, so with Enforce attestation set to Yes every one of them is excluded by design and Bitwarden will never save against that profile. Drop it to No, or build a second profile with attestation off and scope it to the users who need synced keys.
Attested device-bound only, which is the sensible posture for anything privileged? Then Bitwarden failing is correct and you leave it alone. The YubiKey is the one that should go through, and there are two reasons it might not. Attestation enforcement blocks cross-device registration. If that key is being registered over the QR / phone-as-passkey flow instead of plugged in and registered as a straight USB security key, it fails. Register it directly and that path goes away.
The other reason is the AAGUID. The model has to be one Entra's trusted metadata recognises. A YubiKey 5 is fine. Something newer or niche might not be onboarded yet, and there's no admin override for that, so attestation would have to come off for that specific key.
To find out which of these you're sitting on: set Enforce attestation to No on the profile, re-register the same YubiKey. Takes it, and attestation was the gate, now it's purely your policy call. Still fails, and it isn't attestation at all, at which point you're looking at the profile config or a service-side problem, not CA.
On CA, drop it. You cleared it yourself without realising. Report-Only doesn't enforce, your failure event shows no policy applied, and your TAP sign-in succeeded, so registering security info isn't being blocked. The failure logged under AppId 19db86c3 is just the My Sign-ins app authenticating, which you can't exclude from CA anyway. The group management query is Entra resolving which passkey profile applies to you, and both the per-user MFA line and the constant timeouts are normal for that portal.
Profile knobs are here: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2
