HashiCorp Vault NIS2 Compliance: PKI and Transit Secrets Engines Mapped to CIR Annex 9 Cryptography

Search “HashiCorp Vault NIS2” and most of what comes back is vendor content asserting Vault “meets” NIS2 encryption requirements — almost none of it names the actual regulation sub-point, and at least one mapping we reviewed cites a “CIR Annex 9.4 certificate management” clause that does not exist in the text. Article 21(2)(h) of the NIS2 Directive requires “policies and procedures regarding the use of cryptography and, where appropriate, encryption” — the operational detail sits four levels down, in Commission Implementing Regulation (EU) 2024/2690, Annex Section 9. This guide maps Vault’s two relevant secrets engines — Transit and PKI — to the specific sub-points they actually support, for the compliance officer building the audit file and the security architect defending the configuration behind it. See the full breakdown of all ten Article 21(2) measures for how cryptography fits the wider obligation.

What CIR Annex Section 9 Actually Requires — Not What Most Vendor Pages Claim

Article 21(2)(h) of the NIS2 Directive is one sentence: entities must implement “policies and procedures regarding the use of cryptography and, where appropriate, encryption.”[1] The detail sits in Commission Implementing Regulation (EU) 2024/2690, Annex Section 9 — and it has exactly four numbered points, not the five or six that some vendor comparison pages imply. Getting this number wrong matters, because it’s the citation an auditor checks first.

CIR point	What it requires
9.1	A documented policy and procedures for cryptography use — the policy itself is the deliverable, not just the encryption.
9.2(a)	Cryptographic measure type, strength, and quality tied to asset classification and risk assessment.
9.2(b)	Approved protocols, algorithms, and cipher strength, following a “cryptographic agility” approach — the ability to swap algorithms without re-architecting.
9.2(c)	Key management: generation, issuance, distribution, storage, changing, compromise handling, revocation, recovery, backup, destruction, logging, and activation/deactivation dates.[2]
9.3	Periodic review of the policy against the state of the art in cryptography.

Two things follow from that table. First, 9.2(c) is the longest, most operationally demanding point in the entire section — and it’s a key-lifecycle requirement, not a certificate-specific one. Second, nothing in Section 9 references certificates by name; PKI certificates qualify under 9.2(c) because a certificate is a form of managed key material with its own generation, revocation, and destruction lifecycle. Any mapping that cites a standalone “certificate management” sub-point is citing a provision CIR 2024/2690 does not contain.

Where HashiCorp Vault Fits — Two Engines, Two Different Obligations

HashiCorp Vault is not a single “encryption feature” — it’s a platform with separate secrets engines, and only two map directly onto Section 9. Transit handles the encryption-as-a-service obligation in 9.1/9.2(a)/(b). PKI handles the certificate-lifecycle slice of 9.2(c). Conflating the two — treating Vault as one undifferentiated “crypto box” — is the most common documentation error we see in gap assessments, because it leaves an auditor unable to tell which engine’s configuration evidences which sub-point.

For a CISO or security architect, this distinction determines which Vault policies and audit logs you pull for evidence. For a compliance officer building the Article 21 file, it determines which product template maps to which technical control — Doc 27 (Encryption & Cryptographic Controls) covers the 9.1 policy layer; the 9.2(c) key-lifecycle evidence has to come from Vault’s own configuration and audit logs, because no document can substitute for that. Vault’s identity-based access policies are a separate obligation entirely — see our access control guide for the CIR Section 11 mapping — and shouldn’t be conflated with the cryptography file covered here.

Vault Transit: Encryption-as-a-Service Mapped to 9.1 and 9.2(a)/(b)

Transit encrypts and decrypts data on request without ever storing it — applications send plaintext, get ciphertext back, and Vault discards the input.[3] That single design choice is what makes it useful as 9.2(a)/(b) evidence: because the application never holds the encryption key, “key strength and algorithm selection” becomes a Vault-operator decision enforced centrally, not a per-application setting an auditor has to inspect fifty times across fifty codebases.

Three Transit mechanics map onto specific sub-points. Key versioning — Transit keeps a keyring where rotated keys retain a min_decryption_version, so old ciphertext stays readable while new writes use the current key — is the automated half of 9.2(c)’s “changing” requirement.[3] Key derivation lets one master key generate context-specific sub-keys, which is the practical answer to 9.2(b)’s “cryptographic agility” language: you can isolate blast radius per application without provisioning a new root key each time. Convergent encryption — same plaintext always produces the same ciphertext — is a deliberate trade-off for database lookups on encrypted fields; it weakens semantic security and should be scoped to low-sensitivity, high-cardinality data only, never to anything classified above “internal” under your 9.2(a) asset-classification scheme.

Vault PKI: Certificate Lifecycle as 9.2(c) Key Management

The PKI secrets engine issues short-lived X.509 certificates on demand, acting as a root or intermediate CA.[4] The mechanism that matters for 9.2(c) is TTL discipline: HashiCorp’s own documentation states that keeping certificate TTLs short reduces how often revocation is actually needed, which keeps certificate revocation lists small enough to stay useful at scale.[4] That’s a direct, provable answer to the “revocation” and “activation/deactivation dates” language in 9.2(c) — a certificate that expires in 24 hours has already solved most of the problem a manually-issued 12-month certificate creates.

