Notifications
Clear all
Topic starter
08/07/2026 6:59 pm
TL;DR: NIS2 makes credential handling a compliance issue, requiring access control, multi-factor authentication, logging, cryptography, and continuity evidence, according to Passbolt’s analysis. The practical shift is that teams must prove who accessed which secret, when, and under what conditions, or compliance becomes guesswork.
NHIMG editorial — based on content published by Passbolt: NIS2 Requirements: Why Credential Security is Non-Optional
Questions worth separating out
Q: How should organisations prove credential security for NIS2 audits?
A: They should be able to show who had access to each secret, how that access was granted, what authentication protected it, and which logs record use or sharing.
Q: Why do shared spreadsheets and chat tools fail NIS2 credential expectations?
A: They usually cannot prove ownership, access scope, revocation, or traceability well enough for supervisory scrutiny.
Q: What do security teams get wrong about MFA for secret access?
A: They treat MFA as a login checkbox instead of part of the evidence chain.
Practitioner guidance
- Define credential ownership and access scope Assign every secret, key, and shared credential to a named business owner and a reviewable role so you can explain entitlement decisions during audit or incident review.
- Enforce strong authentication for secret access Require phishing-resistant MFA for administrators and any user who can view, share, or recover credentials, and document exceptions with expiry and compensating controls.
- Centralise logging for secret activity Send credential access, sharing, permission change, and recovery events into your SIEM so you can correlate them with incident timelines and reporting obligations.
What's in the full article
Passbolt's full article covers the operational detail this post intentionally leaves for the source:
- Item-level permission modelling for individual credentials and folders.
- Specific MFA options and enforcement settings for credential access.
- Client-side encryption design details and the cryptographic primitives in use.
- Logging, export, and recovery workflows that support NIS2 evidence gathering.
👉 Read Passbolt's analysis of NIS2 credential security requirements →
NIS2 credential security: what IAM teams need to prove now?
Explore further
08/07/2026 7:21 pm
NIS2 turns credential security into a verifiable governance problem, not a tooling preference. The directive is less concerned with which product holds the secret than with whether access, authentication, logging, and continuity can be proved. That shifts the burden from operational convenience to evidentiary control. Organisations that cannot reconstruct access to credentials will struggle to demonstrate compliance when incidents or audits occur.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which is why credential governance must be treated as an ongoing control problem rather than a one-time configuration.
A question worth separating out:
Q: Who is accountable when credential access causes a NIS2 incident?
A: Accountability sits with the organisation that owns the credential lifecycle, including access policy, monitoring, revocation, and recovery. If the process spans IAM, PAM, and NHI teams, responsibility must still be explicit so incident reporting and remediation do not stall in handoffs.
👉 Read our full editorial: NIS2 credential security turns access evidence into a compliance control
