Passbolt self-hosted security check-up for inherited admin access

At a glance

What this is: This is a security check-up for teams inheriting a Passbolt instance, with the key finding that a secure deployment still depends on the host, network, identity provider, backups, and clients around it.

Why it matters: It matters because password and secret management platforms become identity infrastructure, so IAM, PAM, and NHI practitioners need to verify recovery, access boundaries, and client trust rather than assuming the vault itself is sufficient.

By the numbers:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read PassBolt's security check-up for inherited Passbolt admin access

Context

A Passbolt instance can be operational and still be poorly governed if the surrounding infrastructure, identity controls, and recovery paths are unknown. For teams inheriting a secrets platform, the first problem is not the vault itself but whether the host, database, reverse proxy, identity provider, and endpoints around it are actually under control.

That matters for NHI governance because the platform stores and mediates access to credentials that often act as the real identity layer for services, administrators, and shared accounts. Once those secrets are exposed to weak host controls, incomplete offboarding, or unmanaged clients, the password manager becomes part of the attack surface rather than a control layer.

The article is therefore a practical reminder that inherited access is not the same thing as inherited assurance. A running system tells you very little about blast radius, revocation readiness, or whether the organisation can recover cleanly after compromise.

Key questions

Q: What breaks when a secrets manager is inherited without a full security review?

A: Inherited administration often leaves gaps in host hardening, backup recovery, user offboarding, and client trust. The result is a system that may appear functional but still exposes credentials, recovery material, or management paths to compromise. Teams should assume the control history is incomplete until they verify it.

Q: Why do backups alone not guarantee recoverability for a credential vault?

A: Because the database is only one part of restoration. A secrets platform also depends on the server key, recovery keys, documented procedures, and a tested restore path. If any of those pieces are missing, the organisation may be unable to recover access even when backups exist.

Q: How should organisations handle offboarding in a shared password vault?

A: Remove the user, then rotate the shared credentials and confirm no dependent groups or resources still rely on the departed account. Permission removal stops future access, but rotation removes the value of credentials already seen by the former user.

Q: How do you know whether endpoint controls are strong enough for a secrets manager?

A: Look for patched devices, controlled browser extensions, enforced disk encryption, endpoint protection, and limited local administrator rights on every machine that can decrypt secrets. If any one of those controls is missing, the endpoint remains a likely path to credential exposure.

Technical breakdown

Host, proxy, and database controls define the real trust boundary

Passbolt does not operate in isolation. The effective security boundary includes the operating system, TLS termination, reverse proxy headers, firewall rules, database permissions, logging, and the paths used to store configuration and keys. If any of those layers are overexposed or weakly segmented, an attacker can move from the application into the data plane or use the host as a pivot point. The checklist’s value is that it forces administrators to map what is actually running, where credentials live, and which services can reach the database or management interfaces.

Practical implication: verify host hardening, network segmentation, and least-privilege database access before treating the vault as trustworthy.

Backups only matter if the server key and recovery path are restorable

A backup strategy for a secrets platform is more than database copies. Passbolt also depends on recovery of the server OpenPGP key and, where used, the organisation recovery key. If those elements are not backed up, tested, and documented together, the environment may be technically up but practically unrecoverable. This is a lifecycle problem as much as an availability problem because the restore procedure has to survive staff turnover, changed infrastructure, and incident conditions.

Practical implication: test full restoration, including keys and break-glass material, rather than relying on successful backup jobs alone.

Client trust and browser hygiene are part of the secrets security model

The article correctly treats the endpoint as part of the security boundary. Once a secret is decrypted, a compromised laptop, malicious browser extension, or unmanaged endpoint can capture it regardless of how strong the server-side encryption is. That means the platform’s security posture depends on patching, endpoint protection, browser extension control, disk encryption, and user awareness of phishing cues such as the security token prompt. In practice, the client becomes the last mile of secrets governance.

Practical implication: align endpoint management, extension policy, and user training with the vault rather than leaving them outside the control model.

Threat narrative

Attacker objective: The objective is to turn a secrets platform into a trusted access source for broader compromise, persistence, or privileged impersonation.

1. Entry begins when an attacker gains foothold through a weakly governed host, misconfigured proxy, or compromised client rather than through the vault encryption itself.
2. Escalation occurs if the attacker reaches exposed configuration files, database credentials, recovery keys, or unsegmented management interfaces that were never treated as sensitive assets.
3. Impact follows when secrets, shared resources, or recovery material can be extracted, altered, or used to impersonate privileged users across dependent systems.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Inherited secrets platforms create an assurance gap, not just an administration gap. The article is really about what happens when a team takes over a credential store without taking over its control history. A running Passbolt instance can still conceal unknown firewall rules, stale users, weak recovery design, and endpoint trust problems. Practitioners should treat inherited admin access as a prompt to rebuild assurance from the bottom up.

