How can Bluetooth be restricted to passkey authentication only?

Be careful to distinguish passkeys stored on dedicated security keys from cross-device authentication. A hardware key may use NFC or USB, while using a phone's passkey on a workstation relies on Bluetooth as part of the hybrid transport. The Microsoft passkey guidance covers this restricted-Bluetooth scenario.

The reason for the restriction should drive the design. If it is an audit requirement, document the accepted risk and test the exact Windows policy in your environment, including passkey authentication, audio devices, keyboards, and file transfer. If the policy cannot reliably separate those functions, dedicated security keys are likely the cleaner compensating control.

A less complete control is to block Bluetooth file transfer, such as preventing the Windows Bluetooth file-transfer utility from running. That stops one obvious use case, but it does not prevent pairing or address vulnerabilities in the Bluetooth stack, so it should not be treated as equivalent to restricting Bluetooth connections.

Microsoft has a policy specifically for Bluetooth-restricted environments. It can allow the proximity-based Bluetooth connection used for cross-device passkey authentication while preventing normal Bluetooth devices from pairing. This is generally the direction I would investigate through Intune or the relevant Windows MDM policy rather than relying only on endpoint security software.

If the requirement is strong enough to disable ordinary Bluetooth, issuing FIDO2 security keys may be easier to defend and operate than trying to make the Bluetooth stack support one narrowly defined use case. It costs more and users can lose the keys, but it avoids exposing a broader Bluetooth attack surface.