CWE-324 is the weakness of using a cryptographic key or password after its expiration date. The longer a key stays in service, the longer an attacker has to attack it.
Any team that issues certificates, API keys or signing keys can run into this, along with the vendors whose products consume them.
How it happens
MITRE is careful here. An expired key is not automatically compromised. But keys that stay in use for long periods lose integrity over time, so they should be replaced within a period proportional to their strength.
It happens when nobody owns rotation, when the system never checks an expiry date, or when replacing a key is painful enough that people put it off. One observed example, CVE-2021-33020, describes a hospital picture archiving and communication system that used a key or password past its expiration date.
What an attacker gains
A key in use past its date may be compromised, which can give a malicious user access to whatever it protected: bypassing access control, assuming an identity or gaining privileges.
How to find it
Inventory your keys and certificates with their issue and expiry dates. Alert well before expiry, and check that your software refuses expired material rather than quietly accepting it.
How to fix it
MITRE's mitigation is about design. Build the user interface so users are notified before a key expires, understand why a new key matters, and are walked through replacing it as painlessly as possible. For services, automate rotation so it needs no human memory.
Quick check
Does an expired key mean the data was stolen?
No. It means the safety margin has shrunk, and the key should be replaced.
