Encryption in the Enterprise: What, Where, and How to Encrypt

TL;DR

NIS2 Article 21, Paragraph 2h lists concepts for the use of cryptography and, where appropriate, encryption as one of the ten minimum measures -- organizations must document what they encrypt and why.
Encryption falls into three areas: data at rest (hard drives, databases, backups), data in transit (TLS, VPN, email), and data in use (the most difficult area and least relevant for SMEs).
AES-256 for symmetric encryption, RSA with at least 2048 bits or Elliptic Curve Cryptography (ECDSA/ECDH) for asymmetric encryption, and SHA-256 or SHA-3 for hashing are the current minimum standards.
Key management is the real core problem: who creates keys, where are they stored, how are they rotated, and what happens if they are lost? Without proper key management, encryption is worthless.
A cryptography policy documents the company's encryption standards, specifies prohibited algorithms, and governs the handling of key material -- a mandatory document for every ISMS.

Why encryption is no longer an optional feature

Encryption is one of those topics where most IT leaders nod and say: yes, we do that. HTTPS is enabled, hard drives are encrypted, all good. And in many cases that is true -- at least on the surface. But when an auditor or supervisory authority probes deeper -- asking about the encryption strategy, which algorithms and key lengths are used, how key management is organized, and whether there is a documented cryptography policy -- things get thin at most mid-market companies.

NIS2 has elevated the topic from best practice to a legal obligation. Article 21, Paragraph 2 lists ten minimum measures that affected organizations must implement. Letter h explicitly names concepts for the use of cryptography and, where appropriate, encryption. This means: you must not only encrypt but document what you encrypt, why you encrypt it, and according to which standards you do so.

ISO 27001 addresses encryption in Annex A.8.24 (Use of cryptography). The standard requires that rules for the effective use of cryptography, including the management of cryptographic keys, be defined and implemented. This covers both the selection of algorithms and the entire key lifecycle: generation, distribution, storage, use, archiving, revocation, and destruction.

DSGVO (GDPR) mentions encryption in Article 32 as a suitable technical measure for protecting personal data. Organizations that encrypt and can demonstrate in the event of a data breach that the affected data was encrypted may even be exempt from notifying data subjects (Article 34, Paragraph 3a). This makes encryption not just a security measure but a tangible economic advantage in an emergency.

This article brings order to the topic. What must be encrypted? Which algorithms and key lengths are currently secure? How do you organize key management? And what does a practical cryptography policy look like?

The three states of data

To think systematically about encryption, it helps to distinguish the three states in which data can exist. Each state has its own risks and requires its own protections.

Data at rest

Data at rest is data stored on a medium and not currently being processed or transmitted. Hard drives, SSDs, USB sticks, backup tapes, databases, file servers, cloud storage. Whenever data is stored somewhere, it is data at rest.

The risk: if someone gains physical access to the storage medium -- whether through laptop theft, a break-in at the data center, or unauthorized access to a backup tape -- they can read the data. Without encryption, it is enough to remove the hard drive and connect it to another computer. No access control in the world helps when the attacker holds the physical medium.

Data in transit

Data in transit is data currently being transmitted. Network traffic between client and server, emails on the way to the recipient, file transfers via FTP or SFTP, API calls between systems. Whenever data flows from A to B, it is data in transit.

The risk: network traffic can be intercepted and read. In local networks through ARP spoofing, in Wi-Fi through eavesdropping on radio traffic, on the internet through man-in-the-middle attacks on insecure connections. Without encryption, network traffic is plaintext that anyone with access to the transmission path can read.

Data in use

Data in use is data currently being actively processed. This means: it resides in RAM, CPU caches, or registers. In this state, it is generally unencrypted because the CPU cannot compute with encrypted data.

The risk: attacks on data in use are technically demanding but possible. Cold boot attacks extract data from RAM by cooling and reading the memory. Side-channel attacks like Spectre and Meltdown read data from CPU caches. Memory-scraping malware searches RAM for sensitive information like credit card numbers or key material.

For mid-market companies, data in use is the hardest area to protect -- and simultaneously the one with the lowest practical risk. Confidential Computing, the encryption of data even during processing using technologies like Intel SGX or AMD SEV, is still in its infancy and is neither available nor necessary for most SME scenarios. Focus on data at rest and data in transit -- that is where the bulk of the risk and the need for action lie.

Encrypting data at rest

Full-disk encryption

