NIS2 tightens how essential and important entities in the EU must manage risk, access, and incidents. It does not simply ask for “better cybersecurity”; it explicitly mandates baseline measures such as access control, multi-factor authentication, cryptography, logging, and business continuity, with real penalties if they are ignored.
Read the full legal text here: https://eur-lex.europa.eu/eli/dir/2022/2555
Credential security sits at the centre of these requirements. If you cannot prove who accessed which secret, when they accessed it, and under what conditions it was used, demonstrating NIS2 compliance becomes guesswork.
This article explains what NIS2 demands around identities and credentials, how password managers support these expectations, and how Passbolt’s design strengthens an organisation’s NIS2 posture. It does not claim that Passbolt “solves” NIS2 on its own when no tool does. It provides evidence of how Passbolt offers concrete controls that NIS2 requires.
NIS2 Article 21 and 23 requires entities to implement a set of baseline security measures as part of risk management. For credential security, the most relevant parts include:
Organisations must control which users or systems can access which assets, and define the basis on which access is granted.
Strong, layered authentication is expected for both users and systems. Passwords alone are not sufficient.
Entities need documented policies and procedures explaining how cryptography is used and governed instead of a claim that “encryption is used.”
Significant incidents must be reported within strict timelines: a warning within 24 hours, an incident notification within 72 hours, and a final report within one month, all backed by traceable evidence.
Core services, including access to credentials, must remain available or be quickly recoverable during incidents.
NIS2 does not prescribe a specific password manager or identity provider. However, if you rely on informal spreadsheets, shared browsers, or messaging tools for secrets, meeting these requirements in a defensible way becomes extremely difficult.
A password or credential manager, when properly implemented and governed, supports several NIS2 expectations:
Credentials are no longer scattered across devices and chats. Access can be granted, reviewed, and revoked centrally, aligned with documented responsibilities.
Users only see the secrets they actually need. Permissions map to organisational roles, not personal trust or memory.
The credential manager enforces strong, unique passwords, and can provide multi-factor authentication for access to sensitive credentials.
Modern managers use strong encryption, secure development practices, and undergo independent audits, supporting NIS2’s requirement for trustworthy suppliers.
Access events, changes, and sharing actions can be logged, making it easier to reconstruct what happened, who was involved, and what must be reported.
The above NIS2 requirements descriptions are generic. Different tools vary significantly in how they implement these guarantees, how transparent they are, and how much operational control they allow.
For organisations using Passbolt or assessing their credential management approach, NIS2 effectively validates the importance of structured, transparent, and verifiable access control. Many of the directive’s core security measures map directly to capabilities already built into Passbolt’s architecture, which means customers are already well positioned to demonstrate NIS2 compliance without reinventing their credential workflows.
Passbolt uses item-level access control. Each credential is an independent resource with its own permissions (Owner, Update, or Read), assignable to users, groups, or folders.
Each secret is encrypted once per user. Revoking access is not a mere UI toggle; it cryptographically removes a user’s ability to decrypt both current and future versions of the secret. This implements least privilege in a concrete, auditable manner.
Directory synchronisation and system roles for administrators, users, and group managers allow Passbolt to mirror organisational structure without manually managing every permission.
How does this help you with NIS2:
Passbolt uses a cryptographic challenge-response login process (GpgAuth and GpgJwtAuth). The client proves control of a private key. There is no traditional username/password form to steal or replay.
Passbolt also supports several MFA methods, including TOTP, YubiKey OTP, and Duo. Administrators can enforce MFA globally or by role, and control how long factors remain trusted on devices.
How does this help you with NIS2:
What you still need to define:
Passbolt applies true client-side end-to-end encryption. Secrets are encrypted in the browser, mobile app, or CLI before they leave the device. The server never sees plaintext.
Each secret is encrypted separately for each authorised user, and each user has their own key pair. The private key is not derived from the login passphrase, reducing several categories of attack.
Passbolt relies on well-established cryptographic primitives: RSA and elliptic curves for asymmetric encryption, AES-256 for symmetric encryption, and SHA-256 or SHA-512 for hashing. The platform uses GnuPG, OpenPGP.js, and GopenPGP which are long-standing libraries with extensive external scrutiny.
How does this help you with NIS2:
What you still need to define:
Passbolt logs user actions and administrative changes, including logins, secret access events, permission updates, sharing, and configuration changes. Logs can be exported or integrated with your SIEM for correlation with other systems. This provides the raw material NIS2 expects for incident handling.
How does this help you with NIS2:
What you still need to define:
Passbolt can be fully self-hosted and is entirely open source. You control where your data lives and how backups are handled. Secrets remain encrypted at rest and within backups.
Organisation Recovery Keys offer a controlled break-glass option. If a user loses access, administrators can help them recover their account without compromising encryption for other users.
How does this help you with NIS2:
The Passbolt server and clients (including Pro edition) are fully open source. Releases are signed. Vulnerability monitoring and regular security audits are in place. Docker images and the hardened appliance are built from repeatable processes. Passbolt uses CI, static analysis, regular external audits, and holds a SOC 2 Type II audited report.
For NIS2, this supports the requirement to assess suppliers forming part of critical infrastructure.
Passbolt provides:
This makes it easier to answer supply-chain trust questions and demonstrate software integrity.
Several tools can “store passwords.” The following Passbolt properties have a meaningful impact on NIS2 compliance:
Every user has their own key pair. Every secret is encrypted separately for each authorised user. Revoking access means cryptographically removing the ability to decrypt, not just toggling a UI flag.
Passbolt’s login flow is based on a cryptographic challenge-response, not a static password.Phished credentials cannot simply be replayed.
You can inspect cryptography and access control code, verify what is deployed, and cross-check public audits and release signatures.
Run Passbolt on-prem, in your cloud, or air-gapped. You choose which external services (e.g., for MFA) you rely on, maintaining jurisdictional control and compliance with local requirements.
These features do not create compliance on their own but make it easier to design workflows that match NIS2 expectations and to prove they work in practice.
NIS2 requires organisations to treat credential management as a documented operational control with evidence to support it. A password manager is only one part of that picture: policies, logging pipelines, and incident workflows matter just as much.
Passbolt offers per-user and per-item encryption, a phishing-resistant login flow with MFA, open-source and signed releases, and deployment options that keep data and jurisdictional control in your hands. These properties help security and IT teams meet NIS2 expectations in a practical, defensible way.
The remaining work lies in process: writing policies, integrating logs, reviewing permissions, and rehearsing failure scenarios. With those pieces in place, Passbolt becomes a strong foundation for demonstrating compliance when NIS2 obligations apply.
Defines who gets access to what and why.
Lists accepted algorithms, key sizes, rotation rules, and how Passbolt fits in. Docs:
Mirror teams, environments, and applications using groups/folders.
Review Owner/Update/Read permissions quarterly.
Remove unused accounts promptly.
Enable MFA for all users. Docs:
Define required methods per role:
Plan for lost factors/outages.
Export logs
Define alerts for suspicious behaviour.
Regularly restore backups in a test environment.
Test account recovery paths.
Apply TLS, OS, and firewall guidance.
Use non-root Docker images or hardened appliances.
Keep Passbolt updated.
Record that Passbolt is open source and releases are signed.
Monitor advisories
4 min. read
Bitnami’s deprecation of free container images impacts the Passbolt Helm chart. This update covers new open-source alternatives, the migration plan, and user next steps.
13 min. read
A practical guide to running passbolt with MariaDB Galera Cluster and mTLS, ensuring authenticated replication, flexible topology, and no-lag failover.
Made in Europe. Privacy by default.