There is no single correct interval. OWASP's key management guidance says to document a schedule based on your threat model and risk assessment, and gives representative cryptoperiods: up to two years for low-volume symmetric data keys, one to three years for signing keys, and far shorter for high-volume uses.
What a cryptoperiod is
OWASP defines a cryptoperiod as the time span during which a key is authorized for use. Shorter periods limit how much data one key exposes and shorten the window if it is compromised.
Representative periods
From the OWASP guidance, which tells organizations to set their own through risk assessment:
- Symmetric data keys, low volume. Typical period: Up to 2 years.
- Symmetric keys, high volume or link encryption. Typical period: About a day to a week.
- Private signing keys. Typical period: 1 to 3 years.
- Static key agreement pairs. Typical period: Up to 1 to 2 years.
Decryption use should typically end no more than three years after the encryption period, according to the same page.
Volume matters as much as time
OWASP says rotation must account for usage volume as well as elapsed time. For AES-GCM with random 96-bit IVs, it says to limit each key to at most 2^32 encryption operations across all devices sharing it. A busy service could hit that long before a calendar rotation date.
Certificates are different
Renewing a TLS certificate does not necessarily replace its key pair, so key replacement needs its own schedule, OWASP notes. Certificate validity itself is governed by CA/Browser Forum limits. See TLS certificate lifetimes are shrinking.
Build your schedule
- List key types: data keys, wrapping keys, signing keys, TLS keys, API secrets.
- For each, note volume, who can access it and what a leak would expose.
- Set a period and a usage cap, and write down both.
- Automate rotation through a key service where possible. OWASP says to prefer automation to reduce operational error.
- Keep a log of manual rotations: time, operator and authorization reference.
- Plan emergency rotation separately. See what to do when an encryption key leaks.
An example worked through
Suppose a service encrypts customer records under per-tenant data keys wrapped by one KMS key. Each tenant key encrypts few messages, so volume is no concern, and the wrapping key is used rarely. A calendar period such as annual rotation of the wrapping key is a sensible policy, and it can be automated. Now suppose a different service encrypts every message on a busy link under one shared key. Here volume is the driver, and the OWASP figure of about a day to a week for high volume uses is the relevant guide. The same company, two very different schedules. Writing the reasoning beside each number is what makes the policy defensible when someone asks.
Quick check
Is annual rotation required by law?
Not generally by the texts cited here. Some contracts or rules may require it, so check what applies to you.
Is a shorter period always better?
Not if it creates errors or outages. Automation and re-wrapping make short periods practical. Without them, risk can rise.
Sources
Last reviewed: 19 October 2026.
