What NIS2 Article 21(2)(h) cryptography requirements ask an entity to prove
Article 21(2)(h) requires an essential or important entity to have policies and procedures on the use of cryptography and, where appropriate, encryption. In practice, a supervisor will expect to see a written cryptography policy, the procedures that put it into operation, and records showing that encryption and key handling are controlled and reviewed, not left to individual administrators. The duty is a policy-and-procedure duty with several "where appropriate" qualifiers, so the entity must justify where encryption applies and where it does not. Implementing Regulation (EU) 2024/2690 sets the detail for the entities it covers, and the entity should read the cryptography annex against its own service type before it writes anything. The risk is straightforward: data that an attacker can read in transit or at rest, keys that are lost, copied or compromised, and algorithms that stop being trustworthy. The hard part is usually key management rather than choosing a cipher. Keys have a life cycle from generation to destruction, and each stage needs an owner, a method and a log entry. Keys also end up in backups, build pipelines and certificate stores that nobody inventories. Before drafting the policy, the entity should confirm which systems hold data that must be encrypted, which keys protect them, who can rotate or revoke each key, and how long an old key can still decrypt backups. For a supervisor, the practical question is whether the entity can show a current inventory of cryptographic assets, an approved algorithm and protocol list tied to asset classification, and dated evidence of key rotation, revocation and destruction. ENISA's non-binding technical guidance on the 2024/2690 requirements gives examples of this evidence, and the entity should use it to test whether its own records would pass. Where the entity relies on a managed provider for key storage or certificate issuance, it should confirm in the contract who holds the keys and what logs the provider will produce on request.
Which data, keys and systems fall under the cryptography policy
The cryptography policy has to reach every place where data is stored or moved and every place where a key or certificate lives. The cards below show the scoping decisions that change the work, starting with classification, because the asset class decides how strong each control must be. Map each item to an owner before you write the policy, or the policy will describe systems nobody runs.
Data at rest by asset class
Start from your asset classification, not from the technology. For each class, record whether the data is encrypted at rest, which algorithm and strength applies, and where the keys sit. Implementing Regulation 2024/2690 expects the policy to set the type, strength and quality of measures for data at rest and in transit according to that classification. Check file shares, databases, object storage and collaboration platforms, including metadata that some encryption features leave in clear text.
Data in transit and TLS
Inventory every internal and external service that carries data between systems, including east-west traffic inside clusters, database connections, message queues and administrative interfaces. Internal links are often missed because they sit behind a firewall. Record the protocol versions, certificate issuers and renewal method for each one, and identify endpoints that still accept older protocols.
Backups and archives
Backups copy encrypted and unencrypted data into places that are rarely reviewed, so the policy must cover them. Confirm whether backup jobs encrypt before data leaves the source, where the backup keys are held, and whether restore needs a key that the backup system alone cannot reach. Key recovery and backup are both listed as key management life cycle items, so the policy should name who can restore encrypted backups.
Endpoints and removable media
Laptops, mobile devices and removable media carry copies of data outside the data center. Decide which device classes require full-disk encryption, how removable media is encrypted or blocked, and how the organization proves that a lost device held no unencrypted data. Ask your endpoint management team to confirm the current enforcement state per device group, because policy statements alone will not satisfy an assessor.
Cloud key services and hosted systems
Cloud key management services, managed databases and SaaS platforms each hold keys or encrypt data under keys the customer does not fully control. Record which party generates, stores and rotates each key, and whether the customer can revoke it. For third-party hosted systems, the policy should reference contract terms and the supplier's evidence, since the entity still owns the outcome under Article 21.
Teams and suppliers holding keys
List every team, service account and supplier that can generate, export, rotate or destroy a key. Separation of duties matters: the people who run an application should not also hold the only copy of its decryption key. Where a managed service provider operates keys for you, confirm in writing who approves changes and who can revoke access. Use this register as the basis for the key management section of the policy.
How an assessor tests the cryptography policy and key management
This table sets out each step an assessor takes to test the cryptography policy and key lifecycle against Article 21(2)(h) and points 9.2 and 9.3 of the Annex to Implementing Regulation 2024/2690. Read it as a checklist of what to prepare: each row names the test, the evidence it draws on, and the finding that most often appears when that evidence is missing or stale.
| Test step | What the assessor checks | Common finding |
|---|---|---|
| Policy review against point 9.2 | Whether the cryptography policy sets the type, strength and quality of measures for data at rest and in transit by asset classification, and names approved protocols, algorithms and cipher strengths. | Policy exists but does not tie cipher choices to asset classes or names no approved algorithm list. |
| Approved algorithm list review | Whether the list is current, covers every protocol in use, and reflects a cryptographic agility approach where appropriate. | Legacy protocols remain enabled on systems that are not on the approved list. |
| Sampling of data stores | Encryption status of a sample of databases, file stores, backups and object storage, checked against the classification the policy assigns. | Sampled stores hold sensitive data with no documented encryption or an unrecorded exception. |
| Sampling of transport configurations | TLS versions, cipher suites and certificate chains on internal and external endpoints, compared with the policy. | Deprecated protocol versions still accepted on internal service endpoints. |
| Key lifecycle walkthrough | The entity traces one key or certificate from generation through distribution, storage, rotation, revocation, backup, destruction and logging, showing records at each step. | Keys are generated and stored, but rotation, revocation or destruction has no record. |
| Certificate inventory check | Whether every certificate in use appears in an inventory with an owner, issuer and expiry date, and whether renewal runs before expiry. | Expired certificates found in production, or certificates with no named owner. |
| Unmanaged key discovery | Whether keys held in code, configuration files, shared drives or personal stores are identified and brought under the key management process. | Keys stored outside the managed system with no record of who holds them. |
| Exceptions and review cycle | Whether exceptions to the policy are approved, time-limited and recorded, and whether the policy was reviewed at planned intervals against the state of the art. | Undocumented exceptions and no dated review record since the policy was written. |
How to build the cryptography policy and key lifecycle, step by step
This sequence turns Article 21(2)(h) into a working cryptography policy and key lifecycle by starting from what data and assets exist, then setting the rules, the key handling and the ownership that keep them current.
Inventory data and classify assets
Start by listing where data is stored and moved: databases, file shares, backups, message queues, APIs, endpoints and external links. Record which systems hold personal, financial, health or operational data, and assign each asset a classification level that your organization already uses or defines now. The output is an asset register that marks each system with its classification and whether its data is at rest, in transit or both. You know the step is done when a system owner can confirm the entries for their platforms and no in-scope system is missing from the register.
Set approved protocols and algorithms by class
For each classification level, the policy must define the cryptographic type, strength and quality for data at rest and in transit. Name the approved protocols, algorithms, key lengths and cipher suites, and state the usage practices that apply, such as which TLS versions are allowed and where encryption is mandatory. Security architects draft the table, and the risk owner approves it. The output is a signed standard that maps each classification to permitted and prohibited cryptographic choices. It is done when every asset class in the register has a rule and the prohibited list is explicit.
Design the cryptographic agility approach
Where appropriate, the implementing regulation expects a cryptographic agility approach, meaning the organization can replace algorithms and protocols without rebuilding every system. Map which applications hard-code algorithms, which rely on libraries or platform services, and which depend on vendors for changes. Define how a replacement is tested, approved and rolled out, and who holds that authority. The output is a short design note with an inventory of cryptographic dependencies and a change path for each class. It is done when the owners of the highest-classification systems agree that a forced algorithm change is possible within their own change process.
Define the full key lifecycle
Write procedures for each key lifecycle stage: generation, certificates, distribution, storage, changing, compromise, revocation, recovery, backup, destruction, logging, and activation and deactivation dates. Where a stage does not apply, the procedure should say so and why. Platform engineers draft the procedures, and the security team reviews them against the asset register. The output is a key management standard with one section per stage and a named system of record for keys and certificates. It is done when each stage has an owner, a trigger and a log entry that an assessor could trace.
Choose the platforms that enforce and log the policy
Match the lifecycle to the tools that will run it, such as a key management or secrets engine, a certificate authority, and a certificate automation controller for container platforms. Confirm the capabilities of each product against your own requirements, including key rotation, versioning, revocation, backup and audit logging, because capability details change between releases. Document the decision and the configuration baseline. The output is a platform map that links each lifecycle stage to a tool, a configuration standard and a log source. It is done when a test key or certificate can be followed through every stage in a non-production environment.
Assign owners and accountability
Name one accountable owner for the cryptography policy, one for key management operations, and a named owner for each asset class or platform. Define who approves exceptions, who can authorize key compromise response and who signs off destruction of keys. Management should confirm the accountable roles in writing. Where an external implementation partner or managed service provider operates parts of the platform, document which actions they perform and which decisions remain with your staff. The output is a responsibility matrix. It is done when every lifecycle stage and every exception path has one accountable name, not a team alias.
Schedule the policy review
Set a review cycle at planned intervals and record the triggers that require an earlier review, such as a new vulnerability in an approved algorithm, a platform change or a significant incident. The review must take into account the state of the art in cryptography, so assign a person to track relevant guidance from your vendors and national authorities. Record each review, its findings and the changes made. The output is a review calendar, a change log for the policy and a review record that shows the state of the art was considered. It is done when the next review date is set and the review owner has accepted the task.
Why cryptographic agility and planned review matter for supervision
Cryptographic agility means an organization can replace an algorithm, protocol, key length or certificate authority without redesigning the systems that depend on it. The Annex to Implementing Regulation (EU) 2024/2690 asks for an agility approach where appropriate, so a supervisor will look for evidence that the entity can make such a change on purpose and within a known timeframe. In practice, this starts with an inventory of where cryptography is used: TLS termination points, VPNs, database encryption, code signing, backup encryption and the certificate authorities that issue to them. Ask each system owner whether the algorithm and key length are set in one place or hard-coded in applications, and whether the certificate issuer can be switched without re-enrolling every workload. Where the answer is hard-coded, record it as a risk to plan for.
The regulation requires the cryptography policy to be reviewed at planned intervals, taking into account the state of the art in cryptography. It does not set a fixed review period, so the entity must choose one and be able to justify it. A justification might reference the sensitivity of the data, the expected life of the systems and how quickly the cryptographic community is moving for the algorithms in use. Each review should produce a dated record: the participants, the sources consulted, the algorithms and key lengths reviewed, any deviations from the policy, and a decision for each item (keep, change with a deadline, or retire). Confirm with your national competent authority and your own sector guidance whether they expect a particular cadence, because the record of decisions is usually the evidence that is requested first.
Plan the review so it can trigger out-of-cycle action. A published weakness in an algorithm, a vendor advisory or a certificate authority incident should move a specific item forward without waiting for the next scheduled review. Keep a short register of pending cryptographic changes with owners and target dates, and link each review decision to that register. A supervisor reading the register can then see that the policy is maintained in practice rather than written once and filed.
Evidence that satisfies the cryptography and key management requirement
A supervisor testing Article 21(2)(h) looks for a written cryptography policy and proof that the organization follows it. The cards below cover the documents, registers, configuration baselines and key records that connect policy to practice, and how to keep each one current between audits.
Signed cryptography policy
This is the policy document itself, approved by the management body and dated. It should set the type, strength and quality of cryptographic measures for data at rest and in transit, tied to asset classes, and name an owner. Check that the approval date, version history and scope match the systems actually in use. Confirm the policy references the review cycle described in Annex point 9.3 of Implementing Regulation 2024/2690.
Asset classification register linked to cipher rules
A register that lists each information asset, its classification and the cryptographic requirements that apply to it. A supervisor will pick a high-classification system and ask which cipher rules govern its data. Keep the register in the same tooling as the asset inventory so that new systems inherit a classification before they go live. Review it whenever a system's data sensitivity changes.
Approved algorithm and protocol list
A controlled list of approved protocols, algorithms, cipher suites and minimum strengths, with the usage rules for each. It should record the date each entry was approved and the trigger for retiring it. Keep it versioned so an assessor can see when a weak algorithm was removed. Note any cryptographic agility provisions, such as how a replacement algorithm would be introduced across services.
TLS and at-rest configuration baselines
Written baselines for TLS on load balancers, reverse proxies and internal services, and for encryption at rest on databases, file stores and backups. Each baseline should name the configuration keys that enforce it, such as the server-side encryption setting in Nextcloud, which protects file contents but not file names or folder structure. Scan live systems against the baseline and keep the scan output as dated evidence.
Key inventory with lifecycle records
An inventory of every cryptographic key and certificate, with its owner, purpose, storage location and activation and deactivation dates. Annex point 9.2(c) expects coverage of generation, distribution, storage, changes, compromise, revocation, recovery, backup, destruction and logging, where appropriate. Certificate authorities such as FreeIPA's integrated CA and cert-manager's issuers can export issuance records, which feed this inventory.
Rotation, revocation and destruction logs
Dated records showing that keys were rotated on schedule, revoked after suspected compromise and destroyed when retired. A rotation log from a versioned secrets engine, such as the OpenBao transit engine's key versions, shows the rotation history directly. Destruction records should state the method, the person who approved it and confirmation that backups of the key were also removed. Sample these logs quarterly to confirm they are complete.
Key recovery and backup test results
Evidence that keys can be restored from backup and that escrowed or recovery keys work when needed. A test record should state the key set restored, the date, the restore target and the outcome. Without a tested recovery path, a key loss can turn into a multi-week outage, which is the failure supervisors expect entities to have planned for. Repeat the test after any change to the key store.
Policy review minutes
Minutes or sign-off records showing that the cryptography policy and its algorithm list were reviewed at planned intervals, with the state of the art in cryptography considered. Record the reviewer, the sources consulted and any changes agreed. A review that has no recorded decision is weak evidence, even if the document looks current. Ask the management body or delegated owner to confirm each review in writing.
Where encryption is appropriate and how to justify exceptions
The Article 21(2)(h) duty is to have policies and procedures on cryptography and, where appropriate, encryption. The qualifier means encryption is not an automatic blanket requirement, but it also means the organization cannot leave the decision undocumented. In practice, the default should be encryption for data at rest and in transit, scaled by asset classification as the cryptography policy in Implementing Regulation (EU) 2024/2690 requires. Exceptions are the cases where the organization must show a reasoned decision: a legacy appliance that cannot negotiate modern protocols, a monitoring feed that must be inspected in clear text, or a backup target where the key cannot be held separately from the data. Confirm with your supervisor's expectations and your own asset register which classes fall into this category before you draft any exception.
Recital 98 says encryption, in particular end-to-end encryption, should be promoted and, where necessary, be mandatory for providers of public electronic communications networks or services. That obligation is stated for those providers, so it does not directly bind most essential and important entities. Read it as a signal of what supervisors regard as the state of the art for confidential communications. An organization that routes sensitive internal or customer messaging without end-to-end protection should expect to explain why, particularly when a cheaper control exists.
A defensible exception record names the asset, the specific encryption gap, the business reason, the risk owner who accepts it, a review date tied to the planned policy review, and the compensating controls. Typical compensating controls include network segmentation, restricted administrative access, tighter logging, and encryption at a different layer, such as full-disk encryption on a server whose application traffic cannot be encrypted. Store the register with the risk assessment so that the decision and its review trail can be shown to an authority. Confirm with the owner of your cryptography policy who has authority to approve exceptions, because a risk acceptance signed below the management body may not satisfy the governance expectations of Article 20.
What meeting Article 21(2)(h) costs in money and effort
Meeting Article 21(2)(h) is paid for in five broad buckets: tooling or licenses, engineering time for key management and certificate automation, evidence upkeep, external review or testing, and the time spent by supervisors or auditors who examine the result. Each bucket has a different payee. The organization pays its own staff and any vendor licenses directly, an implementation partner is paid for work in the agreed scope, and an independent auditor or assessor is paid for any formal assessment. None of these parties issues the cryptography policy or the compliance evidence on the organization's behalf. The organization owns that output.
- Tooling or licenses: Commercial key management, hardware security modules, certificate authorities and inventory tools carry subscription or support fees. Open-source alternatives may remove the license line but still need hosting and support.
- Engineering time: Staff or a partner design the key hierarchy, automate certificate issuance and renewal, and migrate applications to approved algorithms.
- Evidence upkeep: Someone must keep the cryptography policy current, record key events, and review the policy at planned intervals.
- External review or testing: Independent penetration tests of TLS configuration and key handling, or a formal assessment, are priced separately.
- Supervisor or auditor time: Inspections and audits by national authorities or assessors consume staff hours, even when no fee is charged to the entity.
Ask each bidder to split its quote along these five lines and to state which items are one-time and which recur.
Some cryptography costs are paid once to get the system into shape, while others return every year or every rotation cycle. Confusing the two is the most common reason budgets fail. Initial design, inventory of certificates and keys, algorithm migration and the first policy are one-time work. Certificate renewal, key rotation, log review, periodic policy review, license renewals and support contracts recur. Recurring costs are often larger over several years than the initial build, so the quote should show both.
- One-time: Cryptographic inventory, key hierarchy design, initial migration of protocols and ciphers, and first-time integration of certificate automation.
- Recurring: Certificate renewal and monitoring, scheduled key rotation, key backup tests, and staff time for logs and access reviews.
- Periodic: Review of the cryptography policy at planned intervals, which should reflect the state of the art in cryptography.
- Ongoing vendor fees: Subscriptions for commercial platforms, support contracts and hardware maintenance.
- Ask for: A three-year or five-year cost view with the one-time and recurring lines shown separately, and the assumptions behind each recurring line.
Confirm with the bidder which renewal and support costs are fixed and which vary with the number of systems.
The size of the effort depends less on the policy document and more on the estate it covers. Cryptographic work scales with the number of systems that hold or move data, the number of keys and certificates in use, the cloud footprint, and the age of legacy protocols that still need replacing. An illustrative example: a single application with one public certificate is a small task, while the same organization with hundreds of internal services, several clouds and older devices that only support legacy protocols carries a much larger migration and monitoring load. The drivers below explain most of the difference between quotes.
- Number of systems and data stores: Each system holding data at rest or in transit needs classification and a documented method.
- Key and certificate count: Inventory effort and renewal workload grow with every key and certificate, especially those with short lifetimes.
- Cloud and hybrid footprint: Separate key services in each cloud, and certificates issued by several authorities, multiply the management points.
- Legacy protocols and devices: Hardware that cannot support current algorithms may need replacement, a compensating control or a planned retirement date.
- Degree of automation: Manual renewal costs more over time than automated issuance, though automation takes engineering effort to build.
Ask the bidder to state which of these drivers it assumed and how its quote changes if the count doubles.
Self-hosted open-source platforms can remove license spend for components such as the secrets and transit engine, the internal certificate authority and certificate automation. The organization still pays for the infrastructure that runs them, the staff who operate them and the support it chooses to buy. The cost shifts from a subscription to operations. That trade can be favorable when the organization already runs the relevant infrastructure, and less favorable when it does not. The licenses listed below are the ones named in the supplied facts, and each should be checked against the current version before adoption.
- OpenBao (MPL-2.0): The transit secrets engine encrypts application data without storing it and supports versioned keys with rotation. Operating and backing up the key store becomes an internal responsibility.
- FreeIPA (GPL-3.0-or-later): The integrated Dogtag certificate authority issues and manages certificates. Running identity infrastructure carries its own staffing demand.
- cert-manager (Apache-2.0): Automates TLS certificates for Kubernetes or OpenShift workloads from several issuers and renews them before expiry. Its cost is mostly the cluster and the integration work.
- Nextcloud (AGPL-3.0-only): Server-side encryption protects file contents at rest, but does not encrypt file names or folder structure, so a compensating design may still be needed.
- Support and hardening: A self-hosted stack still needs security updates, monitoring and a tested recovery path.
Ask the bidder to show the license saving and the operations cost side by side, so the net effect is visible.
A quote for this measure is only comparable when every bidder works from the same written scope. The scope should name the systems, the key and certificate types, the cloud and on-premises locations, the planned protocol migrations and the evidence to be produced. Fixed-scope agreements set deliverables and timelines in writing before work begins, which makes changes visible. DeployOpen prepares systems, controls and evidence and does not issue audit reports or certificates. An independent auditor or certification body does that work and is paid separately.
- Written scope: The systems, key types, certificate authorities, cloud accounts and protocols included, and those excluded.
- Cost split: Tooling, engineering, evidence upkeep, external testing and assessor fees, each shown separately.
- Assumptions: Number of keys and certificates, legacy device count, and the planned migration sequence.
- Deliverables: The cryptography policy, key management procedures, inventory and evidence samples, with named owners.
- Recurring terms: Support, renewal and review obligations, with the cost of each and any change-request process.
Confirm with the bidder who owns each deliverable after handover and whether any assessor fee is included.
Which self-hosted open-source tools produce cryptography evidence
This table compares four self-hosted open-source platforms against the cryptography evidence each can produce for Article 21(2)(h). Read each row as a candidate for a specific part of the cryptography policy or key life cycle, not as a complete answer. Confirm the fit of each tool, and its license terms, against your own environment and legal review before you rely on it.
| Tool | Cryptographic function | Evidence it can produce | License caveat |
|---|---|---|---|
| OpenBao | Transit secrets engine for application encryption, decryption, signing and verification, with versioned keys and key rotation | Key inventory, rotation history and version records, and configuration showing which keys encrypt which application data | MPL-2.0 (file-level copyleft). Confirm that your deployment model and any modifications meet its terms |
| FreeIPA | Integrated certificate authority based on Dogtag for issuing and managing internal certificates | Certificate issuance and revocation logs, CA configuration, and records of certificate profiles and lifetimes | GPL-3.0-or-later. Confirm distribution obligations with counsel if you modify or redistribute the software |
| cert-manager | Creates TLS certificates for Kubernetes or OpenShift workloads from ACME, CA key pair, HashiCorp Vault, CyberArk or self-signed issuers, and renews them before expiry | Issuer configuration, certificate resource records with expiry and renewal events, and Kubernetes Secret storage settings | Apache-2.0 (permissive). Check the license of any external issuer, such as a commercial vault, that you connect to it |
| Nextcloud | Server-side encryption that protects file contents at rest on local and external storage, with keys held on the server | Encryption configuration settings, storage encryption status and key recovery procedures, and records of which storage is covered | AGPL-3.0-only. File names and folder structure are not encrypted, so document this limit and confirm the fit for sensitive data |
Who owns the cryptography policy, who implements it and who assesses it
The organization owns Article 21(2)(h) in full. The cryptography policy is an internal governance document, and the people who sign it, approve it and answer for it have to be inside the entity. Under NIS2, the management body approves and oversees the Article 21 measures, so the board or executive committee must be able to show it reviewed the policy and accepted the residual risk. Day-to-day, the policy owner (often the CISO or head of security architecture) decides which algorithms, protocols and key lengths are approved for each asset classification, and key custodians hold operational control over root keys and recovery material.
- Policy owner: maintains the cryptography policy, sets approved algorithms and cipher strength by asset class, and schedules the planned reviews that Annex point 9.3 requires.
- Management approval: records board or executive sign-off, the risk acceptance for any exceptions, and the review outcomes.
- Key custodians: named individuals or roles responsible for root and intermediate key material, split knowledge and dual control where the design calls for it.
- System owners: confirm which data at rest and in transit each application handles, so the asset classification drives the encryption rules.
- Exception register: documents each deviation from approved algorithms, with an owner and an expiry date.
Confirm with your counsel and sector regulator which sign-off and record-keeping duties apply in your Member State, because national transposition laws set the detail.
An implementation partner such as DeployOpen can plan, install, configure and document the technical systems that carry out the policy inside the client's own infrastructure. For cryptography, this usually covers a key management service, a certificate authority, certificate automation for workloads, and the logs and runbooks that show keys were generated, rotated, revoked and destroyed as the policy says. The partner prepares systems and evidence. It does not decide the policy, does not accept risk, and does not issue any report or certificate.
- Key tooling: deploys and hardens a secrets and key service, such as OpenBao with its transit engine, and configures key versioning and rotation to match the policy.
- Certificate automation: sets up issuers and renewal for TLS certificates, for example through cert-manager in Kubernetes or an internal CA such as the Dogtag-based authority in FreeIPA.
- Evidence packs: collects configuration exports, key lifecycle logs, inventories of algorithms in use and test results in a form the internal owner can review.
- Runbooks and handover: documents compromise, revocation and recovery procedures, and trains the custodians who will operate them.
- Independence limit: the partner should not test its own build as if it were the assessor, and should not sign statements of conformity on the entity's behalf.
Ask any partner for a written scope that names which evidence it produces, which items remain the client's responsibility, and who signs off each deliverable.
NIS2 creates no certificate of compliance. National competent authorities supervise compliance through inspections, security audits, security scans, information requests and administrative fines. An entity may also commission an independent auditor or assessor to test its controls against a recognized framework, but that auditor issues the report, not the partner that helped build the systems. Assessors test whether the policy exists, whether it is approved and reviewed, and whether the systems behave as documented.
- Design review: checks that the policy covers data at rest and in transit by classification, and that approved algorithms and protocols are stated.
- Operating tests: samples key generation, rotation and destruction records, and certificate renewal logs against the policy.
- Findings and remediation: the assessor reports gaps and the organization owns the corrective action and its deadline.
- Supervisor requests: a national authority may request the same evidence directly during an inspection or audit.
- Scope of ENISA guidance: ENISA's June 2025 technical guidance gives examples of evidence that assessors and supervisors commonly look for.
Confirm with your supervisor or assessor which evidence formats they accept and whether they require independence from the implementation partner.
Where entities usually fall short on cryptography and how to close each gap
Most cryptography weaknesses under Article 21(2)(h) are not missing tools. They are missing records: an algorithm list nobody owns, certificates nobody tracks, and keys whose lifecycle ends without evidence. The cards below pair each common gap with a fix that produces evidence an assessor can test.
No current approved algorithm list
The cryptography policy must set approved protocols, algorithms and cipher strength, following a cryptographic agility approach where appropriate. Many organizations have a policy that names algorithms once and never updates them, so systems keep using whatever their developers chose. Fix it by maintaining a versioned register of approved algorithms and minimum key lengths, tied to asset classification, with a named owner and a date of last review. Check that every production system can be mapped to an entry on that register.
Certificates tracked in spreadsheets
Expired or forgotten certificates cause outages and hide weak keys, and a spreadsheet cannot show what is actually deployed. Record certificates from an inventory generated by the systems that issue them, including issuer, subject, algorithm, expiry date and the workload that uses each one. In Kubernetes or OpenShift, cert-manager can issue, store and renew certificates automatically, so the inventory comes from the cluster rather than from memory. Check that the register matches what is live on the network.
Keys with no destruction record
The key management requirements expect destruction, activation and deactivation dates and logging for each key, where appropriate. Many teams rotate or retire keys but never record when a key was destroyed or whether any copy remains in a backup or a developer's environment. Fix it by setting a key lifecycle standard in the policy and recording each transition in a system log. Check that you can show, for any retired key, when it was deactivated, when it was destroyed and who approved it.
Backups holding keys without controls
Backups often contain key material, such as database encryption keys or certificate private keys, under weaker controls than the systems they protect. A backup of an encrypted database is only as protected as the key stored beside it. Restrict access to key backups, encrypt them with a separate key, log restores and test them as part of recovery exercises. Check whether backup scope includes key stores and whether the same access rules apply to those copies.
Legacy protocols still enabled
Older protocol versions and weak cipher suites often remain enabled on load balancers, mail servers, VPN gateways and internal services because nobody owns the configuration after deployment. Article 21(2)(h) asks for usage practices that match the approved list, so any enabled protocol the policy does not permit is a gap. Scan externally and internally on a schedule, record exceptions with an owner and an end date, and remove deprecated options from configuration templates. Check that scan results can be compared with the approved list.
No defined trigger for compromise response
The policy must cover key compromise and revocation, but many organizations have no written trigger that starts the response. Without one, a suspected leak of a private key may wait until someone escalates it, while certificates remain trusted. Define the events that count as compromise, such as a host breach or a key found in a repository, and the steps that follow: revocation, reissue, rotation of dependent secrets and notification under the incident process. Check that the trigger links to the incident handling procedure and that a test has walked through it.
Policies never reviewed
Implementing Regulation 2024/2690 requires the cryptography policy to be reviewed at planned intervals, taking into account the state of the art in cryptography. A policy approved once and filed away will not reflect deprecated algorithms or new recommendations. Set a review interval in the policy, assign an owner, and record each review with changes and the reason for them. Check that the most recent review considered current algorithm guidance and that the algorithm register was updated to match.
Questions buyers ask about NIS2 cryptography and key management
How much effort does NIS2 cryptography and key management work take?
The effort depends mainly on how many systems hold sensitive data, how many certificates and keys already exist, and how much of the key life cycle is manual today. Organizations usually start with an inventory of data stores, transport paths, certificates and keys, then classify assets so the cryptography policy can set strength and handling rules for each class. The main cost components are internal staff time for the inventory and decisions, external support for design and implementation, and recurring work for rotation, renewal and policy review. Ask any provider to split a quote into discovery, policy, technical implementation and evidence preparation, so you can see what each phase covers and what your own team must supply.
Can an in-house team handle NIS2 cryptography and key management alone?
Many organizations can, provided they have people who understand TLS, certificate lifecycles, key storage and the systems they operate. The harder part is usually coverage: keys and certificates often sit in application configurations, cloud services, load balancers and legacy hardware that nobody owns end to end. An in-house team should check whether it can produce a complete inventory, define approved algorithms and protocols, automate renewal and rotation, and keep logs of key events. An implementation partner can prepare the platforms and evidence, but the organization must still own the policy, its risk decisions and its controls. Independent auditors or assessors, not consultants, issue any report or certificate.
What does NIS2 cryptography work need from management and engineering?
Management needs to approve the cryptography policy, accept the risk decisions behind any exceptions, and fund the ongoing work, because Article 20 places oversight of the Article 21 measures on the management body. Engineering needs to maintain the asset inventory, implement approved protocols and algorithms, automate certificate issuance and renewal, and document how keys are generated, stored, rotated, revoked, backed up and destroyed. Security and compliance leads should agree on who reviews the policy at planned intervals and how changes in the state of the art are tracked. Without named owners for each key type, the program tends to stall at the first expired certificate.
How long does NIS2 cryptography and key management take?
Duration depends on the size of the estate, the number of systems that need changes, and whether the organization already runs a central certificate authority or secrets platform. Timing is usually set by the inventory and the migration of existing certificates and keys, not by writing the policy. Ask for a timeline tied to written phases and named deliverables, and ask which dependencies sit with your change management, vendors and maintenance windows. No general duration should be treated as a commitment until it appears in a scope agreed in writing. Note that NIS2 itself has no certificate of compliance, so the goal is to have working, evidenced controls by the time a supervisor asks for them.
Is encryption mandatory for every system under NIS2?
No. Article 21(2)(h) requires policies and procedures on the use of cryptography and, where appropriate, encryption, so the organization must decide where encryption applies based on asset classification and risk. Recital 98 encourages encryption, especially end-to-end encryption, and says it should be mandatory where necessary for providers of public electronic communications networks or services. Implementing Regulation (EU) 2024/2690 expects the policy to set the type, strength and quality of cryptographic measures for data at rest and in transit according to asset classification. In practice, a supervisor will expect a documented reason for every system where encryption is not applied, and that reason should be approved and reviewed.
What will the auditor sample for NIS2 cryptography?
An assessor will usually start with the cryptography policy and check that it sets approved protocols, algorithms, cipher strength and usage practices, and that it reflects asset classification. They will then sample systems across data at rest and in transit, pick certificates and keys, and ask for evidence of generation, distribution, storage, rotation, revocation, backup, destruction and logging, along with activation and deactivation dates. Expect requests for records of policy review, decisions on exceptions and proof that the policy was approved by management. Keep these records in a form that can be produced quickly, because the sample is selected by the assessor, not the organization.
How do open-source tools help produce cryptography evidence?
Self-hosted tools can generate much of the evidence inside your own environment. OpenBao's transit secrets engine supports versioned encryption keys with key rotation, FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates, and cert-manager renews TLS certificates for Kubernetes or OpenShift workloads before they expire. Nextcloud server-side encryption protects file contents at rest, but it does not encrypt file names or folder structure, so that gap belongs in your risk record. Confirm each tool's logging, access control and backup features against your own requirements before relying on them as evidence.
How DeployOpen scopes and prepares cryptography evidence for NIS2
DeployOpen plans, implements and hardens self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, and that is the only role it takes on for cryptography under Article 21(2)(h). It configures the key and certificate tooling the entity has chosen, such as OpenBao for the transit secrets engine and key rotation, FreeIPA for its integrated certificate authority, and cert-manager for TLS certificates in Kubernetes or OpenShift, and it prepares the policy documents and evidence packs that show how those systems run. DeployOpen does not issue audit reports, attestations or certifications. Any assessment of NIS2 compliance is performed by the competent national authority or by an independent assessor the entity appoints. The organization keeps ownership of its controls, its cryptography policy and the decisions behind them.
Scope is agreed in writing before any work starts. The first step is to list the systems that hold or transmit data in each asset class, then record for each one whether encryption at rest and in transit is in place, which protocols and algorithms are approved, and who holds the keys. Decisions the client must make before the engagement begins include which key lifecycle stages each platform must cover (generation, distribution, rotation, compromise response, revocation, backup, destruction and logging), which certificate issuers are permitted, and how often the cryptography policy will be reviewed. Where Nextcloud is in scope, the written scope should state that server-side encryption protects file contents but does not encrypt file names or folder structure, so the client can decide whether that gap needs a compensating control.
The deliverables are defined in the same written scope. They typically include the cryptography policy, a key management procedure, a certificate inventory, configuration records for each platform and a log of key lifecycle events. Organizations should ask how each deliverable will be tested, who signs off on it and how it will be kept current as the state of the art changes. Costs fall into the work DeployOpen performs under the agreed scope, internal staff time for policy approval and asset classification, and any independent assessment the entity commissions. Ask for a quote that separates these components and states what is one-time and what recurs, such as certificate renewal or a scheduled policy review. Confirm the final requirements against the Implementing Regulation's text and the ENISA guidance before scope is signed.
