Why seven-year recordings need post-quantum keys

An attacker does not need a quantum computer today to put your recordings at risk. They only need to copy encrypted files or captured traffic now and keep them. When a large enough quantum computer exists, the public-key algorithms in wide use today, RSA and elliptic-curve cryptography, can be broken, and everything protected by them can be opened.

Security agencies call this harvest now, decrypt later. It matters most for data that must stay confidential for a long time, and call recordings are exactly that kind of data.

Regulated organisations keep recordings for years. Trading and advice calls in the European Union must be kept for at least five years under MiFID II, and up to seven when a regulator asks. Many banks, insurers and public bodies keep conversations for seven years or more for disputes, complaints and investigations.

Those recordings hold exactly what an attacker wants: identity checks, account details, health information and the voices of customers and staff. A recording made in 2026 and kept until 2033 must stay confidential for the whole period, so it has to be protected against the attacks of 2033, not just today's.

Most recording systems use two layers of protection.

• The audio itself is encrypted with a symmetric cipher such as AES-256. Quantum computers weaken symmetric ciphers only modestly, and AES-256 is still considered safe.
• The key that unlocks each recording is usually protected, or wrapped, with RSA or elliptic-curve cryptography. This is the layer a quantum computer breaks.

So the fix is not to re-encrypt every recording with a new cipher. It is to change how the keys are wrapped.

In August 2024 the United States National Institute of Standards and Technology (NIST) published FIPS 203, which standardises ML-KEM, a key-encapsulation mechanism designed to resist quantum attacks. NIST has also proposed retiring today's quantum-vulnerable public-key algorithms by 2035.

A sensible way to adopt it is a hybrid mode: each key is protected by both a classical algorithm and ML-KEM, so it stays safe unless both are broken.

1. Find out what you keep. List every recording store, its retention period and the encryption it uses today.
2. Give every recording its own key. A single compromised key should open one call, not an archive.
3. Wrap those keys with ML-KEM in hybrid mode. Start with new recordings, then re-wrap the keys of the archive. The audio does not need to be re-encrypted.
4. Keep keys away from the media. Hold them in a dedicated key management system, never in the same store as the recordings.
5. Make sure no one person can open everything. Split the root secret between custodians and log every key operation.
6. Plan for rotation and destruction. Old keys must still open old recordings, and destroying a key should provably destroy access to its recordings at the end of retention.

iFlux Recorder encrypts each recording with AES-256-GCM under its own key the moment it is written. CoreSec KMS wraps those keys with ML-KEM in a hybrid mode, splits the root secret between two custodians and keeps keys separate from the media. Archived and retired keys still decrypt older recordings, and the whole estate can run on-premise, including air-gapped sites, or in your own cloud.