In 26 years of building security and cryptographic services at Cisco, I’ve worked through a long list of defects in protocols and systems. Only a small minority of the cryptographic failures I’ve seen came from someone breaking the algorithm. Far more often, systems fail in the gap between fix available and fix deployed.
That gap is the last mile of trust. It’s where a patch published upstream reaches a global product portfolio months later. It’s where an embedded device ships with a cryptographic library that will never be updated in its service life. It’s where a fix moves cleanly through four layers of a supply chain and quietly stalls at the fifth.
The math is the part we’ve mostly solved. Logistics are the part we haven’t.
Two Forces, Opposite Ends
Two forces are now stress-testing the last mile at the same time.
On the discovery side, AI has widened the gap between finding bugs and fixing them. While frontier models have sharply lowered the barrier to finding vulnerabilities, fixing them still depends on skilled human judgment for triage, patch authoring, review, release, and deployment. Discovery scales with compute. Remediation scales with headcount. Those curves are diverging, and every report sitting in a maintainer’s queue is a fix that hasn’t started its journey down the last mile.
On the deployment side, post-quantum cryptography (PQC) migration is not a single event. It is a sequence of them, executed under time pressure, against standards and protocol choices that are still being battle-tested in production. Some early decisions will need to be revisited. That isn’t pessimism; it’s the nature of large-scale change.
Together, these forces define this decade’s central security challenge. Cryptographic risk is now governed less by the strength of our algorithms than by the velocity of our change pipelines.
The Missing Control: Upstream Capacity
Cisco defines crypto agility as the ability to update cryptographic algorithms, protocols, libraries, and implementations while minimizing disruption and avoiding unnecessary replacement of the underlying infrastructure. In practice, it rests on four components:
- Abstraction: cryptographic choices are configurable rather than hardcoded.
- Inventory: you know which systems use which primitives.
- Pipeline velocity: you can move a change from upstream to fleet quickly.
- Upstream capacity: the projects you depend on can deliver new capabilities and critical fixes fast.
Most organizations invest in the first two and assume the last two. In reality, the last two are where migrations actually fail.
Upstream capacity is the one almost nobody puts on a roadmap because it sits outside your organization. Nearly every secure connection you made today, from banking and email to the API handshakes behind your applications, depended on cryptographic code maintained by a small team on behalf of the entire internet. You cannot close the last mile if the upstream project lacks the capacity to produce the fix in the first place.
Every other part of your cryptographic supply chain has an owner, budget, and a control objective. In most organizations, upstream capacity has none of those. It has an assumption, and assumptions are not controls.
So, change the question your program asks. Your Software Bill of Material (SBOM) already tells you which open source you use. The harder question is: what do we put back into the projects we cannot operate without? If the honest answer is “nothing,” that is a finding. It belongs in your risk register alongside every other unmanaged dependency.
What This Looks Like in Practice
For Cisco, part of the answer was becoming a Premier Sponsor of the OpenSSL Foundation in August 2025. The three-year commitment funds a full-time Foundation engineer and a seconded Cisco engineer. Their work focuses on foundational engineering, QUIC, post-quantum cryptography, and DTLS 1.3. We treat it as supply chain risk reduction with a direct line to our own deployment velocity, not as philanthropy.
Tomáš Mráz, CTO of the OpenSSL Foundation, describes the impact:
“Cisco’s support for the OpenSSL Foundation allowed us to fund an additional senior software engineer to improve the OpenSSL Library code. Igor Ustinov, who is in the role partially funded by Cisco, is helping the team handle the increased workload caused by the rise in security and bug reports generated by AI. Ryan Hooper, who is employed by Cisco, is a key contributor to the development of DTLS 1.3 protocol support. Both have already become OpenSSL committers thanks to the high quality of their work.”
Mráz is illustrating a maintainer absorbing the downstream consequences of AI-scale discovery. The gap between finding and fixing has arrived as a workload on a specific person’s desk. Both engineers also became committers because of the quality of their work, not because of who funds them. Influence upstream is earned in the codebase, not in the sponsorship agreement.
Duration matters as much as dollars. A foundation can hire against a three-year commitment, but not against a one-off grant. Sustained contribution funds a person, and people are what clear triage backlogs.
Where to Start
You don’t need a sponsorship budget to contribute. Three moves are available to almost anyone:
- Measure your last mile. How many days does it take a fix to move from upstream release to your production environment? If you can’t answer, start there. That number will make your business case for you, and it’s the best available predictor of how your PQC migration will go.
- Upstream what you’re carrying privately. Every patch you carry privately is a contribution you decided not to make and a recurring engineering cost you decided to keep. Forks are the last-mile problem made permanent. Upstreaming code you’ve already written is often the highest-return contribution available, and it requires no new budget.
- Pick one contribution you can sustain. Options include code review, triage, test coverage, interop testing at production scale, CI capacity, documentation, or a seconded engineer. Sustained and modest beats large and episodic every time.
The math will hold. The open question is whether we can ship fast enough to keep up with it, and we can only answer that one collectively. Measure your own last mile, then contribute to someone else’s.
