Introduction
In security, being able to adapt quickly is everything. With new threats like quantum computing on the horizon, this flexibility is crucial. Crypto-agility is simply the capacity to swap cryptographic algorithms and protocols swiftly without disrupting operations or risking security.
The concept emerged from lessons learned during past transitions, such as the prolonged shift from DES to AES, where Triple DES remained in use for nearly 23 years after AES was standardized. Recognizing the increasing need for seamless migration, NIST published its foundational draft, CSWP-39: Considerations for Achieving Crypto-Agility, in March 2025 and later updated to a second public draft in July 2025. This guide delves deep into operational mechanisms, trade-offs, API strategies, and systems-level planning required for effective crypto-agility.
Importance of Crypto-Agility
According to NIST’s CSWP-39, Considerations for Achieving Crypto-Agility, key challenges include backward compatibility, constant need for transition, and resource/performance constraints. For example, the SHA-1 to SHA-2 shift took years because SHA-1 was deeply embedded across protocols even after vulnerabilities were known.
Crypto-agility matters because it equips systems to:
- Rapidly retire weak algorithms when they’re compromised
- Scale cryptographic configurations up as threats evolve
- Maintain operational continuity, even in high-stakes environments
Despite NIST deprecating SHA-1 for digital signatures as early as 2011, an estimated 35% of websites were still using it as late as 2016, leaving them exposed to known collision attacks.
Hardware Constraints as a Barrier to Crypto-Agility
While crypto-agility is often discussed in terms of software flexibility, in practice, the hardware capabilities of deployed devices play a decisive role in determining what can actually be achieved. This challenge is especially pronounced in Operational Technology (OT) environments, where devices are frequently built on resource-constrained embedded platforms rather than high-performance enterprise-grade systems. In simple terms, even if the software can change quickly, the hardware might not be powerful enough to handle those changes.
From a crypto-agility standpoint, these constraints make it far more complex to adopt new cryptographic algorithms or migrate in response to evolving threats. For example, transitioning to post-quantum cryptography as recommended by NIST’s PQC standardization efforts may require significantly greater processing power, memory, and bandwidth than what legacy OT hardware can provide. Some of the limitations are mentioned below:
Limited Processing Resources for Cryptographic Upgrades
Many OT devices operate on microcontrollers or processors with tight CPU and memory constraints. Introducing modern cryptographic algorithms can be computationally expensive. For instance, a TLS handshake using PQC algorithms on a medium-class microcontroller with 192 KB of RAM may consume around 35% of available memory, compared to roughly 1% for a classical elliptic-curve-based handshake.
Even if the firmware could be updated to include PQC support, the remaining memory might be insufficient for normal operation, causing stability or performance issues. In essence, the hardware resource ceiling can cap the extent to which software-based cryptographic upgrades are possible.
Hardware-Accelerated Cryptography
Modern microcontrollers and processors often include dedicated cryptographic accelerators to speed up algorithm execution and meet timing requirements. These accelerators are critical for enabling cryptographic operations on constrained devices.
However, they present two major limitations:
- Static Algorithm Support: Once deployed, hardware accelerators generally cannot be updated to support new algorithms. If the supported algorithms are deprecated or become insecure, the device must fall back to slower, software-only implementations.
- Unpatchable Vulnerabilities: If a flaw is found in the hardware cryptographic implementation, it cannot be patched in the field. Fixing it would require manufacturing new chips, which is an expensive and time-consuming process.
This creates a situation, though hardware acceleration, while initially beneficial, can eventually lock systems into outdated cryptographic primitives.
External Security Modules: Opportunities and Risks
In addition to processor-integrated cryptographic accelerators, many devices leverage external hardware security modules, such as Secure Elements (SEs) or Trusted Platform Modules (TPMs), to strengthen key protection and offload sensitive operations.
From a crypto-agility perspective:
- Soldered Modules: Offer strong security but suffer the same update limitations as on-chip accelerators. Once deployed, their capabilities are fixed.
- Exchangeable Modules: Significantly improve crypto-agility by allowing post-deployment hardware upgrades and key replacements without altering the main device hardware. This flexibility can support both implementation agility and configuration agility.
However, this modular approach comes with its own security risks:
- Unsecured Interfaces: Communication between the host device and the module is often not cryptographically protected, making it vulnerable to tampering.
- Module Theft: If the module is stolen, the attacker gains control of the cryptographic identity stored within, enabling impersonation attacks.
- Human-Dependent Security Measures: Some protection mechanisms require human interaction, which is impractical in unmanned OT deployments.
External modules will see limited use in high-security OT environments until issues such as securing host-to-module communication and enabling tamper-resistant, independent operation are resolved.
Supply Chain Hardware Limitations
Hardware used by supply chain vendors can significantly impact an organization’s ability to remain crypto-agile. Many devices, such as HSMs, IoT chips, or specialized accelerators, are built with fixed cryptographic algorithms and limited upgrade options. If vendors do not design hardware with adaptability in mind, organizations may struggle to transition to new standards or post-quantum algorithms without incurring high costs for replacement. This creates long-term dependencies on vendor roadmaps, delays security upgrades, and increases operational risk. Thus, hardware limitations in the supply chain not only slow down migration efforts but also create long-term security and operational risks.
Let’s take an example of how hardware limitations can affect cryptographic adoption. Falcon uses a trapdoor sampler based on the Fast Fourier Transformation to generate signatures. It offers very small keys and fast verification, but its signing process is much slower compared to Dilithium or traditional ECDSA. This is because Falcon requires 53-bit floating-point precision, while most embedded devices only support 32-bit floats. To compensate, higher precision must be emulated in software, which makes signing operations significantly slower.
Best Practices to mitigate challenges
The following best practices can help organizations design and maintain hardware systems that are both secure and adaptable over time:
| Best Practice | Technical Approach | Why It Matters |
|---|---|---|
| Adopt Upgradable Hardware-Assisted Cryptography | Use hardware that supports firmware-level updates for cryptographic algorithms. This may involve FPGA-based designs, programmable HSMs, or modular crypto accelerators with secure update channels. | Allows algorithm changes (e.g., migrating from RSA/ECC to post-quantum algorithms) without replacing the entire device, reducing downtime and costs. |
| Secure Host-Module Communications | Implement cryptographically bound communication channels (e.g., mutual TLS, message authentication codes, or digitally signed command sequences) between the host system and the external crypto module. | Prevents man-in-the-middle or command injection attacks that could compromise sensitive operations or keys. |
| Enable Modular Architecture for Algorithm and Key Updates | Design systems so that cryptographic components are detachable or replaceable (e.g., using PCIe crypto cards or removable secure elements). | Allows easy hardware refresh cycles without impacting the rest of the OT system, extending system lifespan and supporting crypto-agility. |
| Implement Strong Firmware Integrity Verification | Require firmware updates to be signed with a trusted vendor key and verify signatures within the hardware module before execution. | Ensures only authenticated and approved updates are applied, preventing malicious firmware injection. |
| Plan for Hybrid Algorithm Support | Select hardware that can run multiple algorithms in parallel (e.g., classical and post-quantum) during a migration phase. | Minimizes operational disruption and ensures continuous interoperability during cryptographic transitions. |
By following these best practices, OT operators can build cryptographic systems where hardware is not a limiting factor but an enabler for long-term security. Instead of facing costly and disruptive replacements when algorithms become obsolete, organizations can transition smoothly to newer, stronger cryptographic standards while maintaining operational uptime and compliance.
How can Encryption Consulting Help?
At Encryption Consulting, we help organizations identify hardware-related bottlenecks that could limit their ability to adapt to post-quantum algorithms.
Our process starts by assessing your organization’s current encryption environment and validating the scope of your PQC implementation to ensure it aligns with industry best practices. This initial step helps establish a solid foundation for a secure and efficient transition. Based on this assessment, we develop a strategy and roadmap tailored to the organization’s operational and compliance requirements. As part of this process, we conduct in-depth evaluations of your on-premises, cloud, and SaaS environments and integrate crypto-agile strategies, ensuring a smooth shift to quantum-safe encryption.
We also work with clients to design crypto-agile architectures that make their transition to new cryptographic standards smooth and future-ready. We assist in developing a Cryptographic Bill of Materials (CBOM) to provide a clear inventory of cryptographic assets and support algorithm transitions. The CBOM helps identify vulnerabilities, maintain transparency, and prepare for future risks. We also assist with testing and validation to ensure systems are ready for evolving cryptographic needs.
You can reach out to us at [email protected] to discuss how we can help strengthen your crypto-agility journey.
Conclusion
Achieving crypto-agility is not just about updating software when a new algorithm appears. The bigger challenge lies in building systems that are flexible and adaptable from the start. Organizations should focus on designing solutions that can support new cryptographic methods with minimal disruption to existing operations. This approach not only makes it easier to add post-quantum algorithms but also enables a faster and more effective response to emerging security threats.
In addition, crypto-agility requires maintaining clear policies, strong governance, and a well-documented inventory of all cryptographic assets in use. Continuous monitoring helps detect outdated or weak algorithms before they become a risk. Training development and security teams to work with algorithm-agnostic frameworks ensures that changes can be implemented seamlessly.
