NIS2Shield
Enterprise Compliance Infrastructure
Cryptographic Specification
Version 1.0.0 • January 2026
1. Executive Summary
This document provides a comprehensive specification of the cryptographic algorithms,
key management practices, and security configurations used in NIS2 Shield. All cryptographic
implementations follow industry best practices and comply with NIS2 Directive Article 21.2.f
requirements for cryptography policies.
Symmetric
AES-256
GCM Mode
Asymmetric
RSA-2048
OAEP-SHA256
Transport
TLS 1.2+
Required
Design Principles
- ✓ Defense in Depth: Multiple
encryption layers
- ✓ Zero-Trust: Private keys never in
cloud
- ✓ Forward Secrecy: Unique session
keys per message
- ✓ Audit Ready: All operations logged
with HMAC integrity
2. Algorithm Overview
NIS2 Shield uses a combination of symmetric and asymmetric encryption to provide both
performance and security. The following table summarizes all cryptographic components.
| Component |
Algorithm |
Key Size |
Mode |
Purpose |
| Log field encryption |
AES |
128-bit |
Fernet (CBC+HMAC) |
PII protection in logs |
| Cloud backup payload |
AES |
256-bit |
GCM |
Data confidentiality |
| Cloud backup key wrap |
RSA |
2048-bit |
OAEP-SHA256 |
Session key protection |
| Log signing |
HMAC |
256-bit |
SHA-256 |
Integrity verification |
| Password hashing |
Argon2id |
N/A |
OWASP recommended |
Credential storage |
3. Hybrid Encryption (Zero-Trust)
NIS2 Shield implements a hybrid encryption scheme for cloud backups that ensures
data remains encrypted even if the cloud provider is compromised. The private key
never leaves the customer's secure environment.
3.1 Encryption Flow
Plaintext
→
Generate Session Key
(CSPRNG 256-bit)
→
AES-256-GCM Encrypt
↓
RSA-OAEP
Wrap Session Key
↓
Encrypted Envelope
(JSON)
{ encrypted_data, encrypted_key, iv, tag, key_id }
3.2 Security Properties
-
✓
Forward Secrecy: Each message uses a unique randomly-generated
session key. Compromise of one key does not affect other messages.
-
✓
Authenticated Encryption: AES-GCM provides both confidentiality
and integrity. Any tampering is detected during decryption.
-
✓
Zero-Trust Cloud: The RSA private key is kept offline. The cloud
provider cannot decrypt data even with full system access.
-
✓
Key Rotation: The key_id field enables decryption with historical
keys after rotation. Old data remains accessible.
4. Key Management
RSA Key Pair
Public Key
In container
Private Key
OFFLINE only
Rotation
Annual
Storage
HSM recommended
Session Keys
Generation
CSPRNG
Lifetime
Single message
Storage
Wrapped in envelope
Length
256 bits
4.1 Key Generation Commands
openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -pubout -out public.pem
openssl rsa -in private.pem -check
python -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"
python -c "import secrets; print(secrets.token_hex(32))"
5. TLS Requirements
All network communications in NIS2 Shield require TLS encryption. The following
table specifies the minimum TLS version for each connection type.
| Connection |
Protocol |
Min Version |
Cipher Suites |
| HTTPS (Ingress) |
TLS |
1.2 |
ECDHE+AESGCM, DHE+AESGCM |
| Database (PostgreSQL) |
TLS |
1.2 |
Server default |
| SIEM forwarding |
TLS |
1.2 |
Mutual TLS supported |
| Cloud backup API |
TLS |
1.2 |
Cloudflare managed |
| Inter-service (K8s) |
mTLS |
1.3 |
Service mesh (optional) |
Certificate Management
NIS2 Shield supports automatic certificate management via cert-manager for Kubernetes
deployments. For Docker Compose, certificates should be provisioned via Let's Encrypt
or your organization's PKI.
6. Standards Compliance
All cryptographic implementations in NIS2 Shield comply with the following standards
and regulations.
NIST SP 800-38D
GCM Mode ✓
NIST SP 800-57
Key Management ✓
FIPS 140-2
Approved Algorithms ✓
NIS2 Art. 21.2.f
Cryptography Policies ✓
GDPR Art. 32
Encryption at Rest ✓
PCI DSS 4.0
Strong Cryptography ✓
7. Certification Statement
This document certifies that the NIS2 Shield cryptographic implementation follows
the specifications described above. All algorithms, key sizes, and modes meet or
exceed industry standards for enterprise security.
Document Version: 1.0.0
Effective Date: January 2026
Review Schedule: Annual or upon significant changes
Classification: Public