up:: Migration Architecture MOC

The Three-Way Map

The three-way map is the framework that locates the exact line between what your cloud provider’s post-quantum work already covers and the risk that stays yours, using two moves. Move 1 is a written question to the provider, sent through your account team: for each managed service you use, which endpoints negotiate a post-quantum key exchange today, which are on the roadmap with a date, and which parts of your data path stay classical. Move 2 is a capture of a live connection on your most sensitive endpoints, read for the negotiated key-exchange group. Together they split the estate three ways: connections the provider already protects, cryptography that’s yours to migrate no matter whose servers it runs on, and traffic already harvested that no one can recover.

The short version:

• Move 1 is the written question, through the account team, per managed service: which endpoints negotiate a post-quantum key exchange today, which are on the roadmap with a date, and which parts of the data path stay classical.
• Move 2 is a live capture on the most sensitive endpoints, read for the negotiated key-exchange group, which is Wire Over Config applied at the provider boundary.
• It goes in writing because a verbal “yes, we support post-quantum” collapses three answers into one, and the written reply is what you keep for your own auditors.
• The output splits the estate 3 ways: provider-protected connections, cryptography that’s yours wherever it runs, and traffic already harvested that no upgrade reaches.
• The map applies the moment a managed service sits in your data path, and being on the cloud shrinks the migration while keeping the accountability yours.

Think of a city replacing its lead water mains. The utility swaps out the pipes up to your property line and publishes which streets are done, so part of the fix genuinely arrives without you lifting a finger. The plumbing inside your walls belongs to you, and no work the utility does out in the street changes a pipe in your kitchen. And the water that already ran through the old pipes is spent, because no replacement main reaches backward into last year. A cloud estate under the quantum transition has the same three territories, and the map is how you draw them.

What is the three-way map?

The three-way map is a coverage sort for cryptography at the provider boundary. It exists because the answer to “our provider handles the quantum problem” is a split: some of it really is theirs, and the parts that carry your risk are yours. The framework has exactly two moves and one output, and each piece earns its place.

1. Move 1, the written question. Through the account team, in writing, per managed service: for each managed service we use, which endpoints negotiate a post-quantum key exchange today, which are on the roadmap with a date, and which parts of our data path stay classical?
2. Move 2, the wire check. Capture a live connection on the endpoints carrying your most sensitive data and read the negotiated key-exchange group off the handshake.
3. The output. Every connection and cryptographic surface in the estate lands in one of three categories: the provider already protects it, it’s yours to migrate, or it was already harvested and sits beyond anyone’s reach.

The map applies wherever a provider operates part of your data path, which today means nearly every enterprise estate: managed services, CDNs, cloud key management, hosted load balancers. Where there’s no provider in the path at all, the sort changes shape, which the limits section below covers honestly. The map is the cloud-specific cut of the same reality The Three Zones sorts at estate scale, drawn tight against the provider boundary where the “isn’t this their problem?” question actually lives.

Where does provider coverage actually stop?

At the shared-responsibility line, which every major cloud provider draws the same way: the provider secures the infrastructure, and you secure what you run on it. AWS states it as security of the cloud being the provider’s job and security in the cloud being the customer’s, and it places data encryption, key management, and encryption-option choices on the customer side. Cryptography splits along exactly that line, so the provider migrates the cryptography it operates and you migrate the cryptography you chose.

Source: AWS, “Shared Responsibility Model,” (security of the cloud versus security in the cloud; the customer manages data encryption and key configuration), aws.amazon.com.

The provider side of the line carries real, finished work. Chrome and Edge switched the hybrid group X25519MLKEM768 on by default in Chrome 131 in November 2024, the major CDNs enabled it server-side, and Cloudflare reports a majority of human HTTPS traffic on its network protected by post-quantum encryption, a live figure that keeps climbing. On AWS, the control-plane endpoints for KMS, ACM, and Secrets Manager negotiate hybrid ML-KEM TLS “in non-FIPS endpoints in all AWS Regions in the aws partition,” which is a scope worth reading twice if you run on FIPS endpoints, and AWS-LC was the first open-source module to carry ML-KEM inside a FIPS 140-3 validation. The full current-state picture, including the caution that every adoption percentage is a point-in-time reading, lives in Cloud and Browser PQC Status.

