Least Recently Modified (LRM) eviction is a cache or storage cleanup method that removes the item whose content has stayed unchanged for the longest time. In identity and security systems, it helps control space by discarding stale records, but it can retain frequently accessed items that are still being updated.
How LRM eviction works
Least Recently Modified eviction removes the entry that has remained unchanged for the longest time, rather than the one that has been idle the longest. That makes it a content-staleness policy, useful when freshness of the stored state matters more than access frequency.
In practice, LRM is most useful when many entries are frequently read but only some are actively updated. The policy preserves hot records that still change, while steadily aging out stable records that have not been touched for a long time.
Why LRM differs from common cache eviction policies
LRM is easy to confuse with least-recently-used eviction, but the decision signal is different. LRU looks at access time, while LRM looks at modification time, so an item can be heavily accessed and still remain protected if it keeps changing.
That distinction matters in identity and security systems where the goal is not only to conserve space, but to avoid discarding records that are still operationally active. A stale, unmodified item is a stronger candidate for removal than a recently updated one, even if the updated item is only lightly accessed.
Where LRM is useful in security systems
LRM fits caches, registries, metadata stores, and other lookup layers that accumulate many durable records over time. It is especially useful when the system keeps state for sessions, policy objects, tokens, approvals, or synchronisation data and needs a simple way to trim old entries without disrupting active change flows.
The policy can improve storage efficiency, but it also shapes what the system continues to remember. Because LRM favours recently modified items, it tends to preserve records that are still being changed, which can be a sensible proxy for operational relevance in many security workflows.
Trade-offs and implementation considerations
LRM is only as good as the meaning of “modified” in the underlying system. If the write path includes routine refreshes, noisy updates, or metadata churn, the eviction order may reflect housekeeping activity rather than true business importance.
Designers also need to decide whether modification time should be reset by every change or only by material changes. That choice affects whether LRM protects genuinely active records or simply rewards the noisiest ones, so the policy should match the semantics of the data being stored.
Risk and Threat Considerations
LRM can become risky when modification time is a poor proxy for value. An attacker or a buggy process that repeatedly rewrites low-value records may keep them resident while more useful but quieter records are evicted, which can distort cache behaviour and consume capacity needed for legitimate state.
Failure mechanism: The eviction policy trusts recency of modification, so noisy updates, churn, or deliberate write amplification can skew retention and prevent truly expendable records from being removed.
Impact: The system may waste memory or storage on low-value entries, reduce cache effectiveness, and in the worst case push out records that are still important for security, availability, or audit workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 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 CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | LRM depends on knowing what records and stores exist to manage cleanup properly |
| Recommendation — Inventory the stores that use LRM so eviction rules can be applied consistently. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | LRM operates on stored components and records that should be inventoried and governed |
| SC-28 — Protection of Information at Rest | LRM influences how long data remains resident in storage and caches | |
| Recommendation — Maintain an accurate inventory of caches and storage components that rely on LRM. Limit retention of stale data in stores that hold sensitive information. | ||
| ISO/IEC 27001:2022 | A.8.13 — Information backup | LRM can affect retention and removal of stored information, which must align with recovery needs |
| Recommendation — Align eviction rules with backup and recovery requirements before removing stored records. | ||
Practitioner Guidance
What to watch for: Use LRM only when modification time really correlates with operational value. If frequent writes are normal but not meaningful, pair the policy with size limits, explicit expiry, or separate handling for records whose lifecycle should not depend on change frequency.
Governance implication: Teams should define what counts as a meaningful modification before relying on LRM, because the eviction rule inherits that definition. When the semantics are unclear, the policy can quietly preserve the wrong items for too long.