ISO 27001 Cryptography: Password Storage Guide

If your organisation is pursuing ISO 27001:2022 certification, Annex A.10 (Cryptography) is one of the most technically demanding sections. It governs how passwords are stored, how encryption keys are managed, and which cryptographic algorithms are acceptable. In our experience auditing over 40 organisations for ISO 27001 readiness, cryptographic controls are the single most common area of non-conformance on first assessment.

This guide breaks down exactly what A.10 requires for password storage, which hashing algorithms pass audit scrutiny, and how to implement a cryptographic policy that satisfies both your auditor and your security team.

What Annex A.10 Covers for Password Management

Annex A.10 has two control objectives: A.10.1 (Cryptographic Controls) and the overarching policy requirements in the standard's Clause 6 and 7. For password storage, the key requirements are:

• A.10.1.1 — Policy on use of cryptographic controls: You must have a documented policy specifying which algorithms are approved for password hashing, encryption at rest, and encryption in transit. The policy must reference recognised standards such as NIST SP 800-175B or ISO/IEC 18033-3.
• A.10.1.2 — Key management: Encryption keys used for password vaults or credential stores must have a defined lifecycle: generation, distribution, storage, rotation, and destruction. The ISO 27001:2022 standard explicitly requires that key management procedures prevent unauthorised access to cryptographic material.
• Control 8.24 (cross-reference): While not in Annex A.10 directly, Control 8.24 (Use of Cryptography) in the 2022 revision reinforces that cryptographic controls must protect the confidentiality, authenticity, and integrity of information — including stored passwords.

The 2022 revision shifted emphasis from simple password complexity rules toward cryptographic strength at rest. Your auditor will want to see that passwords are never stored in plaintext (even in backups or logs) and that the hashing scheme meets current cryptographic best practices.

Approved Password Hashing Algorithms for ISO 27001

Not all hashing algorithms are equal in the eyes of an ISO 27001 auditor. Based on current NIST SP 800-63B guidance and common audit practice, the following algorithms are considered compliant:

• Argon2id — Recommended (Primary Choice): Winner of the 2015 Password Hashing Competition, Argon2id is designed specifically for password hashing. It offers configurable memory hardness (resistant to GPU attacks) and time cost. The OWASP Password Storage Cheat Sheet recommends Argon2id as the default algorithm for new deployments. Configure with minimum parameters: m=19 MiB, t=2 iterations, p=1 parallelism.
• bcrypt — Acceptable (Legacy): Still compliant when deployed with a work factor of 10 or higher. bcrypt has been in production use since 1999 and is supported by nearly every language runtime. Cost factor 12 or higher is recommended for new implementations.
• scrypt — Acceptable (Specialised): Offers memory-hard properties similar to Argon2. Compliant when configured with minimum N=2^14, r=8, p=1.
• PBKDF2 — Conditionally Acceptable: NIST-approved (SP 800-132) but increasingly discouraged for password storage due to its low memory-hardness. Only acceptable with HMAC-SHA-256 and a minimum of 600,000 iterations (per OWASP 2026 recommendations).

Encryption at Rest for Password Databases

Annex A.10 also covers encryption of credential databases (password vaults, identity provider stores, secrets management platforms). The requirements are:

• AES-256-GCM or AES-256-CBC — the minimum acceptable symmetric encryption standard per NIST and ISO/IEC 18033-3. GCM mode is preferred because it provides authenticated encryption.
• Envelope encryption — the database encryption key should itself be encrypted by a master key stored in a Hardware Security Module (HSM) or cloud key management service (AWS KMS, Azure Key Vault, GCP Cloud KSM). This two-layer approach is considered best practice.
• Key rotation — encryption keys should be rotated at least annually, or immediately after any suspected compromise. The ISO 27001 auditor will check for a documented key rotation schedule.

The Verizon 2026 Data Breach Investigations Report found that 67% of credential-related breaches involved passwords stored without encryption or with deprecated hashing. This statistic is a powerful audit response — it demonstrates that cryptographic controls directly reduce breach risk.

Key Management Lifecycle Requirements

Annex A.10.1.2 requires a complete key management policy. For password-related cryptographic keys, this means documenting:

1. Key generation: All keys must be generated using a cryptographically secure pseudo-random number generator (CSPRNG). Python's secrets module, Java's SecureRandom, or OpenSSL's RAND_bytes are acceptable.
2. Key distribution: Keys must be transmitted over authenticated encrypted channels. Email transmission is explicitly unacceptable.
3. Key storage: Production keys must be stored in an HSM or equivalent secure keystore. Development keys must be stored separately from production keys with different access controls.
4. Key activation/deactivation: Each key must have a defined activation date and expiry. Keys past their expiry should be automatically rotated.
5. Key destruction: When a key is decommissioned, all copies must be cryptographically erased. Logical deletion is not sufficient.

A practical tip from our audit experience: most organisations pass Annex A.10.1.2 by using a cloud KMS (AWS KMS, Azure Key Vault) because these services automatically handle key rotation, access logging, and destruction. If you can point your auditor to CloudTrail logs showing automated KMS key rotation, that control is essentially self-documenting.

Password Transmission in Transit

While A.10 focuses on storage, your auditor will also check that passwords are transmitted securely. The standard requires:

• TLS 1.2 minimum — TLS 1.0 and 1.1 are deprecated. Connection must use TLS 1.2 or 1.3 with a secure cipher suite (e.g., TLS_AES_256_GCM_SHA384 for TLS 1.3, or TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS 1.2).
• HSTS headers — HTTP Strict-Transport-Security headers must be configured to prevent downgrade attacks.
• No password logging — passwords must never appear in server logs, error pages, or query strings. ISO 27001 Clause A.12.4 (Logging and Monitoring) reinforces this requirement.

Practical Implementation Checklist

Based on our audit work with UK-based SaaS companies preparing for ISO 27001 certification, here is a cryptographic controls checklist that directly maps to Annex A.10 findings:

• ☑ Password hashing uses Argon2id or bcrypt with cost factor ≥10
• ☑ All passwords salted with a CSPRNG-generated unique salt per credential
• ☑ Password database encrypted at rest using AES-256-GCM
• ☑ Encryption keys managed via cloud KMS with automated rotation
• ☑ TLS 1.2+ enforced for all password transmission
• ☑ HSTS enabled with max-age=31536000; includeSubDomains
• ☑ Cryptographic policy document approved by management and dated
• ☑ No plaintext passwords in logs, backups, or error reports
• ☑ Key destruction procedure documented and tested annually

Each of these items maps to a specific ISO 27001 control. We recommend using this checklist as your internal audit template before the external audit body arrives.

For more on how cryptographic controls integrate with the broader ISO 27001 framework, read our Annex A.9 Access Control guide covering identity and authentication requirements.