The reason why the attack works without “biometrics or device unlock” is because it only works on passkeys that were issued without requiring user verification:

> The Pass-ta-key attack is effective when the relying party does not strictly require user verification. Many relying parties configure WebAuthn’s userVerification parameter as preferred rather than required to support diverse devices and user experiences, making them susceptible to this attack.

So it’s possible for a relying party to mitigate this attack by requiring user verification and checking that the proper bit was set.

Later on, the article outlines an issue with the way that Chrome interacts with Windows Hello during passkey registration and another issue where Chrome dumps the TPM’s master key in process memory, but these are endpoint concerns and have since been patched