Imagine an attacker gets one snapshot of your phone's memory. Maybe through malware that was later removed, a brief physical seizure at a checkpoint, or a backup that leaked. They now hold the key your messaging app was using at that moment. The intuitive assumption is that the game is over for that conversation: they have the key, so they can read everything from here on.
For a lot of encryption schemes, that assumption is correct. The static key never changes, so a one-time theft becomes permanent surveillance. Post-compromise security is the design goal that refuses to accept this. It says a conversation should be able to heal, automatically recovering confidentiality even after an attacker has seen a key, as long as they cannot keep watching every exchange forever.
Two halves of the same coin
It helps to line these properties up against the moment of compromise.
| Property | Protects | Question it answers |
|---|---|---|
| Forward secrecy | Messages before the leak | If my key leaks now, are my old messages safe? |
| Post-compromise security | Messages after the leak | If my key leaked, can my future messages become safe again? |
Forward secrecy looks backward in time from the compromise; post-compromise security, sometimes called future secrecy or self-healing, looks forward. A strong protocol provides both, which means a single key exposure ideally leaks only the messages in a narrow window around the moment of the leak, not the entire history and not the entire future.
Compromise is rarely an all-or-nothing event. The honest model is an attacker who gets in, gets discovered, gets evicted, and may get back in later. The valuable property is bounding the damage of each individual breach window rather than pretending breaches never happen.
Why a static key cannot heal
To see why this is hard, consider what recovery would require. If both parties keep using the same long-term key, there is no new secret information entering the system. An attacker who learned that key once knows everything the legitimate parties know. No amount of waiting changes that, because nothing fresh has been introduced that the attacker lacks.
Recovery is only possible if the parties can inject new randomness that the attacker did not capture. The mechanism that makes this work in modern messaging is a repeated Diffie-Hellman key exchange woven into the ongoing conversation. Each new exchange mixes in fresh ephemeral key material. If the attacker missed even one of these exchanges, they are locked out of everything derived from it.
The ratchet that does the healing
The Double Ratchet algorithm, used by the Signal Protocol, is the canonical example. It combines two ratchets. A symmetric-key ratchet advances a hash chain with every message, which gives forward secrecy because old chain keys are deleted and cannot be recomputed. A Diffie-Hellman ratchet runs whenever the direction of conversation turns, generating a fresh key pair and performing a new exchange.
That second ratchet is the source of post-compromise security. Picture the attacker holding a stolen key. As soon as your device performs its next Diffie-Hellman step, with a new private key generated locally that the attacker never saw, the shared secret folds in entropy the attacker does not have. From that step forward, their stolen key is worthless. The conversation has healed, without either user doing anything deliberate.
The crucial detail: healing depends on the attacker being passive after the compromise. If they can keep reading the device's memory continuously, they capture every new private key as it is generated, and recovery never happens. Post-compromise security defends against an attacker who got in and got out, not one who is still resident.
The same idea in groups
Two-party ratchets do not scale cleanly to large groups, because a fresh Diffie-Hellman between every pair of members would cost too much as the group grows. This is one of the problems the Messaging Layer Security (MLS) protocol, RFC 9420 was built to solve. MLS uses a structure called a ratchet tree so that any member can update their own key material in a single operation, and the new secret propagates to the whole group in time that scales with the logarithm of group size rather than linearly.
The practical effect is the same goal at group scale. When a member performs an update, often called a self-update, every key derived afterward is unknown to an attacker who compromised that member before the update. A group can rotate its way back to secrecy after a member device is breached, and the cost stays manageable even for groups of thousands.
What this means for how you use a messenger
Post-compromise security is automatic, but its effectiveness depends on the conversation staying active. The healing happens during ratchet steps, which occur as messages flow. A long-dormant conversation that has not exchanged anything since a compromise has not had the chance to perform a fresh key exchange, so it has not healed yet. Activity is what drives recovery.
There is also a hard limit worth being clear about. These properties protect session keys, not the messages already sitting in plaintext on a device. If an attacker has your unlocked phone, ratchets are not the relevant defense; device encryption and a strong lock screen are. Post-compromise security is about the cryptographic state of a live conversation, and within that scope it turns a permanent breach into a temporary one.
The takeaway
A good way to judge a messaging protocol is to ask what a single key theft costs. If the answer is "every message, forever," the design has no self-healing. If the answer is "only the messages in the window before the next key exchange," the protocol has both forward secrecy and post-compromise security, and that bounded window is the difference between a contained incident and total exposure. Haven uses MLS for group chat for exactly this reason: the same self-healing math, extended to conversations with more than two people.