Choose key sizes that meet current cryptographic strength requirements for the algorithm and expected data life. Larger is not always better, but sizes that are too small can be brute-forced or weakened by advances in computing. Follow current organisational policy and approved standards, and review sizes when protocols or threat models change.
How should you choose a key size?
Key size should be chosen to match the algorithm, the security margin you need, and how long the protected data must remain safe. A size that is adequate today can become weak if the threat model changes or the data needs to survive for years. The practical goal is not maximum size, but the right size for the use case.
That means treating key size as part of the design, not a one-time setting. Short-lived credentials, long-lived signing keys, encryption keys for archival data, and keys that protect high-value systems can justify different strength assumptions. For a deeper lifecycle view, see Cryptographic Key Management Guide.
What makes a key size “best practice” in practice?
Best practice is to follow current organisational policy and approved cryptographic standards rather than picking a size based on habit or vendor defaults. The right choice depends on the algorithm family, expected adversary capability, compliance obligations, and whether the key is being used for encryption, signing, authentication, or exchange.
For example, a key size that is acceptable for one algorithm may be inappropriate for another, even when the numbers look similar. The selection also needs to align with the rest of the crypto design, including how keys are generated, stored, rotated, and retired. If the key is an API credential or bearer secret rather than a classical cryptographic key, the lifecycle expectations change and management discipline matters just as much as nominal length. API Key Management Guide is useful for that operational angle.
When should you revisit key size decisions?
Revisit key sizes when protocols, algorithms, regulatory expectations, or threat models change. A size that was conservative when the system was designed may no longer provide enough margin if computing power improves, the asset value increases, or the data retention period extends. The same review should happen when a system is modernised, re-keyed, or moved into a new trust boundary.
Keys also need review after a compromise event or when a dependency changes the exposure profile, because the right response may be to increase strength, shorten lifetime, or replace the algorithm entirely. The point is to keep key strength proportional to current risk, not historical comfort. NIST SP 800-57 is a useful reference for that lifecycle thinking, especially around cryptoperiods and algorithm selection. NIST SP 800-57 Key Management supports that review process.
Risk and Threat Considerations
Key size is a security boundary, not a cosmetic choice. If the size is too small for the algorithm and data lifetime, an attacker may be able to brute-force the key, wait for computing improvements, or exploit a system that assumed the key would remain strong for longer than it actually will.
Failure mechanism: Weak key sizes reduce the effective search space, which lowers the cost of cryptanalysis and increases the chance that an attacker can recover the key or derive protected material before the data ages out.
Impact: The result can be loss of confidentiality, invalidated signatures, unauthorized access to protected services, and a need to re-encrypt or re-issue dependent material under emergency conditions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Key size choices depend on key lifecycle, cryptoperiods and algorithm selection. |
| Recommendation — Use approved cryptoperiod and algorithm guidance to set key sizes with enough security margin. | ||
| NIST SP 800-53 Rev 5 | SC-13 — Cryptographic Protection | Key size is part of selecting adequate cryptographic protection for data and communications. |
| Recommendation — Select cryptographic parameters that meet the required strength for the protected information. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Key size selection is part of applying cryptography consistently with policy and risk. |
| Recommendation — Define cryptographic strength requirements and review them as threats and systems change. | ||
Practitioner Guidance
What to verify: Confirm that the selected key size matches the exact algorithm, the expected lifetime of the protected data, and the organisation’s approved standard for that use case. Do not assume one approved size transfers cleanly across encryption, signing, token protection, and API credential handling.
Decision rule: If the protected asset must remain trustworthy for a long period, choose a size with conservative margin and review whether the algorithm itself still remains suitable; if the key is operationally short-lived, prioritise lifecycle control and rotation discipline alongside nominal size.
Practitioner takeaway: The best key size is the smallest size that still preserves an acceptable security margin for the full life of the data and the current threat model, with periodic review instead of permanent assumptions.