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 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.
Go deeper
- The Three Zones: sorts the estate into what you control, what you can see, and what stays invisible.
- The Three-Way Map: separates provider-covered crypto from what’s yours to migrate and from already-harvested traffic.
- The Vendor-Claims Checklist: the three questions that turn a vendor’s quantum-safe claim into a CMVP certificate number, a named validated module, and a validation date you can check against NIST’s public registry yourself.
The precedent
In May 2006 a Debian developer ran Valgrind against the OpenSSL package, and it flagged an uninitialized buffer in the seeding routine of the random number generator. Reading uninitialized memory is a real defect and both Valgrind and Purify were right to warn about it, so the lines were removed. They were the ones mixing entropy into the seed. With them gone, the only varying input left was the current process ID, and the default maximum on Linux is 32,768. For the next two years every SSH key and certificate generated on Debian and everything derived from it came from a space of 32,767 possibilities. It was found on 13 May 2008. Nobody downstream had seen the change, reviewed it, or had any way to.
Debian OpenSSL PRNG defect, CVE-2008-0166
The moral: their cryptography was decided by a person they had never met, for a reason that was locally correct.
Most of an enterprise’s cryptography arrives inside things it bought and did not build. The algorithms, the parameter sets, the fallback behavior, and the upgrade timeline are all decided upstream by people optimizing for their own constraints, and the only moment a customer has any influence over any of it is before the contract is signed or at renewal. Nothing in day-to-day operations touches those decisions. The maintainer was not careless. He was fixing a genuine warning in a package he was responsible for, with no way to see what the two lines were doing for everyone else.
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.
Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.