Creating a Cryptography Policy: Algorithms, Key Lengths, and Lifecycle

Why Cryptography Needs Its Own Policy

Encryption is everywhere: in email communication, in data transmission between systems, on hard drives, in VPN tunnels, in authentication. Yet most companies regulate cryptographic methods at best implicitly. The web server uses TLS because the admin set it up that way. Disk encryption runs with BitLocker because Microsoft includes it. And passwords are hashed because the framework does it automatically.

This works as long as nobody asks: which algorithms exactly? With what key lengths? Who generated the keys, and where are they stored? What happens when an algorithm is classified as insecure? How often are keys rotated?

This is exactly where the cryptography policy comes in. It answers these questions bindingly for the entire company and ensures that cryptographic decisions are not left to chance or the individual preferences of individual administrators.

NIS2 Minimum Measure No. 8: What the Law Requires

Article 21(2) of the NIS2 Directive lists ten minimum measures that affected companies must implement. Number 8 reads: "policies and procedures regarding the use of cryptography and, where appropriate, encryption."

That sounds brief but carries significant weight. The wording "policies and procedures" means you not only need to encrypt technically, but you also need to document the principles by which you do so. An auditor will ask for the policy, not the technical configuration. The latter must of course also be correct, but without a documented policy, there's no evidence that you're making the right decisions systematically rather than by chance.

ISO 27001 also addresses the topic. Control A.8.24 "Use of cryptography" requires rules for the effective use of cryptography, including the management of cryptographic keys. If you operate an ISMS under ISO 27001 and also want to comply with NIS2, a solid cryptography policy covers both requirements.

What the Cryptography Policy Must Regulate

Before you start writing, it helps to look at the areas a complete cryptography policy should cover. Each of these areas is detailed in the following sections.

Scope and classification: Which data and systems does the policy apply to? Which data must be encrypted?

Approved algorithms: Which symmetric and asymmetric methods are permitted? Which hash functions may be used?

Prohibited algorithms: Which methods may no longer be used? How are legacy systems handled?

Minimum key lengths: What key lengths are required for each algorithm?

Key management: How are keys generated, stored, distributed, rotated, and destroyed?

Transport encryption: What's the minimum TLS version? Which cipher suites are permitted?

Storage encryption: How is data at rest protected?

Responsibilities: Who decides on cryptographic standards? Who implements them?

Exceptions and migration: How do you handle legacy systems that can't meet the standards?

Recommended Algorithms and Key Lengths

Here's where it gets concrete. The following overview is based on BSI recommendations (Technical Guideline TR-02102) and NIST.

Symmetric Encryption

AES (Advanced Encryption Standard) is the standard for symmetric encryption and will remain so for the foreseeable future. AES-256 should be the default in your policy. AES-128 is technically secure and may be permitted for use cases with lower protection requirements, but AES-256 gives you a comfortable security buffer and is barely slower with modern hardware.

For the mode of operation, GCM (Galois/Counter Mode) is the preferred choice because it simultaneously ensures confidentiality and integrity (Authenticated Encryption). CBC (Cipher Block Chaining) remains acceptable but must be combined with a separate MAC. ECB (Electronic Codebook) is fundamentally prohibited because it encrypts identical plaintext blocks into identical ciphertext blocks, leaving patterns in the plaintext visible.

ChaCha20-Poly1305 is a good alternative to AES-GCM, particularly on devices without AES hardware acceleration (older mobile devices, IoT devices).

Asymmetric Encryption and Key Exchange

RSA remains a broadly supported standard. The minimum key length should be 2048 bits; for keys with a lifetime beyond 2025, BSI recommends at least 3072 bits. RSA-4096 provides additional headroom and is unproblematic in most implementations.

For padding, RSA-OAEP (Optimal Asymmetric Encryption Padding) is mandatory. The older PKCS#1 v1.5 padding has known vulnerabilities (Bleichenbacher attack) and must no longer be used.

Elliptic Curve Cryptography (ECC) offers comparable security levels to RSA with shorter key lengths. Curve25519 (X25519 for key exchange, Ed25519 for signatures) is the recommended curve because it was developed by an independent cryptographer (Daniel Bernstein), is designed to be side-channel resistant, and has broad support in modern libraries.

