When is a cryptographic change finished?

Ask four people whether a cryptographic change is done and you may get four different answers. The engineer merged the fix, the change board approved it, operations deployed something, and security hasn’t checked yet. Each of them is right about their own step, and none of them can say whether the weakness is gone.

Why “done” means different things

Most reports collapse these steps into one word: done. That’s how a fix gets reported as complete in a quarterly review while the weak key is still serving traffic.

Nobody is being careless. Each team reports the step it controls, and the reporting tool has room for one status. The gap appears in the hand-offs, where nobody owns the final check.

Four states, four kinds of evidence

A cryptographic change passes through four states, and each one needs its own evidence:

• Recommended: someone has said what should change and why, with the reason recorded.
• Approved: the target is agreed, the dependencies are known, and a window is booked.
• Deployed: the change is running in production, not just merged in code.
• Confirmed: fresh evidence, collected after the change, shows the weakness is gone.

Only the last state means done. The first three are progress, and they’re worth tracking, but they describe intentions and actions, not outcomes.

What goes wrong between deployed and confirmed

The gap between deployed and confirmed is where most fixes go missing. A new certificate is installed on three servers and missed on the fourth. A load balancer keeps serving the old certificate from its own store. A change is rolled back during an unrelated incident and nobody re-applies it. A renewal reuses the old key, as described in how to tell a renewed certificate from a fixed one.

In every case the deployment record says done. Only a fresh check, looking at what is being served or stored, shows that it isn’t.

When a check can’t run

Sometimes the confirming check fails to complete: a host is offline, a credential has expired, a network path is blocked. It’s tempting to treat that as a pass, because nothing bad was found. It isn’t one. A check that couldn’t run proves nothing either way, so the change stays unverified until one does.

Recording that honestly protects everyone. The owner knows what’s left, the auditor sees a clean distinction between verified and unverified, and the next report doesn’t inherit a false green.

How to report progress

Report the four states separately. For example, a line that says 40 changes recommended, 28 approved, 22 deployed and 15 confirmed tells leadership far more than “22 done”, and it shows exactly where work is waiting.

Over time, the gap between deployed and confirmed becomes a useful measure in its own right. When it grows, something in the hand-off between teams needs attention.

What counts as fresh evidence

Fresh evidence means a check made after the change, against what is running, by a method that would have caught the problem. In practice:

• It looks at the live system, the certificate a service presents or the key a store holds, not the deployment record.
• It covers every place the change was meant to reach, including load balancers, replicas and regions.
• It records when and where it ran, so it can be repeated and audited.
• It tests the actual weakness, for example by comparing keys rather than expiry dates.

Questions to ask when someone says it’s done

• Done meaning recommended, approved, deployed or confirmed?
• What evidence confirmed it, and when was it collected?
• Did the check reach every place the change was meant to reach?
• If any check couldn’t run, where is that recorded?

Asked kindly and consistently, these questions change how teams report, because everyone learns what “done” has to mean.

Where Arcrix™ helps

Arcrix™ by QTrino Labs tracks each step separately, and a check that can’t complete leaves the change unverified rather than resolved, so “we fixed it” comes with evidence.