Forum Discussion
passkeys in the Authenticator app regarding attestation
I have a question about passkeys in the Authenticator app regarding attestation in connection with QR code-based cross-device sign-in.
When we register a passkey with attestation enabled in the Authenticator app, it can be used to complete the sign-in process on another device via QR code and Bluetooth Low Energy. According to Microsoft’s documentation, this shouldn’t be possible with attestation enabled, yet it works. What are we misunderstanding here?
https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-authenticator-passkey
Thanks for your inputs.
Johannes
Hello jgeisler
From what I understand, the observed behavior aligns with the WebAuthn/FIDO2 cross-device authentication model used by Microsoft Authenticator.The confusion likely comes from the documentation mixing different concepts:
- cross-device registration
- cross-device authentication
- attestation enforcement
The QR code + Bluetooth LE flow is part of the official cross-device authentication mechanism. In this scenario, the private key remains stored on the mobile device (device-bound) and only signs the authentication challenge remotely after BLE proximity validation.
Microsoft documentation indicates that when attestation is enabled, restrictions mainly apply to cross-device registration, and in some pages it also mentions cross-device authentication. However, behavior may vary depending on the current implementation, tenant policy configuration, and how the passkey was originally registered.
So based on your test results, this does not appear to be a bypass. It is most likely the expected cross-device authentication behavior supported by Microsoft Authenticator, even when the passkey itself remains device-bound.
4 Replies
I think the confusion comes from the difference between where the credential is stored and how the authentication ceremony is performed.
Attestation mainly verifies properties of the authenticator during registration (device/authenticator trust and provenance). It does not necessarily prevent cross-device authentication flows themselves.
In the QR + BLE scenario, the passkey still remains on the original authenticator device (the phone running Authenticator). The other device is essentially delegating the authentication request to that trusted authenticator rather than exporting or syncing the credential itself.
So even with attestation enabled, cross-device sign-in can still work because the attested authenticator is the one actually performing the cryptographic operation.
At least that’s how I interpret Microsoft’s implementation/documentation behavior here. Curious to hear if anyone from the Entra/Auth team can clarify further.
After doing some more research, I also think this behavior is to be expected. However, as you mentioned, the documentation would need to be updated in several places to make it clearer for everyone.
Thanks
JohannesHello jgeisler
From what I understand, the observed behavior aligns with the WebAuthn/FIDO2 cross-device authentication model used by Microsoft Authenticator.The confusion likely comes from the documentation mixing different concepts:
- cross-device registration
- cross-device authentication
- attestation enforcement
The QR code + Bluetooth LE flow is part of the official cross-device authentication mechanism. In this scenario, the private key remains stored on the mobile device (device-bound) and only signs the authentication challenge remotely after BLE proximity validation.
Microsoft documentation indicates that when attestation is enabled, restrictions mainly apply to cross-device registration, and in some pages it also mentions cross-device authentication. However, behavior may vary depending on the current implementation, tenant policy configuration, and how the passkey was originally registered.
So based on your test results, this does not appear to be a bypass. It is most likely the expected cross-device authentication behavior supported by Microsoft Authenticator, even when the passkey itself remains device-bound.
Amazing!
