01
Post-quantum readiness
The one with a date on it. NIST finalised the post-quantum standards in August 2024, so the algorithms are settled: ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures. What is not settled is anybody’s migration, and the deadlines have been moving forward rather than back.
The hard part was never the mathematics. It is knowing where cryptography actually lives in an estate: certificates nobody renews, embedded devices with hard-coded algorithms, libraries three dependencies deep, and the third parties whose crypto you inherit without ever seeing it. Most organisations cannot yet answer what they would have to change, which makes sequencing impossible.
And the clock already started. Under harvest now, decrypt later, anything intercepted today that must stay confidential into the 2030s is already exposed, whatever happens to quantum hardware in the meantime. For data with a long secrecy life, waiting is itself a decision.
02
Orchestrated digital governance
Most organisations can now discover their digital estate. Very few can govern it. Discovery produces inventories; governance requires an owner, a deadline and an audit trail for every asset and every finding, across security, GRC, legal and brand rather than in four disconnected tools.
Orchestration is the gap between the two: making one picture of the estate that several functions can act on at once, with accountability that survives a person leaving. It is unglamorous, it is where most programmes stall, and practitioners who have done it hold knowledge that does not exist in any vendor deck.
03
The convergence of AI and cybersecurity
Two distinct problems that keep being discussed as one. Securing AI systems is a question of model supply chain, prompt handling, data leakage and agency: what a system is permitted to do on its own. Using AI in security is a question of whether the output can be trusted enough to act on.
Bad actors adopted the technology faster than defenders, because they face no procurement cycle and no assurance requirement. The community’s value here is separating what genuinely works in production from what is being sold, which is a judgement only practitioners can offer honestly.
04
Data sovereignty, viewed through a security lens
Sovereignty is usually treated as a legal and procurement question: which jurisdiction governs the data, who can compel access to it, what a contract promises. Those are necessary, and they are not sufficient.
The security framing asks different questions. Where does the data physically sit, including in backups, logs and the fourth parties nobody mapped. Which keys exist, and who holds them. What actually happens, technically, if a provider is compelled to hand something over. Boards are being asked to attest to sovereignty positions that nobody has verified at the infrastructure level.