Source: Google Security Blog, “A new path for Kyber on the web,” September 13, 2024, security.googleblog.com; Cloudflare Radar, “Post-Quantum Encryption Adoption,” radar.cloudflare.com/post-quantum; AWS Security Blog, “ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager” (7 April 2025), for the three services, the non-FIPS-endpoint scope, and the AWS-LC validation first.

What stays on your side depends on the service model, and the shift catches teams out because the same estate usually runs all three models at once:

Service model	What the provider migrates	What stays yours
IaaS	The physical infrastructure and its own management endpoints	The OS, the libraries, the whole TLS stack, your keys, your certificates, exactly as if the machines were on-premises
PaaS	The runtime, and often TLS termination and certificate handling	The encryption options you select, the keys you bring, the application-layer cryptography in your code
SaaS	Essentially all of the product’s cryptography	Your configuration switches, your contract terms, and the obligation to know what the product protects

Across every model, the customer side keeps the data-layer encryption choices, the application-layer cryptography your own code performs, the keys under your control, your internal PKI, and your code signing. A provider turning on a post-quantum handshake at its front door changes nothing about a database your application encrypted with a key you generated, because that cryptography runs above the layer the provider controls. The wider anatomy of surfaces a vendor operates inside your estate, and the procurement levers that move them, is Vendor-Controlled Crypto Surfaces.

The accountability stays put too. OMB M-23-02, the federal rule for agency cryptographic inventories, requires the inventory to cover cloud-hosted and contractor-operated systems and keeps the accountability with the agency rather than the vendor, and OMB M-26-15 directs agencies to engage their cloud providers to delineate post-quantum migration responsibilities under the shared-responsibility model. That’s federal practice, and it’s the direction private-sector regulators are moving: the provider runs its cryptography, and the obligation to know where your data is protected never transfers. The propagation machinery that carries those deadlines into the cloud market is FedRAMP and PQC.

Source: OMB, “Migrating to Post-Quantum Cryptography,” M-23-02, November 18, 2022, whitehouse.gov; OMB, “Execution of the Migration to Post-Quantum Cryptography,” M-26-15, June 24, 2026, §3.C, whitehouse.gov.

How do you run the written question?

Send one question, through your account team, in writing, and hold the reply. The wording matters, so here it is as sent:

For each managed service we use, which endpoints negotiate a post-quantum key exchange today, which are on the roadmap with a date, and which parts of our data path stay classical?

Why through the account team. The account team is the channel that routes a question to the vendor’s product and compliance organizations and returns an answer on the record, in a thread you can produce later. The support desk returns documentation links, and documentation describes the platform in general rather than the services you actually run.

Why in writing. A verbal “yes, we support post-quantum” collapses three answers into one word. Shipped today, planned for next year, and never planned all fit comfortably inside “support,” and each one prices your risk differently:

1. Negotiating today is coverage you confirm on the wire and then take.
2. On the roadmap with a date is a schedule you hold the vendor to, and a date you diff at renewal.
3. Stays classical is your planning input, because it names the legs of your data path that keep feeding the harvested category until something changes.

The written form forces the vendor to distribute its answer across those three bins, endpoint by endpoint, and the reply that comes back is the map’s raw material.

Why the reply is an audit artifact. When an auditor, a regulator, or an enterprise customer asks how you know what your provider covers, a dated written reply from the provider is evidence, and a recollection of a call is a rumor. Federal agencies already operate this way: the inventory obligation reaches their cloud, the accountability stays theirs, and the responsibility split gets delineated with the provider explicitly rather than assumed. Holding the written reply puts you in the same defensible position ahead of whoever regulates you.

How do you run the wire check?

Move 2 is Wire Over Config applied at the provider boundary: the configuration and the vendor’s answer both state what’s permitted or promised, and only the wire records what a real connection actually negotiated. The full rule, the 30-day log instrument, and the fields to pull live in that note; here the move is the spot check, a capture of one live connection from your own workload to each endpoint carrying your most sensitive data, read for the negotiated key-exchange group.

