Bitwarden’s SSO deadline belongs on the calendar

A reminder for a particular setup

Bitwarden’s 30 September update says reminders start on 13 October for admins and owners using RSAES-PKCS1 v1.5 to encrypt SAML login data. Its stated cutoff is 1 December 2026: organisations still using that method will no longer be able to sign in through SSO. [1]

That is a configuration-specific notice. It should not be read as a claim that all Bitwarden accounts will lose access, or that ordinary password-manager use is being withdrawn. The upcoming reminder date makes the older notice relevant now; we have not confirmed that reminder emails have begun arriving.

Put the owner next to the date

Our reading is that the useful first step is establishing who can determine whether the notice applies. An employee may recognise the password-manager brand without knowing how the organisation’s sign-in system is configured. A calendar entry becomes more useful when it has a responsible person and a clear question attached.

For a South African organisation that uses Bitwarden SSO, that question could be passed to its authorised administrator or identity-service provider: does this deployment use the method identified in the vendor’s notice, and what vendor-supported transition is appropriate? This is a suggested coordination step, not a diagnosis of any reader’s account or an instruction to change a live identity system.

Bitwarden’s official client repository identifies the web, browser-extension, desktop and command-line applications it contains. That public source is useful product context, but reading code or recognising an app icon cannot tell an employee how a particular organisation has configured SAML. The deployment still needs its own answer. [2]

Keep separate changes separate

Separately, the update sets 31 October as the interface beta’s end date and plans November rollout for cloud clients. Self-hosted customers receive the design in a later server release. [1]

Our view is that one short internal note would be clearer than a general announcement that the password manager is changing. It could name the relevant configuration, identify the administrator handling the check and distinguish the SSO cutoff from the interface rollout. People reading that note should be able to see what applies to them.

Avoid treating a product update as evidence that a particular account is already affected. The useful outcome is confirmation from someone who knows the setup, followed by the vendor’s documented plan where a transition is needed. This publication has not inspected any organisation’s sign-in settings.

The dates are concrete enough to organise the work. Keep the original notice linked to the calendar entry, and keep the answer to the configuration question alongside it. That makes the follow-up easier to understand when the reminder arrives.

AI-assisted research, writing and a separate source-checking pass by the same Codex assistant. Company accounts remain attributed; editorial suggestions are identified as our interpretation. No independent hands-on test is claimed.