Add option to disable new device login notification emails #148

New Issue

MrUnknownDE · 2026-04-05T20:32:45+02:00

MrUnknownDE commented

2026-04-05 20:32:45 +02:00

Originally created by @barryw on 1/18/2026

Summary

Adds a new configuration option SEND_NEW_DEVICE_EMAIL that allows administrators to disable the "New Device Logged In" notification emails that are sent when users authenticate from new devices.

Problem

Currently, when SMTP is configured, vaultwarden sends an email notification every time a user logs in from a new device. While this is a useful security feature for typical end users, there's no way to disable these specific emails without disabling SMTP entirely (which also disables password reset emails, 2FA emails, and other important functionality).

This has been requested before by users who need to suppress these notifications.

Use Cases

Bitwarden CLI in Kubernetes sidecar containers: When running the bw CLI in a sidecar container to provide secrets to applications, every container restart causes the CLI to be seen as a "new device," triggering notification emails. In environments with frequent deployments or pod restarts, this generates a flood of emails that obscure genuinely important security notifications.

Kubernetes external secrets provider: When using vaultwarden with external-secrets.io, the external secrets operator authenticates programmatically and frequently from ephemeral pods.

CI/CD pipelines: Automated systems that authenticate to sync or retrieve secrets as part of deployment workflows.

Any high-volume automated access: Scenarios where programmatic access patterns don't benefit from new device notifications and instead create noise.

Solution

Add a simple boolean config option that, when set to false, skips the new device email entirely. The option defaults to true to maintain backward compatibility.

Changes

File	Change
`src/config.rs`	Added `send_new_device_email` config option (bool, defaults to `true`)
`src/api/identity.rs`	Added config check before sending email in both auth flows
`.env.template`	Added documentation for the new option

Usage

# In your environment or .env file
SEND_NEW_DEVICE_EMAIL=false

The option is also available in the Admin panel under the "Advanced" section when enabled.

Relationship to Existing Options

Option	Purpose
`SMTP_*`	Configure email server settings
`REQUIRE_DEVICE_EMAIL`	If `true`, login fails when the notification email cannot be sent
`SEND_NEW_DEVICE_EMAIL` (new)	If `false`, skips sending new device notification emails entirely

Note: When SEND_NEW_DEVICE_EMAIL=false, the REQUIRE_DEVICE_EMAIL option has no effect since no email is attempted.

Testing

Builds successfully (cargo check --features sqlite)
All existing tests pass (cargo test --features sqlite)
Follows the established pattern for config options (same as require_device_email, disable_2fa_remember, etc.)

Backward Compatibility

Default value is true, so existing installations continue to send emails as before
No breaking changes to existing configurations

*Originally created by @barryw on 1/18/2026* ## Summary Adds a new configuration option `SEND_NEW_DEVICE_EMAIL` that allows administrators to disable the "New Device Logged In" notification emails that are sent when users authenticate from new devices. ## Problem Currently, when SMTP is configured, vaultwarden sends an email notification every time a user logs in from a new device. While this is a useful security feature for typical end users, there's no way to disable these specific emails without disabling SMTP entirely (which also disables password reset emails, 2FA emails, and other important functionality). This has been [requested before](https://github.com/dani-garcia/vaultwarden/pull/541#issuecomment-1563285877) by users who need to suppress these notifications. ## Use Cases **Bitwarden CLI in Kubernetes sidecar containers**: When running the `bw` CLI in a sidecar container to provide secrets to applications, every container restart causes the CLI to be seen as a "new device," triggering notification emails. In environments with frequent deployments or pod restarts, this generates a flood of emails that obscure genuinely important security notifications. **Kubernetes external secrets provider**: When using vaultwarden with [external-secrets.io](https://external-secrets.io/main/examples/bitwarden/), the external secrets operator authenticates programmatically and frequently from ephemeral pods. **CI/CD pipelines**: Automated systems that authenticate to sync or retrieve secrets as part of deployment workflows. **Any high-volume automated access**: Scenarios where programmatic access patterns don't benefit from new device notifications and instead create noise. ## Solution Add a simple boolean config option that, when set to `false`, skips the new device email entirely. The option defaults to `true` to maintain backward compatibility. ## Changes | File | Change | |------|--------| | `src/config.rs` | Added `send_new_device_email` config option (bool, defaults to `true`) | | `src/api/identity.rs` | Added config check before sending email in both auth flows | | `.env.template` | Added documentation for the new option | ## Usage ```bash # In your environment or .env file SEND_NEW_DEVICE_EMAIL=false ``` The option is also available in the Admin panel under the "Advanced" section when enabled. ## Relationship to Existing Options | Option | Purpose | |--------|---------| | `SMTP_*` | Configure email server settings | | `REQUIRE_DEVICE_EMAIL` | If `true`, login fails when the notification email cannot be sent | | **`SEND_NEW_DEVICE_EMAIL`** (new) | If `false`, skips sending new device notification emails entirely | Note: When `SEND_NEW_DEVICE_EMAIL=false`, the `REQUIRE_DEVICE_EMAIL` option has no effect since no email is attempted. ## Testing - [x] Builds successfully (`cargo check --features sqlite`) - [x] All existing tests pass (`cargo test --features sqlite`) - [x] Follows the established pattern for config options (same as `require_device_email`, `disable_2fa_remember`, etc.) ## Backward Compatibility - Default value is `true`, so existing installations continue to send emails as before - No breaking changes to existing configurations

MrUnknownDE closed this issue

2026-04-05 20:32:45 +02:00

Sign in to join this conversation.

No Label

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/vaultwarden#148