The reading is binary. X25519MLKEM768 on the handshake means post-quantum key exchange genuinely happened on that connection. A classical curve means it fell back or was never offered, and the capture catches the silent case where both ends could speak post-quantum and the connection still completed classical, which no status page and no reply letter will ever show you.

What goes in each of the three categories?

The two moves feed one output, and every surface lands in exactly one place:

Category	What lands in it	What you can do	The artifact
Connections the provider already protects	Browser-to-edge traffic behind post-quantum-default CDNs, managed-service endpoints whose captures show the hybrid group	Confirm it on the wire and take the win	The capture and the written reply, agreeing, filed together
Cryptography that’s yours to migrate	Application-layer encryption, keys under your control, TLS stacks on rented compute, internal PKI, code signing, every provider option that ships disabled, every roadmap item you’ll have to adopt when it lands	Schedule it, own it, enable it, and where it sits inside a managed service, file the request and hold the date	Migration plan rows with named owners, plus the roadmap dates you diff at renewal
Traffic already harvested	Classical connections captured before the upgrades, wherever a collectible path carried data whose secrecy outlasts the quantum timeline	Bound it by data lifetime and brief it honestly	A dated statement of exposure the board plans against

The first category is earned by evidence, never by press release: a surface belongs there when the written reply and the capture agree. The second category is the working map of your migration, and it’s larger than most teams expect because it holds both the cryptography you operate and the adoption work for everything the provider ships, since an option that exists and was never enabled protects nobody. Some of the second category sits inside managed services where the only available move is filing the request and waiting on the provider’s clock, and the map records that honestly as yours-with-a-dependency rather than theirs.

The third category is the one, and it’s what makes the map trustworthy. An adversary that recorded your classical traffic last year holds ciphertext that no provider roadmap reaches, because an upgrade applied today protects connections from today forward and the archive already exists. That mechanism, and why it makes harvesting the one quantum risk that’s already live, is Harvest Now, Decrypt Later (HNDL). Whether a given slice of harvested traffic actually matters comes down to whether its secrecy has to outlast the arrival of a capable quantum computer, and the inventory of what clears that bar is What Data Is Vulnerable to Harvest Now, Decrypt Later. A map that shows an empty third category was drawn from wishful thinking, since every estate that moved sensitive data over classical TLS across collectible paths has one.

What does the map look like on a real estate?

Take a generic company on one cloud provider, running 3 managed services: a public web application behind the provider’s CDN and managed load balancer, a managed database holding customer records that the application encrypts at the application layer with keys from the provider’s key-management service, and the provider’s secrets manager holding service credentials. Around those sit the company’s own microservices on rented compute talking TLS to each other, and a nightly export to a partner over TLS from a VM the company runs. The details below are illustrative; the shape is what recurs.

The written question goes out through the account team, and the reply comes back split, which is the point: the CDN edge and the key-management and secrets control-plane endpoints negotiate a hybrid group today, the managed database’s TLS listener is roadmapped with a date next year, the CDN-to-origin leg supports the hybrid group only when the tenant enables an option, and the partner-export path goes unmentioned because it runs entirely on the company’s own VM.

The captures, taken before the reply is read, add two facts the letter can’t. The database listener shows a classical curve, consistent with the roadmap. The CDN-to-origin leg also shows classical, because the option the reply describes as available was never switched on, which is exactly the silent case the wire check exists to catch. The estate resolves like this:

Surface	Category	Why it lands there
Browser traffic to the CDN edge	Provider already protects	Default-on hybrid at the edge, confirmed by capture
Key-management and secrets control-plane calls	Provider already protects	Reply and capture agree on the hybrid group
Managed database TLS listener	Yours to migrate, on the vendor’s clock	Roadmapped with a date; you hold the date and adopt on arrival
CDN-to-origin leg	Yours to migrate	Shipped as an option, disabled until you enable it
Application-layer encryption and its keys	Yours to migrate	Customer-side of the shared-responsibility line, wherever it runs
Service-to-service TLS on rented compute	Yours to migrate	Your stack on IaaS, exactly as if on-premises
Partner export from your VM	Yours to migrate	Your TLS stack, your partner’s client, no provider in the loop
Classical connections those paths carried before the flips	Already harvested	Recorded ciphertext sits beyond every roadmap; weight it by data lifetime

