From “Encrypt Everything” to “Encrypt for the Quantum Era”: The Upwind Cloud Cryptography Framework
For most of the last decade, cloud security teams have lived by a simple slogan: encrypt everything. Encrypt at rest. Encrypt in transit. Use customer-managed keys. Rotate them. Pass the audit. Move on.
That slogan just expired.
In August 2024, NIST finalized the first three post-quantum cryptography (PQC) standards and explicitly told organizations: start using them. Regulators around the world are publishing migration timelines. And adversaries are already running a quieter playbook called “harvest now, decrypt later”, exfiltrate encrypted traffic and backups today, sit on them, and decrypt the moment a cryptographically relevant quantum computer exists.
Cloud cryptography stopped being a checkbox. It’s now a discipline.
The Quantum Problem, in Plain Cloud Terms
A sufficiently powerful quantum computer running Shor’s algorithm breaks the public-key cryptography that underpins basically everything we trust in the cloud:
- TLS handshakes on every API gateway and managed database
- Code signing and certificate chains
- Key wrapping in KMS and Key Vault
- JWTs, mTLS, the works
Now translate that to your actual environment. Every TLS endpoint will eventually need a PQC-capable handshake. Every KMS key is on the critical path. Every S3 bucket and Cosmos DB collection is a candidate for re-encryption. And then there’s the newest, juiciest target: AI workloads, Bedrock, SageMaker, Azure ML, Cognitive Services, concentrating proprietary training data, prompts, and model weights, often with the weakest default crypto settings in the entire environment.
“Encrypt everything” doesn’t answer the questions that actually matter:
- Encrypted with what?
- Wrapped by which key?
- Using which protocol version?
- Is it quantum-vulnerable?
- Will it still be safe in 2030?
To answer those, you need an inventory. Not a spreadsheet. A live view tied to the actual resources running in your cloud.
Introducing the Upwind Cloud Cryptography Framework
The new Cloud Cryptography Framework pulls every cryptography-relevant control across AWS and Azure into a single, coherent view. Instead of crypto being scattered across a dozen compliance frameworks as one clause among hundreds, it becomes a first-class domain you can actually reason about.
A few things make it different from a generic “encryption posture” checklist:
It treats cryptography as one cross-cutting concern, not fifty unrelated findings. The same framework covers encryption at rest, transport security (TLS minimums across managed services), and key management hygiene (CMK rotation, customer-managed vs. platform-managed keys, KMS coverage). One lens. One backlog. As cloud providers roll out ML-KEM, ML-DSA, and SLH-DSA, this surface grows. The framework is built to grow with it.
It treats AI workloads as a cryptography problem. Bedrock Agents, Flows, Prompts, Guardrails. SageMaker domains, training jobs, notebooks. Q Business. Azure Cognitive Services, Synapse, Machine Learning Workspace. Every one of these has dedicated CMK controls in the framework. AI systems concentrate the most sensitive proprietary data you own. They deserve to be in the cryptography conversation from day one, not bolted on later.
What’s Next: A Cryptography Bill of Materials
The framework is a strong starting point, but it’s a posture view. The next step on our roadmap is a Cryptography Bill of Materials (CBOM): a structured inventory of every cryptographic asset in your environment and how they relate.
- Algorithms and parameters
- Keys and what they wrap
- Protocols and the endpoints negotiating them
- Workloads and their cryptographic dependencies
This is where Upwind’s runtime view changes the game. A static config scan tells you an S3 bucket can be encrypted with KMS. Runtime context tells you which buckets are actively serving sensitive data, which keys are actually wrapping them, and which workloads are currently negotiating handshakes you’d rather they weren’t. That difference is what turns a CBOM from a static document into something operationally useful.
More on this as the work matures.
Where to Start
Nobody finishes a PQC migration this quarter. That’s fine. But the inventory work that makes every later step possible can start today and it pays off long before any quantum threat materializes.
- Turn on the Cloud Cryptography Framework. Treat its findings as one unified backlog, not a pile of unrelated misconfigs.
- Close TLS < 1.2 gaps first. They’re exploitable today and a prerequisite for any future hybrid PQC handshake.
- Move foundational data stores to customer-managed keys with rotation enabled. You cannot migrate a key you don’t control.
- Pay disproportionate attention to AI workloads. That’s where the data is most sensitive and the defaults are weakest.
The Bottom Line
The shift to quantum-era cloud cryptography isn’t really a shift in tooling. It’s a shift in granularity. You stop counting how many resources are encrypted and start counting which algorithms, with which keys, protecting which data, under which regulatory regime, with which migration deadline.
The Upwind Cloud Cryptography Framework is built for that level of granularity and it’s already PQC-aware.
The quantum clock isn’t waiting. Neither is the harvest-now-decrypt-later adversary. The good news: the work that makes you quantum-ready also makes you measurably more secure today.
