Azure Key Vault vs Bitwarden Secrets Manager

Azure Key Vault

Access runs on Microsoft Entra ID tokens and Azure roles that can be scoped to one secret, with soft delete, a 99.99 per cent SLA and a public OpenAPI contract. Secret rotation needs an Event Grid trigger and a function the owner writes, audit logging is off until enabled, and an Azure subscription needs a person and a payment card.

Bitwarden Secrets Manager

End-to-end encrypted, decrypted only on the client that holds the token. No release since 22 May 2026, and the npm SDK is still 1.0.0 from September 2024.

Azure Key Vault

1. Request a token for the resource https://vault.azure.net and send it as a Bearer header. Every call must carry api-version, such as 2025-07-01, because there is no default
2. Ask for the Key Vault Secrets User role on the vault or the single secret. Key Vault Reader returns metadata only, not values
3. Cache secret values in memory. A vault allows 4,000 reads and 300 secret creations per 10 seconds, and a subscription five times that
4. On 429 wait 1, 2, 4, 8 then 16 seconds. Throttled requests do not count against the limit
5. Don't retry Set Secret blindly. Each successful call creates a new version of the secret

Bitwarden Secrets Manager

1. Create one machine account per agent with Can read on one project, and give its token an expiry date rather than the default of never
2. Run the agent under bws run -- <cmd> so secrets arrive as environment variables and aren't written to disk or into the context
3. Fetch with bws secret list <project-id> --output json once per run; bws secret get needs the secret's UUID, not its name
4. Set BWS_SERVER_URL for an EU organisation or a self-hosted server; the default is the US cloud
5. Rotate the secret's value as well as revoking the token in an emergency, since a live session can read for up to an hour