up:: The Human & Organizational Side MOC
Vendor-Controlled Crypto Surfaces
Vendor-controlled crypto surfaces are the cryptographic implementations running inside your environment that a third-party vendor owns, manages, and updates, rather than your own team. SaaS platforms, cloud services, CDNs, managed security services, third-party APIs, and hardware with vendor firmware all fall here. You cannot unilaterally change the algorithms these surfaces use. Migrating them requires the vendor to ship a post-quantum-capable version and you to adopt it, on a timeline you don’t control. In most enterprises this is the majority of the cryptographic footprint by surface count, and it’s the single largest source of migration-timeline uncertainty.
The short version:
- Most of your cryptography lives in systems a vendor controls, not systems you do.
- You can’t migrate these yourself. You can only pressure the vendor and adopt what they ship.
- They’re invisible to a standard internal audit, so a team that “finished” its migration internally has usually done the easy part.
- Your real leverage is procurement and contract renewal, and using it starts with asking the questions a vendor would rather you skip.
Think of it like the fire safety of a building you lease. You’re accountable for it, tenants depend on it, but the wiring behind the walls belongs to the landlord. You can’t rewire it yourself. You can only inspect it, demand fixes, and time your lease renewal to force the ones that matter.
Why do vendor surfaces dominate your migration risk?
Organizations plan their migration around what they directly control, and that’s the smaller problem. The bigger one is everything they don’t. Vendor surfaces carry three properties that make them the hard part:
- The timeline isn’t yours. You can’t compress a vendor’s migration schedule with internal effort. If a vendor won’t ship post-quantum support until 2029, your migration for those surfaces is blocked until 2029, no matter how fast your own team moves. In Mosca’s terms, the vendor sets your Y.
- Concentration multiplies it. An organization that uses one vendor for key storage, identity, and transport has bundled a large share of its migration into that single vendor’s roadmap. If they’re slow, much of your program is frozen at once.
- Blast radius rides along. A vendor surface that many internal systems depend on carries elevated blast radius, because a failure propagates through everything downstream and recovery waits on vendor action, not yours.
Where do they hide?
They sit across the whole estate, and most never surface in an internal scan:
- Cloud and managed services: cloud key-management and HSM services, cloud TLS termination and load balancers, CDN TLS, managed PKI.
- SaaS platforms: identity providers issuing SAML and JWT tokens, collaboration and email encryption, finance and CRM platforms holding encrypted data and API tokens.
- Network equipment: managed SD-WAN and VPN, cloud-managed firewalls, managed IPsec concentrators.
- Hardware with vendor firmware: switches, routers, and firewalls with fixed-firmware crypto, HSMs whose algorithms change only through a firmware upgrade, and IoT and OT devices.
- Third-party APIs: payment processors, government gateways, industry data-exchange platforms.
They divide into two kinds. Vendor-configurable surfaces let you turn on post-quantum options once the vendor ships them, so you control the timing. Vendor-opaque surfaces make every algorithm decision for you, so migration means waiting for the vendor to upgrade their platform, and sometimes accepting a new contract or product tier to get it.
Why won’t your vendor just tell you?
A vendor’s incentive is to sell you something, not to hand you an honest accounting of the quantum-vulnerable cryptography already sitting inside the product you bought from them. Volunteering that exposure spooks the customer and commits the vendor to a roadmap they’d rather keep flexible. So the burden of visibility falls on you, and the way you meet it is to ask directly and put the answers in the contract. The questions worth asking of every vendor surface:
| Ask the vendor | What it tells you |
|---|---|
| Do you have a published post-quantum roadmap? | Whether migration planning is even possible |
| Which algorithms will you support, and by when? | Alignment with the ML-KEM / ML-DSA timeline |
| Is my current product tier covered for the upgrade? | Whether your existing contract pays for migration |
| Is post-quantum support something I switch on, or something you decide? | Whether you control the timing |
| What’s your FIPS 140-3 validation status for the new algorithms? | Compliance readiness |
| Will you commit to it contractually? | Whether the roadmap is enforceable or just marketing |
A vendor’s verbal “we’re working on it” is a comfort, not a commitment. Only the contractual answer is real.
Who owns the crypto in the cloud?
In the cloud the answer depends on the service model, and the shared-responsibility split is the thing to get straight before you assume a provider has your cryptography covered. Every major cloud provider draws the same line: the provider secures the underlying infrastructure, and the customer secures what they 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 squarely on the customer side.
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.
Where your control ends shifts with the abstraction level of the service, and this is the part that catches teams out:
- Infrastructure as a service (IaaS). You run the operating system, the libraries, and the TLS stack yourself on rented compute, so most of the cryptography is yours to inventory and migrate, exactly as if it were on-premises. The provider gives you the machine; the algorithms are your responsibility.
- Platform as a service (PaaS). The provider operates the runtime and often terminates TLS or manages certificates for you, so control is split. You choose some options (which key, sometimes which protocol versions), and the provider decides the rest inside a managed layer you don’t patch.
- Software as a service (SaaS). The provider owns essentially all of the cryptography, and you’re a vendor-opaque consumer of it. Your only real levers are the configuration switches they expose and the contract you signed, which puts SaaS crypto in the same bucket as the vendor-opaque surfaces above.
The practical read is that moving to the cloud doesn’t hand your quantum migration to the provider. It relocates the boundary of what you control, and a large share of the estate lands on the customer side of the line even when a team assumed “the cloud provider handles encryption.”
How does an SBOM linked to a CBOM make vendor crypto visible?
A cryptographic bill of materials is what turns a vendor’s opaque surface into an inventory you can actually reason about, and linking it to a software bill of materials is what makes it reach the components you didn’t write. An SBOM is a formal, machine-readable list of the software components and dependencies inside a product; the U.S. minimum-elements definition for one was published by NTIA in July 2021 to drive supply-chain transparency. A CBOM extends that idea to the cryptography itself, listing the algorithms, protocols, certificates, and keys those components use, and the OWASP CycloneDX standard added exactly this capability so a single bill of materials can carry both layers.
Source: NTIA, “The Minimum Elements For a Software Bill of Materials (SBOM),” July 12, 2021, ntia.gov.
For a vendor surface the linkage is the difference between a verbal assurance and a checkable artifact. When you require a signed SBOM linked to a CBOM as part of procurement, a vendor’s “we use strong encryption” becomes a queryable list you can test against the ML-KEM and ML-DSA timeline, and the crypto that used to be invisible inside their product becomes a row in your inventory with a real algorithm name attached. This is where the procurement lever and the visibility problem meet: the contract asks for the bill of materials, and the bill of materials is what makes the vendor’s cryptography legible enough to migrate. The deeper transitive reach of this idea, past the direct vendor into the open-source libraries and the suppliers of suppliers, is the subject of Cryptographic Supply-Chain Risk.
How do you actually get them to move?
You have more leverage than it feels like, and almost all of it lives at procurement and renewal, not in day-to-day operations.
- New procurement: write post-quantum readiness into the RFP, and require a documented roadmap with dated support commitments before you sign.
- Contract renewal: negotiate explicit support obligations and timelines into the renewal, including notification when a post-quantum-capable version ships. Renewal dates are forcing functions; use them.
- Enterprise relationships: route the roadmap question through your vendor relationship manager up to the vendor’s product strategy team, not the support desk.
- Regulatory leverage: point to the mandate that binds you. A vendor that serves regulated customers moves faster when compliance risk is on the table.
Because you can’t compress these timelines internally, the honest move is to start vendor engagement immediately, treat every renewal as a deadline, and record each surface in your inventory with its vendor, its roadmap answer, and its contract-renewal date. An opaque vendor surface with no roadmap and a long timeline is one of the highest-priority findings in any migration, precisely because it’s the part you can’t fix alone.
The layer beneath the direct vendor, the open-source libraries and the suppliers-of-suppliers that carry most of your cryptography transitively, is Cryptographic Supply-Chain Risk, which no single contract fully reaches and which an SBOM linked to a CBOM is what makes legible.
Everything here is the map, given freely. When your team needs its vendor surfaces inventoried, assessed, and turned into procurement leverage, that’s the work I do, and there’s an alignment briefing for it.
Last verified 2026-07-14 · Maintained by Addie LaMarr, LaMarr Labs.