DEV Community: Pascal Kuhn

Local-First vs. Cloud Password Managers: What SMBs Should Know

Pascal Kuhn — Wed, 01 Jul 2026 12:17:08 +0000

A practical comparison of local-first and cloud-based password managers for small and medium businesses, with a focus on data sovereignty and compliance

Introduction

Choosing a password manager for an SMB shapes where credentials live, who can access them, and how your organisation responds to audits and regulatory questions. Cloud-based tools dominate because they deploy quickly and sync across devices. Local-first alternatives trade some convenience for tighter control over data location and trust boundaries. This article compares both from an IT decision-maker’s perspective — without declaring a universal winner.

Cloud password managers: convenience with a third-party dependency

Most commercial password managers encrypt secrets on the client, then synchronise ciphertext through the vendor’s cloud. The vendor holds account metadata, device registrations, sharing policies, and recovery mechanisms. Even when vault contents stay unreadable to the vendor, your organisation depends on that third party for availability, policy enforcement, and incident response.

Expanded attack surface

A cloud relay adds layers beyond the endpoint: the vendor’s API and sync infrastructure become persistent targets; account recovery flows can weaken the model if poorly governed; and supply-chain risk applies to every update channel and backend service. Breaches at centralised credential stores affect many customers at once, and SMBs without dedicated security teams can only investigate what the vendor discloses.

Operational dependency

Outages, pricing changes, or data-residency shifts affect your workflows immediately. Vendor lock-in and subprocessors in GDPR documentation become recurring compliance work. Cloud managers are not inherently insecure — the point is architectural: you accept a shared trust boundary with an external operator whose incentives and jurisdictional exposure may not align with yours.

What “local-first” means in practice

“Local-first” is often used loosely in marketing. Architecturally, it should mean that secret material is generated, encrypted, and primarily stored on infrastructure you control, without a mandatory cloud relay for core operations.

In a local-first design:

The authoritative vault resides on a workstation, server, or repository within your environment.
Encryption and decryption happen on the client before data is written to disk or synced.
Browser or SSH integrations communicate with the local client directly — for example via Native Messaging — rather than routing credentials through a vendor cloud hop.
Synchronisation, when needed, uses a channel you choose (local network, self-hosted Git, file share) instead of a proprietary vendor backend.
OxidVault follows this model. The Desktop Safe stores encrypted vault data locally, uses AES-256-GCM for data encryption and Argon2id for key derivation, and connects the browser extension to the desktop client through Native Messaging. Audit events are recorded as structured metadata chains suitable for ISO 27001-style traceability. There is no requirement to send secrets to OxidVault-operated cloud infrastructure for normal use.

Local-first does not mean “never connect to the network.” It means the network is optional and under your control, not a structural dependency for every read and write.

GDPR and data sovereignty for SMBs

For European SMBs, GDPR requires lawful basis, data minimisation, subprocessors documentation, and demonstrable compliance. Cloud password managers process employee identifiers, access logs, and device metadata on vendor infrastructure. Even encrypted vault ciphertext may trigger DPIA obligations or Schrems II concerns when metadata sits on US-hosted services.

Local-first deployments can align data residency with where you run the vault, shrink subprocessor lists, and keep audit trails in systems you administer. This does not remove compliance work — policies, access reviews, and incident response remain yours — but it shifts the accountability boundary inward when credentials are high-risk assets.

Where local-first is harder — and how teams address it

Local-first designs face legitimate operational challenges. Two come up repeatedly in SMB deployments.

Multi-device and multi-site synchronisation

Cloud managers solve sync by default: install the app, sign in, and ciphertext propagates through the vendor. Local-first tools must define an explicit sync strategy. Without one, users maintain separate vaults on each device — a common source of drift, stale credentials, and unsafe workarounds.

Team onboarding and key management

Sharing a vault across colleagues requires more than a shared password. Each user needs authenticated access, ideally with individual credentials and second factors, without exposing a single master key to everyone.

OxidVault addresses team use through a multi-user vault model where each user holds their own Key Encryption Key (KEK), derived from their individual password and 2FA. Vault data is encrypted with a Data Encryption Key (DEK); that DEK is wrapped separately for each authorised user (KEK-wrapped DEK). Adding or revoking a user means re-wrapping keys for the affected parties — a standard pattern that limits blast radius if one user’s credentials are compromised.

For synchronisation, OxidVault offers Git-based sync: encrypted vault artefacts can be versioned in a repository your organisation controls. This provides an auditable history, supports offline-first workflows, and lets you choose hosting — internal GitLab, GitHub Enterprise, or air-gapped remotes — rather than a proprietary sync cloud. The trade-off is that someone must operate the Git remote and onboarding process; there is no invisible vendor backend handling it automatically.

SSH Quickconnect, browser extension integration without a cloud intermediary, and compliance-oriented audit logging round out day-to-day use. The Community Edition supports up to five users per vault under AGPLv3; larger teams can evaluate Enterprise for LDAP and SSO. OxidVault currently ships a full Windows client; Linux and macOS are on the roadmap. Teams needing instant mobile access across unmanaged devices may find local-first workflows less convenient and should plan accordingly.

