Why public sector agencies need a self-hosted password manager
Agencies that hold shared administrator, service and vendor credentials need a vault that runs on agency infrastructure, not in a commercial cloud they cannot inspect or control. A self-hosted vault on agency-controlled servers meets that need. For most agencies, Passbolt is the strongest fit when OpenPGP end-to-end encryption and directory sync are requirements, because each user holds a key pair and receives a personal copy of every shared secret encrypted to their public key. Vaultwarden is a lighter option for smaller teams that do not need OpenPGP or directory provisioning, but it runs a different encryption model and has a different support story, so the choice should be made against written requirements.
The data and hosting picture differs from a commercial deployment in three ways. First, the server stores only ciphertext for credential contents, so the agency's custody of keys matters more than the server's location. Second, metadata such as resource names, URLs and descriptions may still be visible to the server unless the organization enables metadata encryption, which applies to the v5 format. Confirm this setting with the vendor before you write the design. Third, the vault, its database, its backups and its reverse proxy all become systems the agency must patch, back up and document. Ask who holds the administrator role, where backups are stored, and which jurisdiction governs the hosting contract.
Compliance evidence for this design comes from independent auditors and the agency's own assessment bodies, not from DeployOpen. DeployOpen can plan, deploy, harden and document the vault and prepare the control evidence your assessor will request, such as access logs, sharing records and offboarding tickets. Before the assessment starts, confirm with your assessor which control frameworks apply to your agency and which system boundary they will examine.
Requirements public sector agencies must map to their vault
This table traces each public sector requirement to the rule or control that creates it and to what it means for a self-hosted vault. Read each row as a question to answer before choosing hosting, edition and sharing design. Several requirements apply only in specific contexts, so confirm applicability with your compliance lead before writing the build specification.
| Requirement source | What it asks for | What it means for the vault build |
|---|---|---|
| NIST SP 800-53 Rev. 5 baselines | Low, moderate and high baselines select 149, 287 and 370 controls and enhancements respectively under SP 800-53B | Confirm the baseline your system authorization uses, then map access control, audit and authentication controls to vault settings and records |
| FedRAMP scope under OMB M-24-15 | Cloud products that store or process federal information on behalf of an agency fall in scope, while single-agency systems not offered as a shared service generally do not | A vault hosted in a commercial cloud for federal data needs an authorization path; a self-hosted vault in agency-controlled facilities may fall outside it, so confirm scope in writing |
| CJIS Security Policy v6.1 encryption | FIPS 140-3 validated modules or AES with 256-bit keys for criminal justice information in transit and at rest outside physically secure locations | Verify TLS and database encryption use validated modules, set key lengths in writing, and ask the implementer which crypto libraries ship in the container image |
| CJIS vulnerability scanning | Vulnerability scanning at least monthly under RA-5 | Schedule monthly scans of the vault host, container image and database, and keep scan reports as evidence tied to remediation tickets |
| 32 CFR 2002.14(h)(2) for CUI | Federal agencies apply NIST SP 800-171 when setting protections for controlled unclassified information on non-federal systems, unless the CUI category prescribes other safeguards | If the vault holds CUI credentials on contractor or partner systems, map password policy, MFA and logging to SP 800-171 requirements and document the mapping |
| NIS2 for EU public administration | Central government entities are covered regardless of size, and Member States may extend coverage to local public administration | Confirm your national transposition and whether your agency is in scope, then document hosting location, incident handling and supplier security obligations |
| MFA through SSO | Strong authentication for users accessing systems that hold sensitive information | Federate vault login to the agency identity provider so MFA policy lives in one place, and confirm which Passbolt or Vaultwarden features need a paid edition |
| Log retention and audit | Activity records that show who accessed or changed shared credentials, retained for the period your authority sets | Forward vault activity logs to your central log store, set retention in writing, and test that logs survive a restore |
Which password manager fits an agency: Passbolt, Vaultwarden or Bitwarden
Passbolt and Vaultwarden both let an agency host the vault on its own servers, but they protect data differently, and that difference shapes what the server operator can see. Passbolt uses end-to-end encryption based on the OpenPGP standard: each user has a key pair, and each user with access to a shared resource receives a copy encrypted with their public key. Encryption and decryption happen in the browser extension or mobile app, not on the server, and the server stores ciphertext. Vaultwarden is a Rust implementation of the Bitwarden Client API, compatible with the official Bitwarden clients, which use client-side encryption for vault items. Metadata such as names and URLs is encrypted in Passbolt only with the v5 format and when the organization enables metadata encryption, so agencies should confirm that setting before loading sensitive records.
- Passbolt key model: Each user holds an OpenPGP key pair, and sharing means encrypting a copy of the resource for each recipient.
- Passbolt metadata: Enable metadata encryption in v5 format if resource names and URLs are sensitive.
- Vaultwarden client encryption: Vault items are encrypted by the Bitwarden-compatible clients before they reach the server.
- Browser extension trust: Passbolt states its browser extension is cryptographically signed, which agencies should verify in their own distribution process.
Confirm with each vendor exactly which fields the server can read in your deployment and document the answer for your security assessor.
The feature set an agency needs depends heavily on the edition. Passbolt publishes a free self-hosted Community Edition with unlimited users, and it lists several capabilities only in Pro, including LDAP user and group provisioning from Active Directory or OpenLDAP, account recovery, SSO with Microsoft, Google, OpenID and AD FS, MFA policies, syslog activity logs, password expiry policy and SCIM. Passbolt Pro is priced at $4.9 per user per month billed annually with a 10-user minimum, according to Passbolt's pricing page, and Enterprise is quoted individually. Vaultwarden is free and open source, and it implements many organization features, including collections, groups, event logs, policies and Directory Connector support, along with SSO through OpenID Connect since version 1.35.0.
- Passbolt Community: Free self-hosted edition with unlimited users, but without directory provisioning, account recovery or syslog activity logs.
- Passbolt Pro: Adds LDAP and SCIM provisioning, account recovery, MFA policies and syslog logs for a per-user subscription.
- Vaultwarden SSO: OpenID Connect single sign-on was added in version 1.35.0 and refined through 1.37.3.
- Vaultwarden organization features: Collections, groups, event logs, policies and admin password reset are available in the open-source server.
- Bitwarden official edition: Compare its self-hosted and paid tiers directly with the vendor before assuming parity with either option.
Ask each vendor to map every required control to a specific edition and version, then price only the features your audit requires.
Passbolt's API server, Docker packaging and Helm chart are published under AGPL-3.0, which allows self-hosting and modification but carries source-sharing obligations for networked modifications. Vaultwarden is also licensed under AGPL-3.0. Its README states that the project is not associated with Bitwarden or Bitwarden, Inc., and that one active maintainer is employed by Bitwarden and contributes on personal time. The maintainers focus on individuals, families and small organizations, and they direct bug reports to the Vaultwarden project rather than to official Bitwarden support. The README also says the maintainers cannot be held liable for data loss and strongly recommends regular backups of files and the database. For an agency, this means Vaultwarden is not a vendor-supported product in the procurement sense, while Passbolt sells a commercial subscription for its Pro and Enterprise editions.
- Passbolt commercial terms: Pro and Enterprise come from Passbolt under a written subscription, which is the contract an agency can procure.
- Vaultwarden project model: Support comes from the community and maintainers, not from a contracted vendor.
- Bitwarden trademark separation: Vaultwarden is independent of Bitwarden, Inc., so do not describe it as an official Bitwarden product in internal documentation.
- Liability language: Vaultwarden's stated disclaimer on data loss should inform the backup and recovery design.
Have legal and procurement confirm whether a community project or a vendor subscription satisfies the agency's sourcing rules.
Public sector agencies usually need the password manager to follow the same identity source as the rest of the environment. Passbolt Pro provides LDAP provisioning from Active Directory or OpenLDAP, SCIM and SSO with AD FS, and syslog activity logs that a security operations center can ingest. Vaultwarden supports SSO through OpenID Connect and Directory Connector, and its event logs cover organization activity. Whether either option fits depends on your directory design, your joiner and leaver process, and the log format your SIEM expects. Neither tool replaces an identity governance platform, so account lifecycle decisions should still come from the authoritative directory.
- Passbolt directory sync: LDAP and SCIM provisioning are Pro features, so budget for them if automated joiner and leaver handling is required.
- Vaultwarden directory support: Directory Connector and OpenID Connect SSO cover common Microsoft and general identity setups, but confirm behavior with your own directory.
- Audit log export: Passbolt Pro sends syslog activity logs, while Vaultwarden event logs need a documented export path to your SIEM.
- Offboarding evidence: Test that a removed user loses access in both tools and that the removal appears in the logs.
Run a pilot with your own directory and log pipeline before committing to either product.
The support model is often the deciding factor for an agency. Passbolt offers commercial support tied to its paid editions and a hosting guide covering Debian 13, Ubuntu 26.04, Red Hat, AlmaLinux, Rocky Linux and Oracle Linux 9, openSUSE Leap 15 and SLES 16, Docker, Kubernetes Helm and Ansible. Vaultwarden recommends container images from ghcr.io, docker.io and quay.io, requires HTTPS for the web vault, and supports SQLite, MySQL or PostgreSQL, with PostgreSQL marked as recommended in its configuration template. Agencies should confirm which operating systems, database engines and support hours a given contract covers, because vendor terms and community responsiveness differ and this page does not set them.
- Passbolt support terms: Ask for named support levels, response commitments and upgrade coverage in writing before purchase.
- Vaultwarden operating model: Plan internal ownership for upgrades, database maintenance and incident response, since no vendor is contracted.
- Database choice: PostgreSQL is recommended for Vaultwarden, while SQLite suits only small single-node setups.
- Release cadence: Passbolt v5.16.0 and Vaultwarden 1.37.4 are recent releases, so confirm the version your agency will standardize on and its patch policy.
- Implementation partner: DeployOpen can plan, install, harden and support either option inside your infrastructure under a written scope.
Confirm support terms, the fit for your directory and audit needs, and the edition required for each control before you select a product.
How the vault sits in agency infrastructure
A government vault is a set of components the agency controls end to end: hosts, a reverse proxy, a database, the directory, an SSO or MFA layer, logging and backups. The design question is less about the vault itself and more about which of these pieces sit inside agency boundaries and which trust relationships each one creates.
Hosts on agency infrastructure
Passbolt runs on Linux hosts, Docker or a Kubernetes Helm chart, all of which can sit on agency-controlled virtual machines, private Kubernetes or data center hardware. Confirm that the cloud region, hypervisor and backup targets are inside the boundary your authorizing official accepted. Vaultwarden is commonly run from container images, so check that the image sources and registries your team pulls from are approved for the environment.
Reverse proxy and HTTPS
Vaultwarden requires HTTPS for the web vault because the Web Crypto API depends on a secure context, and it is designed to sit behind a reverse proxy. Terminate TLS at a proxy under agency control, use certificates issued by the agency's internal or approved certificate authority, and confirm which TLS versions and cipher suites the proxy enforces. This is also where you decide what the browser extension and mobile clients are allowed to reach.
Database and backup placement
Vaultwarden uses SQLite by default, while its configuration template marks PostgreSQL as the recommended database set through DATABASE_URL. Place the database on agency-controlled storage, restrict its network path to the application, and keep copies of encrypted backups in the country required by policy. The Vaultwarden maintainers state that they cannot be held liable for data loss and recommend regular backups of files and the database, so the backup restore test is an agency responsibility.
Directory and SSO or MFA layer
Passbolt's LDAP provisioning from Active Directory or OpenLDAP, SSO with AD FS and MFA policies are Pro features, so the directory integration is a licensing decision as well as an architecture one. Where the agency wants one identity front end, Keycloak can federate Active Directory or LDAP and handle OpenID Connect or SAML sign-on. Confirm which login path applies to administrators, break-glass accounts and vault recovery, since SSO outages can lock users out.
Trust boundary for client-side encryption
Passbolt encrypts and decrypts in the browser extension or mobile app, not on the server, and the server stores only ciphertext. Vaultwarden similarly keeps vault contents encrypted for the client. Metadata such as names, URLs and descriptions is protected only in the v5 format with metadata encryption enabled, so the server, its database and its logs may still expose structure. Document what the server can see, and ask the vendor or integrator to show it in writing.
Log forwarding to the agency SIEM
Passbolt's Pro edition provides syslog activity logs, and Vaultwarden includes event logs for organizations. Forward these to the agency SIEM over an agency-approved transport and confirm that logs record who accessed or shared which credential, without storing secret values. Check which log lines the chosen edition emits, how long the SIEM retains them, and whether the reverse proxy and database logs are forwarded as well.
How an agency rollout moves from assessment to operation
The sequence moves an agency from a documented scope and control mapping to a production vault that has tested backups, runbooks and monitoring. Each phase closes with an output that the agency's security, records and operations owners can review before the next phase begins.
Scope the vault and map controls to the baseline
The agency's security lead, records owner and DeployOpen's engagement lead agree which systems, user groups and credential types the vault will hold, including whether criminal justice information, controlled unclassified information or other regulated data may be stored. The team maps the agreed scope to the agency's applicable baseline, such as a NIST SP 800-53 baseline selected by the agency's authorizing official, and records which controls the vault supports and which must be met at the system level. The step closes with a signed scope document and a control mapping that names an owner for each control.
Decide platform, edition and hosting location
The team compares Passbolt, Vaultwarden and self-hosted Bitwarden against the scoped requirements, including OpenPGP client-side encryption, sharing model, directory sync, SSO, activity logs and recovery. It confirms which features require a paid edition, identifies the support contract the agency needs for the open-source edition, and selects the hosting location on agency-controlled infrastructure. The step closes with a written decision record covering edition, hosting, data residency, and the named party responsible for patches and upgrades.
Build the vault in a test enclave
DeployOpen's engineers install the chosen platform on a test enclave that mirrors the production network, configure HTTPS with certificates issued by the agency's internal certificate authority, and set up directory synchronization from the agency's identity source. Cryptographic modules for TLS and data encryption are checked against the FIPS 140-3 requirement wherever the control mapping calls for it, and the team documents the validated module versions the agency must confirm with its vendors. The step closes with a build record, a configuration baseline and test results for login, directory group mapping and session handling.
Pilot with a limited group of administrators
A small group of agency administrators uses the vault for real shared administrative accounts, under the agreed sharing rules and approval steps. The team tests folder and group design, password policies, multi-factor enforcement, emergency access and the activity logs that the records owner expects to review. Issues are logged, triaged and fixed in the test enclave before any change reaches production. The step closes with a pilot report listing defects, policy changes and open risks, each with an owner.
Import from the current tool without cleartext exports
The agency exports credentials from its current tool using the method the vendor provides, then imports them into the vault using the platform's supported import formats. Cleartext CSV export is kept disabled in the export policies, and any export needed for migration uses an encrypted format with controlled access and deletion. Imported records are reviewed for duplicates, orphaned entries and shared accounts that need an owner. The step closes with a migration log, a reconciled record count, and confirmation that the source export files were deleted under the agency's retention rules.
Cut over to production with offboarding procedures
The agency schedules the production cutover, freezes changes in the legacy tool, and moves users in groups tied to directory membership. Offboarding procedures are tested in production so that removing a user from the directory revokes vault access, triggers rotation of shared credentials that user knew, and records the action. Legacy access is retired on the agreed date after the agency confirms that all required credentials are in the vault. The step closes with a cutover record, a list of retired accounts, and evidence of at least one tested offboarding event.
Hand over runbooks, restore tests and monitoring
DeployOpen documents installation, upgrade, certificate renewal, user lifecycle and incident procedures in runbooks that the agency's operations team can run. The team performs a backup restore test into the test enclave, confirms that the database and attachments are both covered, and sets up monitoring and alerting for service health, failed logins and log delivery to the agency's security monitoring. The handover is complete when the agency's operators run a supervised restore and an upgrade without DeployOpen assistance, and the support arrangement is confirmed in writing.
How OpenPGP end-to-end encryption changes the audit conversation
Passbolt's OpenPGP model changes the first question an auditor asks, which is what the server can read. Each user holds a key pair, and each user with access to a shared resource receives their own copy of the secret encrypted with their public key. Passbolt encrypts and decrypts inside the browser extension or mobile app, not on the server, and the documentation states that the server only receives and stores ciphertext. That gives an assessor a concrete architecture to test: request the data flow, confirm where decryption happens, and check that the server database holds ciphertext. The browser extension is cryptographically signed, which lets the agency verify what it installs.
Metadata is a separate question. Names, URLs and descriptions are encrypted only with the v5 format and only when the organization enables metadata encryption, so the agency should confirm both before it writes its audit narrative. Ask the vendor or partner to show the metadata settings on the target version (the current v5 release line is in the Passbolt releases) and record the setting as evidence. An auditor will otherwise assume that resource titles and URLs are visible to the server, and the agency should not leave that assumption unanswered.
The encryption model moves control to procedures the agency must still run. Key recovery is the hardest: if a user loses the private key, the agency needs a documented path that does not weaken the model, and it should confirm how account recovery works in the edition it buys, since it is a Pro feature. Admin reset policy also needs a written rule covering who can trigger a reset, how identity is verified, and how the event is logged. Finally, the agency must control browser extension distribution through its own managed channel, verify the signature on each release, and pin approved versions, because a tampered client is the one place where end-to-end encryption can be bypassed.
Evidence auditors and oversight bodies ask for
This table lists the evidence a public sector agency typically needs to show for a self-hosted Passbolt deployment, the component that produces each item, and what to confirm before an assessment. Read each row as a question to answer before the assessor asks it. DeployOpen prepares systems, controls and evidence, but auditors and oversight bodies issue the findings.
| Evidence item | Produced by | What to confirm before assessment |
|---|---|---|
| Access control records with unique user identification | Passbolt user directory, with LDAP or SSO provisioning (Pro edition features) | Every named user maps to one account, and shared accounts are documented as exceptions with an owner |
| Activity logs and audit trails | Passbolt Pro syslog activity logs, forwarded to the agency log platform | Logs leave the vault server, retention matches the agency schedule, and someone reviews them on a set cadence |
| Sign-in and MFA records | SSO identity provider logs (for example Keycloak or the agency's directory) and Passbolt MFA policy settings | The MFA policy is enforced for all vault users, and exceptions are approved and recorded |
| Encryption configuration | Passbolt OpenPGP key records, HTTPS configuration on the reverse proxy, and database encryption settings | Transport encryption uses approved cryptography for the applicable baseline, and key ownership and recovery steps are written down |
| Export policy settings | Passbolt administrator export policy, which disables cleartext CSV by default since version 5.10 | CSV export is off unless an approved exception exists, and export events appear in the activity log |
| Backup and restore test records | Database and server backup job logs, plus signed restore test reports | Restore tests run on a stated schedule, and the restored vault is checked for user access and encrypted resources |
| Vulnerability scan results | Vulnerability scanner on the host and container images, such as Greenbone or Trivy | Scan frequency meets the cadence in the applicable baseline, and findings have owners and remediation dates |
| Offboarding records | SSO deprovisioning logs, Passbolt user deactivation events and resource ownership transfers | Leavers lose access within the agency's stated window, and shared credentials are rotated after departure |
What agencies ask before running a self-hosted vault
Is the Passbolt Community Edition enough for an agency?
The Community Edition can be enough for a small team that does not need directory integration or formal audit trails, but most agencies will need features that sit in the Pro tier. According to Passbolt's pricing comparison, LDAP user and group provisioning, account recovery, SSO with Microsoft, Google, OpenID and AD FS, MFA policies, syslog activity logs, password policies, password expiry and SCIM are listed as Pro features and not in the Community Edition. Map each requirement from your security policy and your identity provider against that list before deciding. Confirm the current feature split on Passbolt pricing because editions change.
What does Passbolt Pro cost per user per month, and what is the minimum?
Passbolt's pricing page lists Pro at $4.9 per user per month, billed annually, with a 10-user minimum and volume discounts after 100 users. Those are list figures from the vendor, so treat them as a starting point for budgeting and not as a quote. Ask the vendor or partner whether taxes, government procurement terms, support tiers and any hosting charges apply. Your total cost also includes the server, backups, the staff time to operate the vault and any implementation work, none of which appear in the per-seat figure.
Must the password manager be FedRAMP authorized?
It depends on whether the vault is a cloud service provided to your agency. FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency, and systems used only for a single agency's operations on cloud infrastructure, not offered as a shared service, are out of scope. A vault you run on your own government infrastructure is therefore a different case from a SaaS vault. Confirm the classification with your authorizing official and your FedRAMP program office, and document the reasoning in your system security plan.
How long does a rollout take, and what must the agency supply?
The duration depends on the number of users, the directory and SSO design, the import of existing credentials, and how many approval steps your change process requires. No duration is supplied here, so ask any partner for a written timeline tied to a fixed scope. Plan to supply a host or virtual machines on approved infrastructure, DNS names and TLS certificates from your internal certificate authority, access to the directory service, a named business owner for the vault, the security policy the vault must meet, and staff for user acceptance testing and training.
Can our own team operate the vault after go-live?
Often yes, if you have a team that already runs Linux servers, reverse proxies, databases and backups, and that can apply patches on a fixed schedule. Passbolt publishes installation paths for several Linux distributions, Docker, a Kubernetes Helm chart and Ansible, so the install can match your existing patterns. The ongoing work includes applying server updates, monitoring the service, testing restores, managing user lifecycle through the directory and handling support requests. Ask a partner to document the runbook and to agree in writing which parts they will support after handover.
What happens to vendor support if we use the open-source edition?
The Community Edition is free to self-host, but vendor support is a separate purchase and is not included in the software license. Passbolt's Enterprise tier is priced on request, so ask the vendor what support levels, response commitments and procurement vehicles are available for your jurisdiction. If you choose an implementation partner instead, the partner's support is governed by the written scope and any retainer you sign. Ask both parties who answers a production outage, who holds the database backups and who patches the server when a security fix ships.
Does the vault keep credentials away from the server operator?
Passbolt uses end-to-end encryption based on OpenPGP, so each user has a key pair and each user with access to a shared resource receives a copy encrypted with their public key. Encryption and decryption happen in the browser extension or mobile app, and the server stores ciphertext. Metadata such as names, URLs and descriptions is only encrypted in the v5 format and when the organization enables metadata encryption, so confirm that setting before you load production data. Also ask who controls the key recovery process, because a lost private key can block access to shared resources.
Questions to put to an implementation partner
Start with key custody and administrative control, because these decide who could read the vault contents. Ask the partner who generates and holds the OpenPGP key pairs in Passbolt, where any recovery material is kept, and which named roles can reset a user's key, change the server's administrator accounts or read the database. For Vaultwarden, ask who holds the master password recovery path and the admin backend token. Ask for the written role matrix before the build starts, and ask who in the agency can revoke those roles without the partner present.
Next, ask how the partner proves that no cleartext export path remains. Passbolt documentation states that since version 5.10, cleartext CSV exports are disabled by default unless an administrator re-enables them in the export policies, so ask for the export policy settings as delivered, a test showing that a non-admin user cannot produce a cleartext file, and the procedure for re-checking this after every upgrade. Also ask whether the partner has operated vaults inside government networks, which accreditation boundaries they have worked within, and which named engineers would staff the work. Request references that the agency can verify through its own channels.
Finally, clarify upgrades, support and data location. Ask how the partner tracks Passbolt and Vaultwarden releases, how a security fix is tested and applied within your change process, and whether the agency or the partner holds the open-source support contract for each edition. Confirm where encrypted backups, database dumps and audit logs are stored, who can restore them, and how long logs are kept. If CJIS Security Policy applies, ask how the partner meets encryption requirements for CJI at rest and in transit, including FIPS 140-3 validated modules, and how monthly vulnerability scanning is scheduled, reported and tied to remediation.
How DeployOpen scopes and supports a public sector vault
A public sector vault touches procurement, security operations and records rules at once, so the work is split into clear pieces with written boundaries. The cards below show how DeployOpen scopes the work, where the agency keeps control, and which parts carry on after go-live.
Fixed-scope written agreement
Most engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts. For an agency, the scope should name the Passbolt edition, the hosting environment, the directory sources, the users in each group and the evidence the agency expects at handover. Ask for the scope document to list what is excluded, such as end-user training or changes to the agency's directory.
Build inside the agency's infrastructure
DeployOpen plans, implements and hardens the vault on the agency's own servers, cloud accounts or networks, so ciphertext and hosting stay under agency control. Confirm which party holds the administrator accounts, the database credentials and the server operating system access at go-live. Passbolt's hosting guide lists supported Linux distributions, Docker, a Kubernetes Helm chart and Ansible, so the choice of deployment method should be recorded in the scope.
Directory and SSO integration
Integration work covers LDAP or Active Directory provisioning, single sign-on and multi-factor policies, which Passbolt lists as Pro features. Agencies should confirm which directory is the source of truth, how groups map to vault access and how a departing employee's access is removed. DeployOpen tests these paths with the agency's own accounts before handover, and the test results are part of the evidence package.
Hardening, backup and restore
Hardening covers the reverse proxy, HTTPS, database settings, export policies and administrator access. Passbolt disables cleartext CSV export by default since version 5.10, and the agency should decide whether to keep that default. Backup and restore must be tested on the agency's own schedule, because a vault that cannot be restored is not a control. Confirm backup location, encryption and who may read it.
Documentation and compliance evidence
DeployOpen documents the architecture, configuration, operating procedures and the control mapping the agency needs for its own assessment. DeployOpen prepares systems, controls and evidence but does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so the agency should confirm early which assessor will review the evidence and in what format.
Ongoing support and testing retainers
After go-live, upgrades, support and continuous security testing are available as retainers, separate from the initial fixed-scope work. Public sector teams should ask how security patches are applied within their change process, who approves upgrades and how the vault's own security is tested over time. Ask for the retainer terms in writing, including response expectations and what is covered outside business hours.