Full-disk encryption is the most basic form of encryption and simultaneously the one with the best effort-to-benefit ratio. The entire hard drive is encrypted so that without the correct key (tied to the user's login or a TPM chip), no access to the data is possible.

Windows: BitLocker. BitLocker is included in Windows Pro and Enterprise and can be centrally activated through group policies or Intune. The encryption key is stored in the device's TPM chip; the recovery key must be centrally stored in Active Directory or Entra ID. Use AES-256 as the algorithm -- this is configurable through group policy. BitLocker encrypts the entire hard drive including the operating system and is transparent to the user -- they notice nothing of the encryption in daily use.

macOS: FileVault. FileVault 2 is built into macOS and encrypts the system partition with XTS-AES-128. Recovery keys can be centrally managed through an MDM like JAMF or Intune. Activation through a configuration profile is straightforward.

Linux: LUKS. Linux Unified Key Setup is the standard for full-disk encryption on Linux. It is typically set up during installation and encrypts the root partition with AES-256 in XTS mode. Central management of recovery keys is more complex on Linux than on Windows or macOS and requires custom tooling or configuration management solutions.

Servers and storage systems. Server hard drives should also be encrypted, especially if they are not located in a physically secured data center. Many storage systems and RAID controllers offer Self-Encrypting Drives (SEDs), where encryption occurs at the hard drive firmware level and produces no performance overhead.

Database encryption

Full-disk encryption protects against physical theft of the storage medium. What it does not protect: data accessed through the operating system or application. An attacker who logs into the server (e.g., through compromised credentials) can query the database normally despite hard drive encryption, because the operating system performs decryption transparently.

For sensitive data in databases, there is therefore a second encryption layer:

Transparent Data Encryption (TDE) encrypts database files on disk so an attacker who copies the database files cannot use them without the database key. SQL Server, PostgreSQL, and MySQL offer TDE natively. TDE is transparent to the application -- no code changes are needed.

Column-level encryption encrypts individual columns in a table, such as credit card numbers, social security numbers, or health data. This provides finer protection than TDE but requires application changes because decryption must be performed explicitly.

For most mid-market companies, the combination of full-disk encryption and TDE is sufficient. Column-level encryption is useful when individual fields contain especially sensitive data and need to be protected from certain roles even within the application.

Backup encryption

Backups are one of the most frequently overlooked vulnerabilities. The production system is encrypted, access rights are properly configured, but backups sit unencrypted on a NAS or at a cloud provider. An attacker who gets to the backups has the entire data set, often including historical data that has long been deleted from the production system. This applies especially to ISMS data, which represents a detailed security map of your organization and therefore requires consistent encryption at rest, in transit, and in backup.

Every backup must be encrypted. Common backup solutions (Veeam, Acronis, Duplicati, restic, BorgBackup) support encryption natively. Use AES-256 and store the encryption key separately from the backup. If the key resides on the same system as the backup, an attacker can obtain both -- and the encryption is worthless.

A special point: regularly test whether you can actually restore your encrypted backups. An encrypted backup for which you have lost the key is worse than no backup at all -- because you think you have one.

Cloud encryption

For cloud services, there are three levels of encryption:

Encryption at rest by the cloud provider. AWS, Azure, and Google Cloud encrypt all stored data by default. This protects against physical theft of hardware in the data center but not against the cloud provider itself or an attacker who compromises your cloud credentials.

Customer-managed keys. You generate and manage the encryption key yourself; the cloud provider uses it for encryption. If you delete or revoke the key, the data is unreadable even for the provider. This gives you more control but requires proper key management.

Client-side encryption. Data is encrypted on your endpoint before upload to the cloud. The cloud provider sees only encrypted data and has no access to the keys. This is the most secure variant but also the most complex because you must integrate encryption into your applications and processes.

For mid-market companies, the recommendation is: use at least the cloud provider's standard encryption (which is usually automatically active). For especially sensitive data, use customer-managed keys. Client-side encryption is useful for specific use cases, such as exchanging confidential documents with external partners.

Encrypting data in transit

TLS: The standard for encrypted connections

Transport Layer Security (TLS) is the foundation of encrypted communication on the internet and in internal networks. When you visit an HTTPS website, establish an encrypted connection to a mail server, or call an API over HTTPS, you are using TLS.

Minimum version: TLS 1.2. TLS 1.0 and 1.1 have been considered insecure since 2020 and should be disabled on all systems. All modern browsers and operating systems support TLS 1.2 and 1.3. There is no reason to tolerate older versions.

Preferred: TLS 1.3. TLS 1.3 is faster (fewer roundtrips during connection setup), more secure (obsolete cipher suites have been removed), and simpler to configure. If your servers and clients support TLS 1.3, you should enable and prefer it.

Selecting cipher suites. Not all encryption methods supported by TLS are equally secure. Disable weak cipher suites (anything with RC4, DES, 3DES, MD5, SHA-1) and prioritize strong suites with forward secrecy (ECDHE-based). For TLS 1.2, ECDHE-RSA-AES256-GCM-SHA384 and ECDHE-ECDSA-AES256-GCM-SHA384 are good default configurations. TLS 1.3 simplifies this because only secure suites are available.

Certificate management. TLS certificates have expiration dates. When a certificate expires, the encrypted connection stops working, and users see a security warning. Automate certificate renewal with Let's Encrypt and Certbot for publicly reachable services. For internal services, operate an internal certificate authority (CA) or use the certificate services of your firewall or reverse proxy.

VPN encryption

VPN connections encrypt data traffic between the endpoint and the corporate network. Encryption occurs at a lower layer than TLS and therefore also protects protocols that do not provide their own encryption (e.g., SMB file shares or older application protocols).

Recommended VPN protocols and their encryption: WireGuard uses ChaCha20 for encryption and Poly1305 for authentication -- a modern and fast combination. OpenVPN should be configured with AES-256-GCM or ChaCha20-Poly1305. IKEv2/IPsec should use AES-256 with SHA-256 or SHA-384.

Email encryption

Email is one of the most insecure communication media. By default, emails are transmitted in plaintext, and even when transport between mail servers is encrypted (STARTTLS), the email sits unencrypted on the mail servers themselves.

There are two approaches to email encryption:

Transport encryption (STARTTLS/TLS). The connection between mail servers is encrypted. This protects against eavesdropping on the transport path but not on the mail servers themselves. Ensure your mail server enforces STARTTLS and does not accept unencrypted connections. MTA-STS (Mail Transfer Agent Strict Transport Security) provides additional protection against downgrade attacks.

End-to-end encryption (S/MIME or PGP). The email is encrypted on the sender's endpoint and decrypted only on the recipient's endpoint. No mail server along the way can read the content. S/MIME uses X.509 certificates and is natively integrated in Outlook and Apple Mail. PGP/GPG uses a web of trust and is technically more flexible but harder to use.

The honest assessment: end-to-end email encryption is rarely practical for day-to-day use in mid-market companies. Key management is complex, usability is poor, and both sides must use the same technology. For regular business communication, transport encryption plus a secure messaging service (e.g., Microsoft Teams or Signal for especially confidential communication) is often the better solution. S/MIME is worthwhile for defined communication channels, such as exchanging confidential documents with a tax advisor or a government agency.

Algorithms and key lengths: What is currently secure?

Selecting the right algorithms and key lengths is a topic that quickly gets technical. For enterprise practice, however, you do not need a cryptography lecture -- you need clear directives on what to use and what not to.

Symmetric encryption

In symmetric encryption, sender and recipient use the same key. This is fast and efficient and is used for encrypting large data volumes (hard drives, databases, VPN tunnels).

Recommended: AES-256. The Advanced Encryption Standard with 256-bit keys is the worldwide standard. It is recommended by NIST, BSI, and all relevant security agencies and cannot be broken by brute force in the foreseeable future -- not even by quantum computers.

Acceptable: AES-128. AES with 128-bit keys is also secure and offers better performance. For most use cases, the difference between AES-128 and AES-256 is academic -- both are secure. If you have the choice, use AES-256, but do not lose sleep over AES-128.

Acceptable: ChaCha20. An alternative to AES that is faster on devices without hardware AES acceleration. Used by WireGuard and modern TLS implementations.

Prohibited: DES, 3DES, RC4, Blowfish. These algorithms are outdated and considered insecure. If you still find them in your infrastructure, replace them.

Asymmetric encryption

In asymmetric encryption, there is a key pair: a public key for encrypting and a private key for decrypting. This is used for key exchange, digital signatures, and certificates.

Recommended: RSA with at least 2048 bits. RSA 2048 is the current minimum standard. RSA 4096 provides more security margin but is slower. For certificates valid for several years, the BSI recommends at least RSA 3072 or RSA 4096.

Recommended: Elliptic Curve Cryptography (ECC). ECDSA and ECDH provide the same security level as RSA with significantly shorter keys. An ECDSA key with 256 bits corresponds roughly to RSA 3072. ECC is faster and more efficient and is increasingly becoming the standard, especially in TLS 1.3.

Prohibited: RSA with less than 2048 bits. RSA 1024 has been considered insecure for years. RSA 512 can be broken in a few hours.

Hash functions

Hash functions produce a fixed-length fingerprint from data. They are used for password hashing, digital signatures, and integrity checks.

Recommended: SHA-256, SHA-384, SHA-512 (SHA-2 family). SHA-2 is the current standard and secure.

Recommended: SHA-3. The latest generation of the SHA family, based on a completely different algorithm (Keccak). SHA-3 is a good choice for future-proofing, but SHA-2 is also secure for the foreseeable future.

For passwords: bcrypt, scrypt, or Argon2. Passwords must never be hashed with SHA-256 or similar fast hash functions. For password hashing, you need intentionally slow algorithms like bcrypt, scrypt, or Argon2 that make brute-force attacks difficult.

Prohibited: MD5, SHA-1. Both are considered broken and must no longer be used for security-relevant purposes. MD5 collisions can be generated in seconds, SHA-1 collisions in hours to days.

Key management: The real core problem

Encryption is only as secure as key management. The best algorithm with the longest key length is useless if the key is on a sticky note on the monitor, in plaintext in a configuration file, or has not been rotated for years.

Key generation

Keys must be generated with a cryptographically secure random number generator. This sounds obvious but is not always the case. Applications that implement their own encryption and use a weak random number generator produce predictable keys. Always use the operating system's cryptographic libraries or established libraries like OpenSSL, libsodium, or the framework's cryptography APIs for key generation.

Key storage

Keys must not be stored in plaintext -- not in configuration files, not in databases, not in code repositories. Not even when access rights are restrictive.

For mid-market companies, there are several options:

Hardware Security Module (HSM). HSMs are dedicated hardware devices that generate and store keys and perform cryptographic operations without the key ever leaving the device. HSMs provide the highest security level but are expensive (several thousand euros per device). For most SMEs, a physical HSM is overkill.

Cloud-based Key Management Services. AWS KMS, Azure Key Vault, and Google Cloud KMS offer HSM-based key storage as a cloud service. Costs are low (a few euros per month per key), and integration with cloud applications is simple. For organizations using cloud services, this is the most pragmatic solution.

TPM chip. The Trusted Platform Module chip in modern laptops and desktops stores the BitLocker key and other keys in a physically protected area. For endpoints, the TPM is the standard solution.

Password managers and secrets management. For API keys, database passwords, and similar secrets needed by applications, there are secrets management tools like HashiCorp Vault, Bitwarden Secrets Manager, or the secrets features of CI/CD platforms. These tools store secrets encrypted and provide them to applications via APIs.

Key rotation

Keys have a limited lifespan. The longer a key is used, the greater the risk it will be compromised -- whether through a security incident, a system vulnerability, or simply the laws of probability.

Define rotation intervals for different key types: TLS certificates every 90 days (Let's Encrypt does this automatically), API keys at least annually, database encryption keys every 1-2 years, backup encryption keys whenever the responsible person changes.

Key loss and recovery

What happens when a key is lost? For full-disk encryption: the data is irrecoverably gone. For backup encryption: the backups are worthless. For email encryption: all encrypted emails are no longer readable.

That is why you need a recovery concept: store BitLocker recovery keys in Active Directory or Entra ID. Keep backup encryption keys at a separate, secured location (not on the same system as the backups). For especially critical keys, set up key escrow with a four-eyes principle, where two people must come together to reconstruct the key.

Practical implementation for SMEs

How do you implement all of this in practice without launching a cryptography project with a six-figure budget? The following prioritization helps:

Implement immediately (weeks 1-2)

Full-disk encryption on all endpoints. BitLocker on Windows, FileVault on macOS. Store recovery keys centrally. Enforce through group policies or MDM that new devices are automatically encrypted. Retrofit existing devices within the next two weeks.

Check TLS configuration. Verify all externally reachable services (web server, mail server, VPN gateway) for their TLS configuration. Tools like SSL Labs (ssllabs.com) or testssl.sh do this in minutes. Disable TLS 1.0 and 1.1, disable weak cipher suites, enable TLS 1.3 where possible.

Check VPN encryption. Ensure your VPN uses AES-256 or ChaCha20. Replace outdated protocols (PPTP, L2TP without IPsec).

Implement short-term (months 1-2)

Activate backup encryption. Enable encryption in your backup solution. Store keys separately from backups. Test the restoration of an encrypted backup.

Evaluate database encryption. Check whether your databases contain sensitive data that needs protection beyond full-disk encryption. If so, activate TDE.

Check email transport encryption. Ensure your mail server enforces STARTTLS. Configure MTA-STS if your mail server supports it.

Implement medium-term (months 3-6)

Create a cryptography policy. Document your organization's encryption standards in a formal policy (more on this in the next section). In ISMS Lite, the cryptography policy can be linked to associated controls and the implementation status of each encryption measure tracked.

Define a key management process. Document who is responsible for which keys, where they are stored, when they are rotated, and what happens in case of loss.

Conduct an encryption inventory. Create an overview of all systems and data flows and document what encryption is used where. Identify gaps and prioritize closing them.

The cryptography policy

A cryptography policy is a mandatory document for every ISMS. It documents the organization's encryption standards and gives all stakeholders -- from developers to administrators -- clear directives on what encryption to use where and how.

What belongs in the policy

Scope. For which systems, data, and communication channels does the policy apply?

Data classification. Which data must be encrypted? The policy should reference the organization's data classification: all confidential and strictly confidential data must be encrypted at rest and in transit.

Approved algorithms and key lengths. A clear list of what is allowed and what is prohibited. The table from the previous section is a good starting point.

Prohibited algorithms. Explicitly list what may no longer be used: DES, 3DES, RC4, MD5, SHA-1, RSA under 2048 bits, TLS below version 1.2.

Key management. Rules for generation, storage, rotation, distribution, and destruction of keys. Who is responsible? How are keys backed up? What happens in case of loss?

Certificate management. Rules for procuring, renewing, and revoking TLS certificates. Who is responsible for renewal? How is it ensured that no certificates expire?

Exceptions. Under what conditions may the standards be deviated from? Who approves exceptions? How are they documented?

Review. How often is the policy reviewed and updated? At least annually, and additionally upon relevant changes in the threat landscape or BSI recommendations.

A word on post-quantum cryptography

The development of quantum computers threatens some of today's cryptographic methods. Asymmetric methods like RSA and ECC are theoretically breakable by quantum computers (Shor's algorithm). Symmetric methods like AES are less affected -- Grover's algorithm doubles the effort, which for AES-256 still yields a security level of 128 bits, meaning it remains secure.

In 2024, NIST published the first post-quantum cryptography standards: ML-KEM (formerly CRYSTALS-Kyber) for key exchange and ML-DSA (formerly CRYSTALS-Dilithium) for digital signatures. TLS 1.3 already supports hybrid methods combining classical and post-quantum algorithms. Chrome and Firefox have begun activating these hybrid methods.

For mid-market companies: you do not need to start a post-quantum migration now. What you should do is mention the topic in the cryptography policy and check at the next review whether your systems support the new standards. Migration will come gradually over the next few years through software and firmware updates. If your systems are kept current, you are on the safe side.

Encryption in the audit

When an auditor reviews the cryptography controls, they will typically ask the following questions: is there a documented cryptography policy? What algorithms and key lengths are defined? Are all endpoints equipped with full-disk encryption? How is key management organized? Is there a key loss procedure? Are backups encrypted? What TLS version is configured on external services?

The cryptography policy is the central document you can present. It is supplemented by technical evidence: BitLocker status reports from the MDM, SSL Labs scans of external services, configuration documentation of backup encryption, and key management process documentation.

Auditors also check whether the policy is practiced. A policy that mandates AES-256, but 3DES is found in the TLS configuration on servers, generates a finding. That is why an inventory of actually deployed encryption is an important step that should occur before the audit.

Encryption as a foundation of information security

Encryption is not a one-time project you implement and check off. It is a continuous process that must be embedded in the ISMS. Algorithms that are secure today may be considered broken tomorrow. Keys must be rotated, certificates renewed, and new systems incorporated into the encryption concept.

But getting started is achievable -- even for mid-market companies. Full-disk encryption on all devices, TLS in current configuration on all services, encrypted backups, and a documented cryptography policy -- these are four building blocks you can implement in a few weeks that cover the bulk of regulatory requirements.

Start with the inventory: what is already encrypted today, and where are the gaps? Close the critical gaps first, document your standards in a policy, and build key management step by step. The perfect cryptography strategy will not exist on day one. But an organization that encrypts its hard drives, runs current TLS configurations, encrypts its backups, and has documented all of this in a policy stands significantly better in an audit and during a security incident than one that leaves encryption to chance.