You’re the Admin Now: A Security Check-Up

September. You’re back from holiday, the coffee machine is vibing, your inbox is not, and you’ve just learned that you are now responsible for your organisation's passbolt instance.

Maybe the previous administrator left. Maybe there was a reorg, followed by another reorg to clarify the first reorg. Either way, congratulations: it’s yours now. The good news is that it works. People can sign in, passwords are being shared, and nothing is obviously on fire.

But you didn’t configure it, and while “nobody has complained yet” is a free and scalable monitoring strategy, you know better than to make it yours.

So, in the spirit of back-to-school season, it’s time to do our homework.

Who this is for

This September check-up is for Sysadmins and DevOps engineers who run a passbolt instance, security engineers doing periodic reviews, or compliance officers who need a dated record that somebody looked at. 

Before the checklist - Why is this necessary? 

Passbolt is running and happily serving encrypted credentials. But encryption doesn’t make the rest of the stack magically take care of itself. Passbolt is doing its part, but the other half of the security checklist is yours.

A secure Passbolt instance still depends on everything around it: the host, database, network, identity provider, backups, healthy clients, and the configuration choices we made along the way.

Which brings us to the checklist. 

1. Check the infrastructure: is the house in order?

Before digging into Passbolt itself, start with what it is sitting on.

First, figure out how Passbolt is actually installed. Is it running from a package, Docker, Kubernetes, a VM under someone's desk, a Samsung connected fridge? Where is the configuration? Where is the database? What sits in front of it? Before checking whether the setup is healthy, you need a rough map of what the setup actually is.

You also probably inherited a few firewall rules, and some configuration files with stock comments or written by people you may never meet.

Once you know what you're looking at, start with the easy one:

Run the Passbolt healthcheck. Depending on your installation method, that will look something like:

./bin/cake passbolt healthcheck

Then work your way down the stack.

Transport

Start from the outside and work your way in.

• Open the instance over plain HTTP and confirm you are immediately redirected to HTTPS. There shouldn't be a usable HTTP version of Passbolt sitting alongside the secure one.
• Check what TLS your server actually negotiates. Prefer TLS 1.3 and keep TLS 1.2 only where you still need compatibility.
• Look at the certificate, including its expiry date and issuer, and confirm that automatic renewal is working rather than just configured. A 90-day lifespan is recommended; don't exceed 366 days.
• Check HSTS and the other security headers are actually present in responses. This is particularly worth doing after reverse proxy, ingress or load-balancer changes.

Host

Next, look at the machine or container environment actually running Passbolt.

• Check the operating system version and make sure it is still supported and receiving security updates.
• Apply outstanding security patches and understand how regularly they are normally applied. 
• Stay on top of security updates. Subscribe to security advisories and CVE notifications for the operating system and the other components in your stack, so you're not relying on someone remembering to check periodically.
• Review the host against at least CIS Level 1. You don't need to rediscover Linux hardening from scratch.
• List listening services and ports. If you don't know why something is running, find out before deciding it needs to stay.
• Review filesystem permissions, particularly around Passbolt configuration, keys, logs and other sensitive material.
• Check NTP is running and the clock is accurate. Clock drift can break TOTP and make audit timestamps considerably less useful.
• Check system logging is actually working. Authentication events, privilege escalation and important system errors should be recorded — and ideally shipped somewhere other than the server itself.

Network and reverse proxy

Now work out how the instance talks to the rest of the world.

• Review the firewall rules rather than assuming they still match the original architecture. Inbound access should normally be limited to HTTPS on 443, with SSH or other management interfaces restricted to trusted administration networks.
• Look at outbound access too. Depending on your setup, Passbolt may need SMTP, LDAP, your IdP, the Yubico API or other explicitly configured integrations. If the server can otherwise reach the entire Internet, consider whether it needs to.
• If you're behind a reverse proxy, check that X-Forwarded-For and X-Forwarded-Proto are forwarded correctly so Passbolt sees the original client and protocol.
• Review the proxy configuration for sensible rate limits, request-size limits and timeouts.

This is also a good moment to draw a very small network diagram if one doesn't exist. It doesn't need to impress anyone: Passbolt, database, proxy, external dependencies and trust boundaries are enough.

Database

Finally, check the place where the instance keeps its data.

• Identify which database Passbolt is actually using, where it runs and whether it is dedicated or shared with other applications.
• Check the Passbolt database user. It should have only the permissions Passbolt requires, with no root or superuser access.
• Check network exposure. If the database only needs to talk to Passbolt, it shouldn't be reachable by half the network.
• Confirm encryption at rest is enabled at the database, volume or storage layer.
• Review database audit logging and where those logs end up.
• Find the database credentials. Know where they're stored, who can access them and how you would rotate them without discovering the procedure in production.

Want to go a little further?

Once the basics are in order, you can start asking a different question: if someone compromised this server, how quickly would you notice?

• Add host or workload intrusion detection. Tools such as Falco can help surface unexpected processes, filesystem activity and suspicious runtime behaviour, particularly in containerised environments.
• Consider a WAF like CrowdSec at the host or reverse-proxy layer to detect abusive behaviour from logs and automatically block known or repeated malicious sources.
• Monitor outbound traffic. A Passbolt server generally has a fairly predictable set of dependencies. A new connection to an unexpected destination should therefore be interesting.
• Monitor DNS activity for the same reason. Unexpected lookups from a server that normally talks to a handful of known services can be a useful signal.
• Centralise logs from the host, reverse proxy, firewall and database so an investigation doesn't require SSHing into four machines and hoping the logs are still there.
• Create a few useful alerts rather than hundreds of noisy ones: unexpected outbound connections, repeated authentication failures, privileged account changes, suspicious processes and security-control failures are good places to start.
• Segment the network. The Passbolt application, database and management interfaces should only be able to communicate with the systems they actually need.
• Test the detection path. Trigger something harmless that should generate an alert and check that it reaches a person or system that will actually act on it.

