Time-Bound Defense

Time-bound defense is the practice of making a credential or key expire before an attacker can exploit it - instead of trying to make it unbreakable. Most security controls are built around the opposite, flawed assumption: if something is strong enough, it can’t be broken. Time-bound defense accepts that everything can eventually be cracked - a password, a key, a certificate - and focuses on a different question: does the credential stop being valid before that happens? Security here comes from winning a race against the clock, not from building an unbreakable wall.

Veeam applies this principle at several layers, from authentication to encryption to certificate management.

gMSA and Kerberos

Group Managed Service Accounts (gMSA) used by Veeam components for Kerberos authentication rotate their password automatically, on a schedule controlled by Active Directory rather than by an administrator. If an attacker captures a Kerberos service ticket and cracks it offline - a Kerberoasting attack - the cracked password is very likely already invalid by the time the cracking finishes. The account was never made uncrackable. The credential simply stopped being useful before the attacker could act on it.

KMS and backup encryption keys

The same logic governs how Veeam handles backup encryption keys through a Key Management System (KMS). Key rotation does not prevent a key from ever being compromised. It limits how long that key stays valid if it is. A stolen key that gets rotated out a week later is only useful for whatever was encrypted with it during that window - not for everything encrypted before or after.

The retention period of the backup itself sets how long that window actually is. A backup rotated out and deleted after 30 days gives an attacker 30 days to crack the key before it becomes useless - a GFS backup kept for 10 years under long-term retention gives them 10 years, which makes the strength of that key far more critical. This doesn’t eliminate the harvest-today-crack-tomorrow risk - an attacker can still exfiltrate an encrypted backup today and attack the key at leisure for as long as that backup exists. But because KMS assigns a distinct key per backup, cracking one key only exposes that single backup, not the entire retention chain. The mechanics of why this holds up are covered in the Encryption section - the point here is simply that retention length and key exposure time are the same number.

TLS certificate lifespan

The same principle shows up at industry scale. The CA/Browser Forum is reducing the maximum lifespan of publicly trusted TLS certificates from the current 398 days down to 47 days by 2029, in phased steps. This isn’t about making certificates harder to forge - it’s about making a compromised certificate or private key expire on its own, fast. The shorter lifespan also forces more frequent key rotation across the ecosystem, which is part of the broader push toward crypto-agility and post-quantum readiness - a topic significant enough to deserve its own page rather than a detour here.

When this doesn’t work: harvest-now, decrypt-later

Time-bound defense fails completely against one specific threat model: harvest-now-decrypt-later. Here the attacker isn’t racing to use a live credential before it expires - they exfiltrate encrypted data and store it offline, indefinitely, waiting for future compute (realistically, a mature quantum computer) to break the encryption later.

This is not a variant of the same problem, it’s a different mechanism, and it needs to be treated as one. There is no validity window to close: the ciphertext itself doesn’t expire, no ticket is timing out, and rotating today’s keys does nothing to protect data an attacker already copied years ago. The only thing moving is the attacker’s available compute - and that clock runs outside your infrastructure, silently, for as long as the attacker wants to hold the data.

There are exactly two real mitigations, and neither is a form of time-bound defense:

• Migrate to post-quantum cryptography before available compute catches up to the strength of the keys protecting your already-exfiltrated data. This is a moving target, but it’s the only technical fix.
• Let the data age out. If the operational value of the backed-up data decays faster than quantum compute matures, the exposure risk shrinks on its own - no technical intervention required. This isn’t a strategy to rely on by default, but it’s a real factor in how much urgency a given dataset deserves.