The NIST curves P-256, P-384, and P-521 are also permitted and in some regulated environments even required. P-256 corresponds in security roughly to RSA-3072.

For key exchange, ECDH (Elliptic-Curve Diffie-Hellman) with ephemeral keys should be used. Ephemeral keys ensure Forward Secrecy: even if the long-term private key is compromised, past sessions cannot be decrypted.

Hash Functions

SHA-256 is the minimum standard for all hash applications. SHA-384 and SHA-512 are also permitted and suitable for high protection requirements. SHA-3 (Keccak) is an alternative based on an entirely different mathematical principle than SHA-2, but is less widely adopted in practice.

Different rules apply for password hashing. Here, specialized functions are required: Argon2id is the current recommendation (winner of the Password Hashing Competition). bcrypt remains acceptable when Argon2 is unavailable. scrypt is also permitted. What must never be used for passwords, even with a salt: plain SHA-256, MD5, or SHA-1.

Digital Signatures

For digital signatures, the same key lengths apply as for encryption. RSA-PSS is the recommended signature scheme (not RSA-PKCS#1 v1.5). Ed25519 is the preferred choice for modern applications because signatures are small, verification is fast, and the implementation is robust against side-channel attacks.

Deprecated: These Algorithms Must Go

Just as important as the list of approved methods is the explicit list of prohibited algorithms. Cryptography ages, and what was secure 15 years ago no longer is today.

DES (Data Encryption Standard): Known to be insecure since the 1990s, with only a 56-bit key length. Can be broken in a few hours with modern hardware. Must be disabled in every system.

3DES (Triple DES): Was intended as a transitional method and served its purpose. Classified as deprecated by NIST since 2023. Effective security is only 112 bits (instead of the theoretical 168 bits), and the Sweet32 attack demonstrated that the short block length is a real problem. Migration to AES is mandatory.

MD5: Collision attacks have been practically feasible since 2004. MD5 must not be used for digital signatures or integrity checks of security-relevant data. The only still-acceptable use is non-cryptographic deduplication, but even there you should prefer xxHash or BLAKE3.

SHA-1: Collision attacks were practically demonstrated in 2017 by Google (SHAttered). CAs have not issued SHA-1 certificates since 2016. SHA-1 must be removed from all security-relevant applications.

RC4: Already prohibited for TLS by RFC 7465 in 2015. Statistical weaknesses in key stream generation make RC4 unsuitable for any cryptographic application.

For legacy systems that still use these algorithms, the policy must provide for a migration plan. This means: an inventory of all systems with deprecated cryptography, a risk assessment for each system, and a timeline for migration. Systems that cannot be migrated need compensating controls such as network segmentation or enhanced monitoring.

Key Management: The Entire Lifecycle

The best algorithms are useless if keys are poorly managed. A compromised key invalidates the entire encryption. Key management is therefore the core of any cryptography policy.

Key Generation

Cryptographic keys must be generated using a cryptographically secure random number generator (CSPRNG). This sounds obvious but is a frequent source of errors in practice. The policy should stipulate that keys are generated exclusively through approved tools and libraries. Examples include /dev/urandom on Linux, CryptGenRandom on Windows, or the respective standard libraries of the programming language (e.g., secrets in Python, crypto/rand in Go).

Manual key generation by entering passwords is only acceptable when a Key Derivation Function (KDF) like PBKDF2, scrypt, or Argon2 with sufficient iterations is used.

For highly critical keys, such as CA root keys or master keys of a key management system, generation should occur in a Hardware Security Module (HSM) or at least on an air-gapped system with a four-eyes principle.

Key Storage

The private key is the crown jewel. The policy must specify where and how keys may be stored. Plaintext keys in configuration files, source code, or databases are fundamentally prohibited. This also applies to environment variables, which are often falsely considered "secure" but can appear in logs, crash dumps, and container inspections.

Suitable storage options include: Hardware Security Modules (HSMs) that never make keys extractable in software; key management systems like HashiCorp Vault, AWS KMS, or Azure Key Vault; encrypted keystores like Java KeyStore (JKS) or PKCS#12, though the password for the keystore itself must again be securely stored.

Access to keys must be governed by the least-privilege principle. Only the services and persons who actually need a key may have access. Every access should be logged.

Key Rotation

Keys have a limited lifespan. The policy should define rotation intervals, graduated by key type and criticality. As a guide: TLS certificates are renewed annually, with Let's Encrypt even every 90 days. API keys and tokens should be rotated at least annually, more frequently for high protection requirements. Symmetric data encryption keys are typically rotated annually, with key wrapping simplifying migration. Disk encryption keys are rotated upon personnel changes or suspected compromise.

Automated rotation is preferable to manual rotation because it's more reliable and avoids downtime. The policy should stipulate that new systems are planned with automated key rotation from the start.

Key Destruction

When a key is no longer needed or has been compromised, it must be securely destroyed. Secure deletion doesn't mean "delete the file" — it means overwriting the storage area with random data and subsequent verification. For HSMs, the devices offer their own deletion functions. Backups of the key must also be destroyed, including on offline media.

The policy should also specify how long old keys must be retained for decrypting archived data. If encrypted data has a retention period of ten years, the decryption key must also be securely stored for ten years, even if it's no longer used for new encryption.

Emergency Procedures for Compromise

In case a key is compromised, the policy must define a clear process: immediate revocation of the compromised key, generation of a new key, assessment of the damage (what data was affected?), reissuance of affected certificates, and notification of affected communication partners. These steps should be documented in advance rather than developed during an actual incident, and should be practiced at least once a year.

Transport Encryption: Configuring TLS Correctly

Transport encryption affects virtually every company, as nearly all systems communicate via HTTPS, SMTPS, IMAPS, or other TLS-secured protocols.

Minimum TLS Version

TLS 1.2 is the absolute minimum version. TLS 1.0 and 1.1 have been officially deprecated since RFC 8996 (March 2021) and must be disabled. SSL in all versions (SSLv2, SSLv3) is of course prohibited.

TLS 1.3 should be the standard for all new implementations. It offers significant improvements: the handshake is faster (1-RTT instead of 2-RTT), insecure cipher suites have been removed (no RSA key exchange, no CBC, no RC4), and Forward Secrecy is mandatory.

Cipher Suites

Not all cipher suites in TLS 1.2 are equally secure. The policy should define an allowlist. Recommended cipher suites for TLS 1.2 include ECDHE-based suites with AES-GCM or ChaCha20-Poly1305, such as TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.

Prohibited are cipher suites with static RSA key exchange (no Forward Secrecy), suites with NULL encryption, suites with DES, 3DES, or RC4, suites with MD5, export cipher suites (intentionally weakened), and anonymous DH suites (no certificate, susceptible to MITM).

In TLS 1.3, cipher suite configuration is less complex because the protocol only allows secure options. The three default suites (TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256) are all recommended.

Certificate Management

The policy should also regulate the management of TLS certificates: minimum key length for certificates (RSA-2048, preferably RSA-3072 or ECDSA P-256), use of trusted CAs (no self-signed certificates in production environments), automated renewal (ACME protocol, Let's Encrypt), and monitoring of certificate expiration dates.

Practical Example: Outline of a Cryptography Policy

To conclude, here's an outline you can use as a starting point for your own policy. The structure is deliberately designed to cover both NIS2 and ISO 27001 A.8.24.

1. Purpose and Scope Describes why the policy exists and which systems, data, and persons it applies to. Typically, it applies to all IT systems and data of the company, including cloud services and third-party systems that process company data.

2. Definitions Explains the most important technical terms (symmetric/asymmetric encryption, hashing, key pair, Forward Secrecy) so that non-cryptographers can also understand the policy.

3. Data Classification and Encryption Obligations Defines which data classes must be encrypted. For example: confidential and strictly confidential data must be encrypted during transmission and storage. Internal data must be encrypted during transmission over public networks. Public data is not subject to encryption requirements.

4. Approved Algorithms and Minimum Key Lengths Tabular overview of permitted algorithms with minimum key lengths, organized by symmetric encryption, asymmetric encryption, hashing, and password hashing.

5. Prohibited Algorithms Explicit list of prohibited methods with justification and migration timeline for legacy systems.

6. Key Management Rules for the entire lifecycle: generation, storage, distribution, rotation, archiving, and destruction. Including responsibilities and access controls.

7. Transport Encryption Minimum TLS version, permitted cipher suites, certificate management, HSTS configuration.

8. Storage Encryption Rules for full disk encryption, database encryption, backup encryption, and encryption in the cloud.

9. Responsibilities Who maintains the policy? Who approves exceptions? Who verifies compliance? Typically: the ISO maintains the policy, IT implements it, and internal audits verify compliance.

10. Exceptions Procedures for handling systems that cannot meet the policy. Every exception must be documented, risk-assessed, and time-limited.

11. Review and Updates The policy is reviewed at least annually and updated on an ad-hoc basis when new weaknesses in cryptographic methods are discovered.

Common Pitfalls in Practice

The same problems repeatedly surface from audits and consulting projects — issues you can address directly when creating your policy.

Policy without an inventory. You can't enforce cryptographic standards if you don't know where cryptography is used. An up-to-date IT asset inventory is the prerequisite. Before the policy comes the assessment: which systems encrypt what, with which algorithms and key lengths?

Deprecated algorithms in legacy systems. Almost every company has some old system still using 3DES or SHA-1. The policy must handle this honestly: not prohibit and ignore, but document, assess the risk, and create a migration plan.

Keys in source code. Developers regularly commit API keys, certificates, or passwords to Git repositories. The policy should reference pre-commit hooks and secret scanning tools that automatically prevent this.

Missing rotation. Many companies generate keys once and then forget them. The policy must define clear rotation intervals and monitor compliance, ideally in an automated fashion.

No emergency procedure. When a private key is compromised and nobody knows what to do, valuable hours are lost. The emergency procedure should be concrete enough that the responsible person can follow it at three in the morning.

Post-Quantum Cryptography: Prepare Now?

A topic of increasing relevance is how quantum computers will affect today's cryptographic methods. RSA and ECC are based on mathematical problems (factorization and discrete logarithm) that a sufficiently powerful quantum computer could solve with Shor's algorithm.

NIST standardized the first post-quantum algorithms in 2024: ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation and ML-DSA (formerly CRYSTALS-Dilithium) for digital signatures. For most companies, immediate migration is neither necessary nor practical, as library support is still incomplete.

What you can do now: the cryptography policy should contain a section making it the ISO's responsibility to monitor post-quantum developments. Additionally, data with a long lifespan that is encrypted and stored today and must remain confidential in ten or twenty years deserves special attention. An attacker could intercept encrypted data today and decrypt it in the future with a quantum computer (harvest now, decrypt later).

Hybrid approaches combining classical and post-quantum algorithms offer a transitional solution. TLS 1.3 already supports hybrid key exchange mechanisms such as X25519Kyber768Draft00.

From Policy to Implementation

A cryptography policy is only as good as its implementation. After creating the policy, three tasks lie ahead.

First, the assessment: inventory all systems that use cryptography and compare them against the policy requirements. Where are there deviations? Where are prohibited algorithms being used? Where is key rotation missing?

Second, technical hardening: implement the requirements on the systems. Adjust TLS configurations, restrict cipher suites, automate key rotation, set up secret scanning.

Third, monitoring: continuously monitor compliance. Tools like SSL Labs, testssl.sh, or Mozilla Observatory can check the TLS configuration of external endpoints. Internal scans should be conducted regularly and the results documented.

The policy itself should be reviewed at least annually and updated as needed. ISMS Lite automatically reminds you of due policy reviews and documents the entire policy lifecycle from creation to retirement. Triggers for unscheduled reviews include new BSI or NIST recommendations, discovered weaknesses in approved algorithms, and significant changes to the IT infrastructure.

Cryptography is not a topic you address once and then forget. It's a living part of your ISMS that deserves continuous attention because the threat landscape and technical capabilities are constantly evolving.

Further Reading

• Encryption in the Enterprise: What You Really Need to Implement
• NIS2 for Mid-Market Companies: What You Need to Know and What to Do Now
• Creating an Information Security Policy: Structure, Content, and Practice
• Protection Needs Assessment: Systematically Evaluating What Needs Protection
• ISMS Documentation Overview: What You Really Need