Recover Backups Without the Primary Tenant

Start a recovery exercise from a clean device with no saved sessions. Assume the main business tenant is unavailable and the usual administrator cannot help. Can another authorised person locate the backup, authenticate to its storage and decrypt the required restore point?

If the answer depends on opening a password vault through the failed identity provider, the recovery plan has a circular dependency. Adding another backup destination will not fix that dependency if both destinations use the same login path.

Draw the access chain before changing it

For each important workload, list the application backup format, repository location, storage account, encryption mechanism, authentication method and owner. Then record what each step requires. A storage login might need an email code; that mailbox might require the identity service being restored.

Include billing and subscription administration. An intact repository is little help when nobody can resolve an account suspension or identify the organisation that owns it. Keep contract identifiers and supplier contact details with the recovery instructions, while storing secrets in the controlled recovery mechanism.

Use a small table with a final column headed “available without production?”. Test that column. Do not fill it with assumptions based on a browser which has been signed in for six months.

The NCSC recommends backups as part of a small organisation's basic protection and explains why independent copies and recovery matter. Its backup guidance is a useful starting point. The access chain is the practical work needed to make those copies usable.

Distinguish a repository password from storage access

Encrypted backup tools often have two separate gates: permission to download repository data and possession of the key material needed to decrypt it. Passing one gate does not satisfy the other.

Restic, for example, supports multiple repository access keys or passwords. That allows a separately controlled recovery credential instead of handing every operator the production automation password. Its key-management commands and behaviour are documented in the restic encryption guide.

This is still a powerful credential. Store it under named ownership, protect it from casual use and record access. A second credential does not create an independent backup: it provides another route to decrypt the same repository.

When an administrator leaves, review the repository credentials they could access as well as the storage login. Removing their cloud account does not erase a decryption secret they previously possessed. Decide whether the incident requires replacing access credentials or rebuilding protection around potentially copied data.

Cloud-managed keys need a different recovery plan

Do not assume every encryption key can be exported into an emergency envelope. With a managed key service, the recovery requirement may be to retain the key and recover authorised access to the service.

AWS KMS documents that deleting a key can make the encrypted data unrecoverable. It provides a waiting period for scheduled deletion and a cancellation path before the operation completes. The KMS deletion guide sets out those limits.

For that design, capture the key identifier, region, account and permitted recovery role. Monitor changes that can disable decryption. Confirm how the supplier verifies ownership if normal authentication is unavailable. A stored key identifier is an inventory item, not a copy of the key.

Build a controlled emergency package

The package should contain enough information to start recovery, but no broad collection of unrelated secrets. Include the approved recovery device requirements, repository instructions, contact tree, credential-retrieval process and a short list of acceptance checks.

Decide who can authorise emergency access and who can perform it when the primary administrator is absent. For a very small firm, this may be the owner and a named support provider. Avoid a process that requires three people who are always away together.

Where an offline copy is appropriate, protect it physically and define how replacements invalidate old copies. Where a separate digital vault is used, inspect its identity and recovery dependencies too. “Separate product” does not necessarily mean separate failure path.

Prove the whole path

Restore a representative file and an application backup into an isolated location. Verify content and permissions, then run an application-specific check. Merely listing snapshots proves less than retrieving and opening them.

Restic's restore documentation describes restoring selected snapshots and paths. Select a specific snapshot for the exercise so the result is repeatable, and avoid overwriting live files.

Record how long access took, which credentials were used and where the operator had to ask for undocumented information. Close those gaps before adding more automation. Review the package after an identity-provider change, key rotation, backup migration or staff departure.

The existing Microsoft 365 break-glass guidance addresses tenant administration. Backup recovery extends beyond that tenant: storage ownership, decryption and a working destination must all survive the same outage.

References

• NCSC: Backing up your data. Accessed 17 October 2026.
• Restic: Encryption and key management. Accessed 17 October 2026.
• AWS: Delete an AWS KMS key. Accessed 17 October 2026.
• Restic: Restoring from backup. Accessed 17 October 2026.