Pre-deployment cryptographic architecture review. Check items as you verify them, then export the checklist for your records.

Keys are generated from a CSPRNG (not Math.random or similar)

Use os.urandom, crypto.getRandomValues, or /dev/urandom. Never seed from time or PID.

Key material is stored in a KMS, HSM, or encrypted keystore — not in source code

Secrets in code are extractable from version control. Use environment variables as a minimum; hardware-backed storage for production.

Key rotation schedule is defined and documented

Define maximum key lifetime. Automate rotation where possible. Document the rollover procedure.

Separate keys for separate purposes (encryption vs. signing vs. MAC)

Key separation prevents cross-protocol attacks. Derive purpose-specific keys using HKDF with distinct info labels.

Key destruction procedure exists for decommissioned keys

Zeroing memory, secure deletion from storage, and revocation of public keys.

All algorithms are 'recommended' or 'acceptable' — no 'legacy' or 'avoid'

Use crypto::compare recommendation levels as a starting point. Legacy algorithms require a documented migration plan.

Symmetric encryption uses authenticated encryption (AEAD)

AES-256-GCM or XChaCha20-Poly1305. Never use ECB, CBC without MAC, or unauthenticated modes.

Password storage uses memory-hard hashing (Argon2id, bcrypt, scrypt)

Never use SHA-256, MD5, or fast hashes for passwords. Tune cost parameters to ≥100ms per hash.

Post-quantum migration path is identified for public-key cryptography

Document which components use RSA/ECDSA/ECDH and plan hybrid or full PQ migration (ML-KEM, ML-DSA).

Hash functions used for authentication use HMAC construction

Raw SHA-256 is vulnerable to length extension. Use HMAC-SHA-256 or KMAC256 for keyed authentication.

Nonces are never reused with the same key

AES-GCM nonce reuse is catastrophic. Use random nonces with XChaCha20 or counter-based nonces with strict monotonicity.

All ciphertext is authenticated before processing (encrypt-then-MAC or AEAD)

Decrypt-then-verify enables padding oracle attacks. AEAD modes handle this correctly by construction.

TLS 1.3 is the minimum for transport security

TLS 1.0/1.1 are deprecated. TLS 1.2 is acceptable with proper cipher suite selection. TLS 1.3 removes legacy modes.

Certificate validation is enforced — no disabled hostname checks or self-signed exceptions in production

Disabling certificate validation defeats the purpose of TLS. Pin certificates or use CT logs for high-value connections.

Timing-safe comparison is used for MAC verification and authentication tokens

Use constant-time comparison (e.g., hmac.compare_digest, crypto.timingSafeEqual). Variable-time comparison leaks secrets.

Cryptographic libraries are audited and actively maintained

Use libraries with published audit reports. Check the Implementation Map for verified options per ecosystem.

No custom cryptographic primitives — only standard, peer-reviewed algorithms

Rolling your own crypto is the #1 cause of cryptographic failures. Use established libraries and standard algorithms.

Sensitive data is zeroed from memory after use

Use secure memory wiping APIs (e.g., sodium_memzero). Compiler optimizations may remove naive zeroing.

Error messages do not leak cryptographic details (padding validity, MAC status, etc.)

Padding oracle and bleichenbacher attacks exploit detailed error messages. Return generic errors for crypto failures.

Side-channel resistance is verified for the deployment environment

Constant-time implementations for secrets processing. No secret-dependent branches or memory access patterns.

Entropy sources are validated at startup

Check that /dev/urandom or equivalent is functional. Fail closed if entropy is insufficient.

Cryptographic operations are logged (without logging sensitive material)

Log algorithm choices, key IDs, operation timestamps. Never log plaintext, keys, or raw nonces.

Incident response plan includes cryptographic compromise scenarios

Document steps for: key compromise, algorithm break announcement, certificate revocation, mass re-encryption.

Regular dependency updates include cryptographic library patches

Subscribe to security advisories for all crypto dependencies. Automate vulnerability scanning.

Backup encryption keys are tested for recovery

Encrypted backups are useless if the decryption key is lost. Test key recovery procedure regularly.

Cryptographic inventory lists all algorithms, key sizes, and libraries in use

Maintain a living document. Include algorithm, key size, library, version, and purpose for each crypto operation.

Compliance requirements are mapped to algorithm choices (FIPS, PCI, HIPAA, etc.)

FIPS 140-2/3 mandates specific NIST algorithms. PCI DSS requires strong cryptography. Document the mapping.

Migration plan exists for deprecated algorithms

Before an algorithm reaches 'legacy' status, have a tested migration path. Include timeline, testing plan, and rollback procedure.

Third-party integrations use secure cryptographic configurations

Verify that APIs, SDKs, and partner connections enforce strong TLS, proper authentication, and current algorithms.

Cryptographic design decisions are documented with rationale

Record why each algorithm was chosen, what alternatives were considered, and when the decision should be revisited.

Architecture Checklist