Briefing leadership on quantum risk: the risk and the ask

Executives do not need a cryptography lecture. They need to understand the risk in business terms, believe it is timely rather than science fiction, and know exactly what you are asking them to approve. Structure the conversation as: the risk, the timing, the ask, and the objections.

The risk, in business terms

Nearly everything that keeps our data confidential in transit — website connections, VPNs, API calls, signed software updates — relies on public-key cryptography that a sufficiently powerful quantum computer can break. When an adversary has that capability, they can read past traffic they recorded and forge signatures we rely on. This is not a niche technical exposure; it is the foundation under most of our digital trust.

Why it is a today problem, not a someday problem

The instinct is to wait until quantum computers are real. Two facts break that instinct. First, harvest-now-decrypt-later: adversaries record our encrypted data now and store it cheaply until they can decrypt it, so any secret that must stay confidential for years is already at risk. Second, migration takes years — finding all our cryptography, planning the change, and rolling it out without breaking production is the long pole, independent of when the threat lands.

The ask

Be specific and modest for the first ask. You are not asking to boil the ocean — you are asking to see the map.

• **A named accountable owner** for the program, with a reporting line to you.
• **Funding for a cryptographic inventory** — a discovery effort that finds where vulnerable cryptography lives across our estate.
• **A reporting cadence** so you can see readiness improve over time.
• **A mandate** for the owner to pull in identity, networking, application, and procurement teams.

Answering the pushback

• **"Quantum computers don't exist yet."** Correct — and the harvesting does not need them. Recording traffic today and decrypting later is the threat. Migration also takes years, so waiting for the machine means starting too late.
• **"Isn't this a vendor problem?"** Partly — but only if you know which vendors and products are exposed, which requires our own inventory and vendor-risk process. We cannot outsource knowing where our crypto is.
• **"Won't the standards change again?"** The core NIST standards (FIPS 203/204/205) are finalized. And building for crypto-agility means future changes are configuration, not rewrites.
• **"What does it cost?"** We cannot give a credible number before the inventory — which is exactly why the first ask is small and scoped to discovery. The inventory turns a guess into a real budget.