

My company insists on expiring passwords every 28 days, and prevents reuse of the last 24 passwords. Passwords must be 14+ characters long, with forced minimum complexity requirements.
Outdated security practices & cargo culture. Someone should roll up a copy of NIST SP 800-63 to smack them over the head until they read it:
The following requirements apply to passwords:
- Verifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.
- Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
- Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.
- Verifiers and CSPs SHOULD accept Unicode [ISO/ISC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.
- Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
- Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Maybe ask them their security qualifications & whether they follow the latest security research & industry standards.
I use Bitwarden, yet not macOS/iOS. Whenever a passkey dialog from the wrong authenticator comes up, I choose option other to redirect to a device running Bitwarden: I see macOS & iOS offer similar controls. However, Bitwarden’s passkey dialog (section with links to configuring that) usually pops up, so that isn’t necessary.
Save a recovery code in Bitwarden (add field type hidden named Recovery code to the login entry)? That’s standard practice for me, though I’ve never needed them.
I’ve seen forms disable paste. Much can go wrong with passwords. Passwords require sharing & transmitting a secret (a symmetric key), which either party can fail to secure. Passkeys, however, never transmit secrets. Instead, they transmit challenges using asymmetric cryptography. The application can’t fail to secure a secret it never has. Far more secure, and less to go wrong.
The password field is a more manual, error prone user interface. With passkeys/WebAuthn, you instead supply a key that isn’t transmitted: easier than passwords when setup correctly, & nothing to do until it’s setup correctly.
Similar situation with ssh: though it can accept passwords, ssh key authentication is way nicer & more secure.