NIS2 Directive and Cryptography: What EU Organizations Must Know

The NIS2 Directive (Network and Information Security Directive 2) is the EU’s most significant cybersecurity legislation. It replaced the original NIS Directive in January 2023, with member states required to transpose it into national law by October 17, 2024. It dramatically expands the scope of organizations covered and strengthens the security requirements — including explicit mandates for cryptography and encryption.

If your organization operates in the EU, provides services to EU entities, or is part of the supply chain of an EU essential/important entity, NIS2 likely applies to you.

---

Who’s Affected

NIS2 covers two categories:

Essential Entities (Strictest Requirements)

• Energy (electricity, oil, gas, hydrogen)
• Transport (air, rail, water, road)
• Banking and financial market infrastructure
• Healthcare (hospitals, labs, pharma, medical devices)
• Drinking water and wastewater
• Digital infrastructure (DNS, TLD registries, cloud providers, data centers, CDNs)
• ICT service management (managed service providers, managed security providers)
• Public administration
• Space

Important Entities (Slightly Lighter Requirements)

• Postal and courier services
• Waste management
• Chemical manufacturing
• Food production and distribution
• Manufacturing (medical devices, electronics, machinery, vehicles)
• Digital providers (online marketplaces, search engines, social networks)
• Research organizations

Size Threshold

Generally applies to: medium enterprises (50+ employees OR €10M+ turnover) and large enterprises. But some sectors have no size threshold (DNS, TLD registries, cloud providers are covered regardless of size).

---

Cryptography Requirements in NIS2

Article 21: Cybersecurity Risk-Management Measures

NIS2 Article 21(2) lists minimum security measures that covered entities must implement. Several directly involve cryptography:

Article 21(2)(e): Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure

• Secure development practices (code signing, integrity verification)
• Vulnerability management (patching cryptographic libraries)

Article 21(2)(h): Policies and procedures regarding the use of cryptography and, where appropriate, encryption

• Documented cryptography policy
• Encryption for data in transit and at rest
• Key management procedures
• Algorithm selection and lifecycle

Article 21(2)(i): Human resources security, access control policies and asset management

• Certificate-based authentication
• Machine identity management
• PKI for access control

Article 21(2)(j): The use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems

• Certificate-based MFA
• Encrypted communications (TLS, mTLS)
• Secure internal communications

What “Policies and Procedures Regarding Cryptography” Means

NIS2 doesn’t prescribe specific algorithms (unlike PCI DSS or CNSA 2.0). Instead, it requires you to have documented policies covering:

1. Algorithm selection: Which algorithms are approved for use? Which are prohibited?
2. Key management: How are keys generated, stored, rotated, and destroyed?
3. Encryption scope: What data must be encrypted (at rest, in transit, in use)?
4. Certificate management: How are certificates issued, monitored, and renewed?
5. Crypto-agility: How will you respond to algorithm deprecation or compromise?
6. Incident response: What happens when a key is compromised?

---

Practical Implementation

Step 1: Cryptography Policy Document

Create a formal policy covering:

# Cryptography Policy

## 1. Approved Algorithms
- Symmetric encryption: AES-256 (minimum AES-128)
- Asymmetric encryption: ECDSA P-256+, RSA-3072+ (RSA-2048 acceptable until 2030)
- Hashing: SHA-256, SHA-384, SHA-512
- Key exchange: ECDHE (X25519, P-256), DHE-3072+
- TLS: Version 1.2 minimum, 1.3 preferred
- Prohibited: MD5, SHA-1, DES, 3DES, RC4, TLS 1.0/1.1

## 2. Encryption Requirements
- Data in transit: TLS 1.2+ for all network communications
- Data at rest: AES-256 for databases, file storage, backups
- Email: TLS enforced for business communications
- Remote access: VPN with strong encryption or zero-trust with mTLS

## 3. Key Management
- Generation: CSPRNG or HSM (FIPS 140-2 Level 2+ for critical keys)
- Storage: KMS/HSM (never plaintext in config files)
- Rotation: Annual for encryption keys, per certificate validity for TLS
- Destruction: Documented zeroization when no longer needed
- Access: Minimum necessary, logged, reviewed quarterly

## 4. Certificate Management
- Inventory: All certificates tracked with owner and expiry
- Monitoring: Alert at 60, 30, 7 days before expiry
- Automation: ACME/cert-manager for renewal where possible
- Revocation: Procedure for emergency certificate revocation

## 5. Crypto-Agility
- Inventory: CBOM maintained (all algorithms, keys, certificates)
- Migration plan: Post-quantum readiness assessment completed
- Testing: PQC algorithms tested in non-production annually
- Timeline: Full PQC migration planned for 2028-2033

