January 1, 2027 is approaching, and for technology suppliers supporting US National Security Systems, it represents an important post-quantum cryptography milestone.
The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) establishes the next generation of cryptographic expectations for these environments.
Understandably, much of the discussion focuses on algorithms.
Which cryptography needs to change? Which products require updated implementations? What validation will be necessary?
Those are important questions.
But for OEMs and software developers, the larger challenge may be the architecture underneath the algorithms.
Replacing cryptography is one task. Modernizing how machines establish trust is another.
A migration that reaches beyond the cryptographic library
In August 2024, NIST finalized its first three major post-quantum cryptographic standards, including ML-KEM under FIPS 203 and ML-DSA under FIPS 204.
These standards establish important foundations for quantum-resistant key establishment and digital signatures.
But implementing a new algorithm does not automatically make a deployed product ready for high-assurance procurement.
Manufacturers must also consider how cryptography interacts with device provisioning, software updates, authentication mechanisms, hardware capabilities and operational requirements.
A product might support an approved algorithm while other elements of its architecture continue to depend on mechanisms that require additional evaluation or modernization.
For long-lived industrial and defence equipment, those decisions affect products that may remain in service for many years.
CNSA 2.0 is forcing difficult engineering decisions
An OEM may have hundreds of deployed systems built around an established software stack.
Its products could depend on certificate authorities, shared secrets, authentication tokens or other persistent identity mechanisms.
These systems may work reliably today.
But adopting post-quantum algorithms can require changes to protocols, hardware resources, cryptographic libraries, integration points and validation procedures.
The process becomes more complicated when products are deployed across multiple customer environments.
One customer may operate centralized identity infrastructure. Another may depend on offline equipment. A third may have strict procurement and accreditation requirements.
The problem isn't necessarily a lack of awareness.
It's that significant architectural changes are difficult to introduce into mature, revenue-producing products.
Stronger cryptography does not automatically solve credential misuse
Post-quantum cryptography addresses the risk that future quantum computers could undermine certain conventional cryptographic algorithms.
It does not independently eliminate the vulnerabilities associated with stolen or misused authentication material.
Consider a device that authenticates using a reusable credential.
The underlying cryptographic algorithm may be quantum-resistant.
But if an unauthorized participant obtains usable authentication material and the surrounding controls fail to distinguish that participant from the expected machine, the system may still be vulnerable.
This is not a failure of post-quantum cryptography.
It is a different problem.
Cryptographic strength and machine provenance are complementary security requirements.
A system needs to protect its communications and establish that the participating machine is the one it intended to trust.
Why machine provenance matters
Connected systems are becoming increasingly software-defined.
An industrial controller can receive firmware updates. A defence platform may run new mission software. An autonomous machine may have operational functionality enabled through application-level entitlements.
As these systems evolve, identity cannot always be reduced to a recognized credential or a static identifier.
Relevant hardware, software and operational attributes can help establish whether the participating machine remains the expected participant.
Continuous Proof Trust (CPT) provides an architectural model for maintaining that confidence through fresh, relationship-bound evidence.
Instead of relying exclusively on a previously successful authentication event, trust can be continually renewed.
Where kin changes the architecture
Iothic's kin technology implements Continuous Proof Trust.
Within kin's authentication process, reusable authentication artifacts are not stored, exchanged or managed.
That removes the reusable authentication credential theft target from this part of the security architecture.
kin also supports machine provenance and continuing verification of protected relationships.
The distinction is important: this does not eliminate every credential or cryptographic mechanism used by the surrounding system.
It changes the basis on which kin authenticates participating machines.
For organizations modernizing their products, this creates an opportunity to address credential dependency alongside the transition to post-quantum cryptography.
Introducing kin without rebuilding the software stack
For software developers, the practical question is often how to improve assurance without redesigning an entire product.
kin Library provides an application-layer integration path through a drop-in API library.
An OEM can begin by identifying a particular machine-to-machine authentication path where reusable credentials introduce risk or lifecycle complexity.
Continuous Proof Trust can then be evaluated within that selected relationship.
Once validated, the approach can be extended to adjacent communication paths and incorporated more broadly into the product.
This allows modernization to proceed incrementally.
Existing application logic, human identity systems, authorization controls and other security capabilities can remain in place where appropriate.
For network and transport-layer deployments, kin Core provides another integration option.
The correct architecture depends on the product, deployment environment and assurance requirements.
Compliance is still a separate responsibility
CNSA 2.0 specifies cryptographic requirements for applicable National Security Systems.
Its requirements include ML-KEM-1024 for relevant key-establishment functions, AES-256 for symmetric encryption and ML-DSA-87 for applicable digital signature functions.
kin uses ML-KEM-1024 in provisioning and AES-256-GCM for protected communications.
These are relevant elements of the post-quantum transition.
However, the presence of those algorithms does not by itself demonstrate complete CNSA 2.0 compliance.
Where required, digital signatures, validated cryptographic modules, approved configurations, product evaluations and other assurance processes must be addressed independently.
The same distinction applies to FIPS validation and procurement eligibility.
kin should be evaluated as an architectural capability within the broader compliance and accreditation process, not as a substitute for it.
What OEMs should be doing now
A useful first step is to understand how machine authentication currently works inside the product.
Where are reusable authentication artifacts stored?
Which relationships depend on certificates or tokens?
How are keys and credentials provisioned, updated and revoked?
What happens when a device is replaced or its software state changes?
Which authentication paths could be strengthened without disrupting existing application functionality?
These questions help identify where a targeted modernization project may provide the greatest value.
For software vendors, beginning with one critical authentication relationship is often more practical than attempting to replace an entire security architecture at once.
The deadline is narrow. The architectural signal is broader.
CNSA 2.0 applies to specific national security environments.
It should not be described as a universal compliance requirement for every commercial product.
Nevertheless, the underlying engineering questions extend well beyond defence procurement.
Critical infrastructure, industrial automation, autonomous equipment, distributed software and connected services all face similar challenges involving machine identity, software provenance and authentication lifecycle management.
Post-quantum modernization provides an opportunity to examine those assumptions.
The next generation of security should not only use stronger algorithms. It should also establish stronger evidence about which machines are participating and whether they remain trustworthy.
Continuous Proof Trust offers an approach to that challenge.
For equipment manufacturers, software developers and OEMs planning their security modernization roadmaps, Iothic welcomes technical discussions about introducing kin Li