Conclusion

Cloud managers suit teams prioritising fast rollout and frictionless multi-device access. Local-first fits SMBs treating credentials as regulated assets or seeking fewer third-party dependencies — at the cost of more operational responsibility. The right choice depends on threat model, regulatory context, and how much infrastructure your team will run.

Next steps:

Visit oxidvault.com for product overview, feature details, and contact options.
Explore the open-source Desktop Safe and releases on GitHub.
Both resources are maintained for evaluation and deployment planning — not as a substitute for your own security assessment.

I Built a B2B Password Manager in Rust

Pascal Kuhn — Mon, 29 Jun 2026 14:16:16 +0000

💡 TL;DR: I built a file-based B2B password manager in Rust with multi-user encryption (DEK wrapping, no server required).

A practical look at building secure multi-user encryption without a server.

At our office, passwords lived in a shared Excel file.

Yeah..., I know.

But if we're being realistic, most people have seen worse.

I started looking at alternatives.

Bitwarden is great, but it wants a server.
KeePass works well, but multi-user support never really felt like a first-class use case.
LastPass had… its moment.
And 1Password means subscriptions and trusting the cloud.

What I wanted felt surprisingly simple:

An encrypted file sitting on a file server.
No Docker. No VPS. No subscription.

Just a vault multiple people could access — each with their own password.

So I built it.

Why Rust Ended Up Being the Right Choice

I could have built this faster in Python or Go.

But a password manager that leaves secrets hanging around in memory isn't a password manager — it's a liability.

That’s where Rust made sense.

Its ownership model removes an entire class of memory-related mistakes from the equation.

The zeroize crate quickly became essential. Every sensitive buffer gets explicitly wiped when it leaves scope:

let master_key: Zeroizing<Vec<u8>> = derive_key(&password)?;
// Automatically wiped when dropped

The Multi-User Problem Is Harder Than It Looks

Single-user encryption is relatively straightforward.

Multi-user encryption without a server gets interesting fast.

The obvious approach is one shared master password.

Which sounds convenient — until someone leaves the company.

Now you're rotating passwords, re-encrypting data, distributing credentials, and inevitably doing it at the worst possible time.

So I ended up with DEK wrapping.

Vault structure

Vault payload
└── Encrypted using DEK (random, never changes)

Each user:
└── KEK derived from user password (Argon2id)

└── DEK wrapped with that KEK

Each person has their own password.

Removing a user means deleting their wrapped DEK entry.

The vault itself never needs to be re-encrypted.

Getting there took three format versions.

Not ideal — but at least the migration code survived.

Tauri Was the Right Choice — Mostly

One thing I didn't expect:

The security boundary became incredibly clean.

The React frontend never touches key material directly.

Secrets move through a single command with rate limiting in place:

#[tauri::command]
pub async fn reveal_secret(
    state: State<'_, AppState>,
    entry_id: String,
) -> Result<String, String> {
    rate_limit_check(&state)?; // 5 requests per 60 seconds
    ensure_vault_unlocked(&state)?;
}

The browser extension via Native Messaging turned out to be harder.

Keeping the connection alive without creating focus loops while the app was minimized to the system tray took three complete rewrites.

The Unexpected PDF Detour

I needed PDF exports for GDPR compliance reports.

First attempt: printpdf.

Two days later: a high-severity vulnerability in lopdf, no upstream fix.

Second attempt: jsPDF in the frontend.

Client-side. Offline. UTF-8 behaved properly. Output looked professional.

In hindsight, I should have started there.

Lesson learned:

Use the simplest solution first — especially for things that aren't your core product.

What I Got Wrong

I wrote everything in German first

My target market was DACH, so it felt reasonable.

The first comment on r/rust:

"readme.de.md — very few people here speak German."

So this week I translated everything.

I built too many features before talking to users

SSH Quick Connect.
Git sync.
GPO policy management.

All before having a single real customer.

Some of it was genuinely fun to build.

Whether anyone actually needs it is still an open question.

I underestimated the system tray

It seemed trivial.

It wasn't.

The interaction between minimize-to-tray, auto-lock policies, browser extension behavior, and focus management created bugs I'm still untangling.

Where OxidVault Stands Today

OxidVault v2.2.0 currently runs on Windows and includes:

Multi-user vaults (per-user password + TOTP)
ISO 27001 audit logs with SHA-256 hash chaining
GDPR compliance PDF export
SSH Quick Connect with host key verification
Browser extension via Native Messaging
Configurable auto-lock timer in the UI

Community Edition is free for up to 5 users (AGPLv3).

GitHub
👉 https://github.com/caRl0oo/oxidvault

Website
👉 https://oxidvault.com

What's Next

Windows toast notifications for expiring passwords — the underlying logic already exists.

And more importantly:

Actually talking to users.

That’s something I should have done much earlier.

If you have thoughts on the crypto architecture or the DEK-wrapping approach, I'd genuinely love to hear them.