NIS2 is a directive, which means it sets obligations and leaves the details to member-state law and to the entities that have to comply. Among its baseline risk-management measures is a short clause about the use of cryptography and, where appropriate, encryption. That clause is easy to read and hard to implement, because it names an outcome and says almost nothing about the operations that produce it. An organization that ticks “we use encryption” has not met the obligation in any meaningful sense, and will discover that the first time a supervisor asks how the cryptography is actually managed.
This post treats the cryptography clause as what it is: a requirement to run certificate and key management as a controlled, demonstrable practice. It does not parse the legal text or the national transpositions. It asks what an essential or important entity has to be able to do operationally so that its use of cryptography would survive scrutiny, and where the common gaps are.
Who NIS2 Applies To, and Why Scope Drives the Work
NIS2 widened the net considerably. It divides covered organizations into essential entities and important entities, spanning energy, transport, banking, health, water, digital infrastructure, public administration, and a long tail of sectors including manufacturing, food, and digital providers. Many organizations that were outside the original NIS scope are now in, often without a security program built for regulatory scrutiny.
The essential-versus-important distinction matters mainly for supervision and penalties rather than for the controls themselves. Both categories owe the same baseline risk-management measures, including the cryptography clause. What differs is intensity of oversight: essential entities face proactive supervision, important entities face reactive supervision triggered by evidence of a problem. For cryptographic operations, the practical reading is that an essential entity should expect to demonstrate its controls on a supervisor’s schedule, while an important entity should expect to demonstrate them the moment something goes wrong. Both need the capability ready; only the timing of the demand differs.
Scope also reaches down the supply chain, which is where the cryptography obligation becomes harder than it first appears. NIS2 expects entities to account for security in their supplier relationships, and cryptography is embedded in nearly every supplier relationship that touches data in transit or at rest.
From “Use of Cryptography” to Operational Reality
The directive’s cryptography clause implies far more than deploying encryption. Encryption that depends on certificates nobody tracks, keys nobody rotates, and algorithms nobody has reviewed is not a control; it is an unmanaged dependency that happens to involve cryptography. The operational reading of the clause is a set of capabilities an entity must possess.
| Directive Expectation | Operational Capability Required |
|---|---|
| Use of cryptography and encryption | Approved algorithms applied to data in transit and at rest, with a policy governing choices |
| As a risk-management measure | Cryptography managed against actual risk, with weak or aging algorithms identified and addressed |
| Effectiveness of controls | Certificates and keys that are inventoried, monitored, and renewed before they fail |
| Supply-chain security | Assurance that suppliers manage the cryptography protecting your data |
| Incident handling | Detection and reporting when a cryptographic control fails |
Read this way, the single clause expands into the same operational program that certificate lifecycle management and key management describe. The directive does not spell out the program, but it is the only honest way to satisfy the clause. An entity that deploys TLS everywhere but cannot say which certificates exist, when they expire, or what algorithms they use has deployed encryption and failed the risk-management obligation attached to it.
Compliance Gap: Required vs. Actual Certificate Coverage
What frameworks require vs. what organizations typically demonstrate
The average enterprise demonstrates 35% certificate coverage against framework requirements that expect 85-95%. This gap is where audit findings live.
Certificate Lifecycle as a NIS2 Control
Certificates are the operational edge of the cryptography clause, because they fail in ways that are both common and visible. An expired certificate is an availability incident, and NIS2 is fundamentally about availability and continuity of essential services. A certificate failure that disrupts a covered service is therefore not merely an operational nuisance; it is the kind of event the directive exists to reduce.
Meeting the obligation operationally means an entity can continuously answer four questions about its certificates:
What Do We Have
A complete and current inventory. The certificates that cause outages and audit findings are almost always the ones outside the known inventory: the ones issued directly by a team, embedded in an appliance, or inherited from an acquisition. An entity cannot claim to manage cryptography it cannot enumerate, and discovery is the first operational step the clause implies.
When Does It Expire, and Who Owns It
Expiry tracking with ownership and lead time. The difference between a routine renewal and an emergency outage is whether the expiry was known far enough ahead for the owner to act. NIS2’s continuity concern makes unmanaged expiry a direct regulatory exposure, not just an ops failure.
Are the Algorithms Still Sound
A view of which certificates use algorithms that are weakening. The risk-management framing of the clause means an entity is expected to notice when its cryptography is aging and to have a path to replace it. This is also where the quantum threat enters NIS2 operationally: a certificate signed with an algorithm that a quantum computer will break is a risk-management concern the directive’s language reasonably covers.
How Fast Do We Know When One Fails
Monitoring that detects failures quickly enough to feed incident handling. A certificate failure discovered by a customer is a detection gap, and NIS2’s incident obligations assume the entity detects its own problems.
Key Management the Directive Assumes
The cryptography clause is meaningless without sound key management, because the security of any encryption reduces to the security of the keys. NIS2 does not enumerate key-management controls, but the risk-management standard it sets cannot be met without them. Operationally, an entity should be able to demonstrate that private keys are generated with approved algorithms and adequate entropy, stored with protection appropriate to their sensitivity, used only by authorized systems for their intended purpose, rotated on a defined basis, and revoked and destroyed under control when retired.
The common gap is not the absence of these practices but the absence of evidence for them. An entity that rotates keys but keeps no durable record cannot demonstrate the control, and under NIS2 the ability to demonstrate controls to a supervisor is itself part of the obligation. The operational fix is a system of record that captures the lifecycle of each key, so that “how do you manage this key” has an answer that is an artifact rather than an assurance.
Supply-Chain Cryptography: The Obligation You Do Not Operate
NIS2’s supply-chain provisions are among its most consequential, and cryptography runs through them. An entity remains responsible for the security of its data even when a supplier processes or transmits it, and that data is protected by cryptography the supplier operates. The directive’s expectation that entities address supply-chain risk therefore extends to the cryptographic controls of their suppliers.
In practice this means an entity should be asking, and recording the answers to, a set of questions its vendor management may never have raised:
- Does the supplier protect our data with cryptography managed to a standard comparable to our own?
- Can the supplier tell us which algorithms and key sizes protect our workloads, and whether any are weakening?
- When a certificate or key the supplier manages fails in a way that affects us, how and how quickly are we informed?
- Can we obtain evidence of these controls, or are we relying on an unverified assertion?
The difficult suppliers are the ones who cannot answer. An entity that depends on a critical supplier with opaque cryptographic controls carries a NIS2 supply-chain gap it does not directly control. Closing it means pushing for transparency through the contractual relationship or documenting the opacity as an accepted, owned risk. “The supplier handles encryption” does not discharge the obligation.
When Cryptography Fails: Incident Reporting
NIS2 imposes a staged incident-reporting regime: an early warning soon after an entity becomes aware of a significant incident, a fuller notification shortly after, and a final report once the incident is understood and resolved. The timelines are tight, and they start when the entity becomes aware, which puts a premium on detection.
A cryptographic failure can be a significant incident. A certificate expiry that disrupts an essential service, a key compromise that forces emergency revocation, a protocol weakness exploited against a covered system, each can meet the significance threshold. The operational consequences are concrete: the entity must detect the failure fast enough to start the reporting clock honestly, assess its significance against the directive’s criteria, and document it well enough to produce the final report’s analysis. Weak certificate monitoring undermines all three. An entity that cannot see its own certificate failures cannot report them on time, and cannot explain them afterward.
Meeting the Clause Before Anyone Asks
The cryptography clause in NIS2 is short, but the operations it implies are not optional, because every adjacent obligation, risk management, supply-chain security, incident reporting, depends on the same underlying capability: knowing and controlling your certificates and keys. An entity that builds a complete inventory, manages lifecycles with evidence, extends visibility to suppliers, and monitors for failure satisfies the cryptography clause and strengthens the obligations around it at the same time.
The entities that will struggle are the ones that read the clause as a checkbox and deployed encryption without the operations beneath it. When supervision arrives, proactively for essential entities and reactively for important ones, the question will not be whether cryptography is in use. It will be whether the entity can show that the cryptography is managed. The way to be ready is to run certificate and key management as a controlled, recorded practice now, rather than assembling the evidence under the pressure of an examination or an incident.
FAQ
Q: Does NIS2 really require certificate lifecycle management, or just encryption? The directive names the use of cryptography and encryption as a risk-management measure. Encryption as a risk-management measure cannot exist without managing the certificates and keys it depends on, so certificate lifecycle and key management are the operational substance of the clause even though the text does not spell them out.
Q: What is the difference between essential and important entities for cryptography? Both owe the same baseline cryptographic obligations. The difference is supervision: essential entities face proactive oversight and should expect to demonstrate controls on a supervisor’s schedule, while important entities face reactive oversight triggered by a problem. Both need the capability ready; only the timing of the demand differs.
Q: How does the quantum threat relate to NIS2? NIS2 frames cryptography as a risk-management measure, which means an entity is expected to notice when its algorithms are weakening and to have a path to replace them. A certificate or key using an algorithm a quantum computer will break is a foreseeable risk the directive’s language reasonably covers, which makes a cryptographic inventory and a migration path part of prudent compliance.
Q: What do we owe for cryptography managed by our suppliers? NIS2’s supply-chain provisions make you responsible for the security of your data even when a supplier handles it. Operationally you need to know whether suppliers manage the cryptography protecting your data to a comparable standard, how you learn about their cryptographic failures, and whether you can obtain evidence rather than assertions. Opaque critical suppliers are a gap you must close or document.
Q: Can a certificate expiry trigger NIS2 incident reporting? Yes, if it disrupts a covered service significantly enough to meet the threshold. The reporting timeline starts when you become aware, so weak certificate monitoring that delays detection directly threatens your ability to report on time and to produce the final root-cause report the regime requires.
About QCecuring
QCecuring helps essential and important entities turn the NIS2 cryptography clause into operations that stand up to supervision. Our platform discovers and inventories every certificate and key, manages each lifecycle with a durable system of record, flags algorithms that are weakening, and extends cryptographic visibility to the suppliers that hold your data, so compliance is a capability you can demonstrate rather than a claim you hope holds.
Operationalize your NIS2 cryptographic obligations
Tags: NIS2, Compliance, Enterprise Security, Certificate Lifecycle Management, Key Management, Supply Chain Security, Incident Reporting, EU Directive, Essential Entities, Risk Management, Post-Quantum Cryptography, Certificate Governance