What is the difference between cache expiry and invalidation?

How expiry and invalidation differ in practice

Cache expiry is time-based. You set a TTL, and the cached entry becomes unusable when the clock runs out. Invalidation is event-based. The cache is cleared or refreshed because something material changed, such as an updated permission, revoked token, rotated secret, or changed source record. The distinction is not academic, because the wrong choice can leave stale state in use after the business truth has already changed.

Expiry is simple and predictable, which is why it is common for content, lookups, and low-risk data. Invalidation is more precise when the cached value represents security-sensitive state or fast-moving business facts. For identity-related caches, the question is whether the risk is governed by time or by an external change event. If the answer is “the event,” expiry alone is usually too weak.

When the source of truth changes before the TTL ends, expiry creates a window where the cache remains temporarily wrong. That window may be acceptable for page fragments or reference data, but it is much less acceptable for authorization decisions, session state, entitlement lookups, and other data where stale results can change access outcomes. For a broader view of lifecycle control, see the NHI Lifecycle Management Guide, which treats rotation and offboarding as governed state changes, not time-only events.

When expiry is enough and when invalidation is the stronger control

Expiry is usually enough when the cache is just an optimisation layer and stale data causes only minor inconvenience. Examples include display data, low-impact metadata, or values that are naturally short-lived and safe to recompute. It works best when you can tolerate a bounded period of inconsistency and the cost of constant invalidation would be higher than the benefit.

Invalidation is the stronger control when correctness depends on the source changing immediately, not eventually. That is the case for permission changes, revocation, secret rotation, account disablement, and other state transitions where using the old value would be unsafe. In those cases, the cache should follow the lifecycle of the underlying identity or secret, not just a time interval. The Guide to NHI Rotation Challenges is useful here because it shows why rotation and refresh problems are really lifecycle-control problems, not merely housekeeping.

Invalidation also matters when the source can change unpredictably. A TTL cannot express “immediately stop trusting this value if the upstream object changes.” Event-driven invalidation, refresh-on-write, or push-based cache busting are better fits because they tie cache freshness to the actual change condition. The practical rule is simple: if stale data can produce the wrong authorization, the wrong secret, or the wrong trust decision, treat invalidation as the primary control and expiry as a backup limit.

Designing cache freshness without creating stale-truth risk

The best pattern is often to combine both. Use expiry as the fail-safe upper bound, but use invalidation to shrink the stale window as much as possible. That gives you a hard limit on drift without relying on the clock as the only freshness mechanism. This is especially important when the cached item represents policy, ownership, or credentials that can change outside the cache’s control.

A useful design question is whether the cache is serving content or authority. Content caches can usually tolerate delay. Authority caches, including permission decisions and identity state, generally should not. For security-sensitive state, design the invalidation path first, then add TTL as the safety net. For secret and key lifecycle thinking, NIST SP 800-57 Key Management is a strong reference because it frames cryptographic material around lifecycle, rotation, and replacement rather than passive ageing.

If your system has many producers of change, cache coherence becomes an operations problem as much as a correctness problem. The more distributed the source updates, the more you need clear invalidation triggers, observability on stale reads, and a defined fallback when the invalidation path fails. For identity and authorization data, that usually means measuring how quickly revocations, rotations, and entitlement changes propagate, not just whether the cache eventually expires.

Risk and Threat Considerations

Stale caches become a security issue when the cached value controls access, trust, or secret validity. The risk is not the cache itself, it is the period where the system continues to use an outdated answer after the source of truth has already changed. That can extend access after revocation, preserve an overprivileged decision, or keep a rotated credential usable longer than intended.

Failure mechanism: A time-based TTL expires too late for a business event, so the cache continues returning a now-invalid value until the timer ends or the entry is manually cleared.

Impact: Attackers or insiders may exploit the stale window to retain access, abuse revoked permissions, or rely on outdated trust state before the cache converges.

Practitioner Guidance

What to prioritise: Classify every cached field by consequence. If a stale read can change access, entitlement, revocation, or secret validity, treat invalidation as mandatory and TTL as secondary.

What to verify: Confirm that the invalidation trigger is tied to the real source-of-truth event, not just a polling interval. If refresh depends on manual cleanup or “eventual” batch jobs, the cache is probably too loose for security-sensitive state.

Practitioner takeaway: Expiry limits age, but invalidation preserves truth; for anything that affects authority or trust, freshness should follow the change event first and the clock second.

Related resources from NHI Mgmt Group

• What is the difference between direct access and effective access in Active Directory?
• What is the difference between managing human identities and non-human identities?
• What is the difference between continuous authorisation and static access controls?
• What is the difference between JIT access and VPN access?