At this point you should have a reasonable answer to the first question: is the environment underneath Passbolt one you are comfortable putting your name on?

2. Check the backups: can you actually get it back?

Now for the question you don't want to answer for the first time during an incident: if this instance disappeared tomorrow, could you recover it?

Passbolt keeps an audit log, but it doesn't provide an undo button when Claude confidently deletes everything in production.

There are three things you need to make sure you can recover.

Database

Check that:

• Database backups are actually running, at a frequency matching how much data you can afford to lose.
• Backups are stored away from the primary server.
• At least one copy is offline or in cold storage, where appropriate for your recovery strategy.
• Retention is intentional and matches your recovery and data-retention requirements.
• You have actually restored one this year, and timed it.

A successful backup job is evidence that you created a backup. But recovering the database is only part of the story.

Passbolt server key

Make sure you can also recover the Passbolt server OpenPGP key.

• Know where the server private key is stored and managed.
• Make sure both are included in your recovery plan and backed up securely.
• Make sure the recovery procedure is documented and has been tested.

Organisation recovery key

If your organisation uses Passbolt account recovery, find out where the organisation recovery key is kept.

It should be treated as break-glass material: stored securely and offline, accessible to the appropriate people, and rotated after use.

More importantly, make sure the procedure exists outside your head.

3. Check Passbolt itself: what did you actually inherit?

The infrastructure is healthy and you know how to recover it. Now comes the interesting part: why is Passbolt configured the way it is?

Not every security setting has one universally correct answer. Some depend on your organisation, your threat model and the trade-offs you've chosen.

The important thing is that they are your choices, not archaeological remains.

Start with the people

Look through the users and groups.

• Are all active users still supposed to be there?
• Do the groups still represent your organisation?
• Who owns important shared resources?
• Did recent departures actually get offboarded completely?

When someone with access to shared resources leaves, removing their permissions prevents future access, but you should also rotate the secrets and passwords they previously had access to. Password expiry can help manage this process by flagging credentials that need to be changed and making sure the rotation doesn't quietly get forgotten.

Review metadata encryption settings

Passbolt gives you choices around how resource metadata is encrypted. Metadata includes information such as resource names, usernames, URLs and descriptions.

Personal resource metadata can be encrypted with the user's own OpenPGP key, while shared metadata can use different modes depending on whether you want the server to have knowledge of the shared metadata key.

Review which mode you're running and make sure it matches your threat model.

Don't assume the setting you inherited represents a deliberate decision. Non-zero-knowledge mode is currently the default in v5, where the server has access to the metadata key to allow easier user onboarding. If your workplace turnover is low, this is probably not the best setting.

If you use shared metadata encryption, rotate the metadata key periodically to maintain forward secrecy, for example once a year, or more frequently if your organisation has higher staff turnover.

Review SSO and MFA

If you use SSO, part of your authentication security also relies on another system:

• Make sure your IdP verifies email addresses before mapping them to Passbolt users. If users shouldn’t be allowed to freely edit their email address without verification.
• Review session lifetimes at the IdP and make sure inactive sessions expire according to your policy.
• Check MFA is enforced according to your organisation's requirements.
• Make sure users have an appropriate fallback or recovery path.
• Make sure MFA and authentication events reach whatever you use to monitor security events.

4. Check the clients

Passbolt's security boundary doesn't stop at the server. In fact, once a secret is decrypted, the client is where the interesting stuff happens.

No password manager is going to win a fight against malware that can read your screen, clipboard, memory or keystrokes. So the security of the devices accessing Passbolt matters just as much as the server they connect to.

• Keep operating systems and browsers patched, and make sure the Passbolt browser extension is auto-updating across your fleet.
• Use MDM or another endpoint management solution where possible to enforce your security baseline rather than relying on every laptop being configured correctly by hand.
• Use endpoint protection such as antivirus or EDR, keep it current and make sure alerts actually go somewhere and get reviewed.
• Enable the host firewall and restrict unnecessary inbound services.
• Encrypt local storage with technologies such as FileVault, BitLocker or equivalent, particularly on laptops.
• Control browser extensions. Use an approved extension policy where possible and remove extensions users don't need. An extension running alongside your password manager is part of the threat model too.
• Lock devices automatically and require strong authentication to unlock them.
• Avoid unnecessary local administrator privileges, particularly for everyday user accounts.

And don't forget the human sitting in front of the client.

Remind users that a strong passphrase isn't just about satisfying an entropy meter. Something can look mathematically complicated and still be very easy to guess if it is based on information everyone in the office knows.

Also make sure users understand the Passbolt security token. It appears when Passbolt asks for their passphrase so they can distinguish the genuine prompt from a convincing fake. It is only useful as an anti-phishing mechanism if users actually know what it is and notice when it is missing.

Homework done

That's it. You now know how Passbolt is installed, what is exposed to the network, where the database lives, whether you can recover it, why the important settings are configured the way they are, and whether the laptops decrypting all those passwords are reasonably trustworthy.

Which is considerably more than you knew when you came back from holiday.

You probably also found a few things to fix, three things to document, one firewall rule nobody remembers creating, and at least one configuration choice you kept explained by “historical reasons.” That's fine. You don't need to fix everything before lunch.

Document what you learned, create the tickets, and schedule the checks worth repeating.

Then find a promising colleague who could use some hands-on security experience and casually mention that taking ownership of one or two of those tickets would be a great learning opportunity.

Congratulations. You've gone from inheriting Passbolt to delegating Passbolt. That’s management. Or mentoring. Depends who’s asking.