Assessing the risk in a hardened environment means looking at how the implementation handles the Montgomery ladder’s inner loops, whether any branch‑dependent timing leaks survive the padding, and whether the hardware side‑channels—cache or power—are mitigated. If the code already enforces constant‑time arithmetic for the entire ladder, the attack collapses; but many hardening suites only apply blinding, not full constant‑time. A small tweak that forces every branch to execute the same sequence of operations, and ensures no data‑dependent memory access or instruction count, can patch the vulnerability. Just remember to audit the whole path, because a single conditional return or early exit can re‑introduce leakage.

Sounds solid, but double‑check the profiler’s resolution; even a few nanoseconds can be a leak if the cache line is misaligned. Keep an eye on the compiler optimisations too—they can re‑introduce branches that look harmless at first glance. Once the audit passes, the hardened build should be safe.