NIS2 Makes Cryptographic Governance Something You Have to Be Able to Show.

Most security programs are fluent in assertion. Ask whether the cryptography is sound and the answer comes back quickly: yes, we use strong algorithms, we follow best practice, our vendors are reputable. NIS2 is built to be unimpressed by that answer. It pushes essential and important entities away from asserting that their security is managed and toward being able to demonstrate it — with risk assessments, controls, and records an outsider can examine. For cryptography specifically, that is a higher bar than most organizations realize they have to clear.

The reason is simple and awkward. Demonstrating that you govern your cryptography requires first knowing what cryptography you have — which algorithms, which keys, which certificates, which protocols, running in which systems and supplied by whom. Most organizations cannot produce that picture on request. They have cryptography everywhere and an inventory of it nowhere, and an obligation to demonstrate control lands directly on that gap.

From asserting security to demonstrating it

The spirit of NIS2 is a shift in the burden of proof. Earlier habits were often satisfied by policy documents and good intentions; this orientation is toward evidence that the measures are real and maintained. The practical test is whether, asked to show how a given risk is managed, you can produce the assessment, the control, and the record of it operating — not a slide claiming it is handled. Cryptography is where this shift bites hardest, because it is at once the most relied-upon control and the least inventoried one.

That is not an accident of neglect so much as of diffusion. Cryptography is not a system you can point at; it is a property scattered across firmware, TLS endpoints, signing pipelines, stored data, hardware security modules, and third-party components. Each team assumes another team owns it. Asked to demonstrate governance over the whole, no one can, because no one holds the whole picture — and NIS2 asks about the whole.

Essential versus important entities

NIS2 widens the population of organizations expected to run mature security, sorting them into essential and important entities across a broad set of sectors. The two categories differ chiefly in how heavily they are supervised, not in whether the core expectations apply. If your organization operates in one of the covered sectors and is above the relevant size, the safe assumption is that the risk-management and reporting obligations reach you, and that the lighter-touch supervision of an important entity is not a reason to do less of the underlying work.

The useful consequence for an engineering leader is that the debate about exact classification matters less than it looks. The measures you would put in place to govern cryptography responsibly are the same ones either category expects. Spending months adjudicating which bucket you fall into is time not spent building the inventory and controls both buckets assume you already have.

Risk management read as crypto governance

At the center of NIS2 are risk-management measures: the requirement to identify risks and apply technical and organizational controls proportionate to them. Read that through a cryptographic lens and it becomes a specific program. Which systems depend on cryptography that is weakening, approaching end of life, or exposed to the harvest-now-decrypt-later threat, where captured ciphertext can be stored today and decrypted once the capability to break it exists. Which keys and certificates are long-lived enough that their assumptions will outlast them. Risk management here is not an abstraction; it is a prioritized list of cryptographic exposures and what you are doing about each.

This is also where the post-quantum transition stops being a research topic and becomes a governance one. Migrating is, in the end, a risk-management exercise carried out over years: deciding what to protect first by how long it must stay confidential, planning crypto-agility so the next algorithm change is cheaper than this one, and sequencing the work. None of that can be steered, let alone demonstrated, without knowing where the cryptography is.

You cannot govern what you have never inventoried — and cryptography is precisely what most organizations have never inventoried.

Supply-chain diligence includes cryptography

NIS2 treats supply-chain security as a first-class concern, and cryptography is one of its most consequential dimensions. The algorithms, libraries, and devices you buy carry cryptographic assumptions you inherit whether or not you examine them. A component with a hard-coded algorithm, an opaque key-management scheme, or no path to update its cryptography becomes your liability the moment it enters your product or your network. Diligence means asking suppliers the questions you would ask of your own systems: what is in use, how is it updated, and what happens when it has to change.

This is where a software bill of materials earns its place beyond the firmware context. A supplier that can hand you a machine-readable inventory of the cryptographic components it ships is a supplier you can govern; one that cannot is a blind spot you have agreed to carry. The crypto-agility of your supply chain — its ability to change algorithms when required — is now part of your own risk posture, not merely the vendor's problem.

Management accountability

A feature of NIS2 that changes behavior more than any technical clause is that it places accountability for cybersecurity risk management with the entity's management body. Oversight of these measures becomes a governance responsibility at the top of the organization rather than a concern delegated entirely to a security team and then forgotten. The effect on cryptography is indirect but powerful: a board that is accountable for risk management will eventually ask to see the cryptographic risk register, and a security function that cannot produce one is exposed in a way it was not before.

This is the mechanism by which inventory and governance acquire a budget. For years the argument for a cryptographic inventory has been technically obvious and organizationally unfunded. Accountability at the management level turns demonstrable control from a nice-to-have a team requests into something leadership has a personal reason to insist on, which is usually what it takes for the unglamorous foundational work to actually happen.

Inventory as the foundation

Every obligation above resolves, eventually, to the same precondition: an inventory of the cryptography you actually run. You cannot assess risk in algorithms you have not located, apply controls to keys you cannot enumerate, answer supply-chain questions about components you have not catalogued, or demonstrate governance over a landscape you have never mapped. The cryptographic inventory is not one task among several; it is the base the others stand on, which is why a mature program treats building and maintaining it as the first move rather than a later refinement.

A useful inventory is more than a list of algorithm names. For each cryptographic dependency it records a few things that turn a catalogue into a working map:

• Where it lives — the system, firmware, endpoint, or stored dataset the dependency sits in, down to the component supplied by a third party.
• What it protects — the data or function behind it, because a key guarding a decade-long secret is a different risk from an ephemeral session key.
• How long it must hold — the confidentiality or authenticity lifetime, which is what the harvest-now-decrypt-later threat turns into a deadline.
• Who supplies it — the vendor or library behind it, so a supply-chain question has an answer that is not a guess.
• How it would change — whether the algorithm can be swapped at all, which is the practical measure of crypto-agility.

Assembled that way, the inventory stops being a compliance artifact and becomes the operational basis for the post-quantum migration — the same discovery work serving both the auditor and the engineer.

Governance that survives an audit

The difference between a program that passes scrutiny and one that does not is rarely the strength of its cryptography. It is whether the organization can show its working: the inventory, the risk assessment built on it, the controls applied, the supply-chain questions asked and answered, and the records that all of this is maintained rather than performed once. Governance that survives an audit is governance that was running before the audit was announced, leaving evidence as a by-product rather than a scramble.

When 6QURE helps an organization put cryptographic governance on a NIS2 footing, the work starts where the obligations do: with discovery. Establishing what cryptography is actually in use, what each piece protects and for how long, where it comes from, and how it would change — then building the risk view, controls, and records on that base so that control can be demonstrated rather than asserted. The same inventory that answers a supervisor's questions is the one that makes the post-quantum migration tractable. Both rest on seeing the cryptography clearly, and that is the part most organizations have never done.