Two moves, a week of elapsed time, and the estate has stopped being “we’re on the cloud, we’re probably fine” and become 8 rows with owners, dates, and one dated exposure statement.

Common misconceptions

1. “Our provider supports post-quantum, so our estate is covered.” Supported is a fact about the provider’s code, and covered is a fact about your connections. Endpoints turn the capability on one at a time, so the provider-wide yes can be completely true on a day when half the endpoints your architecture touches still negotiate classical key exchange. The map replaces the provider-wide yes with a per-endpoint answer.
2. “They gave us a roadmap, so it’s handled.” A roadmap is a schedule for future protection, and until each date lands, the affected paths keep feeding the harvested category. Roadmap dates also move, which is why the reply gets date-stamped and diffed at renewal rather than filed and trusted.
3. “The CDN went post-quantum, so the whole path is covered.” The edge protects the leg from a visitor’s browser to the CDN network. The separate leg from the CDN back to your origin negotiates its own handshake and routinely falls back to classical, so the connection carrying your data across the internet can be the exposed one while the public-facing half looks fully modern.
4. “Contractually it’s the provider’s problem.” The contract allocates operational work, and the obligation to know where your data is protected, and to prove it to a regulator or a customer, stays with you. Federal practice already writes this down: agency inventories must cover cloud-hosted and contractor-operated systems, with accountability kept at the agency. A contract can buy you the migration labor and can never buy you out of the answer.
5. “The account team said yes on the call, and that’s as good as the letter.” The verbal yes is the collapse the written question exists to prevent, and it also leaves you holding nothing. 12 months later, an auditor asks how you established provider coverage, and the difference between a dated reply and a remembered call is the difference between evidence and anecdote.
6. “Our third category is empty.” Every estate that carried sensitive data over classical TLS across a collectible path has a harvested category, and its size is governed by data lifetime rather than by optimism. A map showing none usually means nobody asked which data’s secrecy outlasts the quantum timeline, and the honest, bounded version of that category is what makes the rest of the map credible.

Pro tips

1. Ask per service, never per provider. Coverage varies wildly inside a single vendor: on AWS, the key-management, certificate, and secrets endpoints negotiate hybrid ML-KEM while other services move on their own clocks, because the library layer ships an algorithm long before every service endpoint offers it. A per-provider question invites a per-provider yes, and the yes will be true of the most-migrated endpoint and silent about the rest.
2. Date-stamp the reply and diff it at renewal. The reply is a snapshot, and the next one shows you what moved: roadmap dates that slipped, endpoints that shipped, classical legs that got quietly reclassified. A slipped date across two consecutive replies is renewal-negotiation material, and the stamps are what turn it from a grievance into leverage.
3. Run the capture before you read the reply. Taken first, the capture is an independent measurement, and agreement between the two becomes real confirmation. Taken after, it quietly turns into an exercise in confirming what the vendor told you, and a reply that’s wrong, which happens, gets to frame what you look for.
4. File the reply where the inventory lives. A reply that sits in an inbox expires; a reply attached to the affected rows of your CBOM or risk register, with the renewal date beside it, keeps working. The map is a living artifact, and its home is the inventory rather than the correspondence folder.
5. When the reply is evasive, narrow the question rather than repeating it. “Which named key-exchange groups does this specific endpoint negotiate today” is answerable by any provider engineering team in an afternoon. A vendor that can’t answer the narrow version has told you which category the surface belongs in, and the dated non-answer goes in the file too.

Where does the map break?

Fully on-prem estates collapse it to two categories. The written question has no recipient when no provider operates part of the data path, and the first category empties out, leaving cryptography that’s yours to migrate and traffic already harvested. The sort still earns its keep in the two-category form, because the harvested category and its data-lifetime weighting apply to on-prem traffic exactly as they do to cloud traffic, and the provider-question discipline survives as the vendor question you put to every product carrying cryptography inside your walls, which is Vendor-Controlled Crypto Surfaces territory.