This is also where the reader segmentation matters most. A security architect reads “short-lived certificates” as an operational win — less manual rotation, smaller CRLs. A compliance officer needs to read it as evidence: your audit file should state the configured TTL per role, the CA hierarchy (root vs. intermediate), and whether ACME, EST, CMPv2, or SCEP automation issues the certificates, because “we use Vault” is not, by itself, an auditable control statement. Vault also supports unified CRL and OCSP responses across clusters, which matters if your entity operates in more than one member state and a supervisory authority asks how certificate status is checked in real time.

The Gap Vault Doesn’t Close: Documentation, Not Deployment

Deploying Vault and being able to demonstrate 9.1 compliance are two different projects, and treating them as one is the most expensive mistake in this whole exercise. 9.1 requires a policy — a document stating which data classifications require encryption, which algorithms are approved, and how key management decisions get made — not just a running instance. An auditor who finds Vault in your infrastructure but no cryptography policy document has found a partial control, not a compliant one. Our cryptography and encryption guide covers the full six-stage key lifecycle documentation expectation in detail if you’re starting the 9.1 policy from scratch.

Current state	Required state (9.1–9.3)	Effort to close
Vault Transit encrypting app data, no written policy	Documented policy naming approved algorithms and data classifications	Low — one document, references existing config
Vault PKI issuing certs, TTLs set ad hoc per team	Documented TTL-per-role standard tied to asset classification	Medium — requires a cross-team decision, not just writing
No scheduled crypto policy review	9.3 periodic review against state of the art, logged with dates and outcomes	Low — a calendar process, once the policy exists
Vault deployed without FIPS mode	FIPS-validated build where the entity’s risk assessment calls for it	Medium–High — Enterprise licensing and a build/config change

FIPS Validation and the Article 21(1) “State of the Art” Test

Article 21(1) requires measures appropriate to the entity’s risk, size, and the state of the art — not a fixed checklist.[1] Vault Enterprise 1.19.4 and later supports FIPS 140-3 Level 1 mode by using BoringCrypto, a cryptographic library independently validated under NIST CMVP Certificate #4735; earlier versions rely on a FIPS 140-2 evaluation of the same library by Leidos.[5] That’s an important distinction to get right in an audit file: it’s the underlying cryptographic module that holds the certificate, and Vault Enterprise supports and uses it — not a separate, standalone certification of the Vault product itself. That evaluation status is a genuinely useful state-of-the-art signal for 9.2(b) algorithm selection, but it does not by itself satisfy Article 21 — proportionality still governs, and a small essential entity with a modest risk profile may reasonably run community Vault without FIPS mode and document why that’s an appropriate, risk-based choice, exactly as Article 21(1)’s proportionality clause anticipates.[1]

Germany’s BSI — the country’s NIS2 national competent authority — publishes its own longer-term cryptographic guidance in Technical Guideline TR-02102, aimed at exactly this kind of algorithm-selection decision.[6] Whichever member state’s competent authority you report to, the pattern holds: don’t cite a vendor’s FIPS badge as your compliance evidence — cite it as one input to the documented, risk-based algorithm decision that 9.2(a)/(b) actually requires.

Implementation Checklist

Step	Owner	Effort
Classify data by sensitivity, map each class to a required cryptographic measure (9.2(a))	Security architect + data owner	Medium
Configure Transit keys per classification tier; document algorithm choice and rotation interval	Security architect	Low
Set PKI role TTLs per certificate use case; document root vs. intermediate CA hierarchy	Security architect	Medium
Write the 9.1 cryptography policy, referencing the actual Vault configuration above	Compliance officer	Low
Schedule the 9.3 periodic review (annually at minimum, or on any algorithm-deprecation event)	Compliance officer	Low
Decide on FIPS mode based on documented risk assessment, not by default	CISO / board sign-off	High

For the other nine Article 21(2) measures Vault doesn’t touch, run this checklist alongside our full NIS2 compliance checklist.

Frequently Asked Questions

Does using HashiCorp Vault make my organisation NIS2 compliant?
No single tool satisfies Article 21 on its own. Vault can provide strong technical evidence for the 9.2(a)/(b)/(c) requirements, but 9.1 still requires a written policy, and NIS2 compliance spans nine other Article 21(2) measures Vault has nothing to do with.

Which Vault engine matters most for an auditor: Transit or PKI?
It depends on what you’re protecting. If your risk assessment flags data-at-rest or data-in-transit exposure as the priority, Transit evidence matters most. If certificate sprawl or long-lived, unrotated certificates are your documented risk, PKI evidence is the one to prepare first.

Is Vault Community edition enough, or do we need Enterprise for FIPS?
FIPS 140-3 mode, built on the NIST-validated BoringCrypto library, is a Vault Enterprise feature.[5] Community edition can still support a documented, risk-based cryptography policy — FIPS validation is one specific, higher-assurance input, not a universal NIS2 requirement.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. NIS2 Directive (EU) 2022/2555, Article 21 — nis-2-directive.com mirror
2. Commission Implementing Regulation (EU) 2024/2690, Annex Section 9 — EUR-Lex
3. HashiCorp Developer Docs — Transit secrets engine
4. HashiCorp Developer Docs — PKI secrets engine
5. HashiCorp Developer Docs — Built-in FIPS 140-3 support
6. BSI (Germany) — Technical Guideline TR-02102, Cryptographic Mechanisms