The vibecoding part is probably because "userVerification: required" is essential to have it work somewhat-securely as your sole form of security - like Passkeys is heavily promoting. Without it anyone with physical access to the device can use it to log in. This might not be so bad for a password manager which already has strict session password requirements and short timeout periods of its own, but it is a completely different story with, say, a Yubikey.

If you're building a Passkey-based login page and you specify "userVerification: preferred" or "userVerification: discouraged" you are essentially reducing your security to a single factor - namely the "something you have" one.

The vibe coding attempts I tried weren’t passwordless. For the actual passwordless internal system, AAGUID is checked so only whitelisted password managers are allowed, “something you have” hardware keys are not accepted. I know AAGUID can be spoofed but employee somehow hacking part of the process just to register a hardware key against policy isn’t really part of the threat model.