Heavily SaaS estates starve the second move. Where you terminate no TLS, there’s no wire to capture, so Move 2 degrades to the vendor’s claim plus a dated written attestation, recorded as the weaker evidence it is. That’s the same honest degrade Wire Over Config specifies for surfaces with no wire access, and the map stays drawable; its middle category just leans harder on Move 1 and on contract terms.

The map sorts and never ranks. It tells you which surfaces are yours and says nothing about which of them to migrate first. Sequencing the second category takes the risk models: data lifetime against the quantum timeline per Mosca, dependency weight per blast radius, and harvest exposure per HNDL. The map hands those models an honest inventory to rank.

How do you use it in the boardroom?

The question arrives in one shape: “most of our estate is in the cloud, isn’t this the provider’s problem?” The map is the one-slide answer, because it concedes the true part with evidence and prices the rest. Three lines, each carrying its artifact:

1. What the provider already protects, with the written reply and the agreeing captures attached.
2. What’s ours to migrate no matter whose servers it runs on, with owners and dates attached.
3. What was already harvested, bounded by data lifetime, which is the line that answers “why now” without a single speculative date.

The compressed sentence for the room: “Part of it is theirs, and this is the written line showing exactly which part.” A board that’s been told “we’re on the cloud, we’re fine” has been given reassurance; a board shown the three-way split with the provider’s own letter behind line 1 has been given evidence, and evidence is what boards can govern with. The wider briefing pattern, including how to carry quantum risk upward without theatrics, is Brief Your Board.

Questions people ask

Do I send the written question to each cloud provider separately? Yes, one per provider, itemized per managed service you actually use, because the reply has to map onto your architecture rather than the provider’s catalog. Multi-cloud estates end up holding several replies, and the map merges them into one picture.

Who should send it? Whoever owns the vendor relationship, through the account team, with the security team supplying the wording and receiving the reply. The sender matters less than the channel and the format: on the record, through the team that can route it to product and compliance, in writing.

What if the provider answers with a marketing page or goes quiet? A dated non-answer is information, and it’s the same move The Three Zones makes at estate scale: record it, date it, and bring it to the renewal. Narrow the question to named groups on named endpoints first, because the narrow version separates a vendor that hasn’t migrated from a vendor that hasn’t been asked precisely.

Is the written reply legally binding? It’s an audit artifact rather than a contract term. It proves what you knew, when you knew it, and that you asked, which is most of what an auditor wants. A commitment you can enforce comes from writing the roadmap dates into the renewal, which the reply gives you the material for.

What do I actually capture with, and what am I looking for? A packet capture or a group-reporting TLS client on a connection your own workload makes, read for the negotiated key-exchange group. X25519MLKEM768 means hybrid post-quantum key exchange happened; a classical curve means it fell back or was never offered. The general rule and the fuller 30-day measurement live in Wire Over Config.

How often do I redraw the map? Diff the written reply at every renewal, and re-run the captures when the provider announces endpoint changes or when Cloud and Browser PQC Status moves. The first map is the expensive one; every redraw after that is a diff against artifacts you already hold.

Does the harvested category mean that data is definitely compromised? It means the ciphertext was exposed on a collectible path while key exchange was classical, and recovery is impossible from your side, so the posture is bounding rather than hoping. Whether it matters is a data-lifetime question: records whose secrecy expires before a capable quantum computer arrives age out of the problem, and What Data Is Vulnerable to Harvest Now, Decrypt Later walks that sort.

We’re all-in on one provider, so is the middle category even real for us? It’s usually the largest of the three. Application-layer encryption, keys under your control, internal PKI, code signing, service-to-service TLS on rented compute, and every option the provider ships disabled all sit on your side of the shared-responsibility line regardless of how committed to one vendor you are.

---

Everything here is the map, given freely. The version quantified against your own estate, with the written replies in hand, the captures read, and every endpoint placed on the right side of the line, is the work I do, and the engagements are here.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.