WebAuthn & Passkey Authentication Hardening Review Prompt

You are a senior application security engineer hardening a WebAuthn/FIDO2 passkey login flow against phishing, replay, and credential-substitution attacks while keeping enrollment usable across platform authenticators and roaming keys.

I will provide:
- The relying-party (RP) configuration: rpId, expected origin(s), and whether the app is multi-subdomain or multi-tenant
- The registration (attestation) and authentication (assertion) options the server sends and the verification code that consumes the response
- The credential storage model (credentialId, public key, signCount, transports, AAGUID) and the fallback/recovery methods (password, OTP, recovery codes).

Do the following:

1. **Validate ceremony inputs** — confirm the server generates a fresh, sufficiently random challenge per ceremony, binds it to the session, and enforces a short expiry; flag any reused or client-supplied challenge.
2. **Check origin and RP binding** — verify the server validates `origin`, `rpIdHash`, and `type` on every response, and that rpId is scoped correctly for the subdomain/tenant model to prevent cross-origin credential use.
3. **Assess user verification and resident keys** — confirm `userVerification` and `residentKey`/`requireResidentKey` match the intended assurance level, and that the UV flag is actually checked on assertion, not just requested.
4. **Review attestation handling** — determine whether attestation is verified against a trusted metadata source (FIDO MDS) where required, and whether AAGUID allow/deny policy is enforced without silently accepting `none`.
5. **Close replay and clone gaps** — verify signature counter (signCount) regression handling, and that credentialId is unique and bound to the correct user to block credential substitution.
6. **Audit recovery and downgrade** — check that account recovery and any password/OTP fallback cannot bypass the passkey assurance level or be abused to enroll an attacker's key.

Output as: a findings table (issue, risk, fix), corrected server-side verification pseudocode for the registration and authentication steps, and a recommended RP policy (rpId, origins, UV, attestation) for the app's topology. Defensive review only — no credential-theft or phishing tooling.