Why a password manager for air-gapped networks needs its own plan
If your team works on a network with no internet access and still needs shared credentials, activity logs and a way to recover access, the realistic self-hosted candidates are Vaultwarden and Passbolt. The hard part is the boundary, not the vault. Both products run comfortably on a server inside the enclave, but everything around them assumes a connection: container images are pulled from public registries, browser extensions and mobile apps update from stores, certificates are often issued by public authorities, and support tickets travel over email. Each of those assumptions has to be replaced with a deliberate decision before the first install.
Start with transport. The Vaultwarden README states that the web vault requires HTTPS because of the Web Crypto API, so the enclave needs an internal certificate authority that clients trust and a reverse proxy that serves it. Confirm how your browsers and mobile devices will receive the internal root certificate, because a vault that users cannot reach securely is not a usable vault. On the client side, the browser extension update problem is the one most teams underestimate: an extension installed from a store will not receive fixes unless you mirror its packages into the enclave and push them through managed browser policy. Ask your vendor or partner which client builds they will supply, how each is signed, and how an updated build is verified before distribution.
Treat scope as a written decision. Agree in writing which systems are inside the boundary, which clients are supported, who performs offline upgrades and how backups leave the enclave, if they leave at all. Vaultwarden's maintainers say they cannot be held liable for data loss and recommend regular backups of files and the database, so the backup design is part of the scope, not an afterthought. Before work starts, ask for a written list of every package, image and certificate that must cross the boundary, along with the verification steps for each, so that the plan can be reviewed by the people who own the network.
Which requirements shape an air-gapped password vault
This table maps three regulatory requirements to the concrete build items an air-gapped team vault needs, with the evidence an assessor will ask for and where deployments usually fall short. Read each row as a question to answer for your own sector, and confirm with counsel and assessors which requirements apply to your organization.
| Requirement | What it asks for in the vault | Build item and evidence to keep |
|---|---|---|
| HIPAA 45 CFR 164.312 access control and unique user identification | Each person has their own vault identity, with no shared logins to the vault itself | Named accounts in the offline directory, group-based sharing rights, and a record of who was granted access and when |
| HIPAA 45 CFR 164.312 audit controls | Activity in systems holding ePHI is recorded and periodically examined | Server and admin event logs exported to an internal log store, with a review routine and retention set by policy |
| HIPAA 45 CFR 164.312 person or entity authentication | Strong proof that the user at the keyboard is the enrolled user | MFA enrolled on the offline network with hardware keys or a local authenticator, and documented reset steps |
| HIPAA 45 CFR 164.312 transmission security | Credentials are protected between client and server | HTTPS with a certificate from the internal CA, and TLS settings recorded in the install baseline |
| FTC Safeguards 16 CFR 314.4 multi-factor authentication | MFA for any individual accessing an information system holding customer data | MFA policy enforced on the vault, with enrollment records and exception approvals kept |
| FTC Safeguards 16 CFR 314.4 encryption in transit and at rest | Customer information encrypted on the wire and on disk | Internal CA certificates, encrypted database and backup volumes, and a documented key custody procedure |
| FTC Safeguards 16 CFR 314.4 monitoring of authorized user activity | Logging and monitoring of what authorized users do in the vault | Activity logs forwarded offline, alerting on admin actions, and evidence of review |
| NERC CIP-013-2 software integrity and authenticity | Verification of vendor software and patches before they cross the isolated boundary | Checksums or signatures checked for each container image, package and browser extension, with the check log kept as transfer evidence |
Which password managers fit an isolated network and why
Two open-source vaults cover most team needs on an isolated network, but they differ in encryption model, database, edition packaging and which features need a paid tier. The cards below set out what to check for each before you commit to an offline install.
Vaultwarden licensing and client fit
Vaultwarden is an alternative server for the Bitwarden Client API, licensed under AGPL-3.0, and works with the official Bitwarden clients. For an isolated network, this means the client apps you distribute must come from a source you can verify offline. Confirm that the browser extension and desktop and mobile builds you carry across the boundary match the server version you run. The project states it is not associated with Bitwarden, Inc., so vendor support questions go to the Vaultwarden project.
Vaultwarden database and HTTPS
Vaultwarden uses SQLite by default, and its configuration template recommends PostgreSQL through DATABASE_URL for production. The web vault requires HTTPS because of the Web Crypto API, so an isolated network needs an internal certificate authority and a reverse proxy trusted by every client. Plan the database backup and the certificate chain together, since a vault that loads without valid HTTPS is unusable for browser users.
Vaultwarden organizations and SSO
Vaultwarden implements organizations with collections, member roles, groups, event logs, admin password reset and policies, which covers most shared team needs. Single sign-on through OpenID Connect arrived in version 1.35.0, so check that your identity provider is reachable on the internal network and that SSO settings such as SSO_SIGNUPS_ALLOWED match your onboarding process. Confirm which event log fields your audit process requires, since the README does not list them.
Passbolt end-to-end encryption model
Passbolt uses OpenPGP, so each user holds a key pair and each user with access to a shared resource receives their own encrypted copy. The server stores only ciphertext and encrypts and decrypts in the browser extension or mobile app. On an isolated network this means every user's private key must be backed up and recoverable, which makes the account recovery design a key decision before rollout. Confirm which metadata your organization encrypts under the v5 format.
Passbolt Community limits and Pro features
The Community Edition is free and self-hosted with unlimited users, but account recovery, LDAP provisioning, SSO, MFA policies, syslog activity logs and SCIM are listed as Pro features. Pro is priced at $4.9 per user per month billed annually with a 10-user minimum, according to Passbolt's pricing page. Map each requirement your auditors and directory team need against the edition table before you size the deployment, and ask for a written quote that covers isolated-network support.
Passbolt install paths and export controls
Passbolt supports Docker, a Kubernetes Helm chart, Ansible and installation on several Linux distributions, so you can match the install path to what you can transfer across the boundary. The official charts and images are AGPL-3.0, and the team should verify checksums and signatures of each artifact before transfer. Since version 5.10, cleartext CSV exports are disabled by default, so confirm the export policy matches your data handling rules. Virtual appliances are a Pro option.
How an air-gapped vault rollout proceeds, phase by phase
The sequence moves an air-gapped team vault from agreed scope to a tested, restorable service, with each phase closing on a named artifact so that the client can verify progress before the next phase begins. The order matters because the offline artifacts, certificate chain and client packages must exist before users can be onboarded.
Agree scope and classify the vault data
The client and DeployOpen agree in writing which teams, shared accounts, service credentials and recovery material go into the vault, and which data class each belongs to. The client's security and compliance owners review the classification and sign it off, including where the server, backups and admin credentials will sit. The output is a signed scope and data classification document that sets the boundary for every later phase.
Build the staging environment and artifact inventory
In a connected staging environment, DeployOpen builds the target platform, pins the chosen edition and version, and pulls every container image, operating system package, library and browser extension package the install needs. Each artifact is recorded with its version, checksum and source, and the client's team checks the list against its own supply chain requirements. The output is a signed artifact list that becomes the only input allowed across the isolated boundary.
Install offline and configure internal CA HTTPS
The artifacts are moved into the isolated network through the client's approved transfer process and installed with no outbound connections. The web vault requires HTTPS, so the team issues a certificate from the organization's internal certificate authority, installs the chain on the reverse proxy and confirms that clients trust it. The output is a working vault test in which a staff browser loads the vault over HTTPS and completes a login and a shared item test.
Plan client and browser extension distribution
Because app stores and extension marketplaces are unreachable, DeployOpen and the client agree how desktop clients, mobile apps where used, and browser extensions reach managed devices. The plan records each package's version, signature check, deployment route through device management, and the process for updating extensions when the server version changes. The output is a distribution runbook that names the owner of each package and the update procedure.
Import credentials from the current tool
Credentials are migrated from the current password manager or spreadsheet using the import formats the chosen edition supports, tested first on a sample set in staging. Imported items are checked for completeness, duplicates and correct folder or collection placement, and any cleartext export file is handled under the client's export controls and deleted after use. The output is an import reconciliation report showing counts by source and the items that needed manual correction.
Configure SSO or local MFA
The client confirms whether users sign in through an internal identity provider or through local accounts with multi-factor authentication, and DeployOpen configures the chosen method against the internal directory. Administrative accounts, break-glass access and MFA enrollment paths are tested before general rollout, including what happens when the identity provider is unavailable. The output is a signed authentication configuration record and a test log showing successful and failed sign-ins for each user group.
Test backup and restore
Backups of the database, attachments and configuration are taken on the schedule the client approves and copied to the storage the client designates, all inside the isolated network. DeployOpen then restores the backup to a separate host and checks that users, vault items, sharing and recovery settings come back intact. The output is a restore record that states the backup timestamp, the restore date, what was verified and any gaps the client must close.
Hand over during hypercare
After go-live, DeployOpen supports the client through an agreed hypercare period, watching access failures, extension issues and onboarding questions and updating the runbook with fixes. The client's team takes over operations, upgrades and offline update media, and confirms the procedures it will run. The output is a completed runbook and a handover record listing open issues, owners and the next scheduled backup restore test.
How client delivery differs for each constraint
In a fully disconnected enclave, nothing enters the network except what staff carry across on approved media. Server images, browser extension packages, desktop installers, mobile packages and their signatures are all staged inside the boundary before go-live. Updates arrive as complete bundles that are verified and then installed by hand, so every release is a planned event.
- Browser extensions: Install the signed Passbolt extension or the Vaultwarden-compatible Bitwarden client from packaged files stored on an internal share, and confirm that your browser fleet can load them through managed policy.
- Desktop apps: Copy installers in with their published checksums and record the hash values in the change record.
- Mobile apps: Distribution depends on device management. Confirm whether your MDM can push internal builds to managed devices without an app store.
- Certificates: Vaultwarden requires HTTPS for the web vault, so the internal CA root must be installed on every client before the first login.
- Staff time: Each release needs staging, verification, change approval and a test pass. This effort recurs with every update, so ask any partner to quote the release cadence in writing.
Confirm with your platform team which store and sideload policies apply to each browser and mobile fleet before you choose a client path.
A controlled one-way transfer uses a data diode or guarded transfer point that moves files in one direction only. Packages are scanned, hashed and signed on the outside, then imported on the inside. The vault server cannot reach upstream, so update notices, release notes and new signing keys must also be carried across in the bundle.
- Bundle contents: Build one bundle per release that includes server container images, client packages, signatures, checksums and release notes.
- Integrity checks: Recompute hashes at the transfer point and verify signatures against keys obtained through a separate, trusted channel.
- Browser extensions: Import the signed extension package from the bundle and push it through managed browser configuration. Confirm the push method with your fleet owners.
- Desktop and mobile: Desktop installers come from the bundle. Mobile builds need an enterprise channel that accepts offline packages, so confirm this with the MDM owner.
- Staff time: Each bundle triggers a transfer request, approvals and operator handling. The cost recurs with every release, and the 2026 Vaultwarden releases of 1.37.2 on August 22, 1.37.3 on September 13 and 1.37.4 on October 5 show how often bundles could arrive.
Ask the transfer-point owner for accepted file types and size limits, and confirm with your platform team whether signed client packages are permitted through the gateway.
An internal mirror keeps a local container registry, package repository and download host, and syncs them from upstream on a schedule through a narrow allowlist. Clients update only from internal sources, and the sync job is the single path to the outside. Signatures are checked when content is ingested into the mirror and again on each client, so a mirror cannot quietly replace a verified package.
- Container images: Mirror the Vaultwarden images from the ghcr.io, docker.io or quay.io registries into the internal registry, and pin deployments by digest.
- Browser extensions: Host the signed Passbolt extension package internally and update it only after review in the mirror.
- Desktop and mobile: Keep an internal download location with published checksums. Mobile updates still depend on MDM distribution.
- Signature enforcement: Verify at ingest and configure clients to reject unsigned or mismatched packages, then test that rejection on a sample device.
- Staff time: Sync review, allowlist changes and regression testing recur with each release. Ask for the sync design and the egress approval steps in any quote, since these recur as a cost.
Confirm with your security team which egress destinations the sync job may use and with your platform team whether an internal mirror satisfies store and sideload policy for each device fleet.
Why backups and browser extension updates are the hard part
The backup design is the first thing to get right, because the vault is only as recoverable as its last verified copy. The Vaultwarden README states that the maintainers cannot be held liable for data loss and highly recommends regular backups of both files and the database, so the design has to cover two artifacts: the data directory (attachments, icons and configuration) and the database itself, whether SQLite or the PostgreSQL instance named in DATABASE_URL. Back up both on a schedule, copy them to media that leaves the enclave on a controlled path, and keep the database dump and file snapshot taken at the same point in time so they restore to a consistent state. Confirm with your own team how often a full copy must be taken and how many generations are kept, because the answer depends on how much staff change and how long an isolated network can go without a refresh.
Browser extensions are the second hard part. The Passbolt browser extension is cryptographically signed, so every update has to be treated as a software package crossing the isolation boundary: download it on the connected side, verify the signature and version against the vendor's release, stage it on an internal test endpoint, and then push it to managed browsers through policy rather than letting each user sideload it. Air-gapped fleets often have no automatic update path at all, so the update calendar, the rollback package for the previous version and the owner who signs off each release need to be written down before go-live. The same discipline applies to the Vaultwarden and Passbolt server images, which must be mirrored into an internal registry and checked against the vendor's published releases before they are deployed.
Restore testing and key recovery are where offline designs usually fail quietly. Run a restore into a separate isolated host at a set interval, log the result, and confirm that a named user can log in and decrypt a sample item, since a backup that restores the database but not the OpenPGP key material or the user's recovery path is not usable. For Passbolt, confirm how account recovery works without the internet, because Pro-only account recovery and SSO features may change the answer, and ask the vendor which editions your fleet requires. Before go-live, ask your implementation partner to document the restore runbook, the offline key escrow procedure and who holds the credentials to unlock both.
Evidence the vault produces for assessors
This table maps each piece of evidence an assessor may ask for in an air-gapped vault to the component that produces it and the records to keep. Read it as a checklist of what to export and retain, not as proof of compliance, because the assessor decides whether the evidence is sufficient for the control in scope.
| Evidence item | Component that produces it | What to retain and confirm |
|---|---|---|
| Event logs and admin audit records | Vault server (Vaultwarden or Passbolt syslog and activity logs, confirm edition) | Export on a fixed schedule to an internal log store; confirm which events are recorded and retention length in your edition |
| MFA configuration and enrollment | Vault admin settings and identity provider (SSO or local two-factor) | Screenshots or config exports showing enforced MFA methods and policy scope; confirm whether enforcement is per user, group or organization |
| TLS certificate inventory | Internal certificate authority and the reverse proxy in front of the vault | Certificate subject, issuer, validity dates and the host each certificate covers; keep the CA root and chain documentation |
| Package hash and signature records | Offline staging process (media transfer log and verification step) | Hashes of each image, client installer and extension file, the signing key used, who verified them and the approval record |
| Backup and restore test records | Backup job and a separate restore environment | Dated backup logs, database and attachment checksums, and a restore test result showing a working login and recovered items |
| Access review exports | Vault member, group and collection listings, plus the directory if synced | Periodic exports of members, roles, group membership and shared collections, with reviewer sign-off and removals made |
| Break-glass and emergency access records | Emergency access feature and sealed credential store | Logs of emergency access grants, usage alerts and rotation records after each use |
Questions buyers ask about air-gapped password managers
What drives the cost of an air-gapped password manager deployment?
The main drivers are the number of users and shared resources, the number of environments (production, test, and any disaster recovery site), how much of the offline supply chain you must build, and the depth of integration with your directory and certificate authority. Software licensing is a separate line item: Vaultwarden and the Passbolt Community Edition are free to self-host, while the Passbolt Pro price is published per user per month on the Passbolt pricing page, with a 10-user minimum. Recurring costs include server capacity, backup storage, patching, and any support retainer. Ask for a quote that separates one-time work (offline bundle creation, installation, HTTPS and client packaging, testing) from recurring work (updates, backups, and support), and that states which items are your responsibility.
Can our internal team run an air-gapped password manager alone?
Often yes, if the team already operates Linux servers, containers, and internal certificates, and can maintain an offline update path. The hard parts are not the install itself but the recurring tasks: moving signed software packages across the isolation boundary, keeping server and client versions compatible, rotating the internal CA, testing restores, and handling a lost user key or account recovery request. Vaultwarden and Passbolt both publish container images and installation guides, but a team that has never run a credential store should plan for an initial learning period and a named owner. DeployOpen can plan, implement, document, and support the system inside your environment under a written scope, so you can decide which tasks stay in-house.
How long does setup take for an air-gapped password manager?
Timing depends on the environment, not on the software alone. The factors that change the schedule are the state of the offline package pipeline, whether HTTPS certificates from an internal CA already exist, how many client platforms must be packaged without an app store, the number of users to onboard and import, and the approval cycle for changes in a regulated network. No duration is set here. Ask the implementation partner to show the milestones, the deliverables at each one, the dependencies on your team (network diagrams, CA access, device management, and test users), and the acceptance criteria in the written scope before work starts.
Is Vaultwarden or Passbolt the better fit for an air-gapped network?
It depends on the sharing model and the controls you need. Vaultwarden is a lightweight, Bitwarden-compatible server, licensed under AGPL-3.0, with organizations, collections, groups, event logs, and SSO with OpenID Connect since version 1.35.0. Passbolt uses OpenPGP end-to-end encryption, where each user holds a key pair and each user with access receives their own encrypted copy. Its Community Edition is free, while LDAP provisioning, account recovery, SSO with AD FS and other providers, MFA policies, syslog activity logs, and SCIM are listed as Pro features. Choose Passbolt if you need OpenPGP-based sharing and the Pro controls; choose Vaultwarden if you need Bitwarden-compatible clients and can meet your audit and directory needs with its feature set. Confirm both against your requirements in a proof of concept.
How are browser extension updates handled without internet access?
Browser extensions normally update from the public browser stores, which an isolated network cannot reach. The usual approach is to package the extension version that matches your server, distribute it through your internal software deployment tools or group policy, and disable automatic store updates where your policy requires it. Each new server release can change the client API, so extension and server versions must move together. Passbolt documents that its browser extension is cryptographically signed, which is worth verifying as part of the package intake check. Confirm with the vendor how each client is delivered and updated for your browsers, and document the procedure as part of the change process.
What does the work need from our side before implementation starts?
Most of the early work depends on information only your organization holds. Expect to provide network diagrams that show the isolated segments and the paths users and servers can reach, access to your internal certificate authority or a decision on which CA will issue the HTTPS certificate, and details of the device management platform that will deploy clients. You will also need a named owner for the server, a list of test users and shared resource types, and a copy of your password and sharing policies. For directory integration, provide the directory structure and the identity provider details. Agree these inputs in the written scope so the implementation timeline reflects them.
Does DeployOpen issue audit reports for our password manager?
No. DeployOpen plans, implements, hardens, documents, and supports the system, and it prepares the controls and evidence that an assessment will examine. It does not issue audit reports, attestations, or certifications. Independent auditors and certification bodies perform those assessments. For example, a team preparing for a HIPAA or FTC Safeguards Rule review could ask for evidence such as access control configuration, audit log settings, and the backup and restore test records, then give those records to its own assessor. Clarify in the written scope which evidence DeployOpen will produce and which records remain your responsibility.
What to ask an implementation partner before signing
Start with the offline artifact inventory. Ask the partner to list every container image, client package, browser extension file, database driver and TLS tool that will cross the isolation boundary, with the version and checksum of each. Ask how each artifact is signed, who holds the signing keys, and how your team verifies a signature inside the enclosure without reaching a public keyserver. Ask how the partner handles the Vaultwarden and Passbolt release cycles: Vaultwarden published 1.37.4 on October 5, 2026, and Passbolt published v5.16.0 on September 17, 2026, so ask how many releases are expected to be carried over per quarter and who decides whether a release is worth the transfer. Next, pin down the internal CA and update staging. Ask who issues the server certificate, whether the root is in your PKI or a new one, how client devices receive the root, and how the partner tests that the browser trusts the chain before go-live. Ask how the browser extension and desktop or mobile clients will be staged. The web vault requires HTTPS, and extensions are updated by the browser vendor's store in connected setups, so ask what replaces that path, who approves a new extension package, and how a rollback works if a new build breaks the client-to-server API. Finally, ask for backup and restore evidence and written acceptance criteria. Require a restore test on a separate host, with the database and attachment files recovered and a user able to log in and decrypt a sample entry. Ask which support tiers the partner offers for the open-source edition, what Passbolt Pro features such as account recovery, SSO and MFA policies would require under its published editions, and what the partner will not cover. Put the test steps, owners and pass criteria in the statement of work before signing, so that acceptance rests on observed results rather than on the partner's description of them.
How DeployOpen scopes and supports an air-gapped vault
This sequence turns an air-gapped password manager idea into a written scope, a tested offline build, and a handover package that the client's own team can run and that assessors can review.
Confirm the isolation model and requirements
DeployOpen meets the security owner, the infrastructure lead and the vault administrators to document the network boundary, who may cross it, how media is approved, which users and shared accounts need vault access, and which regulations or internal policies apply. The output is a requirements register that names the edition question (Community, paid or vendor-specific airgapped builds) and the open items the client must confirm with each vendor. Work does not start until the client signs off on this register.
Agree the fixed written scope
DeployOpen writes a fixed scope covering the selected platform, the hosts or containers in scope, the offline installation method, HTTPS design, client distribution, backup and restore testing, documentation, and any evidence to be prepared. Deliverables, exclusions, acceptance criteria and responsibilities for each party are stated explicitly. The client approves the scope and quote in writing before any work begins, so the reader can see exactly what is and is not included.
Design the offline build and certificate chain
DeployOpen designs how software packages, container images and dependencies are obtained on a connected staging side, verified for integrity and authenticity, and transferred across the boundary. The design also covers the internal certificate authority, the certificate chain that browsers and clients must trust, and the reverse proxy in front of the vault. The output is an architecture diagram and a transfer procedure that the client's change process can approve.
Build and harden the vault offline
DeployOpen installs the chosen server (Vaultwarden or Passbolt, depending on the scope) inside the isolated network using only the carried-in artifacts, then applies hardening: database configuration, TLS settings, administrative access, logging, and disabling features the client does not need. Installation is verified by checking that the service starts without outbound connections and that the web vault loads over HTTPS from an internal client. The output is a build record with versions, hashes and configuration values.
Distribute clients and test recovery
DeployOpen prepares a method for installing browser extensions, desktop and mobile clients without public app stores, including how updates are staged and reviewed. It then tests backup and restore of the database and attachments on a separate system, and documents the update path for the browser extension. The check is a restored vault that opens with a test account and an update rehearsal that produces a logged, approved change. Recovery results are recorded so the client knows the procedure works before go-live.
Document operations and prepare evidence
DeployOpen writes runbooks for administrators covering user onboarding and offboarding, backup schedules, certificate renewal, package transfer for patches, and incident handling. It also assembles evidence that an assessor may ask for, such as configuration records, access lists, log samples and test results. DeployOpen prepares this material for the client, but independent auditors and certification bodies issue any assessment outcome. The output is a documentation set the client owns and can hand to its assessors.
Hand over and move to a retainer if needed
DeployOpen runs a handover session with the administrators, walks through the runbooks, and confirms that the client team can perform a backup, restore and patch transfer on its own. If the client wants continued help, ongoing support, upgrades and continuous testing are available as a retainer under a separate written agreement. The closing check is a signed handover record that lists open items, the owner of each item and the agreed next review.