Secrets recovery is a lifecycle problem, not a backup checkbox. Database files alone do not restore a secrets platform if the server key, recovery key, and documented procedure are missing or untested. That is the same governance pattern NHIMG sees across NHI programmes: the system is treated as recoverable until a real event proves otherwise. The implication is that restore readiness must be governed as a credential lifecycle process, not an infrastructure afterthought.

Client trust is where password managers stop being abstract and become identity infrastructure. A password manager that serves decrypted secrets to unmanaged endpoints is part of the identity plane, not merely a storage tool. That means browser extensions, local admin rights, disk encryption, and endpoint detection become part of secrets governance. Teams that separate these controls are describing the environment incorrectly.

Offboarding must include secret rotation, not only permission removal. The article’s user and group review section correctly notes that removing a departed user is insufficient if they have already seen shared credentials. In NHI terms, access revocation without secret rotation leaves standing credential value behind. That failure mode is well understood in OWASP-NHI and remains one of the easiest ways for shared access to outlive accountability.

Identity blast radius is determined by how much trust the vault inherits from surrounding systems. Passbolt is only as contained as its host, proxy, IdP, network path, and client estate. If those layers are broadly trusted, the secrets manager becomes a concentration point for compromise rather than a control point. Practitioners should use this as a reminder that secrets governance is only as strong as the weakest adjacent identity control.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why inherited secrets platforms need governance across users, keys, and endpoints.
• A useful forward step is the Ultimate Guide to NHIs , Standards, which maps these controls to OWASP, NIST, and Zero Trust expectations.

What this signals

Inherited admin access is a governance problem before it is a technical one. Teams that take over a secrets platform should first establish what they can prove, not what they hope is true. When access history, recovery paths, and endpoint assumptions are unclear, the control model needs to be re-baselined rather than merely patched.

The practical signal for IAM and PAM programmes is that shared-secret platforms now sit inside the identity fabric, not beside it. That means offboarding, rotation, endpoint controls, and recoverability should be assessed together, especially where a vault is the hidden source of privilege across multiple systems.

For organisations aligning to NIST Cybersecurity Framework 2.0 and the NIST SP 800-53 Rev 5 Security and Privacy Controls, the lesson is clear: protect the application, but govern the trust boundary around it. Identity blast radius: the real exposure is the set of systems that can read, reuse, or restore the secrets if one control fails.

For practitioners

• Map the inherited trust boundary Document where Passbolt runs, where the database lives, which reverse proxy or load balancer sits in front of it, and which systems can reach management and database ports. Treat the host, proxy, database, and IdP as one control surface.
• Validate restore readiness end to end Restore the database, recover the server OpenPGP key, and confirm the organisation recovery key procedure works outside production. If any step exists only in someone’s memory, the recovery plan is incomplete.
• Review users and rotate shared secrets after offboarding Check active users, group ownership, and recent departures, then rotate any shared secrets those users could access before access removal. If a former user can still authenticate through a reused credential, the offboarding process has failed.
• Harden the client estate that decrypts the secrets Require patched browsers, managed extensions, endpoint protection, disk encryption, and restricted local administrator rights on devices that access Passbolt. The security of the vault is undermined if the endpoint can read the decrypted secret.

Key takeaways

• A secrets manager is only as trustworthy as the host, database, proxy, identity provider, backups, and endpoints around it.
• Recoverability depends on restoring the database, server key, and break-glass procedure together, not on backup success alone.
• Offboarding and endpoint hygiene remain identity controls, because shared credentials and decrypted secrets can outlive the user account.

Key terms

• Secret Manager: A secret manager is a control that stores and sometimes rotates credentials such as tokens, keys, and certificates. It reduces exposure of sensitive material, but it does not by itself establish ownership, entitlement context, or revocation accountability, which means governance can still fail even when storage is secure.
• Break-Glass Recovery Key: A break-glass recovery key is an emergency credential or key material kept offline for exceptional restoration or account recovery. It is only useful if the organisation can locate it, protect it, and test the procedure for using it without improvisation during an incident.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Envelope Encryption: A two-layer encryption pattern that uses a short-lived data encryption key to protect the data and a longer-lived key encryption key to wrap that data key. It scales rotation, supports tenant separation, and keeps the primary key material out of direct data handling.

What's in the full article

PassBolt's full article covers the operational detail this post intentionally leaves for the source:

• Exact healthcheck commands and stack-specific checks for package, Docker, Kubernetes, and VM deployments.
• Step-by-step backup and restore considerations for the database, server OpenPGP key, and organisation recovery key.
• Detailed review points for metadata encryption modes, SSO fallback paths, and MFA event handling.
• Practical endpoint checks for browser extensions, local admin rights, and device encryption.

👉 PassBolt's full article covers infrastructure, backup, client, and identity review steps in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.