CLI SSO login succeeds while actually failing

[athompson-merlin]

Steps To Reproduce

bw login appears to succeed, but it does not: bw unlock immediately after fails in a way it should not. See output below.

We use SSO login, so there are no master keys.

If the login process cannot set a user key, nor prepare unlock to be used, then it shold not report (in green, implying success) you are logged in, rather it should report an error or at the very least a warning that tells the user that yes, perhaps you are technically logged in, but we failed at setting up the environment for yoy.

Then, unlock should not be prompting for a master key on an SSO org account that cannot have a master key, it should be producing some sort of (idealy, useful) error instead of blindly prompting for something non-existent.

We'll follow up the login/unlock problem with [paid!] customer support, but the utility not being able to set things up correctly and then saying "yay, we're all good", and then incorrectly prompting for the master password is (IMHO) a bug in the tool, not just a support case.

Expected Result

login should be able to set a user key, or whatever it needs to do, and emit a warning or error, not success, if it can't.

unlock should not prompt for a non-existent master password.

Actual Result

C:\Users\athompson\Downloads>bw login --sso
Unable to set user key due to missing device key.
Unable to set user key due to missing encrypted device private key.
Unable to set user key due to missing encrypted user key.
You are logged in!

then

C:\Users\athompson\Downloads>bw unlock
? Master password: [hidden]
Master password is required
C:\Users\athompson\Downloads>

Screenshots or Videos

No response

Additional Context

C:\Users\athompson\Downloads>bw --version
2025.12.1

Operating System

Windows

Operating System Version

Windows 11 25H2 build 26200.7840

Shell

PowerShell

Build Version

CMD.EXE Version 10.0.26200.7840

Issue Tracking Info

• I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[bitwarden-bot]

Thank you for reporting this issue! We've added this to our internal tracking system.
ID: PM-32258
Link (for internal use): https://bitwarden.atlassian.net/browse/PM-32258

[rmcdowell-bitwarden]

Hi there,

Thank you for your report!

I was able to reproduce this issue, and I have flagged this to our engineering team.

I would like to note, that the error is that it has indicated a user has successfully logged in. At this time users without a master password are not able to use Bitwarden's CLI client:

"Users who do not have master passwords will not be able to access Password Manager CLI."

https://bitwarden.com/help/about-trusted-devices/#impact-on-master-passwords

If you wish to add any further information/screenshots/recordings etc., please feel free to do so at any time - our engineering team will be happy to review these.

Thanks once again

[jan-dix]

Strong support for this feature

This is a critical missing piece for engineering teams operating under strict security policies.

In our organization, SSO with trusted devices is a hard requirement — it's how we ensure only authorized, managed machines can access company secrets. At the same time, CLI access is equally essential: developers rely on it for local tooling.

We already use Bitwarden Secrets for machine-to-machine communication, and it works well for that purpose. However, managing that setup still requires CLI access, for example, to securely store the Bitwarden Secrets access tokens themselves.

Right now, SSO with trusted devices and CLI access are mutually exclusive, which puts us in a difficult position. We cannot compromise on SSO enforcement, but losing CLI access meaningfully impacts developer productivity and limits how we can integrate secret management into our workflows.

We'd love to see a path forward here, whether that's service account tokens, device-scoped API keys, or another mechanism that fits within the trusted device model. Happy to provide more context on our use case if it's helpful.

[JaredSnider-Bitwarden]

Thank you for your report. We've improved this experience with #22411 with an explicit error for this scenario.