What does “cryptographic risk” mean?

Cryptographic risk is the chance that a key, certificate or algorithm your systems depend on can be broken, misused, or found to fall short of a rule you must meet. It sounds like one thing, and it’s usually reported as one number. In practice it covers three separate questions, and the trouble starts when they’re blended together.

The three questions

• Is it safe today? Whether a key, certificate or algorithm is weak by today’s standards: too short, using a retired method, or possibly exposed.
• Will it stay safe? Whether it will hold up once capable quantum computers exist, and how urgent that is for the data or signatures it protects.
• Does it meet the rules? Whether a policy or standard you answer to requires something here, and whether there’s evidence either way.

Each question has its own evidence, its own owner and its own timetable. The first is usually urgent and fixable this quarter. The second is a planning question measured in years. The third depends on which rules apply to you and when you’re next assessed.

What each looks like in practice

Take one service. Its certificate uses a key that meets today’s minimum, so the answer to the first question is fine. The method behind that key is one quantum computers threaten, so the second answer is “needs a quantum-safe plan”. And a policy you follow requires evidence of key rotation that hasn’t been collected, so the third answer is “not enough evidence”.

That’s one service, three different answers, and three different next steps. A single score would average them into something that sounds reasonable and tells nobody what to do.

Why a single score hides things

A certificate can be perfectly valid and still use a key that’s too weak. A key can be strong by today’s standards and still use a method that quantum computers threaten at any key size, which is why NIST has proposed retiring RSA and elliptic-curve methods by 2035 regardless of size. A system can pass every internal check and still miss a specific rule.

Blend those into one number and the gaps disappear from view. Worse, a routine success, such as a renewal or a clean scan, can be mistaken for a resolved problem, because it nudges the blended number in the right direction.

How to report it to a board

Boards don’t need algorithm names. They need to know what’s exposed, what’s planned and what’s being asked of them. Three lines usually cover it:

• Risk today: how many important systems have weaknesses that can be fixed now, and when they’ll be fixed.
• Risk from quantum computers: which systems hold long-lived data or long-trusted signatures, and where they sit in the plan.
• The rules: which requirements lack evidence, and by when that will change.

Each line has a different owner and a different date, which is exactly why they shouldn’t be merged into one score.

Questions to ask your team

• For our most important systems, what are the three answers today?
• Which of today’s weaknesses can we fix this quarter?
• Which systems hold data that must stay private for the longest time?
• Where are we relying on a pass in one answer to stand in for another?

What this means for your programme

Report the three answers side by side. It takes a little more space than one score, and it changes the conversation. Your teams can fix today’s weaknesses now, plan the quantum-safe work on its own timetable, and close evidence gaps before the next assessment.

It also makes reporting forwardable. A board member can read “three services weak today, twelve needing a quantum-safe plan, two rules lacking evidence” and know exactly what’s being asked of them.

If you’re just starting, why the first scope should be small explains how to get the three answers for one application before trying to get them for all of them.