What can’t I fix myself?
Most of it. In a typical enterprise, the majority of places where encryption is actually running sit inside products a supplier owns, ships, and updates on their own schedule.
Your engineers can change the encryption in software your company wrote. They can’t change the encryption inside a payment processor, an identity platform, a managed firewall, a cloud key service, or a piece of hardware whose cryptography is fixed in firmware. For those, migration means the vendor ships a post-quantum version and you adopt it, on a timeline somebody else controls.
That’s the part of this program that no amount of internal effort compresses, and it’s the reason a team that “finished” its migration internally has usually finished the smaller half.
The short version:
- The supplier sets your date. If a vendor ships post-quantum support in 2029, your migration for those systems finishes in 2029 regardless of internal effort.
- Concentration multiplies the problem. Using 1 vendor for identity, key storage, and transport bundles a large share of your program into a single roadmap.
- These surfaces are invisible to a normal audit, because an internal scan sees your systems rather than the cryptography inside somebody else’s product.
- Moving to the cloud relocates the line rather than removing it. Providers secure their infrastructure, and a substantial share of encryption choices stay on the customer side.
- Your leverage lives at purchase and renewal. A verbal commitment is a comfort; a contract term is an obligation.
- A published list of what’s inside the product is what turns a vendor’s assurance into something you can check.
Which parts of our encryption do we actually control?
Two categories, and the split decides what you can plan versus what you can only pressure.
Systems you built. Applications your developers wrote, servers you configure, databases whose settings you own. Here the migration is engineering work: update the library, change the configuration, reissue the certificates, test it, ship it. Difficult and expensive, and entirely within your authority.
Systems you bought. These divide again:
- Configurable products let you switch on post-quantum options once the vendor ships them. You control the timing of the switch, and the vendor still controls when the switch exists.
- Opaque products make every algorithm decision for you. Migration means waiting for the supplier to upgrade their platform, and sometimes buying a different product tier to get it.
The second category is where the schedule risk concentrates, and it’s the category most migration plans quietly leave out.
Where does the vendor-owned encryption hide?
Across the whole estate, and most of it never appears in an internal scan.
| Where it lives | Examples | What you can change |
|---|---|---|
| Cloud and managed services | Key management and hardware security services, load balancers terminating encrypted traffic, content delivery networks, managed certificate services | Configuration options the provider exposes |
| Business software | Identity providers issuing login tokens, email and collaboration encryption, finance and customer platforms holding encrypted records and API keys | Usually nothing beyond product settings |
| Network equipment | Managed VPN, cloud-managed firewalls, software-defined networking appliances | Firmware versions the vendor releases |
| Hardware with fixed firmware | Switches, routers, security modules, industrial controllers, connected devices | Often nothing, so replacement is the migration |
| Third-party connections | Payment processors, government filing gateways, industry data exchanges, banking interfaces | Whatever the other side supports |
The hardware row is the expensive one. Equipment with cryptography built into the chip frequently can’t be updated at all, which turns a software migration into a capital purchase, and industrial and medical equipment routinely stays in service for 15 to 20 years.
Who owns the encryption in the cloud?
The provider secures the infrastructure and the customer secures what runs on it, and every major provider draws the line the same way. AWS states it as security “of the cloud” being the provider’s responsibility and security “in the cloud” being the customer’s, and it places data encryption, key management, and encryption-option choices on the customer side of that line.
Source: AWS, “Shared Responsibility Model,” aws.amazon.com.
Where your control ends shifts with how much of the stack you rented:
- Rented infrastructure. You run the operating system and software on somebody else’s machines, so nearly all the cryptography is yours to find and migrate, the same as if the servers sat in your building.
- Rented platform. The provider operates the runtime and often handles encrypted connections and certificates for you. Control is split: you pick some options, and the provider decides the rest inside a layer you don’t patch.
- Rented software. The provider owns essentially all of it, and your only levers are the settings they expose and the contract you signed.
The practical read is that moving to the cloud didn’t hand your migration to the provider. A large share of the estate lands on the customer side of that line even in teams that assumed the provider handled encryption.
Why won’t a vendor just tell us?
Because volunteering an accounting of the quantum-vulnerable cryptography inside a product they already sold you unsettles the customer and commits them to a roadmap they’d rather keep flexible. The burden of visibility falls on the buyer, which means you ask directly and write the answers into the agreement.
Six questions, and the answers are more informative than most security questionnaires produce:
| Ask the vendor | What the answer tells you |
|---|---|
| Do you have a published post-quantum roadmap? | Whether planning around this product is even possible |
| Which algorithms, and by what date? | Whether their schedule fits inside your deadline |
| Is our current tier covered for the upgrade? | Whether migration costs us a contract change |
| Do we switch it on, or do you decide when? | Whether we control the timing |
| What’s your validation status for the new algorithms? | Whether it satisfies our own compliance obligations |
| Will you commit to that in the contract? | Whether the roadmap is enforceable |
The last question is the one that separates a marketing answer from a real one. A supplier who says “we’re working on it” has told you nothing you can plan against, and the follow-up worth asking is which dated requirement their roadmap is answering to. A vendor who can’t name one has built a schedule out of intentions.
How do we actually get them to move?
Four levers, and almost all of the force is in the first 2.
- New purchases. Write post-quantum readiness into the requirements, and ask for a documented roadmap with dated commitments before signing. This is the single cheapest moment in the entire relationship to get what you need.
- Contract renewal. Negotiate explicit support obligations and dates into the renewal, including notice when a post-quantum version ships. Renewal dates are forcing functions, and they arrive on a calendar you can plan around.
- The relationship, escalated correctly. Route the roadmap question through your account team to the vendor’s product organization. A support ticket produces a support answer.
- Your regulator, borrowed. Point at the dated obligation that binds you. A supplier serving regulated buyers moves faster when the compliance risk becomes theirs, and one deadline reaches suppliers directly: new U.S. national security system acquisitions require post-quantum algorithms from January 1, 2027, which means vendors serving that market ship well before then.
Source: NSA, “CNSA 2.0 FAQ,” media.defense.gov.
One further ask makes the rest verifiable. A software bill of materials is a formal, machine-readable list of the components inside a product, defined for U.S. purposes by NTIA in July 2021, and the same idea extended to cryptography lists the algorithms, protocols, certificates, and keys those components use. Requiring one at procurement converts “we use strong encryption” into a list you can check against your own deadline.
Source: NTIA, “The Minimum Elements For a Software Bill of Materials (SBOM),” July 12, 2021, ntia.gov.
Questions people ask
What share of our encryption is vendor-controlled? For most enterprises it’s the majority of surfaces, and the only way to know your own number is to inventory it. Teams are consistently surprised by how much of the estate they can’t change.
Can we switch to a vendor that’s further ahead? Sometimes, and it’s worth pricing. Switching costs, integration work, and retraining usually exceed the migration cost, so this tends to make sense when a renewal is already near.
Our provider says they’re post-quantum ready. Are we done? For their layer, possibly. Their readiness covers their infrastructure and the modules they validated. Your application-level encryption, your key management above their boundary, and the promises in your own customer contracts all remain yours.
What if the vendor has no plan at all? Record it as a finding with the contract renewal date attached, and treat that date as your decision point. A supplier with no roadmap and a long timeline is the highest-value item on a vendor list precisely because it can’t be fixed internally.
Does this apply to hardware we own outright? Especially to hardware you own outright. If the cryptography is fixed in firmware and the manufacturer issues no update, replacement is the only migration, and that’s a budget line rather than an engineering task.
When should we start asking? Before the next renewal cycle, because the questions take months to route through a vendor’s product organization and the answers change what you negotiate.
Who should own this inside our company? Procurement and vendor management, with security supplying the questions. Security teams rarely see contract renewals in time, which is the usual reason the leverage gets missed.
Where to go next
- What should I ask my security team covers the internal half of the same question.
- What does this cost covers what the vendor share does to the budget.
- Who is liable when this fails covers what your contracts actually oblige a supplier to do.
- How do I ask a company what their quantum plan is is a letter template that works on your own suppliers.
- For Business Leaders MOC is the full executive route.
Go deeper into the technical detail
The technical treatment is Vendor-Controlled Crypto Surfaces and Cryptographic Supply-Chain Risk.
These open the Post-Quantum Field Guide, a separate site written for security professionals.
Last verified 2026-07-30 · Maintained by Addie LaMarr, LaMarr Labs.