The One Line That Pulls Secret Management Into Scope

NIS2 is Directive (EU) 2022/2555, the EU’s cybersecurity directive covering an estimated 100,000+ organisations across energy, transport, health, finance, water, digital infrastructure, public administration, manufacturing and their supply chains. Member states were required to transpose it into national law by 17 October 2024, and enforcement is now ramping across the EU, unevenly, because several member states transposed late and each supervises under its own national law.

Buried in the list of minimum security measures every in-scope organisation must take, Article 21(2)(h) requires:

“policies and procedures regarding the use of cryptography and, where appropriate, encryption”

One line, no implementation detail. But a policy on the use of cryptography that says nothing about how cryptographic material is issued, stored, rotated and retired is not a policy an auditor will accept. In practice, supervisory authorities and the auditors working for them read Article 21(2)(h) together with 21(2)(i) (asset management) and 21(2)(j) (access control and, where appropriate, multi-factor authentication) as requiring demonstrable lifecycle management of keys, certificates and secrets. ENISA’s technical implementation guidance for the related implementing regulation spells this out for digital infrastructure entities: documented key management, defined validity periods, and revocation and replacement procedures.

If your organisation runs on Azure, “cryptographic material” means, concretely: Key Vault secrets, certificates and keys, App Registration client secrets and certificates in Entra ID, storage account keys, SAS tokens, and the TLS certificates on everything customer-facing.

Who Is In Scope

Two categories, defined in Articles 2 and 3:

  • Essential entities: energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure (DNS, cloud, data centres), ICT service management, public administration, space. Generally organisations with 250+ employees or over EUR 50M turnover in these sectors, with carve-ins for smaller critical providers.
  • Important entities: postal services, waste management, chemicals, food, manufacturing of medical devices and electronics, digital providers (marketplaces, search, social platforms), research. Generally the 50+ employee / EUR 10M+ tier.

The reach that surprises people is Article 21(2)(d): supply chain security. In-scope entities must manage the security of their suppliers, which means a 40-person software company selling into a hospital or an energy utility gets NIS2 questionnaires regardless of its own size. “Show us your key and secret rotation policy” is now a standard row in those questionnaires.

The penalty ceiling makes this a board-level topic by design: up to EUR 10,000,000 or 2% of worldwide annual turnover, whichever is higher, for essential entities (Article 34), EUR 7,000,000 or 1.4% for important entities, plus a management liability provision in Article 20 that makes directors personally accountable for approving the risk-management measures.

What an Auditor Actually Asks For

NIS2 audits are evidence-driven. For the cryptography measure, the requests come down to four artefacts. This is the same pattern as ISO 27001 Annex A 8.24 and SOC 2, so if you have those, you have a head start; if you do not, this is the list to build against.

1. The inventory. Every cryptographic asset: which vaults exist, what lives in them, which App Registrations hold credentials, what expires when, and who owns each item. An auditor who asks “how many secrets do you hold with no expiry date set?” expects a number, not a shrug. This is where most Azure estates fail first, because the honest answer requires enumerating every Key Vault across every subscription and every credential in Entra ID.

2. The policy. A written statement of validity periods (how long a secret or certificate may live), approved algorithms and key lengths, storage requirements (secrets live in Key Vault, not in app settings or pipelines), and who may issue and revoke. It does not need to be long. It needs to be true, which is the hard part: a policy that says “secrets rotate every 90 days” while the estate holds three-year-old credentials is worse in an audit than no policy at all.

3. The rotation evidence. Proof the policy operates: rotation logs with timestamps and actors, alerts that fired before expiry, and what happened when they did. Auditors ask for samples: “show me the last five rotations of production credentials.” An append-only audit trail answers this in minutes; reconstructing it from Azure activity logs after the fact takes days.

4. The exception list. The credentials that do not comply and why, with owners and remediation dates. Every real estate has these. Presenting them yourself, tracked and dated, reads as a functioning control. Having the auditor find them reads as the absence of one.

Producing the Evidence From an Azure Estate

Working backwards from those four artefacts:

Start with the inventory, because everything else depends on it. A point-in-time scan is the fastest way to establish the baseline. Our free CLI scanner enumerates every Key Vault secret, certificate and key across all your subscriptions in a couple of minutes, read-only, using your existing Azure CLI session, and never touching secret values:

pip install certifyclouds
az login
cc-scan --format html

The HTML report is itself a dateable audit artefact: total assets, expiry status, and 11 security findings (secrets with no expiry date, expired credentials still enabled, vaults without purge protection). Details on the scanner page.

Write the policy against what the inventory shows, not against an ideal. Set validity periods you can actually operate: 90 or 180 days for App Registration secrets, a year for internal certificates, whatever SC-081 now forces for public TLS. Then close the gap between policy and reality item by item, keeping the exception list as you go.

Make the evidence continuous rather than annual. A scan the week before the audit proves the week before the audit. Continuous discovery, expiry alerting at 90/30/7 days, automated rotation for App Registration credentials, and an append-only audit log are what turn Article 21(2)(h) from an annual scramble into a standing capability; this is exactly the evidence set CertifyClouds produces, deployed inside your own environment, which matters for the data-residency questions that come with the same audit.

Honest Caveats

Transposition is uneven. Some member states enacted on time, several were referred to the Court of Justice for delay, and national laws differ in registration duties, reporting portals and enforcement style. What does not vary is Article 21’s minimum measure list, which every national law implements. Build the four artefacts above and you are audit-ready in any member state; wait for your specific regulator to publish sector guidance and you are betting the timeline on someone else’s calendar.

The other caveat: NIS2 does not say “buy a secret management product.” It says have policies and procedures for cryptography and be able to demonstrate they operate. A team that can produce the inventory, the policy, the rotation evidence and the exception list from scripts and discipline complies just as well. The question to ask is only whether that discipline survives contact with dozens of vaults, hundreds of credentials and the engineer who leaves in November.

Further Reading