Follow the keys as well as the data

A storage product's “AES encrypted” label is useful but incomplete. Find out how the data key is created, where it lives, how it is wrapped or transported, and how a future restore recovers it. A PQC assessment needs that whole path.

Symmetric encryption and public-key cryptography face different quantum considerations. NIST's PQC FAQ continues to distinguish AES from the public-key migration problem. A TLS scanner cannot assess a disk, backup key, password-derived key, or storage service's internal key management.

1. Map the data and key lifecycle

Layer	Questions to answer	Useful evidence
Stored data	What is encrypted? Which algorithm/mode and key size? Are replicas, exports, snapshots, and temporary files included?	Deployed configuration and product documentation for that version.
Data-encryption key	Who generates it? Is it unique per object, volume, tenant, or backup? Who can retrieve it?	Key-management architecture and access policy, without key material.
Key wrapping / encapsulation	How is the data key protected? Does recovery rely on RSA, elliptic-curve exchange, a KEM, or a symmetric wrapping key?	Exact algorithm, provider/HSM version, and supported migration procedure.
Transport to storage or KMS	Which client, proxy, service endpoint, and internal connection carry data or keys?	Dated TLS/application evidence for each relevant hop.
Recovery	Can the offline recovery tool understand new formats and recover old backups? Who holds recovery authority?	A controlled restore result and documented dependencies.

The NIST key-management recommendation provides a broader framework for key protection and lifecycle management. Use your product's supported implementation rather than inventing a wrapping scheme.

2. Collect a read-only inventory

Start with the storage/backup console's configuration export, the KMS key metadata API or console, and the documented backup manifest. Collect identifiers, algorithms, versions, retention requirements, and access roles. Do not export private keys, recovery secrets, plaintext records, or tokens into your worksheet.

There is no universal safe command that reveals every product's at-rest cryptography. Use the product's documented read-only inspection path and the vendor questions when an algorithm or dependency is not exposed.

Illustrative worksheet record:

Asset: customer archive backups
Required confidentiality: record the actual retention/sensitivity requirement
Data encryption: vendor-documented AES configuration; confirm deployed settings
Key protection: unknown — ask backup/KMS owners
Upload/download TLS: record evidence for each endpoint
Recovery environment: not yet tested with proposed update
Next action: document key wrapping and run an isolated restore test
Evidence status: partially documented; important gaps remain

Keep “vendor documents AES” distinct from “we verified the deployed setting,” and keep key protection unknown until the right owner provides evidence.

3. Prioritize long-lived and captured data

Record how long the information must stay confidential, how many copies exist, and whether an adversary could already have captured ciphertext plus a vulnerable wrapped key or exchange. Upgrading transport protects future traffic; it cannot recall an older intercepted copy.

Likewise, rewrapping a current data key does not change a stolen historical copy of its earlier wrapping. If your risk analysis calls for new data keys or re-encryption, use the vendor's supported migration and recovery procedure. Rotation, rewrapping, and re-encryption are different operations; establish which one the product actually performs.

4. Test a supported change on recoverable copies

Choose a representative nonproduction dataset and retain a known-working recovery path. Document the baseline product, format, algorithm, key identifiers, and permissions.
Apply the vendor-supported upgrade or migration to that test copy. Include the storage client, KMS/HSM, replication, backup agent, and recovery tool when they are dependencies.
Restore both a pre-change backup and a new backup in an isolated environment. Verify expected contents and permissions without placing production secrets in test logs.
Test failed/unauthorized key access and a missing dependency. A readable file restored through an authentication bypass is not success.
Measure duration, resource use, and recovery objectives. Confirm the rollback and old-format compatibility before scheduling production work.

A storage migration can be harder to undo than a software deployment. Do not discard old keys or recoverable backups until the documented retention, restoration, and destruction requirements are satisfied.

5. Keep the remaining gaps visible

Your record should cover storage encryption, key protection, transport, recovery, and vendor dependencies separately. A verified TLS result may close one transport question while all other categories remain open. Assign an owner and retest date to each unresolved item in the private worksheet.

Next, assess backup manifests, signed software, and recovery-image authenticity, and request missing guarantees using the vendor migration checklist.

Documentation reviewed 25 September 2026. This is a planning and verification workflow, not a product-specific encryption or key-rotation script.