A.8.24 — Use of Cryptography

The development team encrypts customer data in the database — using the DES algorithm deprecated since 2005, with the encryption key stored in the application’s configuration file alongside the database password. The encryption provides zero effective protection. A.8.24 requires proper and effective use of cryptography — the right algorithms, managed keys and a documented policy.

Cryptography is a powerful tool when applied correctly and a dangerous illusion when applied poorly. This control covers the entire lifecycle: selecting algorithms, managing keys, complying with legal requirements and planning for algorithm obsolescence.

Purpose: Ensure proper and effective use of cryptography to protect confidentiality, authenticity or integrity of information.
Control type: Preventive
Security objectives: Confidentiality, Integrity
Theme: Technological
BSI modules: CON.1
KPI: Percentage of cryptographic implementations compliant with cryptography policy

Responsible	IT Security Officer
Accountable	Information Security Officer / (C)ISO
Consulted	Asset Owner, Data Protection Officer, Facility Manager, HR Manager, Head of IT, IT Administrator, IT Security Officer, Incident Response Team, Legal Counsel, Software Development Lead, Supply Chain Manager
Informed	All Employees, Asset Owner, Head of IT, IT Administrator, IT Security Officer, Information Security Officer / (C)ISO, Internal Auditor, Legal Counsel, Software Developer / Architect, Top Management

What does the standard require?

Define a cryptography policy. Specify when, where and how cryptography must be used — covering data at rest, data in transit and data in use.
Select appropriate algorithms. Use current, standards-based algorithms with adequate key lengths. Avoid deprecated algorithms.
Manage keys securely. Implement a key management process covering generation, distribution, storage, rotation, backup, revocation and destruction.
Handle compromised keys. Define and document procedures for responding to key compromise.
Comply with legal requirements. Consider legal restrictions on cryptography (import/export controls, law enforcement access requirements) across all jurisdictions where you operate.
Audit cryptographic use. Log and review cryptographic operations to ensure policy compliance.

In practice

Create a cryptography standard. Define approved algorithms and minimum key lengths: AES-256 for symmetric encryption, RSA-2048+ or ECDSA P-256+ for asymmetric, SHA-256+ for hashing, TLS 1.2+ for transport encryption. Publish this as a mandatory standard for all teams.

Use a key management system (KMS). Store keys in a dedicated KMS (AWS KMS, Azure Key Vault, HashiCorp Vault) rather than in configuration files, source code or databases. Automate key rotation and revocation.

Encrypt data at rest and in transit. Disk encryption for endpoints and servers, database-level encryption for sensitive data, TLS for all network communication. Verify actual implementation — a policy requiring encryption means nothing if the database is unencrypted.

Plan for crypto agility. Design systems so that encryption algorithms can be replaced without rebuilding the application. When a new vulnerability affects an algorithm, you need to migrate quickly. Maintaining a crypto register (see above) is the first step.

Typical audit evidence

Auditors typically expect the following evidence for A.8.24:

Cryptography policy — documented rules for algorithm selection, key management and usage (see Cryptography Policy in the Starter Kit and Crypto Register)
Crypto register — inventory of all cryptographic implementations
KMS configuration — evidence of centralized key management
Certificate management — inventory of TLS certificates with expiry tracking
Algorithm compliance evidence — scan results showing no deprecated algorithms in use

KPI

Percentage of cryptographic implementations compliant with cryptography policy

Measured as a percentage: how many of your systems use only approved algorithms and key lengths as defined in the cryptography policy? Target: 100%.

Supplementary KPIs:

Number of systems using deprecated algorithms (target: zero)
Percentage of encryption keys stored in a KMS
Number of TLS certificates expiring within 30 days without renewal plan

BSI IT-Grundschutz

A.8.24 maps to the BSI crypto concept module:

CON.1 (Crypto Concept) — the core module. Requires a documented crypto concept specifying algorithms, key lengths, key management procedures and compliance with BSI technical guidelines (TR-02102 series).

A.8.13 — Information Backup: Backup encryption requirements.
A.8.10 — Information Deletion: Cryptographic erasure as a deletion method.
A.8.20 — Networks Security: Encryption for data in transit.
A.5.17 — Authentication Information: Cryptographic protection of authentication credentials.

Sources

ISO/IEC 27001:2022 Annex A, Control A.8.24 — Use of cryptography
ISO/IEC 27002:2022 Section 8.24 — Implementation guidance for use of cryptography
BSI IT-Grundschutz, CON.1 — Crypto Concept

Frequently asked questions

Which encryption algorithms should we use?

For symmetric encryption: AES-256. For hashing: SHA-256 or SHA-3. For asymmetric encryption: RSA-2048+ or ECDSA P-256+. For TLS: version 1.2 or 1.3 with strong cipher suites. Avoid DES, 3DES, MD5, SHA-1 and RSA-1024.

What is key management and why does it matter?

Key management covers the entire lifecycle of cryptographic keys: generation, distribution, storage, rotation, backup and destruction. A strong encryption algorithm with poor key management is like a vault with the combination written on a sticky note.

Do we need to worry about post-quantum cryptography?

Organizations with long-term confidentiality requirements (data that must remain secret for 10+ years) should begin planning for post-quantum migration. NIST has finalized several post-quantum algorithms (CRYSTALS-Kyber, CRYSTALS-Dilithium). Start by inventorying your cryptographic dependencies.