Step 2: Implement Technical Controls

Data in Transit:
├── TLS 1.2+ on all services (internal and external)
├── mTLS for service-to-service communication
├── VPN or zero-trust for remote access
├── Certificate monitoring and automated renewal
└── Cipher suite hardening (AEAD only, forward secrecy)

Data at Rest:
├── Full disk encryption on all endpoints
├── Database encryption (TDE or column-level)
├── Cloud storage encryption (CMEK where possible)
├── Backup encryption (separate key from primary data)
└── Removable media encryption or prohibition

Key Management:
├── Centralized KMS (cloud KMS or on-premises HSM)
├── Automated key rotation
├── Separation of duties (key admin ≠ data admin)
├── Audit logging of all key operations
└── Documented destruction procedures

Certificate Lifecycle:
├── Complete certificate inventory
├── Automated renewal (ACME, cert-manager)
├── Expiry monitoring with escalation
├── Ownership mapping (every cert has an owner)
└── Incident response for certificate compromise

Step 3: Supply Chain Cryptography

NIS2 explicitly addresses supply chain security (Article 21(2)(d)). For cryptography, this means:

• Verify vendor encryption: Do your suppliers encrypt data in transit and at rest?
• Certificate management in contracts: Require vendors to maintain valid certificates and report expiry risks
• Code signing verification: Verify signatures on all third-party software before deployment
• Key management in SLAs: Define key management responsibilities in vendor contracts

---

Penalties for Non-Compliance

NIS2 introduces significant penalties:

Entity Type	Maximum Fine
Essential entities	€10M or 2% of global annual turnover (whichever is higher)
Important entities	€7M or 1.4% of global annual turnover (whichever is higher)

Additionally:

• Management bodies can be held personally liable
• Temporary suspension of certifications or authorizations
• Temporary ban from exercising managerial functions
• Public disclosure of non-compliance

---

NIS2 vs Other Frameworks

Requirement	NIS2	PCI DSS 4.0	HIPAA	GDPR
Encryption policy required	✅	✅	✅ (addressable)	✅ (appropriate measures)
Specific algorithms mandated	❌ (policy-based)	⚠️ (strong crypto)	❌	❌
Key management documented	✅	✅	✅	❌ (implied)
Certificate inventory	✅ (implied by asset mgmt)	✅ (explicit)	❌	❌
Incident reporting	24h initial, 72h full	Immediate to acquirer	60 days to HHS	72h to DPA
Supply chain security	✅ (explicit)	✅ (service providers)	✅ (BAAs)	✅ (processors)
Crypto-agility/PQC	❌ (not yet)	❌	❌	❌
Personal liability	✅ (management)	❌	❌	✅ (DPO role)

---

Timeline and Preparation

January 2023: NIS2 entered into force (EU level)
October 2024: Member states must transpose into national law
October 2024+: Enforcement begins (varies by member state)
2025-2026: First audits and compliance checks expected

Your preparation timeline:
├── NOW: Gap assessment against NIS2 requirements
├── Month 1-2: Cryptography policy documentation
├── Month 2-4: Technical control implementation
├── Month 4-6: Supply chain assessment
├── Month 6+: Ongoing compliance monitoring
└── Continuous: Incident response readiness

---

FAQ

Q: Does NIS2 apply to non-EU companies? A: If you provide services to EU entities or are part of the supply chain of a covered entity, NIS2 requirements may flow down to you through contractual obligations. The directive itself applies to entities operating in the EU, but supply chain provisions extend the reach.

Q: Is NIS2 more demanding than GDPR for encryption? A: NIS2 is more specific about cybersecurity measures (including cryptography) than GDPR. GDPR says “appropriate technical measures.” NIS2 says “policies and procedures regarding cryptography” — explicitly requiring documented crypto policies, not just encryption implementation.

Q: Do I need post-quantum readiness for NIS2? A: Not explicitly required yet. But NIS2’s crypto-agility expectation (ability to respond to algorithm deprecation) implies you should be planning for PQC. ENISA (EU cybersecurity agency) has published PQC guidance that NIS2 auditors may reference.

Q: What’s the relationship between NIS2 and DORA? A: DORA (Digital Operational Resilience Act) is sector-specific for financial services. If you’re a financial entity, DORA applies (and is more specific than NIS2 for your sector). NIS2 is the general framework; DORA is the financial services overlay. Both require cryptography controls.

Q: How will NIS2 be audited? A: Member states designate competent authorities (like national cybersecurity agencies). They can: request evidence of compliance, conduct audits, issue binding instructions, and impose fines. The audit approach varies by country — some will be proactive (regular audits), others reactive (after incidents).