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 fileSEND_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.
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
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.
## 📋 Pull Request Information
**Original PR:** https://github.com/dani-garcia/vaultwarden/pull/6734
**Author:** [@barryw](https://github.com/barryw)
**Created:** 1/18/2026
**Status:** ❌ Closed
**Base:** `main` ← **Head:** `feature/disable-new-device-email`
---
### 📝 Commits (1)
- [`1403609`](https://github.com/dani-garcia/vaultwarden/commit/1403609b8f8b97491d7b61269b4fee537b783cd2) Add option to disable new device login notification emails
### 📊 Changes
**3 files changed** (+10 additions, -2 deletions)
<details>
<summary>View changed files</summary>
📝 `.env.template` (+4 -0)
📝 `src/api/identity.rs` (+2 -2)
📝 `src/config.rs` (+4 -0)
</details>
### 📄 Description
## 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
---
<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
📋 Pull Request Information
Original PR: https://github.com/dani-garcia/vaultwarden/pull/6734
Author: @barryw
Created: 1/18/2026
Status: ❌ Closed
Base:
main← Head:feature/disable-new-device-email📝 Commits (1)
1403609Add option to disable new device login notification emails📊 Changes
3 files changed (+10 additions, -2 deletions)
View changed files
📝
.env.template(+4 -0)📝
src/api/identity.rs(+2 -2)📝
src/config.rs(+4 -0)📄 Description
Summary
Adds a new configuration option
SEND_NEW_DEVICE_EMAILthat 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
bwCLI 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 totrueto maintain backward compatibility.Changes
src/config.rssend_new_device_emailconfig option (bool, defaults totrue)src/api/identity.rs.env.templateUsage
The option is also available in the Admin panel under the "Advanced" section when enabled.
Relationship to Existing Options
SMTP_*REQUIRE_DEVICE_EMAILtrue, login fails when the notification email cannot be sentSEND_NEW_DEVICE_EMAIL(new)false, skips sending new device notification emails entirelyNote: When
SEND_NEW_DEVICE_EMAIL=false, theREQUIRE_DEVICE_EMAILoption has no effect since no email is attempted.Testing
cargo check --features sqlite)cargo test --features sqlite)require_device_email,disable_2fa_remember, etc.)Backward Compatibility
true, so existing installations continue to send emails as before🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.