CNSA 2.0 Is Quietly Exposing the Real Problem with Machine Trust
CNSA 2.0 is often discussed as a cryptography deadline. That is understandable. The move away from quantum-vulnerable public key algorithms is a major shift, and the new post-quantum standards matter.
But if the conversation stops at algorithms, it misses the larger issue. The post-quantum transition is forcing organizations to confront how machines establish trust in the first place.
Most systems still rely on objects that must be stored and later trusted: certificates, keys, tokens, shared secrets, static identities, and trust anchors. Those objects need to be issued, protected, rotated, revoked, audited, and eventually replaced. The larger and more distributed the environment becomes, the harder it is to defend.
CNSA 2.0 pulls on that thread. It not only asks whether the cryptography is strong enough. It asks whether the trust architecture underneath the product can survive the next era of security expectations.
Protecting Critical Infrastructure
Critical infrastructure was built to keep operating.
Water treatment plants, power generation sites, electrical substations, traffic control systems, rail networks, ports, airports, and emergency services were designed around availability, safety, reliability, and continuity. In many cases, the systems that run them were built long before today’s threat environment existed.
That creates a difficult problem. The systems society depends on most are often the hardest to change. A PLC running part of a water treatment process may be too old to support modern security software. A substation device may be under warranty, certified, or too operationally sensitive to modify. A traffic control system may rely on equipment designed to communicate within a trusted municipal network, not across today’s connected infrastructure.
Security teams know these systems need stronger protection. Operators know they cannot risk disrupting them.