FIDO Case Analysis & Practical Application 2 — Questions and Answers
Question 1: A bank deploys FIDO2 authentication but their legacy mobile app only supports SMS OTP. Which migration strategy best maintains backward compatibility while advancing security?
- Disable SMS OTP immediately and force FIDO2 enrollment
- Run SMS OTP and FIDO2 in parallel, letting users opt into FIDO2 progressively (Correct answer)
- Replace SMS OTP with TOTP apps as an intermediate step before FIDO2
- Deploy FIDO2 only for new accounts and keep SMS OTP for existing users forever
Correct answer: Run SMS OTP and FIDO2 in parallel, letting users opt into FIDO2 progressively
A parallel deployment allows existing users to continue with SMS OTP while new and upgrading users adopt FIDO2, minimizing disruption.
Question 2: A user reports their FIDO security key works on a Windows PC but fails on a Chromebook. Which root cause should be investigated first?
- The security key's AAGUID is blocklisted by the Chromebook policy
- The Chromebook lacks WebAuthn support in its browser
- The security key transport (USB-HID) may not be permitted by enterprise Chromebook policy (Correct answer)
- The authenticator attestation certificate has expired
Correct answer: The security key transport (USB-HID) may not be permitted by enterprise Chromebook policy
Enterprise Chromebook policies can restrict USB device access, preventing HID-class authenticators from being recognized.
Question 3: During a FIDO2 registration ceremony, the Relying Party receives an attestation statement with fmt='packed' but cannot verify the certificate chain. What should the RP do?
- Accept the registration and flag it for manual review later
- Reject the registration because attestation verification failure is a security risk (Correct answer)
- Fall back to accepting self-attestation and complete registration
- Request a new registration attempt using a different authenticator
Correct answer: Reject the registration because attestation verification failure is a security risk
If the RP's policy requires verified attestation and verification fails, the registration must be rejected to prevent enrollment of untrusted authenticators.
Question 4: A healthcare provider wants FIDO authentication but requires that private keys never leave hardware. Which authenticator category satisfies this requirement?
- Platform authenticators that use software-backed keystores
- Roaming authenticators with hardware-backed secure elements (Correct answer)
- Any authenticator that supports the 'resident key' extension
- Cloud-synchronized passkeys stored in a password manager
Correct answer: Roaming authenticators with hardware-backed secure elements
Roaming authenticators with dedicated secure elements (e.g., hardware security keys) generate and store private keys in tamper-resistant hardware that prevents key extraction.
Question 5: An enterprise FIDO deployment logs authentication failures with error code 'InvalidStateError'. What scenario most likely causes this?
- The user entered the wrong PIN three times consecutively
- A registration was attempted with an authenticator that already has a credential for that RP (Correct answer)
- The WebAuthn API timed out before the user responded
- The RP's challenge nonce was reused across two sessions
Correct answer: A registration was attempted with an authenticator that already has a credential for that RP
InvalidStateError is thrown during registration when the authenticator already contains a discoverable credential for the same RP, preventing duplicate registrations.
Question 6: A government agency requires phishing-resistant MFA for all employees. They have users working on both corporate desktops and personal mobile devices. Which deployment model best meets these constraints?
- Deploy TOTP apps on personal devices and hardware keys for desktops
- Issue hardware security keys usable across both device types via NFC/USB-C (Correct answer)
- Use platform authenticators on corporate desktops only and exclude personal devices
- Implement SMS OTP with IP allowlisting to prevent phishing
Correct answer: Issue hardware security keys usable across both device types via NFC/USB-C
Hardware security keys supporting both NFC (for mobile) and USB-C (for desktop) provide phishing-resistant FIDO2 authentication across all device types.
Question 7: A developer notices that after a successful FIDO assertion, the authenticator's signature counter value is lower than the stored value. What action should the Relying Party take?
- Accept the authentication since signature verification passed
- Update the stored counter to the new lower value and continue
- Flag the credential as potentially cloned and require additional verification or revocation (Correct answer)
- Ignore the counter since it is an optional feature
Correct answer: Flag the credential as potentially cloned and require additional verification or revocation
A signature counter lower than the stored value indicates a possible cloned authenticator; the RP should treat this as a security alert and may revoke the credential.
A bank deploys FIDO2 authentication but their legacy mobile app only supports SMS OTP.
Which migration strategy best maintains backward compatibility while advancing security?