NIS2 is a directive that in many organizations has been perceived primarily as a procedural requirement: policies, registers, classifications, audits. Meanwhile, its real impact is much deeper – true compliance begins only at the level of cryptography. This is where the directive expects proof that the organization understands modern threats and can maintain technical security at a “state of the art” level.

Why?
Because TLS, certificates, keys, and encryption protocols are the direct line of contact between the organization and its users, partners, customers, and internal systems. If this layer is weak, no documentation will protect the organization from an incident – let alone from regulatory liability. NIS2 does not explicitly say “use TLS 1.3,” but the end result is clear: companies must demonstrate that their cryptography matches the current threat landscape.

SSL/TLS as a compliance component, not a server configuration.

In many companies, SSL/TLS is something that “someone configured at some point.” The certificate was installed, communication works, the padlock is there – end of story. NIS2 reverses this logic: SSL/TLS stops being a technical afterthought and becomes a measure of operational maturity. This means an ongoing need to monitor, maintain, and verify whether configurations:

• do not rely on outdated algorithms,
• are fully aligned with current industry recommendations,
• provide adequate resistance to modern threats,
• are future-proof – because NIS2 also looks ahead.

Importantly – compliance is not binary. An auditor is not looking for a list of enabled protocols but for evidence that the company has a process and control over its cryptography.

Minimum SSL/TLS profile for NIS2.

Organizations often ask: “what SSL/TLS profile is compliant with NIS2?” There is no single official template, but there is what can be called a market baseline derived from CA/B Forum, BSI, ENISA, OWASP, and financial-sector best practices.

A minimum set that can be reasonably defended during an audit:

• TLS 1.3 as the primary protocol, with TLS 1.2 allowed only for compatibility.
• Disabling TLS 1.0-1.1 because they are not resistant to modern attacks.
• AEAD algorithms (AES-GCM, ChaCha20-Poly1305), as they ensure integrity and confidentiality.
• RSA 3072+ bits or ECDSA P-256/P-384, since shorter keys are practically indefensible.
• No SHA-1 anywhere in the chain – including intermediates.
• Mandatory SAN, because CN has been ignored by browsers for years.

Notice that each of these items has a clear justification. A NIS2 auditor does not ask “what’s enabled?” but rather:

• “why?”
• “how do you monitor it?”
• “can you change it tomorrow if ENISA issues a new recommendation?”

TLS/PKI inventory – the foundation without which compliance collapses.

NIS2 requires organizations to have full awareness of what operates within their environment. For SSL/TLS this means identifying not just public-facing websites but all encrypted communications, including:

• internal and external APIs,
• microservices,
• partner integrations,
• B2B platforms,
• administrative panels,
• tunnels and communication brokers,
• legacy services that “nobody remembers.”

A complete PKI/TLS map allows organizations to:

• detect risky configurations,
• control certificate expiration,
• assess which systems require urgent remediation,
• prepare a realistic migration plan.

This step cannot be skipped – without it, every organization operates “blind.”

Certificate management: under NIS2, the process matters more than the tool.

Companies often focus on whether they use ACME, whether certificates are monitored, or whether a renewal panel exists. This is important, but NIS2 goes deeper – it requires evidence that the organization maintains control over the entire lifecycle of keys and certificates.

A mature process should therefore include:

• a register of all certificates,
• monitoring for expiration, chain issues, and misconfigurations,
• a usage policy (when wildcard, when EV, when internal certs),
• automation where human error introduces the highest risk,
• regular TLS configuration reviews.

This is no longer “good practice” – it is a compliance requirement.

Private keys – the section NIS2 auditors will scrutinize the most.

No PKI element is as critical as the private key. NIS2 treats its protection as an absolute cornerstone because compromise means:

• domain identity takeover,
• real-time MITM attack potential,
• loss of trust from partners and regulators,
• a mandatory incident report,
• financial and operational consequences.

Therefore, organizations must demonstrate:

• where keys are generated,
• how they are stored,
• what permissions they have,
• how rotation works,
• who has access rights,
• what mechanisms detect unauthorized use.

There is no room for half-measures here – auditors check this section first.

Crypto agility and PQC – NIS2 looks to the future more than any previous regulation.

This is where things get interesting. NIS2 does not yet require post-quantum certificates, but it requires organizations to plan security years ahead – not months.

This means considering:

• resistance to “harvest now, decrypt later”,
• migration plans toward ECDHE + ML-KEM (hybrid SSL/TLS),
• timelines for implementing PQTLS in high-sensitivity systems,
• alignment with roadmaps of CAs, CDNs, and cloud providers,
• infrastructure readiness (OpenSSL 3.x, PQC-capable TLS libraries).

Crypto agility – the ability to quickly replace algorithms – becomes one of the key compliance requirements.

A practical NIS2 action plan.

The organizations with the best results adopt a five-stage model:

1. Discovery: Full TLS/PKI map, all endpoints, all certificates, all encrypted communication.
2. Assessment: Risk analysis, key lengths, protocols, chains, configurations.
3. Baseline: A unified TLS profile enforced across the entire organization.
4. Automation: ACME, CA APIs, key rotation, configuration monitoring, expiration monitoring.
5. Modernization (PQC Ready): A roadmap for ECDHE + ML-KEM, preparation for PQTLS and hybrid certificates.

This is exactly what NIS2 expects – regardless of company size.

Most common organizational mistakes.

These are not theoretical errors – they are real cases that resulted in negative compliance outcomes:

• focusing on documentation instead of server configuration,
• ignoring APIs and internal services running on TLS 1.0/1.1,
• lack of certificate automation and recurring expiration incidents,
• private keys stored in server directories,
• no cryptographic strategy for the next 5 years,
• complete blindness to PQC and HNDL threats.

Each of these points undermines compliance.

You may have exemplary procedures, risk assessments, and security policies – but if TLS, certificates, and keys are neglected, the NIS2 audit will expose it. Cryptography becomes the proof of whether an organization truly maintains security or merely claims to. NIS2 is not exaggerating – it simply requires cryptography to be taken seriously. And that means:

• mature SSL/TLS,
• secure keys,
• automation,
• monitoring,
• crypto agility,
• PQC readiness.