Encrypting backups is standard practice and rightly so. The consequence, which receives far less attention, is that the backup copies are now exactly as recoverable as the keys are. A backup set that survives a ransomware event, sits on immutable storage and passes every verification check is worthless if the key material was held in a system that did not survive alongside it.
This is not a rare failure. Key management is usually treated as a security control rather than as part of the recovery path, which means it is designed to keep keys safe and not specifically to keep them available during an incident. Those are different goals and they pull in opposite directions.
The two failure modes
Keys are lost outright or they are temporarily unreachable, and the distinction matters because only one of them is recoverable.
Outright loss happens when the only copy of a key lived in a system that was destroyed, encrypted or decommissioned. It also happens through rotation: a key is replaced, the old one is deleted according to policy, and backups written under the old key become unreadable. This is permanent. There is no vendor escalation that recovers it.
Temporary unavailability is more common and more survivable. The key management service is down, the administrator who could retrieve the key is unreachable, the hardware security module needs a quorum of custodians who are not all available, or the key store authenticates against a directory service that is itself being restored. The keys exist, but the recovery waits, and the delay can run into days.
Where keys live and what that implies
Most environments use one of a small number of arrangements, each with a different exposure during a recovery.
| Arrangement | Strength | Recovery exposure |
|---|---|---|
| Keys held inside the backup application | Simple, nothing extra to operate | Lost with the backup server unless separately exported |
| Enterprise key management service | Central control, rotation and audit | Depends on that service and its own authentication surviving |
| Hardware security module | Strong protection of key material | Quorum and physical access requirements slow recovery |
| Cloud provider key service | Highly available, managed | Requires working connectivity and cloud identity |
| Passphrase known to administrators | No infrastructure dependency | People leave, forget, and are unavailable at night |
| Offline escrow copy | Independent of every running system | Only as good as the retrieval procedure and its testing |
Most organizations end up combining an operational store for day to day use with an offline escrow copy for disaster scenarios. That pairing is sound, and the part that usually needs attention is the escrow: whether it is current, who may open it, and whether anyone has ever tried.
Escrow that survives the scenarios it exists for
An escrow copy should be independent of the production environment in every dimension that matters. It should not authenticate through the corporate directory, sit on infrastructure inside the same failure domain, or require a system that is itself part of the recovery sequence. A sealed physical copy in a safe at a separate location is unfashionable and holds up remarkably well.
It also needs a retrieval procedure with named roles, more than one person able to act, and a record of when it was last verified. Split knowledge, where no single person can retrieve the key alone, is a reasonable control provided the number of custodians is large enough that a holiday or a resignation does not block access.
Currency is the most common gap. Keys rotate, backup configurations change, and the escrow copy quietly becomes a snapshot of an arrangement that no longer applies. A scheduled review that confirms the escrowed material matches the keys currently protecting backups is a small recurring task that prevents a complete recovery failure.
Rotation without orphaning old backups
Key rotation is good practice and it creates a specific hazard: backups written under a retired key remain encrypted under it. If retention is seven years and keys rotate annually, seven keys must remain available, not one. Deleting a retired key according to a security policy while backups encrypted with it are still in retention destroys those backups as surely as deleting the data.
The rule that avoids this is simple to state. A key may only be destroyed when no retained copy depends on it, which means key lifetime has to be tied to backup retention rather than to a separate schedule. Where an organization re-encrypts older backups under a current key, the old key can be retired once that process has verifiably completed, and verifiably is the operative word.
This interacts with retention policy changes. Extending retention extends the life of every key involved, and shortening it does not release a key until the affected copies have actually expired. Both directions deserve a check, in the same way that a change to a retention setting deserves a check on what it silently exposes.
What to verify, and how often
Three checks cover most of the risk. First, perform a restore that requires decryption, from a backup old enough to use a previous key, and confirm it completes. A restore test that only exercises the current key proves less than it appears to. Second, confirm that the escrowed material can be retrieved by someone other than the person who placed it there, following only the written procedure. Third, confirm that the key store's own recovery is documented, including how a hardware security module would be rebuilt and its material restored.
These belong in the same schedule as restore testing rather than in a separate security review, because the failure they prevent is a recovery failure. Running them together also makes the dependency visible to the people who will be executing the recovery.
Where Scality fits in the key question
When backups are written to S3 object storage on Scality RING or ARTESCA, encryption can be applied by the backup software before the data leaves it, by the storage system, or both, and each choice places the keys somewhere different. Server-side encryption keeps key handling within the storage platform's own management; client-side encryption keeps it with the backup application. Knowing which model is in use, and therefore which key store the recovery depends on, is the point worth settling explicitly.
Object Lock protects the copies from deletion and alteration for their retention period, which removes one class of loss, and it makes the key material the remaining single point of failure for that data. Protecting immutable copies without an equally durable key arrangement leaves an unrecoverable gap behind a control that looks complete.
Judge the arrangement by a restore nobody helped with
The useful test is a restore performed by someone who was not involved in setting up the key management, working only from the documented procedure and the escrow store, with the production key service treated as unavailable. If that succeeds, the arrangement is sound.
If it does not, the finding is usually one of three: the escrow was out of date, the retrieval required a person rather than a procedure, or a retired key had been destroyed while backups still depended on it. The first two are fixable in an afternoon. The third is not fixable at all, which is why it is worth checking before it is needed.